WDAC File Rule Level: FilePublisher#

Table of Contents#

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

1. Overview#

FilePublisher is the gold standard rule level for most enterprise WDAC deployments. It offers the optimal balance between specificity and maintainability — tight enough to prevent abuse, flexible enough to survive routine application updates.

FilePublisher combines three independent binding criteria into a single rule:

OriginalFileName — the filename baked into the PE file’s VERSIONINFO resource at compile time (not the on-disk filename, which can be renamed)
Publisher — the combination of the intermediate CA (PCA) TBS hash and the leaf certificate Subject CN, exactly as in the Publisher rule level
MinimumFileVersion — a version floor below which files are rejected even if they pass the name and publisher checks

A file must satisfy all three criteria simultaneously to be allowed by a FilePublisher rule. This triple-binding creates a rule that is simultaneously:

Resistant to filename spoofing (uses embedded OriginalFileName, not the on-disk name)
Resistant to unauthorized signers (publisher check gates on CA + CN)
Resistant to version rollback attacks (MinimumFileVersion blocks downgraded binaries)

Understanding FilePublisher deeply requires understanding each of its three components, how they interact, and the specific edge cases that affect real-world deployments. This document covers all of that in detail.

2. How It Works#

Step-by-Step: What ConfigCI Does When Generating FilePublisher Rules#

When you run New-CIPolicy -Level FilePublisher against a directory of PE files, ConfigCI performs the following for each file:

Step 1: Read the PE VERSIONINFO Resource

ConfigCI calls into the Windows resource parsing APIs to extract the VS_VERSIONINFO structure embedded in the PE file during compilation. From this structure, it reads:

OriginalFileName — the filename the developer assigned at build time
FileVersion — the version tuple (Major.Minor.Build.Revision)
ProductName, ProductVersion, InternalName, CompanyName — available for -SpecificFileNameLevel

Step 2: Extract Certificate Chain Information

ConfigCI extracts the Authenticode signature and builds the certificate chain:

PCA certificate TBS hash → used in <CertRoot Type="TBS" Value="..."/>
Leaf certificate Subject CN → used in <CertPublisher Value="..."/>

Step 3: Create FileAttrib Element

ConfigCI generates a <FileAttrib> element that captures the file-specific attributes:

1
<FileAttrib ID="ID_FILEATTRIB_7ZIP" FriendlyName="7-Zip 7z.exe" FileName="7z.exe" MinimumFileVersion="24.08.0.0"/>

Step 4: Link FileAttrib to Signer

ConfigCI generates a <Signer> element (identical structure to Publisher) and adds a <FileAttribRef> child that links the signer to the specific file attribute:

1
<Signer ID="ID_SIGNER_7ZIP" Name="DigiCert Code Signing PCA">
2
  <CertRoot Type="TBS" Value="AABBCC..."/>
3
  <CertPublisher Value="Igor Pavlov"/>
4
  <FileAttribRef RuleID="ID_FILEATTRIB_7ZIP"/>
5
</Signer>

Step 5: At Enforcement Time

When a binary attempts to execute, ConfigCI checks:

Does the file’s certificate chain produce a PCA TBS hash matching <CertRoot Value="..."/>?
Does the file’s leaf certificate CN match <CertPublisher Value="..."/>?
Does the file’s embedded OriginalFileName match <FileAttrib FileName="..."/>?
Is the file’s FileVersion ≥ <FileAttrib MinimumFileVersion="..."/>?

All four conditions must be true simultaneously. Failure of any one means the FilePublisher rule does not match this file (other rules may still match).

3. The Triple-Binding Deep Dive#

Binding 1: OriginalFileName (Anti-Rename Protection)#

The OriginalFileName field is embedded in the PE binary at compile time and is part of the VERSIONINFO resource structure. It is the filename the developer intended the binary to have.

Why OriginalFileName instead of the disk filename?

On-disk filenames can trivially be changed by anyone with file system write access. OriginalFileName is part of the binary’s content — you cannot change it without modifying the binary itself (which would invalidate the Authenticode signature).

1
# Read OriginalFileName from a PE file
2
$vi = (Get-Item "C:\Program Files\7-Zip\7z.exe").VersionInfo
3
Write-Host "OriginalFileName: $($vi.OriginalFilename)"
4
Write-Host "FileVersion:      $($vi.FileVersion)"
5
Write-Host "ProductName:      $($vi.ProductName)"
6
Write-Host "CompanyName:      $($vi.CompanyName)"
7
Write-Host "InternalName:     $($vi.InternalName)"

What if a file has no VERSIONINFO?

If the PE file has no embedded VERSIONINFO resource (e.g., some older tools, deliberately stripped binaries, or non-PE files), ConfigCI cannot generate a FilePublisher rule and falls back to the next level specified in -Fallback. Typically this means falling back to Publisher or Hash.

Binding 2: Publisher (PCA + Leaf CN)#

This is identical to the Publisher rule level. See Level-Publisher.md for the full explanation of:

What “PCA” means (intermediate CA)
TBS hash computation
Leaf CN case-sensitive matching
How ConfigCI resolves the chain

Binding 3: MinimumFileVersion (Anti-Downgrade Protection)#

The MinimumFileVersion field specifies the lowest file version that is allowed. It corresponds to the FileVersion field in the PE’s VERSIONINFO resource, expressed as a four-part version: Major.Minor.Build.Revision.

Version comparison semantics:

24.08.0.0 allows 24.08.0.0, 24.08.0.1, 24.09.0.0, 25.0.0.0 — anything ≥ the floor
24.08.0.0 blocks 24.07.0.0, 23.0.0.0, 1.0.0.0 — anything below the floor

When ConfigCI scans a file, it sets MinimumFileVersion to the current version of the scanned file. This means:

Any future update (version bump) will still pass the rule without policy changes
The current version passes exactly
Any older version (e.g., a known-vulnerable older release) is blocked

The version floor strategy:

1
Current scanned version: 24.08.0.0
2
MinimumFileVersion set to: 24.08.0.0
3

4
Later scenarios:
5
  v24.08.0.0 deployed → ALLOWED (equals floor)
6
  v24.09.0.0 released → ALLOWED (above floor)
7
  v25.00.0.0 released → ALLOWED (above floor)
8
  v24.07.0.0 (old vuln version) → BLOCKED (below floor)
9
  v1.0.0.0 (ancient version) → BLOCKED (below floor)

This is a key security benefit: FilePublisher rules automatically provide version-rollback protection without any additional configuration.

4. Certificate Chain Anatomy#

1
graph TD
2
    Root["Root CA\nCN=DigiCert Global Root G2\nSelf-signed\nNot directly referenced by WDAC rules"]
3
    PCA["Intermediate / PCA Certificate\nCN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021\nIssued by Root\n★ FilePublisher: CertRoot TBS hash anchors here\n★ Publisher: also anchors here\n★ PcaCertificate: also anchors here"]
4
    Leaf["Leaf Certificate\nCN=Igor Pavlov (7-Zip author)\nIssued by PCA, held by developer\n★ FilePublisher: CertPublisher CN checked here\n★ Publisher: also checks leaf CN\n★ LeafCertificate: TBS hash of THIS cert used"]
5
    File["PE Binary: 7z.exe\nSigned by leaf private key\nContains VERSIONINFO:\n  OriginalFileName=7z.exe\n  FileVersion=24.08.0.0\n★ FilePublisher: OriginalFileName + FileVersion checked here"]
6

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

11
    FilePublisher["FilePublisher Rule\nChecks ALL THREE:\n1. PCA TBS hash\n2. Leaf CN\n3. OriginalFileName + MinimumFileVersion"]
12

13
    File -.->|"rule binds to"| FilePublisher
14
    Leaf -.->|"CN check"| FilePublisher
15
    PCA -.->|"TBS hash"| FilePublisher
16

17
    style Root fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
18
    style PCA fill:#162032,stroke:#1e3a5f,color:#e2e8f0
19
    style Leaf fill:#162032,stroke:#1e3a5f,color:#e2e8f0
20
    style File fill:#0d1f12,stroke:#1a5c2a,color:#86efac
21
    style FilePublisher fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe

FilePublisher vs Other Levels — What Each Checks#

1
graph LR
2
    PCA_cert["PCA Certificate\nTBS Hash"]
3
    Leaf_CN["Leaf Certificate\nSubject CN"]
4
    FileName["File OriginalFileName\n(from VERSIONINFO)"]
5
    FileVer["File Version\n(MinimumFileVersion)"]
6

7
    PcaRule["PcaCertificate Rule"] -->|checks| PCA_cert
8
    PubRule["Publisher Rule"] -->|checks| PCA_cert
9
    PubRule -->|checks| Leaf_CN
10
    FPubRule["FilePublisher Rule"] -->|checks| PCA_cert
11
    FPubRule -->|checks| Leaf_CN
12
    FPubRule -->|checks| FileName
13
    FPubRule -->|checks| FileVer
14
    LeafRule["LeafCertificate Rule"] -->|checks| Leaf_cert["Leaf Certificate\nTBS Hash (not CN)"]
15

16
    style PcaRule fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
17
    style PubRule fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
18
    style FPubRule fill:#0d1f12,stroke:#1a5c2a,color:#86efac
19
    style LeafRule fill:#162032,stroke:#1e3a5f,color:#e2e8f0
20
    style PCA_cert fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
21
    style Leaf_CN fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
22
    style FileName fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
23
    style FileVer fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
24
    style Leaf_cert fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe

5. Where in the Evaluation Stack#

1
flowchart TD
2
    Start(["File Execution Requested\n(exe, dll, sys, ps1, msi...)"])
3
    HasSig{"Valid Authenticode\nsignature present?"}
4
    NoSig["No valid signature"]
5
    HashRuleCheck{"Explicit Hash allow\nrule for this file?"}
6
    FPCheck{"FilePublisher check:\nPCA TBS hash match?"}
7
    FPCheck2{"Leaf CN match?"}
8
    FPCheck3{"OriginalFileName match?"}
9
    FPCheck4{"FileVersion ≥ MinimumFileVersion?"}
10
    FPAllow(["ALLOW via FilePublisher"])
11
    PubCheck{"Publisher check:\nPCA TBS + Leaf CN?"}
12
    PubAllow(["ALLOW via Publisher"])
13
    PCACheck{"PcaCertificate check:\nPCA TBS hash only?"}
14
    PCAAllow(["ALLOW via PcaCertificate"])
15
    LeafCheck{"LeafCertificate check:\nLeaf cert TBS hash?"}
16
    LeafAllow(["ALLOW via LeafCertificate"])
17
    HashAllow(["ALLOW via Hash"])
18
    Block(["BLOCK — default deny\nEvent logged to CodeIntegrity log"])
19

20
    Start --> HasSig
21
    HasSig -->|"Yes"| FPCheck
22
    HasSig -->|"No"| NoSig
23
    NoSig --> HashRuleCheck
24
    HashRuleCheck -->|"Match"| HashAllow
25
    HashRuleCheck -->|"No match"| Block
26
    FPCheck -->|"Yes"| FPCheck2
27
    FPCheck -->|"No"| PubCheck
28
    FPCheck2 -->|"Yes"| FPCheck3
29
    FPCheck2 -->|"No"| PubCheck
30
    FPCheck3 -->|"Yes"| FPCheck4
31
    FPCheck3 -->|"No"| PubCheck
32
    FPCheck4 -->|"Yes (version OK)"| FPAllow
33
    FPCheck4 -->|"No (version too old)"| Block
34
    PubCheck -->|"Match"| PubAllow
35
    PubCheck -->|"No match"| PCACheck
36
    PCACheck -->|"Match"| PCAAllow
37
    PCACheck -->|"No match"| LeafCheck
38
    LeafCheck -->|"Match"| LeafAllow
39
    LeafCheck -->|"No match"| Block
40

41
    style Start fill:#162032,stroke:#1e3a5f,color:#e2e8f0
42
    style FPAllow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
43
    style PubAllow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
44
    style PCAAllow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
45
    style LeafAllow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
46
    style HashAllow fill:#0d1f12,stroke:#1a5c2a,color:#86efac
47
    style Block fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
48
    style FPCheck fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
49
    style FPCheck2 fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
50
    style FPCheck3 fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
51
    style FPCheck4 fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
52
    style HasSig fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
53
    style HashRuleCheck fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
54
    style NoSig fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
55
    style PubCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
56
    style PCACheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0
57
    style LeafCheck fill:#162032,stroke:#1e3a5f,color:#e2e8f0

Important: ConfigCI evaluates all applicable rules concurrently — a file is allowed if any one rule (from any level) permits it. The flowchart above shows logical precedence for understanding, not strict sequential evaluation.

The key behavior to note: if a FilePublisher rule matches on PCA + CN + FileName but the version check fails (file is too old), ConfigCI does not automatically fall through to a Publisher rule. The version-too-old case results in a block (assuming no other broader rule allows it). This is by design — it prevents downgrades.

6. XML Representation#

Complete FilePublisher Rule XML#

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

4

5
  <FileRules>
6

7
    <!--
8
      FileAttrib elements define file-specific attributes.
9
      Each FileAttrib is linked to one or more Signers via FileAttribRef.
10
      A single Signer can reference multiple FileAttribs (= trust multiple files
11
      from the same publisher).
12
    -->
13

14
    <FileAttrib
15
        ID="ID_FILEATTRIB_7Z_EXE"
16
        FriendlyName="7-Zip 7z.exe FilePublisher Rule"
17
        FileName="7z.exe"
18
        MinimumFileVersion="24.08.0.0"/>
19

20
    <FileAttrib
21
        ID="ID_FILEATTRIB_7ZFM_EXE"
22
        FriendlyName="7-Zip 7zFM.exe FilePublisher Rule"
23
        FileName="7zFM.exe"
24
        MinimumFileVersion="24.08.0.0"/>
25

26
    <FileAttrib
27
        ID="ID_FILEATTRIB_7ZG_EXE"
28
        FriendlyName="7-Zip 7zG.exe FilePublisher Rule"
29
        FileName="7zG.exe"
30
        MinimumFileVersion="24.08.0.0"/>
31

32
    <FileAttrib
33
        ID="ID_FILEATTRIB_7Z_DLL"
34
        FriendlyName="7-Zip 7-zip.dll FilePublisher Rule"
35
        FileName="7-zip.dll"
36
        MinimumFileVersion="24.08.0.0"/>
37

38
  </FileRules>
39

40
  <Signers>
41

42
    <!--
43
      A single Signer covers all files from the same publisher.
44
      FileAttribRef elements link this signer to specific file attributes.
45
      The Signer itself is a Publisher-level rule (PCA TBS + Leaf CN).
46
      FileAttribRef adds the per-file binding.
47
    -->
48
    <Signer ID="ID_SIGNER_7ZIP_001" Name="DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021">
49

50
      <!--
51
        CertRoot: TBS hash of the intermediate CA (PCA) certificate
52
        This uniquely identifies the CA that issued the leaf cert
53
      -->
54
      <CertRoot Type="TBS" Value="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE"/>
55

56
      <!--
57
        CertPublisher: exact Subject CN of the leaf (end-entity) certificate
58
        Case-sensitive match required
59
      -->
60
      <CertPublisher Value="Igor Pavlov"/>
61

62
      <!--
63
        FileAttribRef elements link this signer to specific FileAttrib rules.
64
        Without FileAttribRef, this would be a Publisher-level rule.
65
        WITH FileAttribRef, ConfigCI only allows files where BOTH:
66
          (a) The signer matches (PCA TBS + Leaf CN), AND
67
          (b) The file's OriginalFileName + FileVersion match this FileAttrib
68
      -->
69
      <FileAttribRef RuleID="ID_FILEATTRIB_7Z_EXE"/>
70
      <FileAttribRef RuleID="ID_FILEATTRIB_7ZFM_EXE"/>
71
      <FileAttribRef RuleID="ID_FILEATTRIB_7ZG_EXE"/>
72
      <FileAttribRef RuleID="ID_FILEATTRIB_7Z_DLL"/>
73

74
    </Signer>
75

76
    <!--
77
      Example: Google Chrome executables
78
      Multiple files from same publisher under one Signer
79
    -->
80
    <Signer ID="ID_SIGNER_GOOGLE_001" Name="DigiCert SHA2 Assured ID Code Signing CA">
81
      <CertRoot Type="TBS" Value="1FB86B1168EC831F616CE5A19D821E5A73510DC9..."/>
82
      <CertPublisher Value="Google LLC"/>
83
      <FileAttribRef RuleID="ID_FILEATTRIB_CHROME_EXE"/>
84
      <FileAttribRef RuleID="ID_FILEATTRIB_CHROME_DLL"/>
85
    </Signer>
86

87
  </Signers>
88

89
  <SigningScenarios>
90

91
    <SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode">
92
      <ProductSigners>
93
        <AllowedSigners>
94
          <AllowedSigner SignerID="ID_SIGNER_7ZIP_001"/>
95
          <AllowedSigner SignerID="ID_SIGNER_GOOGLE_001"/>
96
        </AllowedSigners>
97
      </ProductSigners>
98
    </SigningScenario>
99

100
  </SigningScenarios>
101

102
</SiPolicy>

XML Element Reference for FilePublisher#

Element	Attribute	Role in FilePublisher
`<FileAttrib>`	`ID`	Unique identifier for cross-referencing
`<FileAttrib>`	`FriendlyName`	Human-readable description
`<FileAttrib>`	`FileName`	Matches against PE `OriginalFileName` from VERSIONINFO
`<FileAttrib>`	`MinimumFileVersion`	Version floor — file must be ≥ this version
`<Signer>`	`ID`	Unique identifier
`<Signer>`	`Name`	Human-readable label (often PCA CN)
`<CertRoot>`	`Type="TBS"`, `Value`	TBS hash of PCA intermediate certificate
`<CertPublisher>`	`Value`	Exact leaf certificate Subject CN
`<FileAttribRef>`	`RuleID`	Links signer to a specific FileAttrib
`<AllowedSigner>`	`SignerID`	References a Signer in the signing scenario

How the Link Works: Signer + FileAttribRef = FilePublisher#

1
Evaluation logic (pseudo-code):
2
  foreach (Signer signer in AllowedSigners):
3
    if (signer.CertRoot.TBSHash == file.PCAChainTBSHash) AND
4
       (signer.CertPublisher.CN == file.LeafCertCN):
5
         // Publisher check passed
6
         if (signer.FileAttribRef.Count == 0):
7
           // No FileAttribRef → this is a Publisher rule → ALLOW
8
           return ALLOW
9
         else:
10
           // Has FileAttribRef → must also match file attributes
11
           foreach (FileAttribRef ref in signer.FileAttribRef):
12
             FileAttrib fa = GetFileAttrib(ref.RuleID)
13
             if (fa.FileName == file.OriginalFileName) AND
14
                (file.FileVersion >= fa.MinimumFileVersion):
15
               return ALLOW
16
           // No matching FileAttrib → this signer doesn't allow this file

7. PowerShell Examples#

Generate FilePublisher Policy from a Directory#

1
# Primary command: generate FilePublisher rules for all PE files in a directory
2
New-CIPolicy `
3
    -Level FilePublisher `
4
    -ScanPath "C:\Program Files\7-Zip" `
5
    -UserPEs `
6
    -Fallback Publisher, Hash `
7
    -OutputFilePath "C:\Policies\7ZipFilePublisher.xml"
8

9
# Parameters explained:
10
# -Level FilePublisher   : Primary rule level
11
# -ScanPath              : Directory to scan recursively
12
# -UserPEs               : Include user-mode executables (not just drivers)
13
# -Fallback Publisher, Hash :
14
#     If FilePublisher cannot be created (e.g., no VERSIONINFO),
15
#     first try Publisher level;
16
#     if Publisher also fails (unsigned), use Hash
17
# -OutputFilePath        : Output XML file

Generate FilePublisher Rule for a Single File#

1
# Single file, FilePublisher level
2
$rule = New-CIPolicyRule `
3
    -Level FilePublisher `
4
    -DriverFilePath "C:\Program Files\7-Zip\7z.exe" `
5
    -Fallback Hash
6

7
# Inspect what was generated
8
$rule | Format-List *
9

10
# The rule object will contain:
11
# - Signer with CertRoot (PCA TBS hash)
12
# - Signer with CertPublisher (leaf CN)
13
# - FileAttrib with FileName (OriginalFileName) and MinimumFileVersion
14
# - FileAttribRef linking the Signer to the FileAttrib

Inspect What FilePublisher Will Generate Before Running#

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

4
    $sig = Get-AuthenticodeSignature -FilePath $FilePath
5
    if ($sig.Status -ne "Valid") {
6
        Write-Warning "Signature status: $($sig.Status) — FilePublisher rule may not be possible"
7
        return
8
    }
9

10
    $vi = (Get-Item $FilePath).VersionInfo
11
    $leaf = $sig.SignerCertificate
12
    $chain = [System.Security.Cryptography.X509Certificates.X509Chain]::new()
13
    $chain.ChainPolicy.RevocationMode = "NoCheck"
14
    $null = $chain.Build($leaf)
15

16
    Write-Host "`n=== FilePublisher Rule Preview: $FilePath ===" -ForegroundColor Cyan
17

18
    Write-Host "`n[FILE ATTRIBUTES - FileAttrib element]"
19
    Write-Host "  OriginalFileName : $($vi.OriginalFilename)"
20
    Write-Host "  FileVersion      : $($vi.FileVersion)"
21
    Write-Host "  ProductName      : $($vi.ProductName)"
22
    Write-Host "  InternalName     : $($vi.InternalName)"
23
    Write-Host "  CompanyName      : $($vi.CompanyName)"
24

25
    Write-Host "`n[PUBLISHER - Signer CertRoot (PCA)]"
26
    if ($chain.ChainElements.Count -ge 2) {
27
        $pca = $chain.ChainElements[1].Certificate
28
        Write-Host "  PCA Subject      : $($pca.Subject)"
29
        Write-Host "  PCA Thumbprint   : $($pca.Thumbprint)"
30
        Write-Host "  PCA Valid Until  : $($pca.NotAfter)"
31
    }
32

33
    Write-Host "`n[PUBLISHER - Signer CertPublisher (Leaf CN)]"
34
    Write-Host "  Leaf CN          : $($leaf.GetNameInfo('SimpleName', $false))"
35
    Write-Host "  Leaf Subject     : $($leaf.Subject)"
36
    Write-Host "  Leaf Valid Until : $($leaf.NotAfter)"
37

38
    Write-Host "`n[RESULTING XML SKETCH]"
39
    Write-Host "  <FileAttrib FileName=`"$($vi.OriginalFilename)`" MinimumFileVersion=`"$($vi.FileVersion)`"/>"
40
    Write-Host "  <Signer><CertPublisher Value=`"$($leaf.GetNameInfo('SimpleName', $false))`"/>"
41
    Write-Host "          <FileAttribRef .../></Signer>"
42
}
43

44
# Usage
45
Get-WDACFilePublisherInfo -FilePath "C:\Program Files\7-Zip\7z.exe"
46
Get-WDACFilePublisherInfo -FilePath "C:\Program Files\Google\Chrome\Application\chrome.exe"

Merging FilePublisher Rules into a Base Policy#

1
# Create rules for multiple applications
2
$rules7zip  = New-CIPolicyRule -Level FilePublisher -DriverFilePath "C:\Program Files\7-Zip\7z.exe" -Fallback Hash
3
$rulesChrome = New-CIPolicyRule -Level FilePublisher -DriverFilePath "C:\Program Files\Google\Chrome\Application\chrome.exe" -Fallback Hash
4

5
# Combine all rules
6
$allRules = $rules7zip + $rulesChrome
7

8
# Generate a policy from combined rules
9
New-CIPolicy `
10
    -Rules $allRules `
11
    -OutputFilePath "C:\Policies\AppPolicy.xml"
12

13
# Convert to binary for deployment
14
ConvertFrom-CIPolicy `
15
    -XmlFilePath "C:\Policies\AppPolicy.xml" `
16
    -BinaryFilePath "C:\Policies\AppPolicy.cip"

Updating MinimumFileVersion After an App Update#

1
# Scenario: 7-Zip updated from 24.08 to 24.09
2
# Existing policy has MinimumFileVersion="24.08.0.0"
3
# New version is 24.09.0.0 — this PASSES the existing rule (>= 24.08)
4
# No policy update needed for upgrades!
5

6
# BUT: if you want to RAISE the floor (require 24.09+ to block 24.08):
7
# 1. Rescan with the new version installed
8
New-CIPolicy `
9
    -Level FilePublisher `
10
    -ScanPath "C:\Program Files\7-Zip" `
11
    -UserPEs `
12
    -Fallback Publisher, Hash `
13
    -OutputFilePath "C:\Policies\7ZipFilePublisher_v2409.xml"
14

15
# 2. The new rule will have MinimumFileVersion="24.09.0.0"
16
# 3. Deploy the updated policy — now v24.08 is blocked

8. The -SpecificFileNameLevel Option#

By default, FilePublisher uses OriginalFileName from the PE VERSIONINFO resource. The -SpecificFileNameLevel parameter allows you to change which VERSIONINFO field is used for the filename binding:

1
# Use ProductName instead of OriginalFileName
2
New-CIPolicy `
3
    -Level FilePublisher `
4
    -SpecificFileNameLevel ProductName `
5
    -ScanPath "C:\Program Files\Microsoft Office" `
6
    -UserPEs `
7
    -OutputFilePath "C:\Policies\OfficeByProduct.xml"

Available -SpecificFileNameLevel Values#

Value	VERSIONINFO Field	Use When
`OriginalFileName` (default)	`OriginalFileName`	Standard — most specific, anti-rename
`InternalName`	`InternalName`	When OriginalFileName is inconsistent across versions
`FileDescription`	`FileDescription`	Human-readable description
`ProductName`	`ProductName`	Broader — covers entire product suite with one name
`PackageFamilyName`	App package family name	UWP/MSIX applications
`FilePath`	On-disk file path	Path-based (broader, lower security)

ProductName Example: Covering Entire Office Suite#

1
# Instead of individual rules for winword.exe, excel.exe, powerpoint.exe...
2
# One FileAttrib per VERSIONINFO field value covers all Office binaries
3

4
# With -SpecificFileNameLevel ProductName:
5
# FileAttrib FileName="Microsoft Office" covers ALL Office executables
6
# that have ProductName="Microsoft Office" in their VERSIONINFO
7

8
New-CIPolicy `
9
    -Level FilePublisher `
10
    -SpecificFileNameLevel ProductName `
11
    -ScanPath "C:\Program Files\Microsoft Office\root\Office16" `
12
    -UserPEs `
13
    -Fallback Publisher, Hash `
14
    -OutputFilePath "C:\Policies\OfficeProductName.xml"

Security Trade-offs of -SpecificFileNameLevel#

Level	Specificity	Maintenance	Spoofing Risk
OriginalFileName	Highest	Per-binary	Must spoof exact original filename
InternalName	High	Per-binary	Must know internal name
ProductName	Medium	Per product suite	Must have same ProductName
FilePath	Low	Path-based	Can be bypassed with path manipulation

9. Pros and Cons#

Factor	Assessment
Specificity	High — triple-binding reduces false positives
Maintenance burden	Low-Medium — survives version updates; breaks on publisher change
Version control	Excellent — MinimumFileVersion blocks rollback attacks
Setup complexity	Medium — more elements per rule than Publisher
Policy XML size	Larger than Publisher (FileAttrib elements add overhead)
Works for unsigned files	No — requires Authenticode signature and VERSIONINFO
Works for MSI/script	No for MSI (see section 13); limited for scripts
Kernel driver support	Yes
User mode support	Yes
Survives app update	Yes — new version ≥ floor passes automatically
Survives cert renewal	Partially — leaf cert renewal OK; CA change breaks rule

Pros#

Best balance of security and manageability for most enterprise deployments
Version floor prevents rollback attacks without requiring policy updates on upgrades
Anti-rename: OriginalFileName cannot be changed without breaking the signature
Granular trust: one rule = one specific file from one specific publisher at a minimum version
Survives app updates: no policy change needed when vendor increments version
Widely supported: Microsoft-recommended primary level for enterprise WDAC policies

Cons#

The “pinned publisher” problem: if a vendor switches to a new CA or changes leaf cert CN (e.g., company rename), all FilePublisher rules for that vendor break
No MSI support: MSI installers lack PE VERSIONINFO — FilePublisher cannot be created for them
VERSIONINFO required: files with no embedded VERSIONINFO fall back to Publisher or Hash
Larger policy files: FileAttrib elements add XML overhead at scale
Version field inconsistency: some vendors use ProductVersion vs FileVersion inconsistently; FilePublisher uses FileVersion only
Not applicable for scripts: PowerShell scripts, batch files lack PE signatures (use Publisher or Hash for scripts)

10. Attack Resistance Analysis#

1
graph TD
2
    Attacker(["Attacker Goal:\nRun malicious binary\nnamed 7z.exe or with\nOriginalFileName=7z.exe"])
3

4
    A1["Attack 1: Rename legitimate malware to 7z.exe\nDrop in arbitrary location"]
5
    A1R(["BLOCKED\nOriginalFileName in PE VERSIONINFO\ndoes not match 7z.exe\nOn-disk name irrelevant"])
6

7
    A2["Attack 2: Set OriginalFileName=7z.exe in VERSIONINFO\nSelf-sign with attacker cert"]
8
    A2R(["BLOCKED\nPCA TBS hash won't match DigiCert\nLeaf CN won't match Igor Pavlov"])
9

10
    A3["Attack 3: Old vulnerable 7z.exe v22.01\n(below MinimumFileVersion 24.08)"]
11
    A3R(["BLOCKED\nFileVersion 22.01.0.0 < 24.08.0.0\nVersion floor rejects it"])
12

13
    A4["Attack 4: Steal Igor Pavlov's leaf cert\nSign malicious binary with OriginalFileName=7z.exe\nSet FileVersion=24.08.0.0"]
14
    A4R(["ALLOWED if undetected\nAll three checks pass\nRequires stealing private key"])
15

16
    A5["Attack 5: Legitimate 7z.exe v24.08.0.0\nPlaced in non-standard path\n(e.g. C:\\Temp\\7z.exe)"]
17
    A5R(["ALLOWED\nFilePublisher does NOT check path\nAny location is permitted\nAdd path rules if needed"])
18

19
    A6["Attack 6: Modified 7z.exe v24.08.0.0\n(content tampered after signing)"]
20
    A6R(["BLOCKED\nAuthenticode signature invalid\nModifying binary breaks signature"])
21

22
    Attacker --> A1 & A2 & A3 & A4 & A5 & A6
23
    A1 --> A1R
24
    A2 --> A2R
25
    A3 --> A3R
26
    A4 --> A4R
27
    A5 --> A5R
28
    A6 --> A6R
29

30
    style Attacker fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
31
    style A1 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
32
    style A2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
33
    style A3 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
34
    style A4 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
35
    style A5 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
36
    style A6 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
37
    style A1R fill:#0d1f12,stroke:#1a5c2a,color:#86efac
38
    style A2R fill:#0d1f12,stroke:#1a5c2a,color:#86efac
39
    style A3R fill:#0d1f12,stroke:#1a5c2a,color:#86efac
40
    style A4R fill:#1f0d0d,stroke:#7f1d1d,color:#fca5a5
41
    style A5R fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
42
    style A6R fill:#0d1f12,stroke:#1a5c2a,color:#86efac

Residual Risks Summary#

Risk	Severity	Mitigation
Stolen leaf cert private key	High	Code signing cert protection (HSM, short validity)
No path restriction	Medium	Add path-based rules or use PathPublisher for high-risk paths
MSI installers not covered	Medium	Use Publisher or Hash for MSI files
Vendor switches CA	Low	Monitor vendor PKI; maintain fallback Hash rules for critical files

11. When to Use vs When to Avoid#

1
flowchart TD
2
    Q1{"Is the file a PE\n(exe, dll, sys, ocx)?"}
3
    Q2{"Does the file have\na valid Authenticode\nsignature?"}
4
    Q3{"Does the file have\nVERSIONINFO\n(OriginalFileName field)?"}
5
    Q4{"Do you need to block\nold vulnerable versions?"}
6
    Q5{"Does the vendor update\nfrequently?"}
7
    Q6{"Do you need coverage of\nentire product suites?"}
8

9
    UseFP(["USE FilePublisher\nIdeal fit"])
10
    UseFPProductName(["USE FilePublisher\nwith -SpecificFileNameLevel ProductName"])
11
    UsePublisher(["Consider Publisher\nno version control"])
12
    UseHash(["Use Hash\nor MSI-specific approach"])
13
    FallbackPub(["Use -Fallback Publisher\nwhen scanning this file"])
14

15
    Q1 -->|"Yes"| Q2
16
    Q1 -->|"No — script/MSI/other"| UseHash
17
    Q2 -->|"Yes"| Q3
18
    Q2 -->|"No — unsigned"| UseHash
19
    Q3 -->|"Yes"| Q4
20
    Q3 -->|"No — no VERSIONINFO"| FallbackPub
21
    Q4 -->|"Yes — block rollback"| UseFP
22
    Q4 -->|"No — any version OK"| Q5
23
    Q5 -->|"Yes — frequent updates"| UseFP
24
    Q5 -->|"No — rare updates"| Q6
25
    Q6 -->|"Yes — entire suite"| UseFPProductName
26
    Q6 -->|"No — specific binary"| UseFP
27

28
    style UseFP fill:#0d1f12,stroke:#1a5c2a,color:#86efac
29
    style UseFPProductName fill:#0d1f12,stroke:#1a5c2a,color:#86efac
30
    style UsePublisher fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
31
    style UseHash fill:#162032,stroke:#1e3a5f,color:#e2e8f0
32
    style FallbackPub fill:#1a1a0d,stroke:#7a6a00,color:#fde68a
33
    style Q1 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
34
    style Q2 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
35
    style Q3 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
36
    style Q4 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
37
    style Q5 fill:#162032,stroke:#1e3a5f,color:#e2e8f0
38
    style Q6 fill:#162032,stroke:#1e3a5f,color:#e2e8f0

12. Double-Signed File Behavior#

Many Windows PE files carry multiple Authenticode signatures — for example, a primary SHA-256 signature and a legacy SHA-1 counter-signature. Some files (particularly Microsoft-signed OS components) may carry two full signature blocks.

When ConfigCI scans a double-signed file at FilePublisher level:

It processes each signature independently
For each signature, it extracts the PCA TBS hash and leaf CN
If the two signatures come from different CA chains (different PCA TBS hashes), two separate <Signer> elements are created, each with the same <FileAttribRef>
If the two signatures share the same PCA chain but differ only in leaf cert (rare), two <CertPublisher> matches are needed — this produces two <Signer> elements

Example: A file with SHA-256 and SHA-1 dual signatures

1
<FileRules>
2
  <FileAttrib
3
      ID="ID_FILEATTRIB_EXAMPLE"
4
      FriendlyName="example.dll"
5
      FileName="example.dll"
6
      MinimumFileVersion="10.0.19041.0"/>
7
</FileRules>
8

9
<Signers>
10
  <Signer ID="ID_SIGNER_SHA256" Name="Microsoft Code Signing PCA 2011">
11
    <CertRoot Type="TBS" Value="4E80BE107C860A21A..."/>
12
    <CertPublisher Value="Microsoft Windows"/>
13
    <FileAttribRef RuleID="ID_FILEATTRIB_EXAMPLE"/>
14
  </Signer>
15

16
  <Signer ID="ID_SIGNER_SHA1" Name="Microsoft Code Signing PCA">
17
    <CertRoot Type="TBS" Value="580A6F4CC4E4B669B..."/>
18
    <CertPublisher Value="Microsoft Windows"/>
19
    <FileAttribRef RuleID="ID_FILEATTRIB_EXAMPLE"/>
20
  </Signer>
21
</Signers>

At enforcement time: ConfigCI checks all signatures in the file against all rules. The file is allowed if any one signature matches any one rule. Dual-signed files therefore have two chances to match — this is the intended behavior and increases robustness.

Policy size implication: Large directories of dual-signed Microsoft OS files will produce roughly 2× the expected number of Signer elements. This is normal.

13. MSI and Non-PE File Exception#

Why MSI Files Cannot Use FilePublisher#

MSI files are structured storage files — they are not Portable Executable (PE) format binaries. As a result:

They do not have a VS_VERSIONINFO resource structure
There is no OriginalFileName field
There is no FileVersion field in PE format

Without OriginalFileName and FileVersion, ConfigCI cannot construct the <FileAttrib> element that is essential for FilePublisher. The scan will fall back to the next level in -Fallback.

What to Use Instead for MSI Files#

File Type	Recommended Rule Level	Reason
MSI installer	Publisher	MSI carries Authenticode; use publisher trust
MSIX package	Publisher or PackageFamilyName	MSIX has its own trust model
PowerShell scripts (.ps1)	Publisher (script signing)	Scripts don’t have PE VERSIONINFO
Batch files (.bat/.cmd)	Hash	Batch files rarely signed
VBScript (.vbs)	Hash	Rarely signed
DLL (with VERSIONINFO)	FilePublisher	Normal PE with VERSIONINFO
EXE (with VERSIONINFO)	FilePublisher	Normal PE with VERSIONINFO
SYS driver (with VERSIONINFO)	FilePublisher	Kernel drivers typically have VERSIONINFO

Handling MSI in a FilePublisher Policy#

1
# Scan a directory containing both PE files and MSI installers
2
# -Fallback Publisher handles MSI (and other non-VERSIONINFO files)
3
New-CIPolicy `
4
    -Level FilePublisher `
5
    -ScanPath "C:\Software\Adobe" `
6
    -UserPEs `
7
    -Fallback Publisher, Hash `
8
    -OutputFilePath "C:\Policies\AdobePolicy.xml"
9

10
# The resulting XML will contain:
11
# - FilePublisher rules for .exe and .dll files (have VERSIONINFO)
12
# - Publisher rules for .msi files (no VERSIONINFO, fallback to Publisher)
13
# - Hash rules for truly unsigned files (final fallback)

14. Real-World Scenario#

Scenario: Enterprise deploying 7-Zip via SCCM with update-resilient policy

1
sequenceDiagram
2
    participant Admin as IT Admin
3
    participant RefPC as Reference Machine
4
    participant PS as PowerShell ConfigCI
5
    participant SCCM as SCCM/Intune
6
    participant Fleet as Enterprise Fleet (1000 PCs)
7
    participant SevenZip as 7-Zip Update Server
8

9
    Note over Admin,Fleet: Initial Deployment
10

11
    Admin->>RefPC: Install 7-Zip v24.08 on reference machine
12
    Admin->>PS: New-CIPolicy -Level FilePublisher -ScanPath "C:\Program Files\7-Zip"
13
    PS->>RefPC: Reads 7z.exe VERSIONINFO: OriginalFileName=7z.exe, FileVersion=24.08.0.0
14
    PS->>RefPC: Reads Authenticode: PCA=DigiCert Trusted G4, Leaf CN=Igor Pavlov
15
    PS-->>Admin: Generates FileAttrib(FileName=7z.exe, MinimumFileVersion=24.08.0.0)
16
    PS-->>Admin: Generates Signer(CertRoot=[DigiCert TBS], CertPublisher=Igor Pavlov)
17
    Admin->>SCCM: Upload policy + deploy 7-Zip v24.08 package
18
    SCCM->>Fleet: Deploy policy + 7-Zip v24.08
19
    Fleet->>Fleet: 7z.exe runs: PCA match + Leaf CN match + FileName match + 24.08≥24.08 ✓
20

21
    Note over Admin,Fleet: 3 months later: 7-Zip v24.09 released
22

23
    SevenZip->>Fleet: Windows Update / SCCM delivers 7-Zip v24.09
24
    Fleet->>Fleet: New 7z.exe: OriginalFileName=7z.exe, FileVersion=24.09.0.0
25
    Fleet->>Fleet: Policy check: PCA match ✓ Leaf CN=Igor Pavlov ✓ FileName=7z.exe ✓
26
    Fleet->>Fleet: Version check: 24.09.0.0 >= 24.08.0.0 ✓
27
    Fleet-->>Fleet: ALLOWED — no policy update required!
28

29
    Note over Admin,Fleet: Security incident: 7-Zip v22.01 (vulnerable) found on some machines
30

31
    Admin->>Fleet: Attempt to run v22.01 7z.exe
32
    Fleet->>Fleet: Policy check: PCA ✓ Leaf CN ✓ FileName ✓
33
    Fleet->>Fleet: Version check: 22.01.0.0 >= 24.08.0.0? NO
34
    Fleet-->>Fleet: BLOCKED — version floor prevents rollback
35
    Fleet->>Fleet: Event 3077 logged to CodeIntegrity audit log
36

37
    style Admin fill:#162032,stroke:#1e3a5f,color:#e2e8f0
38
    style RefPC fill:#162032,stroke:#1e3a5f,color:#e2e8f0
39
    style PS fill:#1a0d2e,stroke:#6b21a8,color:#d8b4fe
40
    style SCCM fill:#162032,stroke:#1e3a5f,color:#e2e8f0
41
    style Fleet fill:#0d1f12,stroke:#1a5c2a,color:#86efac
42
    style SevenZip fill:#162032,stroke:#1e3a5f,color:#e2e8f0

15. OS Version and Compatibility Notes#

Feature	Windows Version	Notes
FilePublisher level (UMCI)	Windows 10 1703+	FileAttrib/FileAttribRef elements introduced
FilePublisher level (KMCI)	Windows 10 1703+	Kernel mode FilePublisher support
`-SpecificFileNameLevel`	Windows 10 1709+	ProductName, InternalName, etc.
`PackageFamilyName` in FileAttrib	Windows 10 1709+	UWP app trust
Multiple active policies	Windows 10 1903+	Enables supplemental + base policy combo
CiTool.exe deployment	Windows 11 22H2+	No-reboot policy update
HVCI + FilePublisher	Windows 10 1703+	HVCI enforces KMCI FilePublisher rules strictly
`New-CIPolicyRule -Level FilePublisher`	Windows 10 1703+	PowerShell cmdlet support

Minimum Version for FilePublisher#

FilePublisher is not available on Windows 10 1607 (Anniversary Update) and earlier. On those versions, Publisher is the most specific cert-based level available. Always check %SystemRoot%\System32\CI.dll version if deploying to mixed fleets with older Windows versions.

16. Common Mistakes and Gotchas#

Mistake 1: Forgetting FilePublisher Does NOT Check File Path#

A FilePublisher rule allows 7z.exe (with matching publisher and version) anywhere on disk — C:\Program Files\7-Zip\7z.exe, C:\Temp\7z.exe, C:\Users\Public\7z.exe. If you need path restriction, combine FilePublisher with path-based controls or use separate path deny rules.

Mistake 2: Expecting Version Downgrades to Be Blocked When Using Publisher Fallback#

If your policy has a FilePublisher rule for 7z.exe with MinimumFileVersion=24.08 and a Publisher rule for Igor Pavlov (added as fallback), the Publisher rule has no version restriction. An old v22.01 7z.exe that fails FilePublisher will still be allowed by the Publisher fallback rule.

Solution: If version protection matters, do NOT include a Publisher-level fallback for the same vendor. Use only Hash as the fallback, or accept that unsigned/no-VERSIONINFO files are blocked.

Mistake 3: OriginalFileName vs On-Disk Filename Confusion#

1
# Confusing scenario:
2
# VERSIONINFO OriginalFileName: 7z.exe
3
# VERSIONINFO FileVersion: 24.08.0.0
4
# Signed by: Igor Pavlov cert chain
5

6
# FilePublisher rule has FileName="7z.exe"
7
# Even though file is named "compression-tool.exe" on disk,
8
# it WILL match the FilePublisher rule because OriginalFileName="7z.exe"
9
# This is by design — prevents bypass by renaming

Mistake 4: Version String Format Mismatches#

FileVersion in PE VERSIONINFO is a 64-bit value (four 16-bit fields). MinimumFileVersion must be expressed as Major.Minor.Build.Revision. Mismatches in field count cause evaluation errors:

1
<FileAttrib MinimumFileVersion="24.08.0"/>
2

3
<FileAttrib MinimumFileVersion="24.08.0.0"/>

Mistake 5: MSI Silently Falls Back to Publisher#

When scanning a directory containing both PE files and MSI files with -Level FilePublisher -Fallback Publisher, the resulting policy will silently contain Publisher rules for the MSI files. This is broader than expected. Audit the generated XML to confirm which rules were created at which level.

1
# After generating policy, inspect what levels were actually used
2
[xml]$policy = Get-Content "C:\Policies\MyPolicy.xml"
3
$signers = $policy.SiPolicy.Signers.Signer
4
$fileAttribs = $policy.SiPolicy.FileRules.FileAttrib
5

6
Write-Host "FilePublisher rules (have FileAttribRef): $(($signers | Where-Object { $_.FileAttribRef }).Count)"
7
Write-Host "Publisher rules (no FileAttribRef):        $(($signers | Where-Object { -not $_.FileAttribRef }).Count)"
8
Write-Host "FileAttrib elements:                        $($fileAttribs.Count)"

Mistake 6: The “Pinned Publisher” Problem After Cert Renewal#

If a vendor renews their code signing certificate and the new leaf certificate has a different CN (e.g., company renamed from “Acme Corp” to “Acme Software LLC”), all FilePublisher rules with <CertPublisher Value="Acme Corp"/> will stop matching. The new binaries will be blocked.

Mitigation strategies:

Subscribe to vendor security announcements for PKI changes
Keep audit mode enabled on a subset of machines to detect future breaks early
Maintain -Fallback Hash rules for critical business applications

Mistake 7: Ignoring the FileVersion vs ProductVersion Distinction#

MinimumFileVersion uses the FileVersion field from VERSIONINFO, not ProductVersion. Some vendors increment ProductVersion for marketing releases but FileVersion lags behind, or vice versa. Always verify which field is actually changing on update by inspecting with (Get-Item $path).VersionInfo.

17. Summary Table#

Property	Value
Rule Level Name	FilePublisher
Binding 1	Intermediate CA (PCA) TBS hash — `<CertRoot Type="TBS">`
Binding 2	Leaf certificate Subject CN — `<CertPublisher Value="..."/>`
Binding 3	OriginalFileName from PE VERSIONINFO — `<FileAttrib FileName="..."/>`
Binding 4	MinimumFileVersion from PE VERSIONINFO — `<FileAttrib MinimumFileVersion="..."/>`
Version Floor Direction	≥ MinimumFileVersion (higher versions pass; lower versions blocked)
Filename Field Used	OriginalFileName by default; overridable via `-SpecificFileNameLevel`
Works for MSI	No — MSI lacks PE VERSIONINFO; falls back to Publisher or Hash
Works for Scripts	No — scripts lack PE signatures and VERSIONINFO
Survives App Updates	Yes — newer versions pass the floor automatically
Survives Cert Renewal	Partial — leaf CN change breaks rule; CA change breaks rule
Blocks Version Rollback	Yes — MinimumFileVersion enforces floor
XML Elements	`<FileAttrib>` + `<Signer>` + `<CertRoot>` + `<CertPublisher>` + `<FileAttribRef>`
PowerShell Parameter	`-Level FilePublisher`
Key Advantage	Triple binding = best security/maintenance balance
Key Limitation	Publisher infrastructure change requires policy update
Recommended Fallback	`-Fallback Publisher, Hash`
Introduced	Windows 10 1703
Microsoft Recommendation	Primary level for most enterprise deployments