I know this error is infuriating — you're mid-deployment, the service won't start, and Windows is throwing a cryptic hex code at you like it's your job to decode it.
NTE_UI_REQUIRED (0x8009002E) translates to "this operation requires input from the user." The short version: something is trying to use a cryptographic key protected by Windows Hello, a PIN, or a smart card, but it's running in a context where no UI can pop up. A Windows service, a scheduled task running as SYSTEM, a headless PowerShell script — none of those can show you a PIN prompt. So the call fails.
The fix depends on what is calling the key. Let's go through the real solutions.
Fix 1: Switch the key to a non-UI Key Storage Provider
If you're hitting this in code — C#, PowerShell, a .NET app using RSACng or ECDsaCng — the key is likely stored under the Microsoft Software Key Storage Provider with a UI policy attached, or it's under the Microsoft Passport Key Storage Provider (Windows Hello). Passport keys always require user presence. There's no way around it.
The real fix: create the key under the software KSP without UI protection. In PowerShell:
$params = New-Object System.Security.Cryptography.CngKeyCreationParameters
$params.Provider = [System.Security.Cryptography.CngProvider]::MicrosoftSoftwareKeyStorageProvider
$params.KeyUsage = [System.Security.Cryptography.CngKeyUsages]::AllUsages
$params.ExportPolicy = [System.Security.Cryptography.CngExportPolicies]::AllowPlaintextExport
$key = [System.Security.Cryptography.CngKey]::Create([System.Security.Cryptography.CngAlgorithm]::Rsa, "MyAppKey", $params)
Run this as the same account that will later use the key. If you create it as your admin user and then a service account tries to open it, you'll get a different error — NTE_BAD_KEYSET — but it's the same neighborhood of pain.
Fix 2: Stop running the operation as a service or SYSTEM
This is the one that trips people up in IIS and Windows Services. Your app works fine when you double-click it. It fails the moment it's installed as a service. That's because services run in Session 0 with no interactive desktop. No desktop means no PIN dialog, no smart card prompt, no Hello for Business gesture.
Options:
- Move the crypto work out of the service. Have the service call a small helper that runs in the user's session via a scheduled task with "Run only when user is logged on."
- Use a certificate with an exportable private key stored in the machine's cert store, not a Hello-protected one. Import it into
Cert:\LocalMachine\Myand grant the service account read access to the private key file under%ProgramData%\Microsoft\Crypto\RSA\MachineKeys. - For SQL Server or IIS app pools, load the user profile. In IIS, set Load User Profile to
Truein the app pool advanced settings. That alone clears 0x8009002E in a surprising number of ASP.NET apps using DPAPI-NG.
Fix 3: Disable the PIN policy temporarily to confirm the diagnosis
If you just need to prove that Windows Hello is the culprit, check the registry policy:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork\PINComplexity
And the per-user Hello container:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Cryptography\NGC
Don't delete these — just rename the NGC key to NGC_old and reboot. If the error goes away, you've confirmed it. Then put it back and fix the calling code properly. Renaming NGC nukes the user's Hello keys, and they'll need to re-enroll. Warn them first, or you'll be the person who broke everyone's fingerprint login on a Tuesday morning.
Why any of this works
CNG (Cryptography Next Generation) keys have a UI policy flag. When that flag is set — which it is by default for Hello and Passport keys — any operation that touches the private key checks whether it can raise a user prompt. If the calling process is:
- running as a service
- in Session 0
- behind a non-interactive logon token
- or the desktop is locked
…the check fails and CNG returns NTE_UI_REQUIRED. The 0x8009002E value is just the HRESULT wrapper around that NTE code. Once you either (a) remove the UI policy from the key, (b) run in an interactive session, or (c) provide the prompt, the flag is satisfied and the operation proceeds.
Less common variations
Smart card logon on RDP
Connecting to a server with a smart card and then running a script that tries to sign with that cert? The cert's private key lives on the smart card, which needs a PIN. Over RDP with "smart card redirection" misconfigured, the PIN prompt can't reach the card. Fix the CertPropSvc service and check RDP-Tcp listener settings.
WinRM and PowerShell remoting
Invoke-Command to a remote host that then tries a Hello-protected operation will fail with this exact code. CredSSP doesn't help. The remote session has no UI, period. Move the crypto work to the local session or use a certificate key.
Windows Sandbox and containers
Containers can't touch host Hello keys. If your Dockerfile or Windows Sandbox script references a certificate stored in the host's NGC container, it'll fail. Export the cert with its private key and import it inside the container's cert store.
Prevention
The rule is simple: never let non-interactive code depend on a UI-required key. Before you ship anything that runs as a service, scheduled task, or remote session, decide up front whether the crypto operations need user presence. If they don't, generate the key under the Software KSP with no UI policy. If they do, design the app so the interactive piece happens in the user's session and the result (a signed blob, a decrypted secret) is handed off to the service.
Also, document which certs and keys your app uses, where they're stored, and under which account. Half the 0x8009002E tickets I've seen came down to "nobody remembered this key was a Hello key." A 5-minute note in the runbook saves a 5-hour outage later.