WDAC File Rule Level: Publisher#

Table of Contents#

Overview
How It Works
Certificate Chain Anatomy
Where in the Evaluation Stack
XML Representation
PowerShell Examples
Pros and Cons
Attack Resistance Analysis
When to Use vs When to Avoid
Double-Signed File Behavior
Real-World Scenario
OS Version and Compatibility Notes
Common Mistakes and Gotchas
Summary Table

1. Overview#

The Publisher rule level is one of the most practical and widely used certificate-based trust levels in Windows Defender Application Control (WDAC), also known as App Control for Business. It answers a simple question: “Do I trust everything signed by this specific software publisher?”

At its core, Publisher combines two elements:

PCA Certificate — the intermediate Certificate Authority certificate that issued the leaf (end-entity) signing certificate used by the publisher. This is typically one level below the root CA in the certificate chain. (“PCA” historically stood for “Partner Certificate Authority” or is simply shorthand for the intermediate CA level.)
Leaf Certificate CN (Common Name) — the Subject Common Name field of the leaf certificate, which identifies the actual organization or entity that signed the file.

Together, these two elements create a rule that says: “Allow any file signed by a leaf certificate whose CN matches [Publisher Name] AND whose certificate was issued by the intermediate CA with TBS hash [PCA TBS Hash].”

This means all files from a given publisher — regardless of filename, version, or specific signing certificate renewal — will be trusted, as long as the publisher continues to use the same CA infrastructure.

Key Characteristics:

No filename restriction
No version floor or ceiling
No file-specific attributes checked
Trust is “publisher-wide” — all executables, DLLs, scripts from that publisher pass

2. How It Works#

The PCA Concept: What Does “PCA” Mean in WDAC?#

In WDAC terminology, the “PCA” certificate refers to the intermediate Certificate Authority certificate that sits one level below the root in the chain ConfigCI resolves for a given file. This is important to understand precisely:

It is NOT the root CA (e.g., DigiCert Global Root G2)
It is NOT the leaf certificate (the actual signing cert held by the vendor)
It is the intermediate CA — an entity that DigiCert (or another root CA) has authorized to issue code-signing certificates

When WDAC builds a Publisher rule, the New-CIPolicy cmdlet (or the New-CIPolicyRule cmdlet) performs the following steps:

Read the Authenticode signature from the PE file
Extract the full certificate chain
Walk up the chain, stopping one level below the root (or the highest resolvable certificate if the chain cannot be fully resolved online/locally)
Record the TBS (To-Be-Signed) hash of that intermediate certificate — this becomes the <CertRoot Type="TBS" Value="..."/> element
Extract the Subject CN of the leaf certificate — this becomes the <CertPublisher Value="..."/> element
Combine both into a single <Signer> entry

TBS Hash: What Is It?#

The TBS (To-Be-Signed) hash is computed over the portion of an X.509 certificate that is actually signed — the certificate body without the outer signature wrapper. This hash uniquely identifies a specific certificate instance (specific key, specific validity period, specific issuer). Using TBS rather than the full certificate hash is a WDAC convention that provides stable identification across different DER encodings.

Leaf CN Matching: Case Sensitivity#

A critical detail: the CN match in Publisher rules is a case-sensitive string comparison. If the leaf certificate Subject has CN=Intel(R) Code Signing (with specific capitalization), the <CertPublisher> value in your XML must exactly match that string. A mismatch due to case or whitespace will cause the rule to fail silently — files won’t be blocked with an error, they simply won’t match the Publisher rule and will fall through to other rules.

How ConfigCI Identifies the PCA Certificate#

To manually identify which certificate is the “PCA” for a given file:

1
# Step 1: Get the signer certificate from the file
2
$sig = Get-AuthenticodeSignature "C:\path\to\file.exe"
3
$leafCert = $sig.SignerCertificate
4

5
# Step 2: Build the full chain
6
$chain = New-Object System.Security.Cryptography.X509Certificates.X509Chain
7
$chain.Build($leafCert) | Out-Null
8

9
# Step 3: List all certs in the chain (index 0 = leaf, last = root)
10
$chain.ChainElements | ForEach-Object {
11
    $c = $_.Certificate
12
    Write-Host "Subject: $($c.Subject)"
13
    Write-Host "Issuer:  $($c.Issuer)"
14
    Write-Host "Thumbprint: $($c.Thumbprint)"
15
    Write-Host "---"
16
}
17

18
# Step 4: The PCA is typically index 1 (chain[1]) — one above the leaf
19
$pcaCert = $chain.ChainElements[1].Certificate
20
Write-Host "PCA CN: $($pcaCert.Subject)"

For a typical Microsoft-signed system file, the chain might look like:

1
[0] Leaf:  CN=Microsoft Windows, OU=MOPR, O=Microsoft Corporation, ...
2
[1] PCA:   CN=Microsoft Windows Production PCA 2011
3
[2] Root:  CN=Microsoft Root Certificate Authority 2010

WDAC uses index [1] — the PCA — for the Publisher rule’s <CertRoot> TBS hash.

Trust Scope#

When a Publisher rule is in effect, ConfigCI checks each PE file at load time:

Does the file carry a valid Authenticode signature?
Does the chain resolve to the expected PCA certificate (by TBS hash)?
Does the leaf CN match <CertPublisher Value="..."/>?

If all three pass, the file is allowed — regardless of what the file is named, what version it claims, or where it lives on disk.

3. Certificate Chain Anatomy#

The following diagram shows the full certificate chain and which level each WDAC rule level “anchors” to:

1
graph TD
2
    Root["Root CA\nCN=DigiCert Global Root G2\nSelf-signed, trusted by Windows"]
3
    PCA["Intermediate / PCA Certificate\nCN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021\nIssued by Root CA\n★ PUBLISHER LEVEL anchors here (TBS hash)"]
4
    Leaf["Leaf Certificate (End-Entity)\nCN=Intel Corporation\nIssued by PCA\n★ PUBLISHER adds Leaf CN check\n★ LEAFCERTIFICATE anchors here\n★ FILEPUBLISHER also uses Leaf CN"]
5
    File["Signed File\nexe / dll / sys\nSigned by private key of Leaf cert\n★ FILEPUBLISHER adds OriginalFileName + Version"]
6

7
    Root -->|"issues"| PCA
8
    PCA -->|"issues"| Leaf
9
    Leaf -->|"signs"| File
10

11
    style Root fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
12
    style PCA fill:#162032,stroke:#1e3a5f,color:#e2e8f0
13
    style Leaf fill:#162032,stroke:#1e3a5f,color:#e2e8f0
14
    style File fill:#0d1f12,stroke:#1a5c2a,color:#86efac

Publisher Level specifically:

Anchors at the PCA (intermediate) certificate via its TBS hash
Additionally requires that the leaf certificate’s CN matches a specific value
Does NOT check: filename, file version, file path, or any file attributes

Contrast with neighboring levels:

Level	Anchor Certificate	Additional Checks
PcaCertificate	PCA cert (TBS hash)	None
Publisher	PCA cert (TBS hash)	+ Leaf CN match
FilePublisher	PCA cert (TBS hash)	+ Leaf CN + OriginalFileName + MinimumFileVersion
LeafCertificate	Leaf cert (TBS hash)	None

4. Where in the Evaluation Stack#

1
flowchart TD
2
    Start(["File Execution Requested"])
3
    IsKernel{"Kernel mode\nor User mode?"}
4
    HasSig{"File has valid\nAuthenticode signature?"}
5
    HashCheck{"Explicit Hash rule\nexists for this file?"}
6
    PubCheck{"Publisher rule match?\nPCA TBS hash + Leaf CN"}
7
    FilePubCheck{"FilePublisher rule match?\nPCA + Leaf CN + FileName + Version"}
8
    PCACheck{"PcaCertificate rule match?\nPCA TBS hash only"}
9
    LeafCheck{"LeafCertificate rule match?\nLeaf cert TBS hash"}
10
    DefaultDeny(["BLOCK — no rule matched"])
11
    Allow(["ALLOW — file executes"])
12

13
    Start --> IsKernel
14
    IsKernel -->|"HVCI active"| HasSig
15
    IsKernel -->|"User mode"| HasSig
16
    HasSig -->|"No signature"| HashCheck
17
    HasSig -->|"Valid signature"| PubCheck
18
    HashCheck -->|"Hash match"| Allow
19
    HashCheck -->|"No hash match"| DefaultDeny
20
    PubCheck -->|"Match"| Allow
21
    PubCheck -->|"No match"| FilePubCheck
22
    FilePubCheck -->|"Match"| Allow
23
    FilePubCheck -->|"No match"| PCACheck
24
    PCACheck -->|"Match"| Allow
25
    PCACheck -->|"No match"| LeafCheck
26
    LeafCheck -->|"Match"| Allow
27
    LeafCheck -->|"No match"| DefaultDeny
28

29
    style Start fill:#162032,stroke:#1e3a5f,color:#e2e8f0
30
    style Allow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
31
    style DefaultDeny fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
32
    style HasSig fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
33
    style HashCheck fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
34
    style PubCheck fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
35
    style FilePubCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
36
    style PCACheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
37
    style LeafCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
38
    style IsKernel fill:#1a1a0d,stroke:#7a6a00,color:#fde68a

Publisher rules are checked as part of the signer evaluation. ConfigCI evaluates all signer-based rules in parallel against the file’s certificate chain — it does not strictly proceed in the linear order shown above. The flowchart illustrates logical precedence for understanding; in practice, CI checks all applicable rules simultaneously and allows the file if any rule permits it.

5. XML Representation#

Full Publisher Rule XML Structure#

A Publisher rule produces the following elements in a WDAC policy XML file (SiPolicy.xml):

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

4

5
  <Signers>
6

7
    <!--
8
      Publisher Rule for Intel Corporation drivers/software
9
      - Name attribute: human-readable label, typically the PCA cert CN
10
      - ID attribute: unique identifier referenced by AllowedSigners
11
    -->
12
    <Signer ID="ID_SIGNER_INTEL_001" Name="DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021">
13

14
      <!--
15
        CertRoot anchors this rule to the PCA (intermediate CA) certificate
16
        - Type="TBS" means the Value is a TBS hash of the PCA certificate
17
        - Value: SHA-256 TBS hash of the intermediate CA cert, hex-encoded
18
        This TBS hash uniquely identifies the specific intermediate CA cert
19
      -->
20
      <CertRoot Type="TBS" Value="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE"/>
21

22
      <!--
23
        CertPublisher narrows the trust to a specific leaf certificate CN
24
        - Value: exact string match against SubjectCN of the leaf/end-entity cert
25
        - This is case-sensitive — must match exactly as it appears in the cert
26
        Without this element, the rule becomes a PcaCertificate-level rule
27
      -->
28
      <CertPublisher Value="Intel Corporation"/>
29

30
    </Signer>
31

32
    <Signer ID="ID_SIGNER_MSWIN_001" Name="Microsoft Windows Production PCA 2011">
33
      <CertRoot Type="TBS" Value="4E80BE107C860A21A621E2D0831F85F701AFF1B007AEB99BBBA4B02B72D7B6A5"/>
34
      <CertPublisher Value="Microsoft Windows"/>
35
    </Signer>
36

37
  </Signers>
38

39

40
  <SigningScenarios>
41

42
    <SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS" FriendlyName="Kernel Mode">
43
      <ProductSigners>
44
        <AllowedSigners>
45
          <AllowedSigner SignerID="ID_SIGNER_INTEL_001"/>
46
          <AllowedSigner SignerID="ID_SIGNER_MSWIN_001"/>
47
        </AllowedSigners>
48
      </ProductSigners>
49
    </SigningScenario>
50

51
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode">
52
      <ProductSigners>
53
        <AllowedSigners>
54
          <AllowedSigner SignerID="ID_SIGNER_INTEL_001"/>
55
          <AllowedSigner SignerID="ID_SIGNER_MSWIN_001"/>
56
        </AllowedSigners>
57
      </ProductSigners>
58
    </SigningScenario>
59

60
  </SigningScenarios>
61

62
</SiPolicy>

Key XML Elements Explained#

Element	Attribute	Purpose
`<Signer>`	`ID`	Unique identifier for cross-referencing
`<Signer>`	`Name`	Human-readable label (typically PCA CN)
`<CertRoot>`	`Type="TBS"`	Specifies TBS hash identification method
`<CertRoot>`	`Value`	Hex-encoded TBS hash of the PCA certificate
`<CertPublisher>`	`Value`	Exact CN of the leaf certificate Subject
`<AllowedSigner>`	`SignerID`	References the Signer by its ID

What Makes a Publisher Rule vs a PcaCertificate Rule#

The difference is purely the presence or absence of <CertPublisher>:

1
<Signer ID="ID_SIGNER_PCA_ONLY" Name="DigiCert PCA">
2
  <CertRoot Type="TBS" Value="3F9001EA..."/>
3
</Signer>
4

5
<Signer ID="ID_SIGNER_INTEL_PUB" Name="DigiCert PCA">
6
  <CertRoot Type="TBS" Value="3F9001EA..."/>
7
  <CertPublisher Value="Intel Corporation"/>  <!-- adds CN filter -->
8
</Signer>

6. PowerShell Examples#

Creating a Publisher Policy from Existing Files#

1
# Generate a policy at Publisher level from a directory of files
2
New-CIPolicy `
3
    -Level Publisher `
4
    -FilePath "C:\Intel\Drivers" `
5
    -ScanPath "C:\Intel\Drivers" `
6
    -UserPEs `
7
    -Fallback Hash `
8
    -OutputFilePath "C:\Policies\IntelPublisher.xml"
9

10
# Explanation of parameters:
11
# -Level Publisher        : Use Publisher as the primary rule level
12
# -ScanPath               : Directory to scan for PE files
13
# -UserPEs                : Include user-mode executables (not just kernel drivers)
14
# -Fallback Hash          : If Publisher level cannot be created (unsigned file),
15
#                           fall back to Hash level
16
# -OutputFilePath         : Where to write the resulting policy XML

Creating a Publisher Rule for a Single File#

1
# Create a Publisher rule from one specific file
2
$rule = New-CIPolicyRule `
3
    -Level Publisher `
4
    -DriverFilePath "C:\Program Files\Intel\GraphicsDriver\igxprd64.dll" `
5
    -Fallback Hash
6

7
# Inspect the rule object
8
$rule | Format-List *
9

10
# Add the rule to an existing policy
11
Merge-CIPolicy `
12
    -PolicyPaths "C:\Policies\BasePolicy.xml" `
13
    -Rules $rule `
14
    -OutputFilePath "C:\Policies\MergedPolicy.xml"

Inspecting Publisher Information Before Creating Rules#

1
# Full inspection workflow — understand what Publisher rule will be created
2
function Get-WDACPublisherInfo {
3
    param([string]$FilePath)
4

5
    $sig = Get-AuthenticodeSignature -FilePath $FilePath
6

7
    if ($sig.Status -ne "Valid") {
8
        Write-Warning "File signature status: $($sig.Status)"
9
        return
10
    }
11

12
    $leafCert = $sig.SignerCertificate
13

14
    # Build certificate chain
15
    $chain = [System.Security.Cryptography.X509Certificates.X509Chain]::new()
16
    $chain.ChainPolicy.RevocationMode = [System.Security.Cryptography.X509Certificates.X509RevocationMode]::NoCheck
17
    $null = $chain.Build($leafCert)
18

19
    $elements = $chain.ChainElements
20

21
    Write-Host "`n=== Certificate Chain for: $FilePath ===" -ForegroundColor Cyan
22
    for ($i = 0; $i -lt $elements.Count; $i++) {
23
        $cert = $elements[$i].Certificate
24
        $label = switch ($i) {
25
            0 { "LEAF (used for CertPublisher CN)" }
26
            { $_ -eq $elements.Count - 1 } { "ROOT" }
27
            default { "INTERMEDIATE/PCA (used for CertRoot TBS hash)" }
28
        }
29
        Write-Host "`n[$i] $label"
30
        Write-Host "    Subject:    $($cert.Subject)"
31
        Write-Host "    Issuer:     $($cert.Issuer)"
32
        Write-Host "    Thumbprint: $($cert.Thumbprint)"
33
        Write-Host "    Valid:      $($cert.NotBefore) → $($cert.NotAfter)"
34
    }
35

36
    Write-Host "`n=== Publisher Rule Would Use ===" -ForegroundColor Yellow
37
    Write-Host "CertPublisher (Leaf CN): $($elements[0].Certificate.GetNameInfo('SimpleName', $false))"
38
    if ($elements.Count -ge 2) {
39
        Write-Host "CertRoot PCA Subject:    $($elements[1].Certificate.Subject)"
40
    }
41
}
42

43
# Usage
44
Get-WDACPublisherInfo -FilePath "C:\Windows\System32\ntoskrnl.exe"
45
Get-WDACPublisherInfo -FilePath "C:\Program Files\Intel\Wi-Fi\driver\netwtw14.sys"

Converting a Policy to Binary and Deploying#

1
# After generating the XML policy, convert to binary
2
$policyXml = "C:\Policies\IntelPublisher.xml"
3
$policyBin = "C:\Policies\IntelPublisher.cip"
4

5
ConvertFrom-CIPolicy -XmlFilePath $policyXml -BinaryFilePath $policyBin
6

7
# Copy to enforcement location (kernel reads from this path)
8
$policyGuid = "{PolicyGUID}" # Extract from XML PolicyID attribute
9
Copy-Item $policyBin "C:\Windows\System32\CodeIntegrity\CiPolicies\Active\$policyGuid.cip"
10

11
# Restart required for policy to take effect (or use CiTool.exe on Win11)
12
# CiTool.exe --update-policy $policyBin  (Windows 11 22H2+ only)

7. Pros and Cons#

Factor	Assessment
Setup complexity	Low — one scan generates rules for all files from a publisher
Maintenance burden	Low — survives app updates as long as same publisher signs new versions
Specificity	Medium — narrower than PcaCertificate, broader than FilePublisher
False positives	Low risk — tied to specific publisher identity
Attack surface	Medium-High — compromise of publisher’s signing infrastructure = all files allowed
Survives cert renewal	Partially — survives leaf cert renewal if PCA stays same. Breaks if publisher switches CAs
Works with unsigned files	No — unsigned files require Hash fallback
Works with MSI installers	Yes — MSIs can carry Authenticode signatures at Publisher level
Kernel driver support	Yes — works for KMCI (kernel mode) and UMCI (user mode)
Ease of understanding	High — “trust this company’s software” is intuitive

Pros#

Wide coverage with minimal rules: A single Publisher rule covers an entire vendor’s software catalog.
Survives version updates: When a vendor releases a new version with the same CN, no policy update needed.
Survives filename changes: Vendor can rename a tool and the rule still applies.
Appropriate for OEM software: Perfect for device driver suites where hundreds of files from one OEM need to be trusted.
Manageable rule count: Fewer rules = smaller policy XML = faster evaluation.

Cons#

Publisher-wide trust: A compromised publisher signing key allows the attacker to sign ANY file and have it run.
No version protection: If a known-vulnerable old version of software exists and is Publisher-signed, it will be allowed.
No filename protection: A malicious file can be signed with a compromised publisher cert and still pass.
CA dependency: If the publisher switches from DigiCert to Sectigo, the PCA TBS hash changes and rules break.
Harder to audit: “All Intel-signed files allowed” is a broad trust that can be hard to justify in high-security environments.

8. Attack Resistance Analysis#

1
graph TD
2
    Attacker(["Attacker Goal:\nRun malicious code"])
3

4
    Unsigned["Attempt 1:\nDrop unsigned malicious EXE"]
5
    UnsignedResult(["BLOCKED\nNo hash rule, no signature\nDefault deny applies"])
6

7
    SelfSigned["Attempt 2:\nSelf-sign with attacker cert"]
8
    SelfSignedResult(["BLOCKED\nPCA TBS hash won't match\nLeaf CN won't match"])
9

10
    StealLeaf["Attempt 3:\nSteal leaf cert private key\nSign malicious file with Intel cert"]
11
    StealLeafResult(["ALLOWED if undetected\nLeaf CN = Intel Corporation\nPCA chain resolves correctly\nWDAC cannot detect forged intent"])
12

13
    StealPCA["Attempt 4:\nCompromise DigiCert intermediate CA\nIssue new cert with CN=Intel Corporation"]
14
    StealPCAResult(["ALLOWED\nNew cert has same CN\nPCA TBS hash matches\nExtremely difficult attack"])
15

16
    SamePublisher["Attempt 5:\nObtain legitimate cert from same CA\nDifferent company, different CN"]
17
    SamePublisherResult(["BLOCKED\nCN does not match Intel Corporation\nPublisher check fails"])
18

19
    Unsigned --> UnsignedResult
20
    SelfSigned --> SelfSignedResult
21
    StealLeaf --> StealLeafResult
22
    StealPCA --> StealPCAResult
23
    SamePublisher --> SamePublisherResult
24

25
    style Attacker fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
26
    style Unsigned fill:#162032,stroke:#1e3a5f,color:#e2e8f0
27
    style SelfSigned fill:#162032,stroke:#1e3a5f,color:#e2e8f0
28
    style StealLeaf fill:#162032,stroke:#1e3a5f,color:#e2e8f0
29
    style StealPCA fill:#162032,stroke:#1e3a5f,color:#e2e8f0
30
    style SamePublisher fill:#162032,stroke:#1e3a5f,color:#e2e8f0
31
    style UnsignedResult fill:#0d1f12,stroke:#1a5c2a,color:#86efac
32
    style SelfSignedResult fill:#0d1f12,stroke:#1a5c2a,color:#86efac
33
    style StealLeafResult fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
34
    style StealPCAResult fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
35
    style SamePublisherResult fill:#0d1f12,stroke:#1a5c2a,color:#86efac

Attack Surface Summary#

Attack Vector	Publisher Resistance	Notes
Unsigned binary	High	Blocked by default deny
Self-signed binary	High	PCA TBS hash won’t match
Stolen leaf cert	Low	If attacker has private key, they can sign arbitrary files
Stolen PCA cert (CA compromise)	Low	CA compromise is catastrophic at all cert-based levels
Legitimate cert with different CN	High	CN mismatch blocks it
Timestamped old binary (expired cert)	Medium	Depends on policy’s AllowedSigners + timestamp policy

9. When to Use vs When to Avoid#

1
flowchart TD
2
    Q1{"How many files\nfrom this vendor?"}
3
    Q2{"Is the vendor a\npublic software company\nwith a well-known signing cert?"}
4
    Q3{"Do you need version-level\ncontrol (block old vulnerable versions)?"}
5
    Q4{"Is this for kernel drivers\nor an OEM hardware suite?"}
6
    Q5{"Does the vendor change\nleaf certs frequently?"}
7
    UsePublisher(["USE Publisher\nGood fit for this scenario"])
8
    UseFilePublisher(["CONSIDER FilePublisher\nAdds version + filename control"])
9
    UsePCA(["Consider PcaCertificate\nOnly for internal/private CAs"])
10
    AvoidUseHash(["Avoid Publisher\nUse Hash for high-security scenarios"])
11

12
    Q1 -->|"Dozens to hundreds"| Q2
13
    Q1 -->|"Only 1-3 files"| UseFilePublisher
14
    Q2 -->|"Yes"| Q3
15
    Q2 -->|"No / Internal CA"| UsePCA
16
    Q3 -->|"Yes, version matters"| UseFilePublisher
17
    Q3 -->|"No, any version OK"| Q4
18
    Q4 -->|"Yes — OEM/driver suite"| UsePublisher
19
    Q4 -->|"No — general app"| Q5
20
    Q5 -->|"Yes, frequent renewals"| UsePublisher
21
    Q5 -->|"No, stable cert"| UseFilePublisher
22

23
    style UsePublisher fill:#0d1f12,stroke:#1a5c2a,color:#86efac
24
    style UseFilePublisher fill:#162032,stroke:#1e3a5f,color:#e2e8f0
25
    style UsePCA fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
26
    style AvoidUseHash fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
27
    style Q1 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
28
    style Q2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
29
    style Q3 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
30
    style Q4 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
31
    style Q5 fill:#162032,stroke:#1e3a5f,color:#e2e8f0

Decision Summary#

Use Publisher when:

You need to trust a broad set of files from one software vendor (e.g., a full driver suite)
The vendor releases frequent updates and you cannot afford policy updates on every version bump
Kernel-mode drivers from an OEM need to run (Publisher is appropriate for driver packages)
The vendor regularly renews leaf certs but stays with the same intermediate CA

Avoid Publisher when:

You need version pinning (a vulnerable old version must be blocked)
You are operating in a high-assurance environment where per-file control is required
The “publisher” is a large public CA sub-entity that signs many unrelated companies’ code
You need filename verification as part of your security model

10. Double-Signed File Behavior#

Some files carry two or more Authenticode signatures — this is common for Microsoft OS binaries (e.g., they may carry both a SHA-1 signature for legacy compatibility and a SHA-256 signature) and for files signed by both a vendor and a timestamping authority in certain PKI models.

When ConfigCI scans a double-signed file with -Level Publisher, the following occurs:

ConfigCI iterates over all embedded signatures in the file
For each signature, it builds the certificate chain and extracts the PCA cert and leaf CN
It generates a separate Publisher rule for each distinct (PCA TBS hash, Leaf CN) pair
Both rules are written to the policy XML

1
<Signer ID="ID_SIGNER_INTEL_SHA256" Name="DigiCert Code Signing SHA2">
2
  <CertRoot Type="TBS" Value="AABBCC..."/>
3
  <CertPublisher Value="Intel Corporation"/>
4
</Signer>
5

6
<Signer ID="ID_SIGNER_INTEL_SHA1" Name="VeriSign Class 3 Code Signing 2010 CA">
7
  <CertRoot Type="TBS" Value="112233..."/>
8
  <CertPublisher Value="Intel Corporation"/>
9
</Signer>

At policy enforcement time, ConfigCI checks all signatures in the file against all rules. The file is allowed if any one of its signatures matches any one Publisher rule.

Implication for policy size: Scanning a large directory of dual-signed files will produce roughly twice the number of signer rules. This is expected behavior — it is not a bug.

11. Real-World Scenario#

Scenario: Enterprise deploying Intel NUC workstations with full Intel driver suite

An IT administrator needs to allow a complete Intel driver package (graphics, Wi-Fi, Thunderbolt, ME firmware) across 500 workstations. Using Hash rules would require updating rules every time Intel releases driver updates. FilePublisher would require per-executable rules. Publisher is the appropriate choice.

1
sequenceDiagram
2
    participant Admin as IT Administrator
3
    participant Workstation as Reference Workstation
4
    participant PS as PowerShell / ConfigCI
5
    participant MDM as Intune MDM
6
    participant Fleet as 500 Workstations
7

8
    Admin->>Workstation: Install full Intel driver package
9
    Admin->>PS: New-CIPolicy -Level Publisher -ScanPath C:\Intel\Drivers
10
    PS->>Workstation: Scan all PE files in driver directory
11
    PS->>PS: Extract PCA TBS hash (DigiCert intermediate)
12
    PS->>PS: Extract leaf CN (Intel Corporation)
13
    PS->>PS: Generate <Signer> with CertRoot + CertPublisher
14
    PS-->>Admin: IntelPublisher.xml generated (5-10 signer rules)
15
    Admin->>PS: ConvertFrom-CIPolicy -XmlFilePath IntelPublisher.xml -BinaryFilePath IntelPublisher.cip
16
    Admin->>MDM: Upload .cip policy to Intune
17
    MDM->>Fleet: Deploy policy via OMA-URI
18
    Fleet->>Fleet: Policy active on next boot
19

20
    Note over Fleet: 6 months later: Intel releases new driver version
21

22
    Admin->>Workstation: Intel driver auto-updates via Windows Update
23
    Fleet->>Fleet: New driver binary runs
24
    Fleet->>Fleet: ConfigCI checks: PCA TBS hash matches? YES
25
    Fleet->>Fleet: ConfigCI checks: Leaf CN = "Intel Corporation"? YES
26
    Fleet-->>Fleet: ALLOWED — no policy update needed
27

28
    style Admin fill:#162032,stroke:#1e3a5f,color:#e2e8f0
29
    style Workstation fill:#162032,stroke:#1e3a5f,color:#e2e8f0
30
    style PS fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
31
    style MDM fill:#162032,stroke:#1e3a5f,color:#e2e8f0
32
    style Fleet fill:#0d1f12,stroke:#1a5c2a,color:#86efac

12. OS Version and Compatibility Notes#

Feature	Windows Version	Notes
Publisher level (UMCI)	Windows 10 1507+	Available since initial WDAC introduction
Publisher level (KMCI)	Windows 10 1507+	Kernel mode code integrity supported from launch
`New-CIPolicy -Level Publisher`	Windows 10 1607+	PowerShell cmdlet requires RSAT/ConfigCI module
CiTool.exe deployment	Windows 11 22H2+	Allows in-place policy update without reboot
Multiple active policies	Windows 10 1903+	Multiple .cip files in CiPolicies\Active\
SHA-256 TBS hashes	Windows 10 1703+	Earlier versions use SHA-1; SHA-256 recommended
HVCI enforcement	Windows 10 1703+	Hypervisor-Protected Code Integrity strengthens KMCI
Managed Installer interaction	Windows 10 1703+	Publisher rules override Managed Installer for matching files

ConfigCI Module Availability#

The ConfigCI PowerShell module (New-CIPolicy, New-CIPolicyRule, ConvertFrom-CIPolicy) is available:

Natively on Windows 11 (no additional install)
On Windows 10: requires RSAT feature “Windows Defender Application Control Tools” or being on an Enterprise/Education SKU with the module pre-installed
On Windows Server 2019+: available via Windows Features

13. Common Mistakes and Gotchas#

Mistake 1: Assuming PCA = Root CA#

Many administrators confuse “PCA certificate” with the root CA. The PCA is the intermediate — if you look at the chain Root → Intermediate → Leaf, the PCA is the intermediate, not the root. WDAC almost never anchors to the actual root CA because root certs are universal trust anchors and would be far too broad.

Mistake 2: Case-Sensitive CN Mismatch#

1
# WRONG — slightly different spacing or capitalization
2
<CertPublisher Value="intel corporation"/>   # lowercase — will NOT match
3
<CertPublisher Value="Intel  Corporation"/>   # double space — will NOT match
4

5
# CORRECT — must exactly match SubjectCN from the certificate
6
<CertPublisher Value="Intel Corporation"/>    # exact match

Always use Get-AuthenticodeSignature and inspect SignerCertificate.Subject to get the exact string before writing it into XML.

Mistake 3: Publisher Rule for MSI Files with No PE Signature#

MSI files sometimes embed Authenticode in a different way. If an MSI lacks a standard PE signature, a Publisher rule won’t match it. Use -Fallback Hash in New-CIPolicy to handle unsigned or non-PE files.

Mistake 4: Publisher Rule Breaks When Vendor Switches CAs#

If Intel switches from DigiCert to Sectigo for code signing, the PCA TBS hash changes. Your existing Publisher rule for CertRoot Value="DigiCert TBS..." will no longer match new Intel-signed files. You must add a new Publisher rule for the new CA. Monitor vendor PKI change announcements.

Mistake 5: Expecting Publisher to Block Old Vulnerable Versions#

Publisher rules do NOT check file version. If you have a Publisher rule for Intel software and a known-vulnerable old version is present, it will still be allowed. For version-based blocking, you need FilePublisher rules with version floor, or explicit deny Hash rules for vulnerable versions.

Mistake 6: Not Testing in Audit Mode First#

Always deploy WDAC policies in audit mode (<Option>Enabled:Audit Mode</Option>) before enforcement. Publisher rules are broad — you need to verify what gets allowed/blocked before enforcement to avoid operational disruption.

Mistake 7: Forgetting SigningScenario Scope#

A Signer defined in <Signers> only takes effect when referenced in an <AllowedSigners> block within a <SigningScenario>. A Signer with no corresponding <AllowedSigner> reference has no effect. Always verify your XML has proper references for both KMCI (Value=“131”) and UMCI (Value=“12”) scenarios as appropriate.

14. Summary Table#

Property	Value
Rule Level Name	Publisher
Certificate Anchored	Intermediate CA (PCA) — one level below root
Anchor Method	TBS hash of PCA certificate (`<CertRoot Type="TBS">`)
Additional Filter	Leaf certificate Subject CN (`<CertPublisher Value="..."/>`)
File Attributes Checked	None — no filename, no version, no path
Trust Granularity	All files from a named publisher (via specific CA)
Survives App Updates	Yes — as long as same publisher CN and same CA
Survives Cert Renewal	Partially — leaf cert renewal OK, CA change breaks rule
Kernel Mode Support	Yes
User Mode Support	Yes
MSI Support	Yes (if MSI carries Authenticode signature)
Fallback Recommended	Yes — `-Fallback Hash` for unsigned files
Primary Use Case	OEM driver suites, vendor software suites with many files
Key Risk	Publisher signing key compromise allows arbitrary signed files
XML Elements	`<Signer>` + `<CertRoot Type="TBS">` + `<CertPublisher>`
PowerShell Parameter	`-Level Publisher`
Introduced	Windows 10 1507