Signed WDAC: What Changes to Secure Boot, UEFI and Recovery?

Windows Defender Application Control, now App Control for Business, controls what software Windows is allowed to run at the Kernel level. Applications, scripts and drivers can be approved by publisher, file identity, certificate or hash, with anything outside the policy blocked.

An enforced WDAC policy is already a strong security control. Signing the policy takes it further because it protects the WDAC policy itself and links that protection into the UEFI and Secure Boot environment.

That turned out to be rather more significant than simply putting a digital signature on a .cip file.

In my home lab, systems that had previously booted happily from deployment USB media stopped doing so after the WDAC policy was signed. Hyper-V VMs showed similar behaviour when rebuilding from a mounted ISO.

Apparently I had secured the machines against unauthorised software and, rather efficiently, my normal rebuild process. This is not the first time I've "secured" myself out of my own system, everyday is a school day.

Secure Boot

Secure Boot protects the system before Windows starts.

The UEFI firmware checks that the boot software is signed by a trusted authority before allowing it to execute. Windows Boot Manager then continues that trusted process through the Windows loader, kernel and boot-critical components.

Secure Boot therefore answers a fairly simple question:

Can I trust what is starting Windows?

Once Windows is running, Secure Boot does not decide whether every application or driver should be allowed to execute.

That is where WDAC comes in.

WDAC

WDAC extends that trust into Windows.

Instead of allowing software to run and waiting for antivirus or EDR to decide whether it is malicious, WDAC defines what is permitted to execute.

The rule type determines how broad that trust becomes.

Rule	What It Trusts	Security	Maintenance
Hash	One exact binary	Very High	Very High
FilePublisher	Specific signed file, publisher and minimum version	High	Medium
Publisher	Software signed by an approved publisher	Medium	Low
Certificate	Software signed by an approved certificate	Medium	Low
FileName	Trusted file metadata	Medium-Low	Medium
FilePath	Software running from an approved location	Low	Low

Publisher rules are convenient but relatively broad. Trusting software signed by Dell, HP or Microsoft can potentially trust other applications using the same approved publisher identity.

FilePublisher is more restrictive because it includes the particular file and minimum version.

For a tightly controlled environment I prefer:

-Level FilePublisher -Fallback Hash

This gives signed applications some flexibility to update while unsigned or unusual applications fall back to an exact hash.

Unsigned WDAC

An unsigned WDAC policy does not mean the applications themselves are unsigned.

The policy can still validate software using Publisher, FilePublisher, certificates and hashes.

Unsigned refers to the WDAC policy itself.

An enforced unsigned policy can therefore provide very strong application control, but someone with sufficient administrative access may potentially remove or replace that policy.

If an attacker gains Administrator access, the policy deciding what Administrator is allowed to run becomes an obvious target.

Signed WDAC

Signing addresses that weakness.

The WDAC policy is digitally signed using an authorised policy-signing certificate. Windows verifies that the security policy making application control decisions has not been modified.

More importantly, that protection extends beyond C:\Windows. Signed policies are written to the EFI System Partition under \EFI\Microsoft\Boot\CiPolicies\Active\ and written into UEFI NVRAM variables.

Once activated, the policy becomes a persistent part of the pre-OS trust state. Removing or updating it requires deploying a new policy signed by the same authorized key, simply deleting the .cip file will render the system unbootable.

VBS and HVCI

Virtualization-Based Security (VBS) uses the Windows hypervisor to create a protected area of memory. HVCI, or Memory Integrity, uses that isolation to protect Code Integrity from normal kernel-mode code.

This works particularly well with WDAC. WDAC defines which applications and drivers are trusted, while HVCI helps protect the mechanism enforcing those decisions from kernel-level tampering.

Signing then protects the WDAC policy itself.

Together the controls reinforce each other: Secure Boot protects startup, HVCI protects Code Integrity, WDAC controls what can execute and signing protects the WDAC policy from being replaced.

Why UEFI Matters

Without UEFI-backed protection, bypassing WDAC offline would be relatively straightforward.

Assuming Bitlocker isn't enabled, boot WinPE, mount the Windows volume, delete the policy and restart.

Signed WDAC is designed to make that considerably harder.

The machine expects the authorised signed policy to remain present and valid. Removing or replacing it incorrectly is likely to stop Windows booting.

It's worth being clear about what is happening here:

• Normal signed WDAC does not replace the UEFI Platform Key, KEK, db or dbx.

• Secure Boot remains the root of trust.

• Signed WDAC uses that protected environment to protect its own policy.

• It is therefore more accurate to say that signing extends the Secure Boot trust model into Windows Code Integrity.

What About the Windows Boot Files?

Signed WDAC does not re-sign files such as:

bootmgfw.efi
winload.efi
ntoskrnl.exe

Secure Boot and Windows Trusted Boot already protect those components.

WDAC controls the drivers and executable code Windows is permitted to load.

Signing then protects the WDAC policy from being changed.

Each control has a different job, but together they create a much stronger chain of trust.

USB and Hyper-V Generation 2

This is where signing becomes operationally challenging.

Because signed WDAC writes state into UEFI NVRAM, the hardware enforces this security state before the OS even loads.

When you attempt to boot a standard WinPE environment, mounted ISO or deployment USB, the UEFI environment evaluates that boot media against the machine's protected state.

If the USB media lacks the necessary signed binaries or policy context, it gets blocked.

The ease of wiping and rebuilding physical devices or VMs from a USB or mounted ISO is officially over, at least without a trip into the firmware settings to disable Secure Boot.

PCRs, Measured Boot and BitLocker

The TPM adds another layer through Platform Configuration Registers, or PCRs.

Secure Boot determines whether trusted boot components are allowed to execute. Measured Boot records evidence of what actually happened during startup.

BitLocker commonly uses PCR 7 and PCR 11 when sealing its TPM protector on Secure Boot systems. Changes to the protected boot environment can therefore cause BitLocker to see a different measured state and request the recovery key.

For that reason, I temporarily suspend BitLocker before the initial signed WDAC deployment.

First check the current PCR profile:

manage-bde -protectors -get C:

Then suspend BitLocker:

Suspend-BitLocker `
    -MountPoint "C:" `
    -RebootCount 0

Deploy the signed WDAC policy and reboot.

Once the machine has successfully started and the policy is confirmed as active:

Resume-BitLocker -MountPoint "C:"

Suspending BitLocker does not decrypt the disk. It temporarily prevents a planned boot-security change from becoming an unnecessary recovery-key exercise.

And, obviously, make sure the recovery key actually exists somewhere useful before changing Secure Boot or deploying signed WDAC.

Finding that out afterwards would add an unnecessary level of excitement.

Unsigned vs Signed WDAC

The practical difference is fairly simple.

Capability	Unsigned WDAC	Signed WDAC
Controls applications and drivers	Yes	Yes
Uses Publisher/FilePublisher/Hash rules	Yes	Yes
Works with VBS/HVCI	Yes	Yes
Protects the policy from replacement	No	Yes
Makes Administrator policy tampering harder	No	Yes
Uses UEFI/Secure Boot for policy protection	No	Yes
Makes offline policy bypass harder	No	Yes
Changes recovery considerations	Limited	Significant

Final Thoughts

Secure Boot protects how Windows starts.

HVCI protects Code Integrity.

WDAC controls what Windows is allowed to run. Signing then protects the WDAC policy itself and ties that protection back into the UEFI and Secure Boot environment.

That is a great security model.

I learned the hard way after discovering that my USB media and ISOs I had been happily using to rebuild machines had suddenly become considerably less useful.

So, technically, signed WDAC worked perfectly.

I had successfully stopped unauthorised software, protected the policy from administrators and made offline tampering considerably harder.

Unfortunately, the administrator it was protecting the machines from appeared to be me.