Share via

Secure Boot failure caused by OEM SkuSiPolicy.p7b — reproducible across Insider builds

F G 271 Reputation points
2026-05-01T21:55:01.1333333+00:00

This report was prepared with the help of Windows Copilot:

Summary

On systems that include an OEM‑injected SkuSiPolicy.p7b in the EFI partition (example: Dell XPS 8940), Secure Boot fails to validate Insider bootloaders and WinRE. Removing or renaming the policy file and performing a Secure Boot OFF → ON cycle restores normal boot behavior across all OS partitions and recovery environments.

This appears to be a regression in how Insider builds handle the SkuSiPolicy signature chain.

Affected Systems

  • Dell XPS 8940 (confirmed)
  • Other OEM systems that ship EFI\Microsoft\Boot\SkuSiPolicy.p7b
  • Not affected: systems without OEM policy injection (e.g., GMKtec)

Symptoms

With SkuSiPolicy.p7b present:

  • Windows 11 Insider Canary 28020.1873 fails to boot under Secure Boot
  • WinRE for that build fails to boot
  • USB installer for 29576.1000 fails to boot
  • Secure Boot state change forces Windows Hello PIN removal/re‑creation

All failures disappear once the policy file is neutralized.

Reproduction Steps

  1. Use a system that includes: EFI\Microsoft\Boot\SkuSiPolicy.p7b
  2. Attempt to boot:
    • Insider Canary 28020.1873
      • WinRE for that build
        • USB installer for 29576.1000
        1. All fail with Secure Boot trust‑chain errors.
        2. Rename the policy file (example): MSSkuSiPolicy.p7b.Bad
        3. Turn Secure Boot OFF, boot once, then turn Secure Boot ON and boot again.
        4. All previously failing environments now boot normally.

Verified Workaround

  • Rename or remove SkuSiPolicy.p7b
  • Perform a Secure Boot OFF → ON cycle
  • Recreate Windows Hello PIN (expected after Secure Boot boundary change)

After this, all OS partitions and WinRE boot correctly.

Technical Notes

  • The failure is isolated to the SkuSiPolicy signature chain.
  • OEM systems enforce this policy strictly; non‑OEM systems do not.
  • The regression appears to have been introduced in recent Insider builds.
  • Multiboot setups (RP, Dev, Canary) all recover once the policy is disabled.

Request to Microsoft

Please review the SkuSiPolicy enforcement path in current Insider builds. A corrected policy file or temporary suspension of enforcement may be required to restore expected Secure Boot behavior on OEM systems.

Verified Workaround

  • Rename or remove SkuSiPolicy.p7b
  • Perform a Secure Boot OFF → ON cycle
  • Recreate Windows Hello PIN (expected after Secure Boot boundary change)

After this, all OS partitions and WinRE boot correctly.

Technical Notes

  • The failure is isolated to the SkuSiPolicy signature chain.
  • OEM systems enforce this policy strictly; non‑OEM systems do not.
  • The regression appears to have been introduced in recent Insider builds.
  • Multiboot setups (RP, Dev, Canary) all recover once the policy is disabled.

Request to Microsoft

Please review the SkuSiPolicy enforcement path in current Insider builds. A corrected policy file or temporary suspension of enforcement may be required to restore expected Secure Boot behavior on OEM systems.

Summary

On systems that include an OEM‑injected SkuSiPolicy.p7b in the EFI partition (example: Dell XPS 8940), Secure Boot fails to validate Insider bootloaders and WinRE. Removing or renaming the policy file and performing a Secure Boot OFF → ON cycle restores normal boot behavior across all OS partitions and recovery environments.

This appears to be a regression in how Insider builds handle the SkuSiPolicy signature chain.

Affected Systems

  • Dell XPS 8940 (confirmed)
  • Other OEM systems that ship EFI\Microsoft\Boot\SkuSiPolicy.p7b
  • Not affected: systems without OEM policy injection (e.g., GMKtec)

Symptoms

With SkuSiPolicy.p7b present:

  • Windows 11 Insider Canary 28020.1873 fails to boot under Secure Boot
  • WinRE for that build fails to boot
  • USB installer for 29576.1000 fails to boot
  • Secure Boot state change forces Windows Hello PIN removal/re‑creation

All failures disappear once the policy file is neutralized.

Reproduction Steps

  1. Use a system that includes: EFI\Microsoft\Boot\SkuSiPolicy.p7b
  2. Attempt to boot:
    • Insider Canary 28020.1873
      • WinRE for that build
        • USB installer for 29576.1000
        1. All fail with Secure Boot trust‑chain errors.
        2. Rename the policy file (example): MSSkuSiPolicy.p7b.Bad
        3. Turn Secure Boot OFF, boot once, then turn Secure Boot ON and boot again.
        4. All previously failing environments now boot normally.

Verified Workaround

  • Rename or remove SkuSiPolicy.p7b
  • Perform a Secure Boot OFF → ON cycle
  • Recreate Windows Hello PIN (expected after Secure Boot boundary change)

After this, all OS partitions and WinRE boot correctly.

Technical Notes

  • The failure is isolated to the SkuSiPolicy signature chain.
  • OEM systems enforce this policy strictly; non‑OEM systems do not.
  • The regression appears to have been introduced in recent Insider builds.
  • Multiboot setups (RP, Dev, Canary) all recover once the policy is disabled.

Request to Microsoft

Please review the SkuSiPolicy enforcement path in current Insider builds. A corrected policy file or temporary suspension of enforcement may be required to restore expected Secure Boot behavior on OEM systems. Verified Workaround

  • Rename or remove SkuSiPolicy.p7b
  • Perform a Secure Boot OFF → ON cycle
  • Recreate Windows Hello PIN (expected after Secure Boot boundary change)

After this, all OS partitions and WinRE boot correctly.

Technical Notes

  • The failure is isolated to the SkuSiPolicy signature chain.
  • OEM systems enforce this policy strictly; non‑OEM systems do not.
  • The regression appears to have been introduced in recent Insider builds.
  • Multiboot setups (RP, Dev, Canary) all recover once the policy is disabled.

Request to Microsoft

Please review the SkuSiPolicy enforcement path in current Insider builds. A corrected policy file or temporary suspension of enforcement may be required to restore expected Secure Boot behavior on OEM systems.

Microsoft Security | Microsoft Authenticator

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Q&A Assist
    2026-05-01T21:55:33.8933333+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    The described behavior is consistent with Secure Boot rejecting part of the boot chain when a policy or boot component is not trusted by the platform’s current Secure Boot databases and keys.

    From the available guidance, the supported and safe remediation paths focus on:

    1. Ensuring Secure Boot databases and keys are valid and up to date.
    2. Recovering or rebuilding the EFI boot files if Secure Boot–related changes break the boot chain.
    3. Re‑enabling Secure Boot only after the platform is back in a known‑good state.

    Given the scenario (OEM‑injected policy affecting Insider builds), the following supported steps are relevant:

    1. Confirm Secure Boot keys and databases are in a valid state
      OEM platforms rely on the Secure Boot signature database (db), revoked signatures database (dbx), and Key Enrollment Key database (KEK) stored in firmware NVRAM. If these are out of sync with current Windows boot components, trust failures can occur.
      • The db/dbx contain allowed and revoked signers or image hashes for UEFI applications and OS loaders (such as Windows Boot Manager). If an image hash appears in both, dbx takes precedence and the image is blocked.
      • KEK is used to update db and dbx; Microsoft’s key in KEK allows Windows updates to add new trusted boot software or revoke compromised images.
        If the firmware’s Secure Boot variables are corrupted or misconfigured, OEM‑specific recovery or resetting Secure Boot keys to factory defaults is required.
    2. Use the documented Secure Boot recovery procedure if the system becomes unbootable
      If Secure Boot changes or policy interactions cause boot failures (including WinRE or external media), the supported recovery sequence is:
      1. Turn off Secure Boot in UEFI firmware.
      2. If available, reset Secure Boot keys to factory defaults (use “Reset” rather than “Clear” where both exist). This restores manufacturer default Secure Boot variables.
      3. Attempt to boot Windows from the system disk and, once logged on, rebuild the EFI boot files using an elevated Command Prompt: 
              mountvol S: /s
      del S:\*.*/f /s /q
      bcdboot %systemroot% /s S:
        After “Boot files successfully created.”, restart and verify normal boot.
      4. If this does not recover the device, reinstall Windows from recovery media, then verify it boots.
      5. Re‑enable Secure Boot in firmware and reboot.
      This process restores a clean, trusted boot environment aligned with the platform’s Secure Boot keys and databases.
    3. Re‑enable Secure Boot in a supported way
      When Secure Boot has been disabled for troubleshooting or recovery, the supported re‑enable sequence is:
      • Uninstall or remove any hardware, OS, or boot components that are not compatible with Secure Boot.
      • Open the BIOS/UEFI menu (via boot‑time key such as F1/F2/F12/Esc, or via Windows → Shift+Restart → Troubleshoot → Advanced Options → UEFI Firmware Settings).
      • Locate the Secure Boot setting and set it to Enabled. On some systems, select Custom and then load the built‑in Secure Boot keys. If enabling is blocked, reset BIOS/UEFI to factory defaults and retry.
      • Save changes and reboot. If the PC fails to boot, disable Secure Boot again and use the recovery procedure above.
      • If issues persist, OEM support is required.
    4. Security considerations
      • Disabling Secure Boot or altering its policy/keys reduces protection against bootkit malware. Microsoft recommends Secure Boot as part of a trusted boot path from UEFI through Windows Trusted Boot.
      • Any workaround that removes or bypasses OEM Secure Boot policy should be evaluated carefully, as it may weaken the intended security posture of the device.
      • For long‑term compatibility, ensure Secure Boot certificates and revocation lists are updated per Microsoft guidance, especially as older certificates begin expiring.

    For Insider‑specific regressions or OEM‑policy interactions (such as SkuSiPolicy.p7b), the supported escalation path is to file feedback via the Windows Insider Feedback Hub and/or work with the OEM, while using the documented Secure Boot recovery and re‑enable procedures to keep the device in a supported state.

    References:

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.