Fix STATUS_SMARTCARD_SUBSYSTEM_FAILURE (0XC0000321) on Windows

You try to log on with a smart card, or a scheduled task tries to use one, and Windows throws STATUS_SMARTCARD_SUBSYSTEM_FAILURE (0XC0000321) with the line "The Kerberos protocol encountered an error while attempting to use the smart card subsystem." What's actually happening here is that Kerberos asked the local smart card subsystem for a certificate and a private key operation, and the subsystem didn't answer in a usable way. Kerberos itself is fine. The failure is below it, in the card service, the driver stack, or the certificate-to-account mapping.

I've seen this on everything from a Dell Latitude 5420 with a built-in Broadcom reader to a VM with a USB CCID reader passed through. The pattern is the same: the CardSpace/SCardSvr path is broken, and Kerberos reports it as a subsystem failure because it can't see anything deeper.

Cause 1: The Smart Card service isn't running or can't start

This is the most common one by a wide margin. The SCardSvr service (Smart Card) has to be running for any PKINIT smart card logon to work. If it's stopped, disabled, or crash-looping, Kerberos gets 0XC0000321 every time.

Check it first:

sc query SCardSvr
sc qc SCardSvr

You want to see STATE : 4 RUNNING and START_TYPE : 2 AUTO_START. If it's DISABLED, someone probably hardened the box with a CIS or STIG baseline and didn't realize smart card logon needs it. Set it back:

sc config SCardSvr start= auto
sc start SCardSvr

Also check the dependent services. ScDeviceEnum and SCPolicySvc should be running too. If SCardSvr starts and then immediately dies, look in Event Viewer under Applications and Services Logs > Microsoft > Windows > SmartCard-<something> and also System. A common culprit is a third-party card middleware (ActivClient, SafeNet, Gemalto) that registered a broken CSP and crashes the service on load. Uninstall the middleware, reboot, retest with the base Microsoft CSP, then reinstall the vendor package in current version.

One more thing people miss: Group Policy. Computer Configuration > Windows Settings > Security Settings > System Services > Smart Card can forcibly set the startup type at every gpupdate, so your sc config reverts on the next refresh. If that's happening, fix the GPO, not the local service.

Cause 2: Stale or wrong smart card reader driver

The second most common cause is the reader driver itself. Windows ships a generic CCID driver (Usbccid.sys), and it works for most readers. But the vendor driver (Broadcom, Identiv, HID Omnikey, SCM) sometimes breaks after a Windows update because the driver was signed for an older build and the smart card stack changed underneath it.

The symptom is subtle. Device Manager shows the reader with no yellow bang, but certutil -scinfo hangs or returns nothing. That's your tell. Here's how to test:

certutil -scinfo -silent

If it can't enumerate the card, the driver is the problem, not Kerberos. The real fix is to swap to the Microsoft CCID driver as a baseline. In Device Manager, right-click the reader > Update driver > Browse my computer > Let me pick from a list > choose Microsoft Usbccid Smartcard Reader (WUDF). Reboot. If smart card logon works, you've confirmed the vendor driver was at fault. Then go get the current signed driver from the vendor instead of the one Windows Update pushed.

On Hyper-V or VMware guests with a USB-passthrough reader, the problem is often the passthrough itself. RDP smart card redirection (rdpdr) also fails this way. For RDP, make sure the Smart Cards option is checked in the client, and on the host verify both UmRdpService and SCardSvr are running. A misconfigured Remote Desktop Session Host > Device and Resource Redirection > Do not allow smart card device redirection policy set to Enabled will break it instantly, and the error you see on the client is 0XC0000321.

Cause 3: Certificate isn't mapped to the AD account, or the cert chain is broken

Kerberos PKINIT needs the certificate on the card to map to a user account in Active Directory. If the mapping is missing, malformed, or the certificate can't chain to a trusted root, the KDC rejects the request and Windows surfaces 0XC0000321 on the client because the smart card subsystem couldn't complete the exchange.

On a domain controller, look at Event ID 5 in the System log (Kerberos-Key-Distribution-Center). You'll see lines like "the smart card certificate used for authentication was not trusted" or "the KDC has no support for the certificate's encryption type." That's not a client problem, it's a PKI problem. On the client, run:

certutil -scinfo
certutil -verify -urlfetch -v <exported cert>.cer

Chain errors mean the issuing CA's root isn't in Trusted Root Certification Authorities on the DC, or NTAuth is missing the CA. Check NTAuth:

certutil -viewstore -enterprise NTAuth

If the issuing CA isn't listed, publish it: certutil -dspublish -f CA.cer NTAuthCA from an Enterprise Admin context. Then deal with mapping. If you use explicit mappings, verify them with certutil -map. If you rely on the altSecurityIdentities attribute, confirm it's populated and matches the cert's issuer and serial or SKI. A typo in one character there gives you exactly this error and nothing else, which is why it's maddening to troubleshoot.

Smart card removal policy matters too. If Interactive logon: Smart card removal behavior is set to "Lock Workstation" and the card is pulled mid-logon, or set to "Force Logoff" and the reader briefly drops, you can trip 0XC0000321. Set it to "No Action" temporarily to rule it out.

Quick reference

Work top to bottom. Nine times out of ten you'll fix it at the first row, and the tenth time it's a PKI mapping that a previous admin left half-finished.