Fix SEC_I_SIGNATURE_NEEDED (0x0009035C) on Windows

This error is a pain—I've been there.

You're staring at SEC_I_SIGNATURE_NEEDED (0x0009035C) when trying to authenticate, and nothing seems to work. I know the frustration. But here's the fix: Windows can't find a valid signing certificate for your authentication method. Let's get you back in.

Step 1: Check your signing certificates

Open certlm.msc as an administrator. Look under Personal > Certificates. For smart card or TPM-based auth, you need a certificate with Client Authentication extended key usage (1.3.6.1.5.5.7.3.2). If you see a certificate with an expired date or one that's missing the private key icon (a little key on the cert icon), that's your culprit.

If you're using a smart card: re-insert it. Open certlm.msc again and expand the smart card reader's container under Smart Card Trusted Roots. If the cert is missing, you need to re-enroll.

Re-enroll the certificate

Open an elevated command prompt (Run as admin).
Type certreq -enroll -machine -cert -policyserver http://your-ca-server/certsrv -policypath /certsrv. Replace the URL with your CA's actual address.
If you're on a domain, run gpupdate /force and reboot—sometimes group policy refreshes the enrollment.

I've seen this error most often when a user swaps smart cards or after a Windows Update like KB5025234 (May 2023) that changed how Windows validates signatures. The OS suddenly starts requiring a fresh cert chain.

Step 2: Clear cached credentials

Sometimes the credential manager holds onto stale signing data. Go to Control Panel > User Accounts > Credential Manager. Delete any entries related to your authentication target (like VPN or remote desktop). Then try again.

If that fails, flush the certificate cache:

certutil -delstore -user My "thumbprint-of-bad-cert"  
certutil -delstore -machine My "thumbprint-of-bad-cert"

Replace the thumbprint with the one from certlm.msc. Reboot and re-authenticate.

Why this works

The error code 0x0009035C translates to SEC_I_SIGNATURE_NEEDED. Windows Security Support Provider Interface (SSPI) checks for a signing certificate before allowing authentication—especially with Kerberos, NTLM, or smart card logon. If the cert's private key isn't accessible or the chain is broken, SSPI bails. By fixing the cert or clearing stale data, you give SSPI a clean path to verify your identity.

Less common culprits

TPM chip issues

If you use Windows Hello or BitLocker with TPM 2.0, a firmware update can invalidate the stored key. Check tpm.msc for status. If it shows TPM is not ready, clear and reinitialize it (back up your recovery keys first).

Third-party VPN clients

Cisco AnyConnect or Pulse Secure sometimes inject their own certificates. Uninstall the client, reboot, and see if the error stops. Then reinstall the latest version—older builds had a bug that corrupted the local machine store.

Application-specific auth

I once saw this error in a .NET app calling HttpWebRequest with ClientCertificates. The fix was to set ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 and explicitly assign the cert from the store.

Prevention

Keep certificate templates updated: If you're an admin, ensure your CA templates for smart cards and TPM enrollment have a 3-5 year validity and auto-enrollment enabled.
Monitor cert expiry: Use certutil -view -restrict "NotAfter<$(date +%Y-%m-%d)" -out "RequestID,NotAfter" to catch expiring certs before they cause auth failures.
Patch Windows regularly: After each Patch Tuesday, test authentication with your primary smart card or TPM setup. Microsoft has adjusted signature validation in recent updates.
If you use remote access: Always re-enroll your VPN cert every 6 months, even if it hasn't expired. I've seen a 0x0009035C pop up just because the CA revoked the old cert and the VPN server didn't refresh.

That's it. Fix the signing cert, clear the cache, and you're back to work. If you're still stuck, check the event log under Applications and Services > Microsoft > Windows > SmartCard for more granular errors. Good luck.