WDAC Policy Boot-Stop Failure and Emergency Recovery

An App Control policy that blocks a boot-critical driver or core system component causes a boot-stop failure (BSOD) and prevents Windows from starting. When standard in-band recovery is not possible, administrators must use out-of-band firmware-level procedures to regain file-system access, remove problematic policy artifacts, and restore a secure boot posture.

Causes of Boot-Stop Failure

A WDAC policy that blocks a boot-critical driver or core system component prevents Windows from completing startup, resulting in a boot-stop failure (BSOD). Boot failures can also occur when a signed policy is tampered with, when policy artifacts are deleted directly without an authorized replacement, or when a signer mismatch is encountered — all of which Code Integrity treats as unauthorized modification attempts.

Important:
The policy retirement procedure described in the Standard WDAC Policy Removal and Retirement Procedure topic is an in-band, planned administrative workflow performed while Windows and the BigFix Agent are fully operational. The emergency recovery procedures described in this topic are out-of-band recovery workflows used when a policy-related boot failure prevents Windows or the BigFix Agent from starting, or when a signed policy cannot be updated using an authorized signer. Do not apply out-of-band recovery steps to a functioning system undergoing planned decommission.

First-Line Automated Recovery — Option 10 (Enabled: Boot Audit On Failure)

Option 10 serves as the primary OS-level safety net for boot-critical driver blocks. If a boot-critical driver is blocked during startup, Windows automatically shifts policy enforcement to Audit Mode for that driver, allowing the operating system to complete boot processing so administrators can investigate via event logs.

Attention:
Option 10 mitigates boot failures caused by blocked drivers only. It does not prevent all categories of boot-stop failure and does not override signed-policy UEFI tamper protections. For failures outside the scope of Option 10 — including signed policy removal without an authorized signer — firmware-level recovery is required.

Firmware Recovery via Secure Boot

When a policy block prevents Windows from booting entirely, disabling UEFI Secure Boot in system firmware provides the out-of-band override. Disabling Secure Boot unbinds hardware-rooted policy checks and suspends WDAC policy enforcement across both kernel and user modes, granting administrative file-system access to clear problematic policy binaries.

This approach also applies when a signed Base Policy must be retired but its original signing certificate is lost, expired, or otherwise unavailable, and a replacement policy cannot be authorized through <UpdatePolicySigners>. Under these conditions, Windows Code Integrity rejects all in-band update attempts. Disabling Secure Boot bypasses the signature requirement, allowing administrators to directly delete .cip policy artifacts without triggering a BSOD.

BitLocker Impact During Recovery

Disabling UEFI Secure Boot alters TPM Platform Configuration Register (PCR 7) measurements that BitLocker uses to validate platform integrity. Because these integrity checks fail under a modified boot state, the TPM will refuse to automatically unseal the Volume Master Key, requiring administrators to enter the system's 48-digit BitLocker Recovery Key at startup to unlock the OS volume.

To avoid repeated recovery key prompts during multi-reboot recovery procedures, administrators should temporarily suspend BitLocker protection before disabling Secure Boot. Once emergency policy remediation is complete and UEFI Secure Boot has been re-enabled, BitLocker protection must be resumed immediately to re-bind TPM PCR 7 measurements and restore standard drive encryption posture.

Remember:
Suspending BitLocker is a temporary operational step for the duration of the recovery procedure only. Failing to resume BitLocker protection after re-enabling Secure Boot leaves the drive encryption posture degraded.

Emergency Artifact Cleanup Locations

Emergency recovery requires removing the targeted .cip policy file from both active policy storage locations:

  • %OSDrive%\Windows\System32\CodeIntegrity\CiPolicies\Active\{PolicyId}.cip
  • <EFI System Partition>\Microsoft\Boot\CiPolicies\Active\{PolicyId}.cip
Warning:
Because emergency removal operates out-of-band without BigFix® orchestration, policy binaries must be verified as completely removed from both active storage locations before restoring Secure Boot. A residual .cip file in either path leaves Code Integrity partially locked and will re-trigger a BSOD on the next restart.

Posture Restoration

Re-enabling Secure Boot in system firmware re-establishes the hardware-rooted security baseline. Complete all of the following steps before returning the endpoint to managed operation:

  1. Verify that the .cip policy artifact has been removed from both active storage locations (see Emergency Artifact Cleanup Locations above).
  2. Re-enable Secure Boot in system firmware.
  3. If BitLocker protection was suspended during the recovery procedure, resume BitLocker protection immediately after Secure Boot is restored to re-bind TPM PCR 7 measurements and restore drive encryption posture.
  4. Verify that Windows starts normally and that the BigFix Agent re-establishes contact with the Root Server.