Option 5 — Enabled Default Policy#

The Reservation Pattern in WDAC Policy Design#

App Control for Business (formerly WDAC) policy rule options are encoded as a compact bitmask inside the policy binary. Microsoft follows a conservative extension model: before a new behavioral option is shipped to end-users, the bit position is claimed and documented in advance so that:

1. Policy files authored today remain forward-compatible. When the OS eventually implements the behavior, existing policies that already set the flag will automatically gain the new capability without re-authoring.
2. Policy tooling (ConfigCI, WDAC Wizard, Intune) can expose the option early so administrators can learn about it and plan deployment before the feature lands.
3. Interoperability with pre-release builds is preserved. Windows Insider / Preview channels may implement the flag earlier; reservation ensures production policies can be tested on those builds.

The conceptual intent suggested by the name — inherit from a default policy — points toward a future model where a supplemental policy can explicitly delegate evaluation back to the default base policy for a given signer or path, rather than adding its own rules on top. This would allow a supplemental policy to say “use whatever the base says here” rather than remaining silent (which already causes fall-through to the base). The exact semantics remain unspecified in public documentation.

Enable Option 5#

1
# Enable:Inherit Default Policy on a base policy
2
Set-RuleOption -FilePath "C:\Policies\MyBasePolicy.xml" -Option 5
3

4
# Enable on a supplemental policy
5
Set-RuleOption -FilePath "C:\Policies\MySupplementalPolicy.xml" -Option 5

Disable / Remove Option 5#

1
# Remove the option (return to default — absent from XML)
2
Remove-RuleOption -FilePath "C:\Policies\MyBasePolicy.xml" -Option 5

Verify Current State#

1
# Read back all options present in a policy file
2
[xml]$policy = Get-Content "C:\Policies\MyBasePolicy.xml"
3
$policy.SiPolicy.Rules.Rule | Select-Object -ExpandProperty Option

Full Scripted Example with Conversion#

1
$policyPath   = "C:\Policies\MyBasePolicy.xml"
2
$binaryOutput = "C:\Policies\MyBasePolicy.p7b"
3

4
# 1. Set option 5 (reserved, no current effect)
5
Set-RuleOption -FilePath $policyPath -Option 5
6

7
# 2. Confirm it was written
8
$xml = [xml](Get-Content $policyPath)
9
$opts = $xml.SiPolicy.Rules.Rule | Select-Object -ExpandProperty Option
10
Write-Host "Active options: $($opts -join ', ')"
11

12
# 3. Compile to binary
13
ConvertFrom-CIPolicy -XmlFilePath $policyPath -BinaryFilePath $binaryOutput
14

15
# 4. (Optional) Deploy via CiTool
16
CiTool --update-policy $binaryOutput

Note: Because this option currently has no runtime effect, steps 1–2 are purely administrative. The compiled binary will contain the bit, but the enforcement engine will ignore it.

Option Present in Policy XML#

When Option 5 is set via Set-RuleOption, the following element appears inside the <Rules> block of the policy XML:

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

5
  <VersionEx>10.0.0.0</VersionEx>
6
  <PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
7
  <PlatformID>{2E07F7E4-194C-4D20-B96C-1498069CCC11}</PlatformID>
8

9
  <Rules>
10
    <Rule>
11
      <Option>Enabled:Inherit Default Policy</Option>
12
    </Rule>
13
    <Rule>
14
      <Option>Enabled:Unsigned System Integrity Policy</Option>
15
    </Rule>
16
  </Rules>
17

18
</SiPolicy>

Option Absent from Policy XML#

When the option is not set (the default state), the <Rule> element for Option 5 simply does not appear. There is no explicit “disabled” element; absence equals disabled.

Bitmask Position#

Inside the compiled binary (.p7b / .bin), policy rule options are stored as a 32-bit flags field. Option 5 occupies bit position 5 (0-indexed from the LSB). Its hex mask value is 0x00000020.

Compatibility Matrix#

Scenario: Enterprise Prepares Policies for an Upcoming Windows Feature Release#

An enterprise security team receives a preview of an upcoming Windows feature that will use Option 5 to allow supplemental policies to explicitly inherit rules from the base. They decide to pre-stage their supplemental policies with the flag set so that, when the OS update ships, no policy re-deployment is needed.

sequenceDiagram
    actor Admin as Security Admin
    participant VS as WDAC Wizard / ConfigCI
    participant GIT as Policy Git Repo
    participant INTUNE as Microsoft Intune
    participant OS as Windows 11 (Insider)
    participant CI as CI.dll (Enforcement)

    Admin->>VS: Create supplemental policy for LOB apps
    VS->>VS: Generate XML with standard rules
    Admin->>VS: Set-RuleOption -Option 5 (future-compat)
    VS->>GIT: Commit policy XML with Option 5 present
    GIT->>Admin: PR approved, policy tagged v1.2

    Admin->>VS: ConvertFrom-CIPolicy → .p7b binary
    Admin->>INTUNE: Upload .p7b as Custom OMA-URI
    INTUNE->>OS: Deploy policy to pilot devices

    OS->>CI: Load policy binary on boot
    CI->>CI: Parse option bitmask — bit 5 set
    CI->>CI: No handler registered → skip (today)
    CI->>OS: Policy active, rules enforced normally

    Note over CI,OS: On future OS update, bit 5\nhandler activates automatically\n— no policy re-deployment needed

    Admin->>OS: Upgrade to future Windows build
    OS->>CI: Reload policy — bit 5 handler now active
    CI->>CI: Supplemental inherits base signer rules
    CI->>OS: Enhanced inheritance behavior enabled

This workflow illustrates that setting the option early is purely administrative but carries zero risk and zero overhead today. The only cost is a single additional <Rule> element in the XML.

Potential Future Risk#

If and when Microsoft implements the behavior behind this flag, misconfiguring it could produce unintended rule inheritance. For example, if the future semantics are “supplemental policy inherits all deny rules from base,” then setting this flag on a supplemental policy that was designed to be additive-only could cause unexpected blocks.

Misconfiguration Consequence Matrix (Current + Future Projection)#

flowchart LR
    WRONG["Option 5 set\nincorrectly (future)"]
    RIGHT["Option 5 omitted\nor set intentionally"]

    WRONG --> W1["Unexpected rule\ninheritance from base"]
    WRONG --> W2["Supplemental may\nbecome more restrictive\nthan intended"]
    RIGHT --> R1["Predictable behavior\nmatch policy intent"]
    RIGHT --> R2["No cross-policy\nrule bleed"]

    style WRONG fill:#1f0d0d,color:#fca5a5
    style RIGHT fill:#0d1f12,color:#86efac
    style W1 fill:#1f0d0d,color:#fca5a5
    style W2 fill:#1f0d0d,color:#fca5a5
    style R1 fill:#0d1f12,color:#86efac
    style R2 fill:#0d1f12,color:#86efac

Supplemental Policy Constraints Context#

Supplemental policies can only expand what a base policy allows — they cannot tighten restrictions. Option 5 may eventually let a supplemental policy explicitly acknowledge its inheritance relationship with a specific base, potentially unlocking behaviors like:

• Explicit base-signer trust propagation
• Rule deduplication (supplemental does not re-state rules already in base)
• Priority ordering (supplemental defers to base for unresolved code identities)

For now, placing Option 5 in a supplemental policy is harmless and syntactically correct.