Option 8 — Required Signers#

The Code Signing Trust Problem#

Standard Authenticode code-signing certificates (OV — Organization Validation) can be obtained with relatively minimal identity verification. This has historically led to malware authors obtaining legitimate certificates to sign malicious code, which then passes standard WDAC signer-rule checks. Several high-profile supply chain attacks have leveraged legitimately signed but malicious binaries.

Extended Validation (EV) certificates address this problem through:

1. CA/Browser Forum (CABF) EV Guidelines compliance — issuers must follow strict procedures
2. Physical organization verification — the CA must confirm the organization’s legal existence and physical location
3. Phone/postal verification — direct human contact required for issuance
4. Annual or biennial revetting — identity is periodically re-confirmed
5. Dedicated hardware tokens — EV private keys often must be stored in HSMs, reducing theft risk

When Option 8 is eventually implemented, it would allow security teams to require not just any valid Authenticode signature but specifically an EV-grade signature, dramatically raising the bar for attackers to produce policy-compliant signed malware.

Why “Required” Prefix#

The “Required:” prefix in the option name means the condition is mandatory — no code without an EV signature would pass, not even code signed with a standard OV certificate. This is the strictest possible signer quality gate.

EV vs OV vs DV in Context#

graph TD
    DV["DV Certificate\nDomain Validation\nLowest assurance\nFast issuance"]
    OV["OV Certificate\nOrganization Validation\nMedium assurance\n1-3 days issuance"]
    EV["EV Certificate\nExtended Validation\nHighest assurance\n1-2 weeks + verification"]
    WDAC_STD["Standard WDAC\nSigner Rule\n(accepts OV+)"]
    WDAC_EV["Option 8: Required:EV Signers\n(EV only — future)"]

    DV --> OV --> EV
    WDAC_STD --> |"passes"| DV
    WDAC_STD --> |"passes"| OV
    WDAC_STD --> |"passes"| EV
    WDAC_EV --> |"rejects"| DV
    WDAC_EV --> |"rejects"| OV
    WDAC_EV --> |"passes ONLY"| EV

    style DV fill:#1f0d0d,color:#fca5a5
    style OV fill:#1a1a0d,color:#fde68a
    style EV fill:#0d1f12,color:#86efac
    style WDAC_STD fill:#162032,color:#58a6ff
    style WDAC_EV fill:#1c1c2e,color:#a5b4fc

EV Certificate OID Structure (Reference)#

graph LR
    ROOT[Root CA Certificate] --> INT[Intermediate CA]
    INT --> EV_CERT[EV Code Signing Cert]
    EV_CERT --> OID1["OID: 2.23.140.1.3\nCode Signing — EV"]
    EV_CERT --> OID2["OID: 1.3.6.1.5.5.7.3.3\nCode Signing EKU"]
    EV_CERT --> ORG["Organization: Verified\nCABF EV Guidelines\ncompliant"]

    style ROOT fill:#162032,color:#58a6ff
    style INT fill:#162032,color:#58a6ff
    style EV_CERT fill:#0d1f12,color:#86efac
    style OID1 fill:#0d1f12,color:#86efac
    style OID2 fill:#0d1f12,color:#86efac
    style ORG fill:#0d1f12,color:#86efac

Enable Option 8#

1
# Set Option 8 on a base policy
2
# Note: No runtime effect on current Windows releases
3
Set-RuleOption -FilePath "C:\Policies\MyBasePolicy.xml" -Option 8

Remove Option 8#

1
Remove-RuleOption -FilePath "C:\Policies\MyBasePolicy.xml" -Option 8

Check EV Certificate Status of a Signed Binary#

While Option 8 is not yet enforced by WDAC, you can manually verify whether a binary is EV-signed using:

1
function Test-EVSignature {
2
    param([string]$BinaryPath)
3

4
    $sig = Get-AuthenticodeSignature -FilePath $BinaryPath
5
    if ($sig.Status -ne "Valid") {
6
        Write-Host "NOT SIGNED or invalid signature: $BinaryPath" -ForegroundColor Red
7
        return
8
    }
9

10
    $cert = $sig.SignerCertificate
11
    $chain = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Chain
12
    $chain.Build($cert) | Out-Null
13

14
    # Check for EV OID in certificate policies extension
15
    $evOid = "2.23.140.1.3"
16
    $isEV = $false
17

18
    foreach ($element in $chain.ChainElements) {
19
        foreach ($ext in $element.Certificate.Extensions) {
20
            if ($ext.Oid.Value -eq "2.5.29.32") {  # Certificate Policies OID
21
                if ($ext.Format($false) -like "*$evOid*") {
22
                    $isEV = $true
23
                    break
24
                }
25
            }
26
        }
27
        if ($isEV) { break }
28
    }
29

30
    Write-Host "Binary: $BinaryPath"
31
    Write-Host "Signer: $($cert.Subject)"
32
    Write-Host "EV Certificate: $(if ($isEV) { 'YES — EV grade' } else { 'NO — OV or lower' })" `
33
        -ForegroundColor $(if ($isEV) { 'Green' } else { 'Yellow' })
34
}
35

36
# Usage
37
Test-EVSignature -BinaryPath "C:\Windows\System32\notepad.exe"
38
Test-EVSignature -BinaryPath "C:\Program Files\MyApp\myapp.exe"

Audit Existing Policy File for EV Readiness#

1
# Check if a policy has Option 8 set
2
function Test-PolicyEVOption {
3
    param([string]$PolicyPath)
4
    [xml]$pol = Get-Content $PolicyPath
5
    $opts = $pol.SiPolicy.Rules.Rule | Select-Object -ExpandProperty Option
6
    $isEVRequired = $opts -contains "Required:EV Signers"
7

8
    Write-Host "Policy: $(Split-Path $PolicyPath -Leaf)"
9
    Write-Host "Option 8 (EV Signers): $(if ($isEVRequired) {'REQUIRED (no-op today)'} else {'NOT SET'})" `
10
        -ForegroundColor $(if ($isEVRequired) {'Yellow'} else {'Gray'})
11

12
    # Warn about supplemental policy incompatibility
13
    $policyType = $pol.SiPolicy.PolicyType
14
    if ($isEVRequired -and $policyType -eq "Supplemental Policy") {
15
        Write-Warning "Option 8 is NOT valid for supplemental policies. Remove it."
16
    }
17
}

Option 8 Present in Base Policy#

1
<?xml version="1.0" encoding="utf-8"?>
2
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy"
3
          PolicyType="Base Policy">
4

5
  <VersionEx>10.0.0.0</VersionEx>
6
  <PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
7

8
  <Rules>
9
    <Rule>
10
      <Option>Enabled:Unsigned System Integrity Policy</Option>
11
    </Rule>
12
    <!-- Option 8: Reserved — will require EV code-signing certificates
13
         when implemented. Currently has no runtime enforcement effect. -->
14
    <Rule>
15
      <Option>Required:EV Signers</Option>
16
    </Rule>
17
  </Rules>
18

19

20
  <!--
21
    When Option 8 is implemented, signers listed here will need to be
22
    EV-grade certificates (carrying OID 2.23.140.1.3 in their policy chain).
23
    Non-EV signers in the policy may generate policy compilation warnings.
24
  -->
25

26
</SiPolicy>

Invalid: Option 8 in Supplemental Policy#

1
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy"
2
          PolicyType="Supplemental Policy">
3
  <Rules>
4
    <Rule>
5
      <Option>Required:EV Signers</Option>
6
    </Rule>
7
  </Rules>
8
</SiPolicy>

When attempting to compile a supplemental policy with Option 8, future OS versions may reject the policy or throw a compilation error. Current OS versions will silently ignore it.

Bitmask Position#

Option 8 occupies bit position 8 in the 32-bit option flags field: 0x00000100.

Interaction Table#

Why Not Valid for Supplemental Policies?#

The “Required Signers” option sets a system-wide trust floor. This kind of foundational trust requirement must come from the base policy, which governs the overall security posture of the device. A supplemental policy is an extension mechanism — allowing supplementals to set EV requirements would create ordering dependencies and potential conflicts between competing supplemental policies. By restricting Option 8 to base policies only, WDAC ensures a single authoritative trust tier definition.

Scenario: Financial Institution Prepares for Maximum-Assurance Code Signing#

A tier-1 bank’s CISO mandates that all internally deployed code must eventually be signed with EV certificates to satisfy a new cyber-risk framework. The security team begins preparing policy infrastructure before the OS feature ships.

sequenceDiagram
    actor CISO
    actor SecEng as Security Engineer
    participant CA as DigiCert EV CA
    participant DEV as Dev Teams
    participant WDAC as ConfigCI
    participant PILOT as Pilot Machines (50)
    participant PROD as Production Fleet (5000)

    Note over CISO,PROD: Phase 1 — Assessment

    CISO->>SecEng: "All internal code must be EV-signed within 6 months"
    SecEng->>DEV: Audit all internally signed binaries
    DEV->>SecEng: Inventory: 47 internal applications, 12 currently EV-signed

    Note over CISO,PROD: Phase 2 — Certificate Procurement

    SecEng->>CA: Request 5 EV code-signing certificates
    CA->>CA: Organization identity verification (14 days)
    CA->>SecEng: 5 EV certs issued, keys in HSMs
    DEV->>DEV: Re-sign all 47 applications with EV certificates

    Note over CISO,PROD: Phase 3 — Policy Preparation

    SecEng->>WDAC: Set-RuleOption -Option 8 (base policies)
    WDAC->>SecEng: Option 8 added (no runtime effect on current OS)
    SecEng->>WDAC: Verify option is NOT on any supplemental policies
    WDAC->>SecEng: Confirmed — Option 8 only on base policies

    SecEng->>PILOT: Deploy updated base policies to pilot
    PILOT->>PILOT: OS parses Option 8 — no action (current build)
    PILOT->>SecEng: No unexpected blocks — all EV-signed apps run

    Note over CISO,PROD: Phase 4 — Future OS Activation

    PROD->>PROD: Windows major update ships Option 8 handler
    PROD->>PROD: Base policies already have Option 8 set
    PROD->>PROD: EV enforcement activates automatically
    PROD->>DEV: Any OV-signed code now blocked (Event 3077)
    DEV->>SecEng: Alert: legacy OV-signed utility blocked
    SecEng->>DEV: "Expected — sign with EV cert per policy"
    DEV->>DEV: Re-sign with EV cert
    SecEng->>WDAC: Add hash rule for interim coverage
    WDAC->>PROD: Hash rule deployed — utility runs while re-signing in progress

EV Certificate Procurement Timeline#

gantt
    title EV Code Signing Certificate Lifecycle
    dateFormat  YYYY-MM-DD
    section Procurement
    Request submission          :a1, 2026-05-01, 2d
    CA identity verification    :a2, after a1, 14d
    Certificate issuance        :a3, after a2, 1d
    HSM key installation        :a4, after a3, 2d
    section Usage
    Initial code signing        :b1, after a4, 30d
    Annual re-vetting           :b2, 2027-06-01, 7d
    Certificate renewal         :b3, 2028-05-01, 7d

Current (No-Op Era) — Minimal Risk#

The only risk today is administrative confusion: setting Option 8 on a supplemental policy violates the schema spec even though the OS currently ignores it. If a future OS update validates this constraint during policy load, the supplemental policy may fail to load.

Scenario A: Option 8 on Supplemental Policy (Invalid)#

flowchart TD
    MISTAKE[Set Option 8\non supplemental policy]
    DEPLOY[Deploy to devices]
    TODAY{Current OS?}
    FUTURE{Future OS with\nOption 8 validation?}

    MISTAKE --> DEPLOY
    DEPLOY --> TODAY
    TODAY -- "Yes" --> SILENT[Silently ignored\nPolicy loads fine today]
    TODAY -- "No\n(future)" --> FUTURE
    FUTURE -- "Yes" --> REJECTED["Supplemental policy\nREJECTED at load time\nApps it was supposed\nto allow are now BLOCKED"]

    style MISTAKE fill:#1f0d0d,color:#fca5a5
    style DEPLOY fill:#1a1a0d,color:#fde68a
    style TODAY fill:#1a1a0d,color:#fde68a
    style FUTURE fill:#1a1a0d,color:#fde68a
    style SILENT fill:#0d1f12,color:#86efac
    style REJECTED fill:#1f0d0d,color:#fca5a5

Scenario B: Enable Option 8 (When Implemented) Without EV-Signing All Code#

If Option 8 becomes active and your environment has OV-signed code:

• Every OV-signed binary triggers a block (Event 3077)
• Includes third-party software that uses OV certs (likely most commercial software)
• Potential system instability if critical system tools are blocked

Risk Matrix#

Recommendation: If you set Option 8 proactively, also maintain an OV-signed binary inventory so that when the feature activates, you have a clear remediation plan.

Why This Restriction Exists#

EV signer requirements establish a minimum trust bar for all code on the system. This is a foundational security invariant that must be set at the base policy level, not selectively applied by extensions. If supplemental policies could set EV requirements, conflicts would arise:

• Supplemental A: EV required for path X
• Supplemental B: No EV required for path X
• Result: Undefined behavior — race condition on policy merge

By reserving Option 8 for base policies only, WDAC ensures a single, authoritative, non-conflicting EV requirement definition.

Enforcement of This Restriction#

Currently (no runtime effect): The restriction is not enforced — a supplemental with Option 8 will load fine. This is expected to change when Option 8 is implemented.

Future enforcement will likely throw an error code similar to HRESULT: 0xC0E90003 (policy configuration error) when loading a supplemental with invalid options.

EV Certificate Standards Reference#