TRUST_E_FINANCIAL_CRITERIA 0x8009601E: Fix Authenticode Financial Extension Errors

You're trying to install something — an old line-of-business app, a driver package, a vendor's installer — and Windows throws 0x8009601E at you. In Event Viewer or the setup log it reads: The certificate does not meet or contain the Authenticode financial extensions. That's TRUST_E_FINANCIAL_CRITERIA, and it trips people up because the cert looks perfectly valid in the certificate store. It chains fine, it's not expired, the thumbprint matches. And yet Windows refuses to trust it.

Here's the deal. Authenticode has two classes of certs: standard code-signing certs and “financial” certs. The financial ones carry the SPC_FINANCIAL_CRITERIA extension in the certificate itself, which historically was used to distinguish software that handles money (bank clients, payment software) from general-purpose code. Some old installers — particularly ones built with InstallShield pre-2010 or wrapped with legacy Authenticode tooling — were signed with certs that expect that extension to be present. When it's not, the trust check fails with 0x8009601E before the installer even gets to unpack its payload.

You'll hit this most often on legacy enterprise software being deployed to Windows 10 or 11, or when a driver INF is signed with the wrong cert type. I've seen it three times in the last year, all on 15-year-old medical imaging installers that vendors still ship.

Below is the troubleshooting flow. Stop as soon as your situation is resolved.

Step 1 — The 30-second fix: check if you even need the signature

If this is your own machine and you trust the source, the fastest way past 0x8009601E is to unpack the installer and run the MSI directly, bypassing the Authenticode pre-flight check on the bootstrapper.

1. Open an elevated Command Prompt.
2. Run setup.exe /extract "C:\Temp\app_extract" — works for most InstallShield and Inno Setup bootstrappers. For NSIS, use 7-Zip to open the EXE and extract.
3. Run the MSI inside that folder directly: msiexec /i "C:\Temp\app_extract\app.msi".

MSIs go through Authenticode too, but the financial extension check is done by the bootstrapper's WinVerifyTrust call, not by MSI itself for most cases. Nine times out of ten, this gets you past the error and the install completes normally. Don't bother disabling UAC or running as SYSTEM for this — it doesn't help, the check happens before elevation.

If extracting fails or the vendor's installer hard-fails without the bootstrapper, move on to Step 2.

Step 2 — The 5-minute fix: verify what cert you actually have

Before you mess with anything, confirm the cert is what you think it is. Open the EXE's properties, go to Digital Signatures, select the signature, click Details, then View Certificate, then the Details tab. Look under Extensions for the cryptographic extensions.

Or from the command line, use signtool:

signtool verify /pa /v "C:\Path\To\Installer.exe"

You're looking for output like:

Error: SignerSign() failed." (-2146869246/0x8009601E)
SignTool Error: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

If you see 0x8009601E, the cert is missing the financial criteria extension. You can dump the full cert to a file to inspect extensions:

certutil -dump "C:\Path\To\Cert.cer" | findstr /i "extension SPC financial"

If SPC_FINANCIAL_CRITERIA or 1.3.6.1.4.1.311.2.1.27 (that OID) is not present, and the software is legitimately signed by a trusted vendor, the fix is to re-sign the binary with a cert that does have the extension, or to add the extension to the existing cert. Adding requires the private key, so unless you're the vendor, re-signing isn't an option.

What you can do on the client side: skip the bootstrapper (Step 1) or push the MSI through your deployment tool (Intune, SCCM, PDQ) which invokes msiexec directly and never runs the failing WinVerifyTrust call against the bootstrapper.

Step 3 — The 15-minute fix: re-sign with a financial-extensions cert (or bypass properly)

If you control the code — you're the developer or the packaging team — you need to sign with a cert that has the extension. Most cert authorities stopped issuing these around 2015 because Microsoft's own financial criteria policy was deprecated for standard code-signing. What you do instead is one of two things:

Option A: Add the extension to your own internal CA cert

If you're signing in-house, generate the cert with the extension embedded. With OpenSSL and a custom config:

[ v3_signature ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature
extendedKeyUsage = codeSigning
1.3.6.1.4.1.311.2.1.27 = DER:30:00

That 30:00 is an empty SEQUENCE — the financial criteria extension has no content, its mere presence is the signal. Sign with signtool:

signtool sign /f mycert.pfx /p password /fd SHA256 /tr http://timestamp.digicert.com /td SHA256 /a app.exe

Then verify:

signtool verify /pa /v app.exe

Should return Successfully verified with no 0x8009601E.

Option B: Use a modern EV cert and re-package

The cleaner path is to abandon the legacy bootstrapper entirely. Re-package the app as an MSI, sign the MSI with a current EV code-signing cert (DigiCert, Sectigo, GlobalSign all still issue these), and distribute the MSI. Modern Windows 10/11 accepts standard EV-signed MSIs without demanding financial extensions. Windows 11 22H2 and later enforce stricter chain validation, so this is really the only forward-compatible answer.

Option C: Register an exception via AppLocker or WDAC

If you can't re-sign and can't extract, and the vendor is useless (I've been there), you can allow the binary through WDAC. Get the file hash:

Get-FileHash "C:\Path\To\Installer.exe" -Algorithm SHA256

Then add a hash rule in your WDAC policy XML using Allow and Hash. Do not do this with AppLocker publisher rules — publisher rules validate the signature and will hit the same 0x8009601E. Hash rules don't care about signatures.

This is a workaround, not a fix. Document it, set a reminder to revisit when the vendor finally updates their toolchain. Which they will, right around the time hell freezes over.

What doesn't work (and why people try it anyway)

• Disabling UAC entirely. The WinVerifyTrust call happens independent of UAC elevation. You'll just get 0x8009601E with a UAC prompt skipped first.
• Adding the cert to Trusted Root or Trusted Publishers. The cert is already trusted. The failure is on extension presence, not trust anchor.
• Registry hacks under HKLM\SOFTWARE\Microsoft\Cryptography. There's no toggle that bypasses SPC_FINANCIAL_CRITERIA. Anyone who tells you otherwise is confusing it with DisableRootAutoUpdate.
• Running with -ExecutionPolicy Bypass. That's PowerShell script policy. Unrelated.

Quick reference: the OID and what it means

If you're still stuck after Step 3, the vendor is the problem. File a ticket, attach signtool verify /pa /v output, and tell them their Authenticode cert predates the current decade. That usually lights a fire.