Smart cards give organisations hardware-bound, phishing-resistant authentication, but most deployments are weakened by loose certificate mapping, password fallbacks and slow revocation rather than by the card itself. Personal Identity Verification (PIV) cards, the US Department of Defense Common Access Card (CAC) and commercial PIV-compatible cards all keep private keys on a chip that will not export them, and unlock those keys with a PIN. This guide explains how the card and its keys work, how smart card logon connects to Active Directory and cloud identity providers, and how to roll out, monitor and harden a programme. It is written for identity engineers, PKI owners and security architects in government, defence supply chains and regulated enterprises.
Key takeaways
- The card is strong; the plumbing decides the outcome. Weak certificate mapping, surviving password paths and stale revocation data undo a non-exportable key.
- Enforce strong certificate mapping in Active Directory. Microsoft moved domain controllers to Full Enforcement of strong certificate binding in February 2025 (KB5014754); issuer-and-serial or SID-extension mapping is now the baseline.
- Know which key does what. The PIV Authentication key (9A) needs the PIN and proves the cardholder; the Card Authentication key (9E) needs no PIN and only proves the card, so it must never be accepted for logical access on its own.
- Derived credentials and FIDO2 complement cards. FIPS 201-3 allows derived PIV credentials for devices without readers, and FIDO2 suits organisations without a PKI.
- Measure enforcement, not issuance. Track password-based Kerberos requests for smart-card-required accounts, weak-mapping warnings and revocation lag, not the number of cards printed.
How PIV and CAC smart cards work
A PIV card is a contact and contactless integrated circuit card running the PIV Card Application defined in NIST SP 800-73-5. The application is selected by its identifier (AID A0 00 00 03 08 00 00 10 00 01 00) and holds key pairs, X.509 certificates and signed data objects. Client software talks to it with ISO/IEC 7816-4 APDUs: SELECT to open the application, VERIFY to present the PIN, GET DATA to read objects such as certificates, and GENERAL AUTHENTICATE to make the card sign or decrypt with a private key that never leaves the chip.
SP 800-73-5 Part 1 requires seven mandatory data objects: the Card Capability Container, the Card Holder Unique Identifier (CHUID), the X.509 certificates for PIV Authentication and Card Authentication, cardholder fingerprints, the facial image and the Security Object. The CHUID data object stays mandatory, but FIPS 201-3 removed the CHUID authentication mechanism, so a relying system must not treat reading the CHUID as authentication. Visual inspection of the card (VIS) is deprecated as a standalone mechanism.
PIV key references and access rules
| Key reference | Key | Access rule (contact interface) | Typical use |
|---|---|---|---|
| 9A | PIV Authentication key | PIN or on-card biometric comparison (OCC) | Windows smart card logon, TLS client authentication, certificate-based sign-in to identity providers |
| 9C | Digital Signature key | PIN Always (PIN for every signature) | Signing documents and email |
| 9D | Key Management key | PIN or OCC | Decrypting S/MIME email and files |
| 9E | Card Authentication key | Always (no PIN) | Physical access readers; proves the card, not the person |
| 9B | Card Application Administration key | Always (contact only) | Card management by the issuer |
| 04 | Secure Messaging key | Always | Establishing an encrypted channel to the card |
- PIN rules: SP 800-73-5 Part 2 sets the PIV PIN at 6 to 8 digits, enforced by the card, with a separate 8-byte PIN Unblocking Key (PUK). FIPS 201-3 permits no more than 10 consecutive failed activation attempts before the card blocks; issuers may set a lower limit.
- Contactless use: keys that need a PIN can only be used over the contactless interface through the virtual contact interface (VCI), which runs over secure messaging using cipher suite CS2 (P-256, AES-128) or CS7 (P-384, AES-256).
- Algorithms: SP 800-78-5 allows RSA 2048 or 3072 and ECDSA P-256 or P-384 for the authentication, signature and card authentication keys through 2030, and RSA 3072 or the same curves from 2031. The symmetric Card Authentication key and 3TDEA are deprecated. NIST published working drafts of post-quantum updates to the PIV standards in June 2026. See the Post-Quantum Readiness Guide.
- Lifetimes: FIPS 201-3 caps a PIV card at six years; IDManagement.gov notes certificates are valid for three, so renewals happen on cards in the field.
PIV, PIV-I, CAC and derived credentials compared
| Credential | Who issues it | Personnel vetting | Where it fits |
|---|---|---|---|
| PIV card | US federal agencies under FIPS 201-3 | Required (favourable background investigation) | Federal employees and long-term contractors; physical and logical access |
| CAC | US Department of Defense | Required | Active duty, Selected Reserve, DoD civilians and eligible contractors; DoD buildings and networks |
| PIV-I | Federal agencies or non-federal issuers under the Federal Bridge certificate policy | Not asserted in a standard way | Short-term staff, partners, state and local bodies, and industry needing interoperable cards |
| Derived PIV credential | Issued on proof of possession of a valid PIV card | Inherited from the PIV card | Mobile devices and endpoints where a card reader is impractical |
| Commercial PIV-compatible card or token | The organisation's own PKI | Whatever the organisation requires | Enterprises wanting smart card logon outside the federal trust framework |
- CAC and PIV: CAC certificates chain to the DoD PKI, so relying systems outside the department need those roots in their trust store. The federal PIV guidance warns that CAC environments may still carry SHA-1 signed certificates and may lack a Card Authentication certificate; test for both before assuming parity with agency PIV cards.
- PIV-I: PIV-I cards are technically interoperable with PIV but use PIV-I certificate policy OIDs, a FASC-N populated with nines and a visibly different card design. Holding one grants nothing; the relying party decides access.
- Derived credentials: FIPS 201-3 section 2.10 says derived credentials are issued on proof of possession of the PIV card and must meet AAL2 or AAL3 of SP 800-63B; a credential at AAL2 can only be used at AAL2. NIST SP 800-157 Rev. 1 (final public draft, November 2024) widens the permitted authenticator types beyond PKI; check its status before citing it in policy.
Smart card logon in Windows and Active Directory
Windows smart card logon is Kerberos with public key pre-authentication (PKINIT, RFC 4556). The client signs the AS-REQ with the private key on the card (pre-authentication type PA-PK-AS-REQ), the domain controller validates the certificate chain and revocation status, maps the certificate to an account and returns a ticket-granting ticket encrypted with a key that is not derived from the user's password. Domain controllers need their own Kerberos certificates, and the issuing CA must be in the NTAuth store.
Strong certificate mapping (KB5014754)
KB5014754 fixed elevation-of-privilege flaws in certificate-based authentication to the KDC (CVE-2022-26923, CVE-2022-26931 and CVE-2022-34691). Microsoft classes mappings as strong when they rely on identifiers that cannot be reused. Enterprise CAs now add a SID extension (OID 1.3.6.1.4.1.311.25.2) to issued certificates; non-Microsoft CAs, such as those behind PIV and CAC cards, do not, so those certificates need an explicit strong mapping in the user's altSecurityIdentities attribute.
| Mapping | Strength | Notes |
|---|---|---|
| X509IssuerSerialNumber | Strong (Microsoft's recommended option) | Must be updated whenever the certificate is renewed |
| X509SKI | Strong | Subject Key Identifier; changes when the key pair changes |
| X509SHA1PublicKey | Strong | Hash of the public key |
| SID extension in certificate | Strong | Issued automatically by Microsoft Enterprise CAs |
| X509IssuerSubject, X509SubjectOnly, X509RFC822 | Weak | Based on names or email addresses that can be reissued to another person |
| UPN in Subject Alternative Name (implicit) | Weak without the SID extension | Denied under Full Enforcement unless a strong mapping also exists |
The behaviour is controlled by StrongCertificateBindingEnforcement (REG_DWORD) under HKLM\SYSTEM\CurrentControlSet\Services\Kdc: 0 disables the check (not recommended), 1 is Compatibility mode and 2 is Full Enforcement. Microsoft moved domain controllers to Full Enforcement with the 11 February 2025 update, and the ability to return to Compatibility mode ended with the 9 September 2025 update. If certificates from your PIV or CAC issuer are not strongly mapped, those users cannot log on.
Policy settings that matter
| Setting | Where | Recommended position |
|---|---|---|
Interactive logon: Require smart card (scforceoption) | Security Options, per computer | Enable on administrative workstations once every user of the device has a working card |
| Smart card is required for interactive logon | User account option in Active Directory | Enable per user, starting with privileged accounts; the account's password is replaced with a random value |
| Enable rolling of expiring NTLM secrets during sign on | Domain properties in Active Directory Administrative Center (Windows Server 2016 domain functional level) | Enable so the hidden NTLM secret rotates |
Interactive logon: Smart card removal behavior (scremoveoption) | Security Options | Lock Workstation, or Disconnect for Remote Desktop sessions; the Smart Card Removal Policy service (ScPolicySvc) carries out the action, so confirm it runs |
Allow signature keys valid for Logon (AllowSignatureOnlyKeys) | Administrative Templates, Smart Card | Leave disabled so only the PIV Authentication certificate is offered |
Allow time invalid certificates (AllowTimeInvalidCertificates) | Administrative Templates, Smart Card | Leave disabled; expired certificates should fail visibly |
UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors | KDC and client registry | Do not set; it disables revocation checking |
Certificate-based authentication to cloud identity providers
Cloud applications reach the same card through certificate-based authentication (CBA) at the identity provider. Microsoft Entra CBA validates certificates directly in Entra ID, without AD FS:
- Username binding affinity: mappings on IssuerAndSerialNumber, SKI or SHA1PublicKey are high affinity; PrincipalName, RFC822Name, IssuerAndSubject and Subject are low affinity. Microsoft notes CBA is only as secure as its weakest binding, so require high affinity for administrators. Populate the
certificateUserIdsuser attribute with the strong identifiers. - Single factor or multifactor: certificates are single-factor by default. Rules keyed on issuer or certificate policy OID mark PIN-protected card certificates as multifactor. The built-in phishing-resistant MFA authentication strength in Conditional Access includes CBA, and its advanced options can require certificates from a specific issuer or policy OID for sensitive resources.
- Revocation: each trusted CA can publish one HTTP CRL distribution point; OCSP and LDAP CDPs are not supported, so publish CRLs over HTTP with enough frequency to meet your revocation target.
- Gaps: CBA does not cover web sign-in at the Windows sign-in screen and does not remove the password option, so close password access by policy. See the Identity Provider and SSO Security Guide.
Readers, middleware and contactless use
- Readers: USB readers implementing the CCID class work with built-in drivers on Windows, macOS and Linux. On reset the card returns an Answer to Reset (ATR) that middleware uses to identify it, so a new card stock can produce ATRs older middleware does not recognise.
- Middleware: Windows uses a smart card minidriver (with inbox PIV support), macOS uses CryptoTokenKit, and Linux and cross-platform applications use PKCS#11. OpenSC implements all three interfaces and is listed in the US government's PIV guidance alongside commercial middleware.
- PIN entry: MITRE ATT&CK T1111 (Multi-Factor Authentication Interception) describes keylogging the smart card PIN and then proxying authentication through the inserted card on an infected host. Removal policy and short sessions narrow that window; endpoint protection matters as much as the card.
- Contactless: FIPS 201-3 allows electromagnetically opaque holders against unauthorised reads. Door readers using only the Card Authentication key verify the card, not the person.
- Virtual smart cards: Windows TPM-based virtual smart cards need no reader, but Microsoft recommends Windows Hello for Business or FIDO2 keys for new installations and encourages existing users to move.
Smart cards or FIDO2: decision guidance
CISA names two forms of phishing-resistant MFA: FIDO/WebAuthn and PKI-based authentication such as PIV and CAC, which it says needs "highly mature identity management practices" and has weaker support in common services.
| Factor | Smart card (PIV, CAC, PIV-I, enterprise card) | FIDO2 security key or device-bound passkey |
|---|---|---|
| Phishing resistance | Yes, when the certificate is mapped strongly and passwords are removed | Yes, origin-bound by design |
| AAL3 under SP 800-63B-4 | Yes with a hardware card and PIN | Yes with a hardware, non-exportable key; syncable passkeys are not permitted at AAL3 |
| Infrastructure | PKI, CRL or OCSP publishing, card management system, readers | Identity provider support only |
| Other card functions | Physical access, document signing, S/MIME encryption | Authentication only |
| Legacy reach | Kerberos, Remote Desktop, VPNs and TLS client auth that predate WebAuthn | Browser and modern operating system sign-in |
| Cross-organisation trust | Strong where federal bridges or cross-certification exist | Each relying party registers keys separately |
- Choose smart cards when: you must accept PIV or CAC (SP 800-53 control IA-2(12) requires federal systems to accept and electronically verify PIV credentials), you need one credential for doors, signing and encryption, or you have legacy Kerberos and VPN estates that cannot use WebAuthn.
- Choose FIDO2 when: you have no PKI team or your estate is mostly SaaS behind one identity provider.
- Small organisations: a PKI and card management system for a few hundred users is hard to justify unless contracts require it; FIDO2 keys give phishing resistance with less operational load. See the Passwordless and Passkeys Guide.
- Large and regulated organisations: running both is common: cards for privileged and on-premises access, FIDO2 or derived credentials for mobile and cloud, tied to one identity record so revocation covers both.
Implementation: a phased rollout
- Inventory and design. List every system where staff authenticate: domain logon, Remote Desktop, VPN, identity provider, privileged access tools, Linux SSH. Decide the certificate profile (PIV Authentication certificate with UPN in the SAN, client authentication and smart card logon EKUs), the strong mapping method and the CRL publishing interval. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Prepare the trust chain. Publish the issuing CA to NTAuth, issue domain controller certificates, and publish CRLs over HTTP reachable by every relying party.
- Populate strong mappings before enforcement. Write
X509IssuerSerialNumberorX509SKIvalues intoaltSecurityIdentities(andcertificateUserIdsfor Entra) from your card management system, and automate the update on every renewal. Watch Kdcsvc event 39 to find unmapped certificates. - Pilot ring. Issue cards to the identity and help-desk teams first, then to a pilot group of administrators. Keep
scforceoptionoff and record failures: reader drivers, unrecognised ATRs, middleware conflicts, Remote Desktop redirection. - Enforce for privileged accounts. Set "Smart card is required for interactive logon" on administrative accounts, enable NTLM secret rolling, apply
scforceoptionon privileged access workstations and require the phishing-resistant authentication strength for admin portals. See the Privileged Access Management Guide. - Extend to all staff in rings, then close side doors: VPN gateways, mobile clients and legacy protocols that accept passwords.
- Roll back safely. The rollback for a user is clearing the smart-card-required flag and issuing a temporary access method through a verified help-desk process; for a device, disabling
scforceoptionby group policy. Keep two tested break-glass accounts excluded from enforcement and monitored. See the Break-Glass Account Guide.
Detection and measurement
- Event 4768 (Kerberos TGT requested): smart card logons show pre-authentication type 15, 16 or 17 and populate Certificate Issuer Name, Serial Number and Thumbprint. Alert when a smart-card-required account uses another type, or when the issuer is not an authorised logon CA.
- Result code 0x3E: client trust failed (revoked certificate or untrusted root). Event 4771 with 0x10 indicates the right certificate could not be found.
- Kdcsvc events 39, 40 and 41: 39 means no strong mapping, 40 means the certificate predates the account, and 41 means the SID in the certificate does not match the account, which can indicate a certificate issued for someone else.
- Certificate abuse: MITRE ATT&CK T1649 (Steal or Forge Authentication Certificates) notes that stolen or forged certificates stay usable "despite user password resets". Revocation, not password reset, is the containment step. See the ITDR Guide.
| Metric | Target direction |
|---|---|
| Privileged accounts with "Smart card is required for interactive logon" set | 100 percent, excluding documented break-glass accounts |
| Password-based (pre-auth type 2) TGT requests by smart-card-required accounts | Zero; every occurrence investigated |
| Kdcsvc event 39 count per week | Falling to zero as mappings are completed |
| Time from card loss or termination to certificate revocation and CRL publication | Within your policy; FIPS 201-3 sets 18 hours for federal PIV |
| Share of interactive and remote access sign-ins using card or derived credential | Rising each ring |
| Help-desk PIN unblock and card reissue requests verified by an approved method | 100 percent |
Where identity fits
Smart cards authenticate people. Service accounts and automation cannot insert a card, so they are exempt from enforcement and remain password-based, which makes them the obvious target once humans are on cards. Review every exempt account and move workloads to group managed service accounts, managed identities or short-lived certificates from the same PKI. See the Service Account Security Guide and the NHI Authentication Guide.
Framework mapping
| Framework | Reference | How smart cards address it |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-2(1), IA-2(2) | Multi-factor authentication for privileged and non-privileged accounts |
| NIST SP 800-53 Rev. 5 | IA-2(12), IA-8(1) | Accept and electronically verify PIV credentials, including those of other agencies |
| NIST SP 800-53 Rev. 5 | IA-5(2) | Public key-based authentication: path validation, revocation, key protection, account mapping |
| NIST CSF 2.0 | PR.AA-01, PR.AA-02, PR.AA-03 | Credentials managed, identities proofed and bound to credentials, users authenticated |
| NIST SP 800-63B-4 | AAL3 | Hardware-protected, non-exportable, phishing-resistant authenticator |
| CIS Controls v8.1 | 6.3, 6.4, 6.5 | MFA for externally exposed applications, remote network access and administrative access |
| ISO/IEC 27001:2022 Annex A | 5.17, 8.5 | Authentication information and secure authentication |
| MITRE ATT&CK | T1111, T1649 | PIN interception and card proxying; stolen or forged certificates |
Common failure patterns
- Smart card at the desk, password at the edge. Enforcing cards for workstation logon while the VPN or remote desktop gateway still accepts a password leaves the easiest path open; a single VPN account without MFA was the entry point in the Colonial Pipeline attack. See the Remote Access Identity Guide.
- Weak mapping left in place. Mapping on UPN or email lets anyone who obtains a certificate with the right name authenticate as that user; KB5014754 exists because this was exploitable.
- Revocation that does not reach relying parties. Infrequent CRLs, CDPs the identity provider cannot reach, or revocation checks disabled during an outage and never restored keep a leaver's card working.
- Card Authentication key used for logon. Accepting the 9E certificate, which needs no PIN, turns a stolen or cloned-read card into a single-factor credential.
- Unverified help-desk reissue. PIN unblocks and temporary access are a social-engineering target, as the MGM Resorts breach showed for help-desk resets. See the Account Recovery and Help Desk Security Guide.
- Static NTLM secrets. Without secret rolling, the random password set on a smart-card-required account can persist for years and be stolen as a hash.
Practitioner checklist
- Confirm every domain controller runs in Full Enforcement of strong certificate binding and that Kdcsvc event 39 is zero.
- Write strong mappings (issuer and serial, or SKI) for PIV, CAC and PIV-I certificates and automate updates on renewal.
- Accept only the PIV Authentication certificate (9A) for logical access; never the Card Authentication certificate.
- Set "Smart card is required for interactive logon" for privileged accounts and enable NTLM secret rolling.
- Require high-affinity bindings and the phishing-resistant authentication strength for cloud administrator roles.
- Close password paths on VPN, remote desktop gateways and legacy protocols for card-enforced users.
- Alert on non-smart-card Kerberos pre-authentication for smart-card-required accounts and on untrusted issuers.
- Plan algorithm migration to RSA 3072 or ECC P-256/P-384 before 2031 and track NIST's post-quantum PIV drafts.
Standards and references
- NIST: FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors
- NIST: SP 800-73-5, Interfaces for Personal Identity Verification
- NIST: SP 800-78-5, Cryptographic Algorithms and Key Sizes for Personal Identity Verification
- NIST: SP 800-63B-4, Authentication and Authenticator Management
- IETF: RFC 4556, Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
- Microsoft: KB5014754, Certificate-based authentication changes on Windows domain controllers
- Microsoft Learn: Smart card Group Policy and registry settings
- GSA IDManagement.gov: PIV-I 101
Related NHI Mgmt Group resources: MFA Guide · Passwordless and Passkeys Guide · Active Directory and Entra ID Hardening Guide · Public Sector Identity Security Guide