Fix 0x80097010 – MSSIPOTF_E_FAILED_POLICY signature policy

Quick answer for the impatient

Run signtool verify /pa /v kernel32.sys to find the exact missing attribute. Then re-sign with /td SHA256 /fd SHA256 flags plus a trusted timestamp server.

What's actually happening here

Error 0x80097010 hits when you try to install a driver or load a signed binary on Windows 10/11 22H2 or Server 2022. The file has a valid cryptographic signature—no tampering, correct certificate chain—but Windows’ Code Integrity (CI) subsystem still rejects it. The reason? The signature doesn't carry the policy attributes that CI expects.

Policy attributes are extra metadata embedded in the PKCS#7 signature structure. They tell Windows which signing policy to enforce (e.g., kernel-mode code signing, Windows Hardware Quality Labs). Without them, CI treats the signature as incomplete and throws MSSIPOTF_E_FAILED_POLICY.

This usually happens when you sign with an older tool version—or forget the /td and /fd flags—and the signing timestamp comes from an RFC 3161 server over SHA1. Windows 10 build 1903+ requires SHA256 timestamps for kernel drivers. You can't cheat this by just renewing your certificate; the policy check is structural, not expiry-based.

Fix steps

Find which file triggers the error – Look in Event Viewer under System logs, source CodeIntegrity, event ID 3076 or 3080. The file path is listed there.
Verify the current signature – Open an admin Command Prompt and run:
```
signtool verify /pa /v C:\path\to\file.sys
```
Look for a line that says Policy: Success or Policy: FAILED. If it fails, you'll see 0x80097010 in the verbose output.
Remove the old signature – You can't patch policy attributes onto an existing signature. Strip it:
```
signtool remove /s C:\path\to\file.sys
```
Re-sign with correct policy flags – Use SignTool version 10.0.19041.0 or newer (shipped with Windows 10 SDK). The magic incantation:
```
signtool sign /fd SHA256 /td SHA256 /tr http://timestamp.digicert.com /a /v C:\path\to\file.sys
```
- /fd SHA256 – file digest algorithm. This is mandatory for EV certs.
- /td SHA256 – timestamp digest algorithm. Without it, the timestamp defaults to SHA1 and Windows rejects it.
- /tr – RFC 3161 timestamp server. DigiCert's is the most reliable; avoid Verisign's old servers.
- /a – auto-select the best certificate from your store. If you have multiple, use /sha1 with the thumbprint.
Verify the re-signed file – Run the verify command from step 2 again. It should now show Policy: Success.

Alternative fixes when the main one fails

If you're using a cross-certificate (like a kernel driver from a non-EV cert): The cross-cert must be in the Windows Trusted Publishers store. Run certmgr.msc, import the .cer into Trusted Root Certification Authorities and Trusted Publishers. Then re-sign with /ac cross.cer attached to the command.

If the file is already installed and can't be re-signed (e.g., a third-party driver): Open gpedit.msc → Computer Configuration → Administrative Templates → System → Driver Installation → Code signing for device drivers. Set it to Ignore. Warning: this disables integrity checks entirely—use only for testing. Revert after the test.

If SignTool itself throws the error (rare on Windows 11 23H2): Your SDK version is stale. Download the latest Windows 10/11 SDK (10.0.26100.0 or later) and use that signtool.exe. The old SDK from 2019 doesn't support /td properly.

Prevention tip

Build your signing pipeline to always include /fd SHA256 /td SHA256 and a modern RFC 3161 timestamp server. Never use signtool sign /t (the old Authenticode timestamp)—that's what produces policy-incomplete signatures. Also, pin your SDK version: the signing tool from SDK 10.0.20348.0 (Windows 11 21H2) works fine; anything older than 10.0.19041.0 is a risk.