WDAC File Rule Level: RootCertificate#

CRITICAL: The RootCertificate level is NOT SUPPORTED in App Control for Business (WDAC). This document explains why, what happens if you try to use it, and what you should use instead.

Table of Contents#

Overview
Why RootCertificate Is Not Supported
The Trust Surface Explosion Problem
Certificate Chain Anatomy
Where in the Evaluation Stack
What Happens If You Try It
XML Representation (Attempted vs. Correct)
PowerShell Examples
The Correct Alternative: PcaCertificate
Pros & Cons Table
Attack Resistance Analysis
When to Use vs. When to Avoid — Decision Flowchart
Real-World Scenario: End-to-End Sequence
OS Version & Compatibility
Common Mistakes & Gotchas
Historical Context
Summary Table

1. Overview#

App Control for Business (the successor to Windows Defender Application Control, still internally called WDAC) uses a tiered system of file rule levels to determine how broadly or narrowly a policy trusts signed binaries. These levels range from highly specific (Hash) to broadly generalized certificate-based trust.

RootCertificate sits conceptually at the very top of the certificate trust chain — it represents the self-signed root CA that anchors an entire PKI hierarchy. In most PKI models, trusting the root means trusting every single certificate ever issued under it, including intermediate CAs and every leaf certificate they sign.

This is precisely why RootCertificate is explicitly excluded from WDAC’s supported rule levels.

The supported rule levels in App Control for Business, from broadest to most specific, are:

Level	Description
PCACertificate	Intermediate (PCA) CA cert — the level just below root
Publisher	Leaf cert CN + PCA combined
FilePublisher	Publisher + file name + minimum version
SignedVersion	Publisher + minimum version (no filename)
PcaCertificate	Same as PCACertificate (alias)
RootCertificate	NOT SUPPORTED
WHQL	Windows Hardware Quality Lab EKU
WHQLPublisher	WHQL EKU + leaf CN
WHQLFilePublisher	WHQL EKU + leaf CN + filename + version
FileName	File’s internal OriginalFileName attribute
FilePath	Specific file path on disk
Hash	Cryptographic hash of file contents

Notice that RootCertificate appears in the conceptual hierarchy but is marked NOT SUPPORTED. If you attempt to generate rules at this level, WDAC tooling will either refuse or fall back silently to a different level.

2. Why RootCertificate Is Not Supported#

The Core Problem: Catastrophically Broad Trust#

A root CA certificate is the trust anchor for an entire certificate hierarchy. A single root CA may have signed dozens or hundreds of intermediate CAs. Each intermediate CA may have issued thousands of leaf certificates. Each leaf certificate may be used to sign hundreds of software binaries.

If WDAC allowed RootCertificate as a rule level, a single XML entry saying “trust Microsoft Root Certificate Authority 2010” would implicitly authorize every binary signed by:

Every Microsoft product team
Every third-party ISV that received a code-signing certificate from Microsoft’s PKI
Every driver vendor certified by WHQL
Every OEM that received an Authenticode certificate under the Microsoft hierarchy
Historical artifacts and legacy software signed years ago

This is equivalent to saying “allow anything that has ever been vouched for by Microsoft, in any context, for any purpose” — which completely defeats the purpose of application whitelisting.

The Specific Example: Microsoft Root CA#

Consider Microsoft’s own certificate hierarchy:

1
Microsoft Root Certificate Authority 2010
2
  └── Microsoft Code Signing PCA 2011
3
        ├── Microsoft Corporation (leaf — signs Windows binaries)
4
        ├── Microsoft Windows (leaf — signs OS components)
5
        └── [hundreds of other leaf certs]
6
  └── Microsoft Time-Stamp PCA 2011
7
  └── Microsoft Azure TLS Issuing CA 01-08
8
  └── [dozens of other intermediate CAs]

Trusting the root would allow ALL of these. There is no mechanism to say “trust the root, but only for binaries from this one product team.” The granularity simply does not exist at the root level.

The Contoso Example#

Suppose your organization uses an internal CA called “Contoso Root CA” to sign internal software. You want WDAC to allow all Contoso-signed software. A naive approach might be:

“I’ll create a RootCertificate rule for Contoso Root CA.”

The problem: “Contoso Root CA” likely signs:

Internal application A
Internal application B
VPN client certificates
Email S/MIME certificates
Web server TLS certificates
Contractor laptop certificates

Trusting the root allows anyone with any Contoso-issued certificate — including a contractor who received a personal auth certificate — to run arbitrary signed binaries. The correct approach is to trust the specific intermediate CA used only for code signing, not the root.

3. The Trust Surface Explosion Problem#

1
graph TD
2
    ROOT["Microsoft Root CA 2010\n(Self-Signed)"]:::root
3

4
    PCA1["Microsoft Code Signing PCA 2011"]:::pca
5
    PCA2["Microsoft Time-Stamp PCA 2011"]:::pca
6
    PCA3["Microsoft Azure TLS Issuing CA"]:::pca
7
    PCA4["Microsoft Windows Hardware Compatibility PCA"]:::pca
8

9
    LEAF1["Microsoft Corporation\n(Authenticode)"]:::leaf
10
    LEAF2["Microsoft Windows\n(OS Signing)"]:::leaf
11
    LEAF3["NVIDIA Corporation\n(WHQL Driver Signing)"]:::leaf
12
    LEAF4["Intel Corporation\n(WHQL Driver Signing)"]:::leaf
13
    LEAF5["Adobe Systems\n(3rd party ISV)"]:::leaf
14

15
    FILE1["calc.exe"]:::file
16
    FILE2["notepad.exe"]:::file
17
    FILE3["nvlddmkm.sys"]:::file
18
    FILE4["e1d68x64.sys"]:::file
19
    FILE5["AcroRd32.exe"]:::file
20

21
    TRUST_SURFACE["EVERYTHING ABOVE IS ALLOWED\nif RootCertificate rule exists\nfor Microsoft Root CA 2010\n\nThis is thousands of binaries\nfrom hundreds of publishers"]:::danger
22

23
    ROOT --> PCA1
24
    ROOT --> PCA2
25
    ROOT --> PCA3
26
    ROOT --> PCA4
27
    PCA1 --> LEAF1
28
    PCA1 --> LEAF2
29
    PCA1 --> LEAF3
30
    PCA1 --> LEAF4
31
    PCA1 --> LEAF5
32
    LEAF1 --> FILE1
33
    LEAF2 --> FILE2
34
    LEAF3 --> FILE3
35
    LEAF4 --> FILE4
36
    LEAF5 --> FILE5
37
    FILE1 & FILE2 & FILE3 & FILE4 & FILE5 --> TRUST_SURFACE
38

39
    classDef root fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
40
    classDef pca fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
41
    classDef leaf fill:#162032,stroke:#1e3a5f,color:#e2e8f0
42
    classDef file fill:#162032,stroke:#1e3a5f,color:#e2e8f0
43
    classDef danger fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5

This diagram illustrates why root-level trust is unworkable: a single rule at the root exposes the entire downstream subtree of certificates and files. WDAC’s designers explicitly rejected this model.

4. Certificate Chain Anatomy#

Understanding why root-level trust is dangerous requires understanding the full certificate chain and what each level represents in WDAC.

1
graph TB
2
    subgraph "Certificate Chain (Top to Bottom)"
3
        R["Root CA Certificate\n(Self-Signed, air-gapped HSM)\nThumbprint: A4341..."]:::root
4
        I1["Intermediate CA (PCA)\nIssued by Root CA\nPurpose: Code Signing\nThumbprint: B2291..."]:::pca
5
        I2["(Optional) Sub-Intermediate\nIssued by PCA\nThumbprint: C3371..."]:::pca
6
        L["Leaf Certificate\nIssued to: Vendor Name\nCN=NVIDIA Corporation\nThumbprint: D4481..."]:::leaf
7
        F["Binary File\nnvlddmkm.sys\nSigned by Leaf Cert\nContains embedded signature"]:::file
8
    end
9

10
    subgraph "WDAC Rule Levels (What Each Maps To)"
11
        RL["RootCertificate\n[NOT SUPPORTED]\nWould match Thumbprint A4341..."]:::danger
12
        PL["PcaCertificate\n[SUPPORTED — Broadest Allowed]\nMatches Thumbprint B2291..."]:::warn
13
        PUB["Publisher\n[SUPPORTED]\nMatches B2291... + CN=NVIDIA Corporation"]:::ok
14
        FP["FilePublisher\n[SUPPORTED — Most Specific]\nMatches B2291... + CN + nvlddmkm.sys + v1.0+"]:::ok
15
    end
16

17
    R --> I1
18
    I1 --> I2
19
    I2 --> L
20
    L --> F
21

22
    R -.->|"Would match"| RL
23
    I1 -.->|"Matches"| PL
24
    L -.->|"Contributes to"| PUB
25
    F -.->|"Contributes to"| FP
26

27
    classDef root fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
28
    classDef pca fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
29
    classDef leaf fill:#162032,stroke:#1e3a5f,color:#e2e8f0
30
    classDef file fill:#162032,stroke:#1e3a5f,color:#e2e8f0
31
    classDef danger fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
32
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
33
    classDef ok fill:#0d1f12,stroke:#1a5c2a,color:#86efac

Key insight: WDAC deliberately skips the root level and starts at the PCA (intermediate) level as the broadest permitted trust anchor. This forces policy authors to make a conscious decision about which intermediate CA they trust, rather than blindly inheriting everything from a root.

5. Where in the Evaluation Stack#

When WDAC evaluates a file, ci.dll (the Code Integrity kernel component) walks through the policy rules in a specific order. Even if RootCertificate were supported, understanding where it would fall helps clarify why it is rejected.

1
flowchart TD
2
    START(["File Execution Requested"]):::node
3
    HASH_CHECK{"Hash rule\nexists for this file?"}:::node
4
    HASH_ALLOW(["ALLOW — Hash match"]):::allow
5
    LEAF_CHECK{"Leaf cert rule\nexists? (Publisher/\nFilePublisher)"}:::node
6
    LEAF_ALLOW(["ALLOW — Publisher match"]):::allow
7
    PCA_CHECK{"PcaCertificate rule\nexists for signer\nchain?"}:::node
8
    PCA_ALLOW(["ALLOW — PcaCertificate match"]):::allow
9
    ROOT_CHECK{"RootCertificate rule\nexists?"}:::warn
10
    ROOT_SKIP(["SKIPPED — Not evaluated\nci.dll ignores this level\nRule has no effect"]):::block
11
    DEFAULT{"Default action\nin policy?"}:::node
12
    BLOCK(["BLOCK — Execution denied"]):::block
13
    ALLOW_ALL(["ALLOW — Default allow\n(Audit-only mode)"]):::allow
14

15
    START --> HASH_CHECK
16
    HASH_CHECK -->|"Yes"| HASH_ALLOW
17
    HASH_CHECK -->|"No"| LEAF_CHECK
18
    LEAF_CHECK -->|"Yes"| LEAF_ALLOW
19
    LEAF_CHECK -->|"No"| PCA_CHECK
20
    PCA_CHECK -->|"Yes"| PCA_ALLOW
21
    PCA_CHECK -->|"No"| ROOT_CHECK
22
    ROOT_CHECK -->|"RootCert rule found"| ROOT_SKIP
23
    ROOT_SKIP --> DEFAULT
24
    ROOT_CHECK -->|"No rule"| DEFAULT
25
    DEFAULT -->|"DefaultDeny"| BLOCK
26
    DEFAULT -->|"DefaultAllow/Audit"| ALLOW_ALL
27

28
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0
29
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
30
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
31
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

The evaluation engine simply does not have a code path that validates RootCertificate rules. If such a rule were somehow injected into a compiled policy binary, the kernel-mode Code Integrity (CI) component would either fail to parse it or silently skip it during rule evaluation. The file would then fall through to the default action.

6. What Happens If You Try It#

Attempting with PowerShell#

If you run:

1
New-CIPolicy -ScanPath "C:\Windows\System32" -Level RootCertificate -FilePath ".\test-policy.xml"

The WDAC tooling (ConfigCI module) will silently fall back to PcaCertificate and generate rules at that level instead. The output XML will contain <Signer> elements referencing the intermediate CA, not the root. There is no error message. The tooling simply treats RootCertificate as an invalid level and promotes the rules to the nearest supported level.

Attempting with Direct XML Authoring#

If you manually craft XML with a <Signer> element that references a root certificate’s thumbprint and add it to a WDAC policy, the following occurs:

The policy compiles (no compile-time error)
When deployed, ci.dll evaluates the rule
The rule does not match files, because the matching algorithm for signer rules compares against intermediate CA certificates, not root certificates
The binary fails to match the malformed rule
The binary falls through to the default action (typically deny in production policies)
The file is blocked — the opposite of what was intended

This is a dangerous silent failure mode. Policy authors who craft such rules will believe they have allowed a set of files, but those files will actually be blocked. This can cause system instability or application failures.

7. XML Representation (Attempted vs. Correct)#

Incorrect Approach (Root Level — Do NOT Use)#

1
<Signer ID="ID_SIGNER_ROOT_EXAMPLE" Name="Microsoft Root Certificate Authority 2010">
2
  <CertRoot Type="TBS" Value="D8C5388AB7301B1BB6A09FE8097E4DE9C1A3C1E7..." />
3
</Signer>

Correct Approach (PCA Level — Use This)#

1
<Signer ID="ID_SIGNER_MSFT_PCA" Name="Microsoft Code Signing PCA 2011">
2
  <CertRoot Type="TBS" Value="F252E794FE438E35ACE6E53762C0A234A2C52135" />
3
</Signer>
4

5
<ProductSigners>
6
  <AllowedSigner SignerID="ID_SIGNER_MSFT_PCA" />
7
</ProductSigners>

The TBS (To-Be-Signed) Hash#

WDAC uses the TBS (To-Be-Signed) hash of the certificate, not the full certificate thumbprint. The TBS hash covers the subject, public key, validity period, and extensions — the actual content that was signed by the issuing CA — but excludes the issuing CA’s signature itself. This makes it stable across certificate renewals that preserve the same key and subject.

To compute the TBS hash for a certificate:

1
# Get the TBS hash of a certificate from a signed file
2
$cert = (Get-AuthenticodeSignature "C:\Windows\System32\ntoskrnl.exe").SignerCertificate
3

4
# Walk the chain to find the intermediate CA
5
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
6
$chain.Build($cert) | Out-Null
7
$intermediateCert = $chain.ChainElements[1].Certificate  # Index 1 = intermediate, 0 = leaf, 2 = root
8

9
# Display the TBS hash (used in WDAC XML)
10
$intermediateCert.GetRawCertData() | ForEach-Object { [System.BitConverter]::ToString($_).Replace("-","") }

8. PowerShell Examples#

Scanning and Generating Rules (Correct Level)#

1
# Generate a policy using PcaCertificate level (the correct alternative to RootCertificate)
2
# This creates Signer rules for intermediate CAs — not root CAs
3
New-CIPolicy `
4
    -ScanPath "C:\Program Files\MyApp\" `
5
    -Level PcaCertificate `
6
    -Fallback Hash `
7
    -FilePath "C:\Policies\MyApp-PCA-Policy.xml" `
8
    -UserPEs
9

10
# Output: Signer elements referencing intermediate CA certs, Hash rules for unsigned files

1
# What happens if you accidentally specify RootCertificate:
2
New-CIPolicy `
3
    -ScanPath "C:\Program Files\MyApp\" `
4
    -Level RootCertificate `       # <-- Unsupported
5
    -Fallback Hash `
6
    -FilePath "C:\Policies\test.xml"
7

8
# Result: WDAC tooling silently promotes to PcaCertificate level
9
# The output XML will contain intermediate CA signers, not root CA signers
10
# No error is raised — this is a silent behavior change

Inspecting the Certificate Chain of a Signed File#

1
function Get-WDACSignerInfo {
2
    param([string]$FilePath)
3

4
    $sig = Get-AuthenticodeSignature -FilePath $FilePath
5
    if ($sig.Status -ne "Valid") {
6
        Write-Warning "File is not validly signed: $FilePath"
7
        return
8
    }
9

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

13
    $elements = $chain.ChainElements
14
    Write-Host "Chain for: $FilePath" -ForegroundColor Cyan
15
    Write-Host ""
16

17
    for ($i = $elements.Count - 1; $i -ge 0; $i--) {
18
        $cert = $elements[$i].Certificate
19
        $level = switch ($i) {
20
            { $_ -eq ($elements.Count - 1) } { "ROOT (Not used in WDAC rules)" }
21
            0                                 { "LEAF (Used in Publisher/FilePublisher)" }
22
            default                           { "INTERMEDIATE/PCA (Used in PcaCertificate rules)" }
23
        }
24
        Write-Host "[$level]" -ForegroundColor $(if ($i -eq ($elements.Count - 1)) { "Red" } elseif ($i -eq 0) { "Green" } else { "Yellow" })
25
        Write-Host "  Subject: $($cert.Subject)"
26
        Write-Host "  Thumbprint: $($cert.Thumbprint)"
27
        Write-Host ""
28
    }
29
}
30

31
# Example usage:
32
Get-WDACSignerInfo -FilePath "C:\Windows\System32\ntoskrnl.exe"

Verifying That a Policy Has No Root-Level Rules#

1
function Test-WDACPolicyForRootRules {
2
    param([string]$PolicyXmlPath)
3

4
    [xml]$policy = Get-Content -Path $PolicyXmlPath
5
    $ns = @{ si = "urn:schemas-microsoft-com:sipolicy" }
6

7
    $signers = $policy.SelectNodes("//si:Signer",
8
        ([System.Xml.XmlNamespaceManager]::new([xml]$policy | Select-Object -ExpandProperty NameTable)))
9

10
    # Root CA certs are typically self-signed (Subject == Issuer)
11
    # In practice, check if any signer thumbprint matches known root CA thumbprints
12
    # This is a heuristic — proper validation requires checking the actual cert
13
    Write-Host "Policy: $PolicyXmlPath"
14
    Write-Host "Signer count: $($signers.Count)"
15
    Write-Host ""
16
    Write-Host "Note: WDAC does not support RootCertificate level rules." -ForegroundColor Yellow
17
    Write-Host "All signers in this policy should reference intermediate CA (PCA) certificates." -ForegroundColor Yellow
18
    Write-Host "If any signer references a self-signed root CA, it will be silently ignored." -ForegroundColor Red
19
}

9. The Correct Alternative: PcaCertificate#

The PcaCertificate level trusts binaries whose certificate chain contains a specific intermediate CA (PCA) certificate. This is:

Broad enough to cover all software signed by a CA’s leaf certs
Specific enough to exclude unrelated certificate hierarchies
The exact security boundary that WDAC’s designers intended

1
graph TD
2
    subgraph "PcaCertificate — Correct Scoping"
3
        ROOT2["Microsoft Root CA 2010\n(NOT in WDAC rule)"]:::root
4
        PCA_A["Microsoft Code Signing PCA 2011\n← WDAC rule anchors HERE\nTrusted scope: all files signed\nunder this specific PCA"]:::pca_trusted
5
        PCA_B["Microsoft Time-Stamp PCA 2011\n← NOT in WDAC rule\nTimestamping only — not code"]:::pca_untrusted
6
        PCA_C["Microsoft Azure TLS CA\n← NOT in WDAC rule\nTLS/Web — not code signing"]:::pca_untrusted
7

8
        LEAF_OK1["Microsoft Corporation\n(Allowed via PCA_A rule)"]:::allow
9
        LEAF_OK2["Windows Components\n(Allowed via PCA_A rule)"]:::allow
10
        LEAF_NO1["Azure CDN Service\n(Blocked — not under PCA_A)"]:::block
11
        LEAF_NO2["Timestamp Service\n(Blocked — not under PCA_A)"]:::block
12
    end
13

14
    ROOT2 --> PCA_A
15
    ROOT2 --> PCA_B
16
    ROOT2 --> PCA_C
17
    PCA_A --> LEAF_OK1
18
    PCA_A --> LEAF_OK2
19
    PCA_B --> LEAF_NO1
20
    PCA_C --> LEAF_NO2
21

22
    classDef root fill:#162032,stroke:#1e3a5f,color:#e2e8f0
23
    classDef pca_trusted fill:#0d1f12,stroke:#1a5c2a,color:#86efac
24
    classDef pca_untrusted fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
25
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
26
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5

When to Choose Which PCA#

Scenario	Correct PCA to Trust
Allow all Windows OS binaries	Microsoft Windows PCA 2011
Allow all Microsoft signed applications	Microsoft Code Signing PCA 2011
Allow WHQL-certified drivers	Use WHQL level instead (EKU-based)
Allow internal Contoso apps	Contoso Code Signing Intermediate CA
Allow specific vendor software	Vendor’s code-signing intermediate CA

The key principle: identify the specific intermediate CA used for code signing — not the root — and trust that. This limits scope to software that specifically went through that CA’s issuance process.

10. Pros & Cons Table#

Note: Since RootCertificate is not supported, this table compares the conceptual RootCertificate level against the recommended PcaCertificate level.

Attribute	RootCertificate (Conceptual)	PcaCertificate (Recommended)
Supported in WDAC	No — not supported	Yes — fully supported
Trust scope	Entire PKI tree from root down	Only subtree under specific intermediate CA
Security risk	Catastrophically broad	Manageable — bounded by CA purpose
Maintenance burden	Low (set once, forget)	Low (intermediate CAs rarely change)
False positive risk	Extreme — allows unrelated certs	Low — focused on code-signing CA
Attack surface	Any cert from the root hierarchy	Only certs from the specific intermediate
WDAC tooling support	None — silently falls back to PCA	Full support in ConfigCI PowerShell
XML authoring	Broken — ci.dll ignores it	Correct — matches expected Signer format
Practical equivalent	n/a	The correct choice for broad CA trust

11. Attack Resistance Analysis#

1
graph TD
2
    subgraph "Attack Scenario A: Compromised Intermediate CA"
3
        ATK_A["Attacker obtains leaf cert\nfrom a DIFFERENT intermediate CA\nunder the same root"]:::block
4
        CHECK_A{"Is the leaf cert under\nthe trusted PcaCertificate?"}:::node
5
        BLOCK_A(["BLOCKED — Different PCA\nPcaCertificate rule does not match"]):::block
6

7
        ATK_A --> CHECK_A
8
        CHECK_A -->|"No (different PCA)"| BLOCK_A
9
    end
10

11
    subgraph "Attack Scenario B: Stolen Leaf Certificate"
12
        ATK_B["Attacker steals a valid leaf cert\nfrom under the trusted PCA"]:::warn
13
        CHECK_B{"Leaf cert under\ntrusted PCA?"}:::node
14
        PASS_B(["ALLOWED — PcaCertificate matches\nThis is expected behavior\nMitigate with Publisher/FilePublisher levels"]):::warn
15

16
        ATK_B --> CHECK_B
17
        CHECK_B -->|"Yes"| PASS_B
18
    end
19

20
    subgraph "If RootCertificate Were Supported (Hypothetical)"
21
        ATK_C["Attacker gets ANY cert from\nany intermediate under the root"]:::block
22
        CHECK_C{"ANY cert under root?"}:::node
23
        ALLOW_C(["ALLOWED — Root rule matches\nNo way to limit to specific CA branch"]):::block
24

25
        ATK_C --> CHECK_C
26
        CHECK_C -->|"Yes (any)"| ALLOW_C
27
    end
28

29
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0
30
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
31
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
32
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

Key security insight: Even PcaCertificate is vulnerable to stolen leaf certs from under the trusted intermediate. This is why, for high-security environments, Publisher or FilePublisher levels (which also check the leaf cert’s CN) are preferred. RootCertificate would be strictly worse than all alternatives.

12. When to Use vs. When to Avoid — Decision Flowchart#

1
flowchart TD
2
    Q1["Goal: Trust all software\nsigned by a specific CA"]:::node
3
    Q2{"Is this a root CA\nor intermediate CA?"}:::node
4
    ROOT_ANS["It's a ROOT CA"]:::warn
5
    INT_ANS["It's an INTERMEDIATE CA"]:::node
6
    Q3{"How broad do you\nneed the trust to be?"}:::node
7

8
    USE_PCA(["Use PcaCertificate level\n— Trust all files from any\nleaf cert under this intermediate CA\n— Correct and supported"]):::allow
9
    USE_PUB(["Use Publisher level\n— Trust files from specific\nleaf CN under this PCA\n— More restrictive"]):::allow
10
    USE_FP(["Use FilePublisher level\n— Trust specific files from\nspecific leaf CN + version\n— Most restrictive"]):::allow
11

12
    ROOT_ADV["Find the code-signing\nINTERMEDIATE CA\n(not the root itself)"]:::warn
13
    ROOT_AVOID(["Do NOT use RootCertificate\n— Not supported in WDAC\n— Would be too broad even if it were"]):::block
14

15
    Q1 --> Q2
16
    Q2 -->|"Root CA"| ROOT_ANS
17
    Q2 -->|"Intermediate CA"| INT_ANS
18
    ROOT_ANS --> ROOT_AVOID
19
    ROOT_ANS --> ROOT_ADV
20
    ROOT_ADV --> USE_PCA
21
    INT_ANS --> Q3
22
    Q3 -->|"All files from CA"| USE_PCA
23
    Q3 -->|"Files from specific publisher"| USE_PUB
24
    Q3 -->|"Specific files + version"| USE_FP
25

26
    classDef node fill:#162032,stroke:#1e3a5f,color:#e2e8f0
27
    classDef allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
28
    classDef block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
29
    classDef warn fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

13. Real-World Scenario: End-to-End Sequence#

Scenario: An IT admin at Contoso wants to create a WDAC policy that allows all software signed by the company’s internal code-signing infrastructure. They initially try RootCertificate and discover why it fails, then implement the correct approach.

1
sequenceDiagram
2
    participant Admin as IT Admin
3
    participant PS as PowerShell (ConfigCI)
4
    participant XML as Policy XML
5
    participant CI as ci.dll (Kernel)
6
    participant File as Internal App (signed)
7

8
    Note over Admin,File: Phase 1 — Incorrect Attempt with RootCertificate
9

10
    Admin->>PS: New-CIPolicy -Level RootCertificate -ScanPath "C:\InternalApps"
11
    PS-->>Admin: [No error, but silently falls back to PcaCertificate level]
12
    PS->>XML: Creates Signer referencing intermediate CA (not root)
13
    Admin->>Admin: Examines XML, confused — expected root CA, sees intermediate
14

15
    Note over Admin,File: Phase 2 — Understanding the Correct Model
16

17
    Admin->>PS: Get-AuthenticodeSignature "C:\InternalApps\app.exe" | Select SignerCertificate
18
    PS-->>Admin: Returns leaf certificate info
19
    Admin->>PS: Walk chain to find intermediate CA
20
    PS-->>Admin: "Contoso Code Signing CA 2022" (intermediate, not root)
21
    Admin->>Admin: Understands: WDAC uses PcaCertificate (intermediate) level
22

23
    Note over Admin,File: Phase 3 — Correct Implementation
24

25
    Admin->>PS: New-CIPolicy -Level PcaCertificate -ScanPath "C:\InternalApps" -FilePath policy.xml
26
    PS->>XML: Creates correct Signer for "Contoso Code Signing CA 2022"
27
    Admin->>CI: Deploys compiled policy via MDM/Group Policy
28

29
    File->>CI: Requests execution (app.exe)
30
    CI->>CI: Validates cert chain of app.exe
31
    CI->>CI: Finds "Contoso Code Signing CA 2022" in chain
32
    CI->>CI: Matches against PcaCertificate Signer in policy
33
    CI-->>File: ALLOWED — chain matches trusted intermediate CA
34

35
    Note over Admin,File: Phase 4 — Confirming Root-Level Attempts Are Ineffective
36

37
    Admin->>XML: Manually adds Signer for "Contoso Root CA" (root cert)
38
    Admin->>CI: Redeploys policy with root-level Signer
39
    File->>CI: Requests execution (new-app.exe)
40
    CI->>CI: Evaluates rules — root Signer is skipped/not matched
41
    CI-->>File: Falls through to default action (BLOCKED in production)
42
    Admin->>Admin: Confirms: RootCertificate rules have no effect, breaks allow-listing

14. OS Version & Compatibility#

OS Version	PcaCertificate Support	RootCertificate Support
Windows 10 1903+	Full support	Not supported
Windows 10 1709–1809	Full support	Not supported
Windows 11 21H2+	Full support	Not supported
Windows Server 2019+	Full support	Not supported
Windows Server 2022	Full support	Not supported
Windows Server 2025	Full support	Not supported

RootCertificate has never been supported in any version of WDAC or its predecessor (Device Guard / Code Integrity Policies). This is a design decision, not a version limitation.

15. Common Mistakes & Gotchas#

Mistake 1: Assuming RootCertificate Will Work Like Other Levels#

Wrong assumption: “I’ll add a RootCertificate rule for our enterprise root CA and all our signed software will be allowed.”

Reality: The rule is silently ignored. Software falls through to the default action, which in enforced mode means a block. This causes unexpected application failures that appear unrelated to WDAC.

Fix: Use PcaCertificate for the code-signing intermediate CA.

Mistake 2: Confusing the TBS Hash of Root vs. Intermediate#

Wrong approach: Extracting the thumbprint of the root CA and putting it in a <CertRoot Type="TBS"> element in a Signer rule.

Reality: WDAC Signer rules match against intermediate CA TBS hashes. Providing the root CA’s TBS hash will not match any file in the chain walk.

Fix: Walk the certificate chain and extract the TBS hash of the first intermediate CA (index 1 in the chain, not index 2 which is the root).

Mistake 3: Trying to Use RootCertificate to “Trust Everything” from a Vendor#

Wrong approach: Adding a root CA rule to create a blanket “trust this vendor” policy entry.

Reality: Even if it worked, it would trust far more than the vendor’s software — it would trust every certificate ever issued by that root’s entire PKI tree.

Fix: Identify the specific intermediate CA the vendor uses for code signing. Create a PcaCertificate rule for that specific intermediate. If you need further scoping, use Publisher (adds leaf CN) or FilePublisher (adds filename and version).

Mistake 4: No Error Message from WDAC Tooling#

The most dangerous aspect of attempting RootCertificate is the complete absence of error messages. PowerShell’s New-CIPolicy silently falls back. Direct XML authoring silently fails at runtime. Policy compilation succeeds. Only application failures reveal the problem, often in production.

Mitigation: Always review generated policy XML and verify that <Signer> elements reference intermediate CA (PCA) certificates, not root CA certificates. You can verify by cross-referencing the TBS hash against known root CA thumbprints.

Mistake 5: Believing RootCertificate Exists in WDAC Documentation#

Some older community blog posts and third-party documentation list RootCertificate as a valid level. This is incorrect for App Control for Business. The official Microsoft documentation explicitly lists the supported levels, and RootCertificate is not among them.

16. Historical Context#

Why Was RootCertificate Explicitly Excluded?#

When Microsoft designed Windows Defender Application Control (the predecessor to App Control for Business, first shipped in Windows 10 1607 as part of Device Guard), the engineering team considered the full spectrum of certificate-based trust levels.

The inclusion of a RootCertificate level was considered and explicitly rejected for the following reasons:

Precedent from AppLocker: AppLocker, the predecessor policy system, had demonstrated that overly broad certificate trust led to policy bypasses. Administrators would trust a publisher’s root CA, and attackers would obtain legitimately-issued certs from that CA for their malware.
Microsoft’s own PKI surface: If Microsoft’s own employees used RootCertificate to trust Microsoft’s root CA for Windows policy deployments, the policy would become essentially useless — it would allow any Microsoft-signed binary, including many that should not be present in a restricted environment.
The PCA layer as the natural trust boundary: Microsoft’s PKI architecture already had a natural boundary at the PCA (Policy/Program Certificate Authority) level. Different PCAs are used for different purposes (OS signing, Authenticode, Azure, timestamping). Trusting at the PCA level allows meaningful segmentation of trust.
Defense in depth: WDAC is designed as a defense-in-depth control. Making the broadest allowed level still meaningfully restrictive (PcaCertificate rather than RootCertificate) ensures that even broadly-scoped policies provide real security value.

The decision was never revisited because it proved correct: PcaCertificate-level rules provide sufficient coverage for virtually all real-world use cases while maintaining meaningful security boundaries.

17. Summary Table#

Property	Value
Level Name	RootCertificate
Supported in WDAC	NO — Not Supported
Why Not Supported	Trusts entire PKI subtree — catastrophically broad
What ci.dll Does	Ignores the rule / does not evaluate it
PowerShell Behavior	Silently falls back to PcaCertificate
XML Authoring Behavior	Compiles but fails to match at runtime
Correct Alternative	PcaCertificate (broadest supported level)
Security Risk	Would be the highest risk level if supported
Use Case	None — never use this level
Decision Rule	If you want root-level trust → find the intermediate CA → use PcaCertificate
OS Versions	Never supported on any Windows version
Kernel Component	ci.dll (Code Integrity)
Related Levels	PcaCertificate, Publisher, FilePublisher
Documentation	Microsoft WDAC File Rule Levels reference (intermediate CA section)