You're mid-morning, coffee in hand, and a client calls — their line-of-business app won't start. The error says SEC_E_CANNOT_INSTALL (0x80090307). If you're lucky, it's just that one app. If you're not, it's everything that uses Windows authentication — RDP, file shares, even Outlook. I've seen this pop up right after a Windows update, or when someone messes with the Local Security Authority (LSA) settings. The worst case I had was a small dental office whose entire scheduling system died because a third-party backup tool stuffed a bogus security package into the registry.
What's actually happening
Windows uses security packages — Kerberos, NTLM, Negotiate — to handle logons and encrypted connections. When an app or service tries to load one of these packages, it calls into the LSA. If the package's DLL is missing, corrupted, or not properly registered, you get 0x80090307. The error literally means the package couldn't initialize, so Windows won't install it.
The most common cause I see is a leftover entry in the registry under:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Security Packages
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\OSConfig\Security Packages
These are multi-string values. If something adds a package name that doesn't exist (or the DLL got uninstalled), you're stuck. I've also seen this after a botched antivirus uninstall — it leaves hooks in the LSA.
The fix: clean out the broken packages
Before you do anything, back up the registry. Not just the Lsa key — the whole thing. You'll thank me later.
- Press Win + R, type
regedit, hit Enter. - Go to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. - Double-click Security Packages (the multi-string value).
- You'll see a list of names like
kerberos,msv1_0,negoexts. Look for anything unusual — a vendor name, a random GUID, or something that doesn't match a known Windows package. - Remove the suspicious entries, but keep the standard ones. If you're not sure, Google the name first.
- Do the same for the OSConfig key — it's right below under
Lsa\OSConfig. - Close regedit and reboot.
If you can't tell which entry is bad
Look at the file path of each package. Windows packages are in %SystemRoot%\System32. If the entry points to a DLL in Program Files or the temp folder, that's your suspect. A client of mine had a package called protector.dll from some security trial they'd installed months ago. Removing it fixed everything.
Still failing? Run system file checks
Sometimes the registry is fine, but the actual system files are corrupted. This happens after a failed update or a disk error. Open an elevated command prompt (right-click Command Prompt → Run as administrator) and run:
sfc /scannow
If SFC finds issues but can't fix them, run DISM:
DISM /Online /Cleanup-Image /RestoreHealth
Then reboot and try again. I've had this solve it on Windows 10 21H2 and Windows Server 2019.
What about Kerberos specifically?
If the error mentions Kerberos or happens during domain logons, check the KdcProxy settings or make sure the kerberos package is listed first in the Security Packages value. Sometimes a group policy overwrites the list and drops it.
If it still won't budge
Don't go nuclear yet. First check the Event Viewer under Windows Logs → System for LSA errors — they'll name the exact DLL that failed. Search for that filename. If it's a third-party security software, reinstall that software cleanly, then uninstall it with their removal tool. If it's still broken, you might need to repair the Windows image with a bootable USB. But honestly, nine times out of ten, it's the registry entry.
One last thing: if you're on a domain, check with your admin — a bad Group Policy can push a broken security package to every machine. I saw a school district push out a bad vendor package to 300 PCs once. That was a fun week.