You tried to log in with a password and Windows slammed the door: STATUS_SMARTCARD_LOGON_REQUIRED (0XC00002FA). That's not a bug. It's a policy doing exactly what someone told it to do.
The message means the account is flagged SmartcardRequired — either directly on the user object or inherited from a domain-level policy. Windows won't accept a password for that account under any circumstances. You need the card, the reader, and the PIN. If any of those three is missing or busted, you get 0XC00002FA.
Work through this in order. Most people hit the fix in the first two minutes.
Step 1 — The 30-second check: is the reader alive?
Before you touch anything in AD, verify the hardware. This is the culprit more often than people want to admit. Especially on laptops that got yanked off a dock or desktops where someone bumped the USB cable.
- Unplug the smart card reader and plug it back in. Different USB port if you have one free.
- Open Device Manager. Look under Smart card readers. If it's not there, or there's a yellow bang, that's your problem — not the account.
- Insert the card. Does the reader's LED blink or turn solid? No light means the card isn't seated or the reader is dead.
- On the logon screen, look for the smart card icon. If Windows doesn't see a reader, the icon won't appear and you're stuck on the password field.
If the reader shows up fine and the card is seated, move on. Don't waste time here.
Real-world trigger: this bites hardest on Windows 11 22H2+ laptops using USB-C docks. The reader enumerates on the dock, but the dock's USB hub drops it during sleep. Unplug/replug the dock, not just the reader.
Step 2 — The 5-minute check: PIN and card state
Reader's fine, card's in, still getting 0XC00002FA or the logon just fails silently. Now you're looking at the card itself.
PIN locked
Three wrong PINs in a row usually locks a PIV card. The card doesn't tell you it's locked on the logon screen — it just refuses. Check with the middleware. For YubiKey PIV, that's the YubiKey Manager. For Gemalto/Thales cards, it's the SafeNet Authentication Client. For most DoD CACs, it's ActivClient or the built-in certutil if the card is in the reader:
certutil -scinfoThat dumps every cert on the card and tells you if the card is even being read. If scinfo hangs or errors out, the middleware is the problem, not the account.
Certificate expired
The logon certificate on the card has a validity window. When it expires, Windows silently falls back to "no valid cert" and you get 0XC00002FA on the next attempt. Check the cert expiry in certutil -scinfo output or in the middleware GUI. If it's expired, the card has to be reissued. No workaround.
Wrong cert mapped
Some cards carry multiple certs — one for logon, one for signing, one for encryption. If the wrong one is mapped to the user in AD, logon fails. Open Active Directory Users and Computers, find the user, Properties → Published Certificates. Confirm the cert thumbprint matches the one currently on the card. Compare with certutil -scinfo.
Step 3 — The 15-minute check: the AD attribute
Hardware and card are fine. Now you're dealing with the actual policy.
Open an elevated PowerShell on a machine with RSAT, or just use dsa.msc:
Get-ADUser -Identity jsmith -Properties SmartcardLogonRequired | Select Name, SmartcardLogonRequiredTrue means the account requires a smart card. That's expected if you're supposed to be using a card. It's a problem if the user has no card, lost their card, or you're trying to do admin work with a password.
To clear it (only if policy allows — see warning below):
Set-ADUser -Identity jsmith -SmartcardLogonRequired $falseOr in dsa.msc: user Properties → Account tab → Account options → uncheck Smart card is required for interactive logon.
Warning: if this attribute is set by a fine-grained password policy or by a group policy preference that reapplies on the next gpupdate, unchecking it won't stick. It'll flip back the moment the policy refreshes. You have to find the policy, not the attribute. Check dsa.msc → domain → System → Password Settings Container, and check any GPOs that push SmartcardLogonRequired.
The SCRIL flag
Related but different: SmartcardRequired for Interactive Logon (SCRIL) at the domain functional level. If the domain has SCRIL set, every account in scope gets the requirement whether you like it or not. Check with:
Get-ADDomain | Select SmartcardLogonRequiredIf that returns True, you're fighting a domain-wide setting. Get approval before touching it. Somebody turned it on for a compliance reason.
Step 4 — When it's not the user account at all
Every now and then the account looks clean, the card is fine, and you still get 0XC00002FA. That's usually one of these:
- Credential Guard conflict. On Windows 10/11 Enterprise with Credential Guard enabled, some third-party smart card middleware fights with the virtualized credential stack. Test with Device Guard and Credential Guard hardware readiness tool and try disabling CG on one machine to confirm.
- Kerberos PKINIT failure. The smart card logon uses PKINIT. If the DC can't reach the CRL or OCSP responder for the card's cert chain, PKINIT fails and you get a smart card error, not a network error. Check System and Application event logs on the DC for KDC event 19 or 21.
- Certificate services trust. If the issuing CA's root isn't in Trusted Root Certification Authorities on the client, logon fails. Push it via GPO if it's missing.
- Reader driver from the Windows store. Windows sometimes installs a generic driver that half-works. Roll back to the vendor's driver. Real fix, saves hours.
Quick decision table
| Symptom | Likely cause | Fix |
|---|---|---|
| No smart card icon on logon screen | Reader not detected | Replug reader/USB, check Device Manager |
| Icon present, PIN rejected | PIN locked or wrong | Unlock via middleware GUI |
| Card reads, logon fails | Expired cert or wrong cert mapped | Reissue card or remap cert in AD |
| Works on some machines, not others | Missing root CA or Credential Guard | Push root via GPO, test CG disabled |
| Account has no card at all | SmartcardLogonRequired set wrongly | Clear attribute or find the enforcing policy |
What not to bother with
Don't disable the smart card service SCardSvr thinking it'll bypass the requirement. It won't. The logon stack checks the account flag before it checks the service.
Don't try runas with a password. Same check. Same failure.
And don't just yank the SmartcardLogonRequired flag on a user without understanding why it's set. In a lot of orgs that flag exists because of a compliance control (CAC/PIV mandates, DoD, finance). Clearing it for one user can be a finding in the next audit. Ask first, then fix.