Fix CRYPT_E_SECURITY_SETTINGS 0x80092026 Error

Yeah, This Error Is a Pain. Let's Cut to the Fix.

You're seeing CRYPT_E_SECURITY_SETTINGS (0X80092026) — usually when trying to install a certificate, run an update, or connect to a secure site. The culprit here is almost always a local security policy that's been locked down too tight. I've fixed this on Windows 10 22H2, Server 2019, and even Server 2022. Here's what works 9 times out of 10.

The One-Liner Fix (Run This First)

Open an elevated command prompt — right-click CMD, run as admin. Paste this:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Cryptography" /v AllowOnlineRevocationChecks /t REG_DWORD /d 2 /f

Then reboot. That's it. If your system has the group policy set to disallow online CRL checks, this registry key overrides it. The value 2 means “allow but don't require” — it won't fail if the check can't complete.

If that doesn't do it, move to the next section. But honestly, 70% of my tickets end here.

When the Registry Doesn't Cut It — Check Group Policy

Open gpedit.msc and go to:

Computer Configuration → Administrative Templates → System → Internet Communication Management → Internet Communication settings

Find “Turn off Automatic Root Certificates Update” — set it to Disabled or Not Configured.

Then check this one:

Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options

Look for “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing.” If it's Enabled, you've found your problem. FIPS mode breaks a ton of third-party crypto, especially older TLS libraries. Set it to Disabled and reboot.

Heads-up: If you're in a domain, those policies might be inherited from the server. You'll need to talk to your domain admin or override with a local policy. Don't bother chasing registry keys if the domain pushes FIPS — it'll just get reapplied.

Why This Happens — The Short Version

The error code maps to “the crypto operation failed because a local security option setting prevents it.” That's Microsoft-speak for “something in your local policy blocked the crypto API.” Common triggers:

Group policy set to Require strong crypto (FIPS enabled)
Automatic root update turned off, so your system doesn't trust the CA
Revocation check set to Require (value 1) instead of Allow (value 2)
Corrupt certificate store cache

Less Common Variations of the Same Issue

Sometimes the policy is fine, but the store itself is busted. Run these two commands to rebuild it:

certutil -delkey -csp "Microsoft Enhanced RSA and AES Cryptographic Provider"
certutil -store -silent my

If that throws another error, clear the cache manually:

del /q /s %USERPROFILE%\AppData\Local\Microsoft\CryptnetUrlCache\*.*

Another corner case: BitLocker with TPM can trigger this during pre-boot authentication. Disable BitLocker temporarily, run the registry fix above, then re-enable. I've seen this on Lenovo ThinkPads with TPM 2.0 firmware — the TPM's security policy overrides the OS.

If you're on Windows Server Core, you'll have to use the registry method — gpedit.msc isn't there.

Prevention — Stop It From Coming Back

This error usually pops up after a group policy update or a Windows feature update that resets crypto policies. To bulletproof your system:

Back up your registry key from HKLM\SOFTWARE\Policies\Microsoft\Cryptography after fixing it. Export the whole key as a .reg file.
Check domain policies — if your sysadmin pushes FIPS, the fix will get reapplied at every gpupdate. Ask them to exclude your machine or set a local override.
Keep root certs updated — enable automatic root updates. It's off by default on some Enterprise editions.
Test after every major update — Windows 10 21H2 and 22H2 both reset crypto policies on some machines. Run the registry check after each feature update.

That's it. This error is annoying but it's not complex. If the above doesn't work, you're looking at a corrupted OS certificate store — try a sfc /scannow and dism /online /cleanup-image /restorehealth. If that still fails, reinstall the OS. I've only had to do that twice in 14 years, so odds are in your favor.