How to Set Up YubiKey Smart Card Logon for Windows (PIV Certificate-Based Authentication)

Using Microsoft Entra ID? Consider FIDO2 first. If your users and devices are in Microsoft Entra ID (cloud-only or hybrid joined), FIDO2 security keys are natively supported for Windows sign-in, Microsoft 365 and Conditional Access phishing-resistant MFA, and are far simpler to deploy. There is no certificate authority, CRL, enrolment agent or minidriver to run: you enable the Passkeys (FIDO2) authentication method in Entra and users register their key in My Security Info. Revoking access is as simple as disabling the account or deleting the registered key. PIV smart card logon, covered in this guide, is the better fit for on-premises Active Directory without Entra, environments that already run a PKI, or systems that specifically need certificates (such as some VPNs, legacy apps and document signing). See our ultimate guide to FIDO2 and phishing-resistant MFA and how to roll out passkeys across your team.

Passwords are the weakest link in Windows sign-in. Certificate-based authentication with a YubiKey replaces the password with something the user has (the key, holding a private key that can never be copied off it) and something they know (a PIN). Windows has supported smart card logon natively for decades, and every YubiKey 5 Series key includes a PIV (Personal Identity Verification) smart card application, so you get enterprise-grade, phishing-resistant sign-in without buying separate smart cards and readers.

This guide walks IT administrators through the full lifecycle in an Active Directory environment:

1. Configuring the certificate store (Active Directory Certificate Services).
2. Provisioning a certificate onto each user's YubiKey in PIV slot 9a.
3. Revoking access when a staff member leaves, including when they do not return the key.

It applies equally to office desktops, laptops, shared workstations, kiosks and privileged admin accounts. If this is your first time with a YubiKey, read the gotchas section before you start: most failed rollouts trip on the same handful of issues.

Which YubiKeys support PIV smart card logon?

Not every Yubico key includes the PIV smart card application, so check before you buy:

Match the connector to your fleet: the YubiKey 5 NFC for USB-A machines, the YubiKey 5C NFC for USB-C laptops, both of which also tap to phones over NFC.

Before you start

This guide uses native Windows smart card logon: an on-premises Active Directory domain, an Enterprise CA (AD CS), and a user certificate generated on each YubiKey in PIV slot 9a.

Check your identity platform first. Native certificate logon only works for domain accounts. For on-premises Active Directory, or where you specifically need certificates, follow this guide. For Microsoft Entra ID, FIDO2 is usually the better choice (see the note at the top); if you do need certificates in a cloud-only tenant, Microsoft Entra certificate-based authentication is the equivalent path and the YubiKey provisioning steps are similar. Standalone PCs with local accounts cannot use certificate logon or central revocation; join them to a domain first.

What you need

How it fits together

The private key is generated on the YubiKey and never leaves it. At sign-in the domain controller validates the certificate chain, checks revocation, maps the certificate to the AD account and checks the account is enabled.

Step 1: Configure the certificate store

One-off setup. Budget half a day in a test OU first, then roll out.

1.1 Stand up an Enterprise CA

1. On a Windows Server, add the Active Directory Certificate Services role, Certification Authority service.
2. Choose Enterprise CA. For production, a two-tier PKI (offline root, online Enterprise issuing CA) is best practice. A single Enterprise Root CA is acceptable for a small organisation, but protect that server like a domain controller.
3. Key: RSA 2048 or higher, SHA-256. CA validity longer than any certificate it will issue (for example 10 years).

1.2 Make revocation information reachable

Domain controllers check the CRL on every smart card logon. If they cannot get a valid CRL, every smart card logon fails.

1. CA Properties > Extensions. Add an HTTP location for the CDP and AIA that DCs and client devices can reach. Tick "Include in CDP extension of issued certificates".
2. Revoked Certificates > Properties: set the CRL publication interval (for example base 7 days, delta 1 day). Shorter intervals mean faster revocation but more dependency on the CA being up.
3. Optional but recommended: add the Online Responder (OCSP) role for near real-time revocation.
4. Run certutil -crl and confirm health in pkiview.msc (all green).

1.3 Give domain controllers a Kerberos certificate

1. Issue the Kerberos Authentication template on the CA.
2. Enable certificate autoenrolment for DCs (GPO: Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment = Enabled, renew and update ticked).
3. Verify on each DC: certutil -dcinfo verify.

1.4 Confirm the CA is in NTAuth

An Enterprise CA publishes itself automatically. Check with certutil -viewstore -enterprise NTAuth. If the CA is missing, logons fail with a generic smart card error.

1.5 Install the YubiKey Minidriver

Install on the CA, the enrolment workstation and every device users sign in to. Push the MSI by GPO or Intune (Installing on Networked Systems) and check it with Verifying Installation. The inbox Windows driver can use a provisioned key but cannot provision one.

1.6 Create the smart card logon template

In certtmpl.msc, right-click Smartcard Logon > Duplicate Template:

Then in certsrv.msc > Certificate Templates > New > Certificate Template to Issue > select it.

1.7 Set up enrolment agents

1. Issue the Enrollment Agent template, restricted to a small admin group, and enrol the admins who will provision keys.
2. CA Properties > Enrollment Agents tab: restrict agents to the YubiKey Smartcard Logon template and the YubiKey Users group.

Prefer users to self-enrol? Skip this step, drop the Issuance Requirement signature, and follow Self-Enrolling YubiKeys on Windows. Enrol-on-behalf keeps control with IT and is the better fit for most organisations.

1.8 Group Policy for smart card devices

Link to the OU holding the devices that should require a YubiKey:

To enforce the YubiKey per user rather than per device (common for privileged admin accounts), tick Smart card is required for interactive logon on the AD account instead. Keep a break-glass admin account excluded from the requirement, password in a vault.

Step 2: Provision a YubiKey for each user (PIV slot 9a)

About 5 minutes per key once practised. Do the PIN and PUK prep with ykman or Yubico Authenticator, then enrol the certificate through Windows. Do not use both toolsets to load certificates on the same key (see gotchas).

Factory defaults on a new key: PIN 123456, PUK 12345678, management key the well-known default (see PIV Commands).

2.1 Record the key

Run ykman info. Note the serial number and firmware version (firmware cannot be upgraded; see gotchas). Put a numbered asset label on the key rather than the user's name.

2.2 Reset PIV (reused or unknown keys only)

ykman piv reset wipes all PIV keys and certificates and restores defaults. New keys can skip this.

2.3 Set retry counts, then PIN, then PUK (in that order)

ykman piv access set-retries 5 5
ykman piv access change-pin
ykman piv access change-puk

• set-retries resets the PIN and PUK to defaults, so it must come first.
• PIN: 6 to 8 characters. Set a temporary PIN the user changes at first sign-in (Ctrl+Alt+Del > Change a password, once the minidriver is installed).
• PUK: random, held by IT in a password vault against the key serial. Never give it to the user.
• Leave the management key at default. On first enrolment the minidriver generates a random management key and stores it PIN-protected on the key (ProtectManagement, see the registry reference). A custom unprotected management key will make Windows enrolment fail.

Setting the PUK before Windows touches the key matters: see Setting PIN Unblock Code (PUK). Close ykman or Authenticator before the next step.

2.4 Enrol the certificate on behalf of the user

On the enrolment workstation, signed in as an enrolment agent, with the minidriver installed:

1. Insert the user's YubiKey (only one key plugged in).
2. Open certmgr.msc > Personal > Certificates > right-click > All Tasks > Advanced Operations > Enroll On Behalf Of.
3. Select your Enrollment Agent certificate as the signing certificate.
4. Tick YubiKey Smartcard Logon, then Browse to select the target user.
5. Click Enroll. Enter the YubiKey PIN when prompted. The key pair is generated on the YubiKey and the certificate written to it.
6. Choose Next User or Close.

The first smart card logon certificate lands in slot 9a (PIV Authentication), which is the slot Windows logon uses.

2.5 Verify the key

1. ykman piv info: slot 9a shows a certificate with the user's name and the expected expiry.
2. certutil -scinfo: reads the card through Windows and validates the chain (prompts for PIN).
3. In the certificate details, check the SAN contains the user's UPN and extension 1.3.6.1.4.1.311.25.2 (the SID) is present. A missing SID means logon failure on patched DCs.

2.6 Test sign-in

1. Insert the key at the Windows sign-in screen, choose the smart card tile, enter the PIN.
2. Remove the key and confirm the session locks (or logs off, per your policy).
3. On devices that require a smart card, confirm password sign-in is refused.

2.7 Register and hand over

Record in your key register: user, key serial and asset number, certificate serial number, issue date, expiry date, PUK vault reference. You will need the certificate serial in Step 3. Have the user sign an acceptable use acknowledgement and change the PIN at first sign-in.

Renewals

Certificates expire on the template's validity. Diarise renewal from the register and renew with the same Enroll On Behalf Of process before expiry; an expired certificate means that user cannot sign in.

Step 3: Revoke access when a staff member leaves or does not return their key

When someone leaves, their access must be dead the same day whether or not the key comes back. Disabling the AD account is the immediate control. Revoking the certificate is the permanent one, so the key is useless even if the account is ever re-enabled. You do not need the physical key for any of this.

3.1 Disable the account at the exit time

For a planned exit, set it in advance so it happens even if IT is busy on the day:

Set-ADAccountExpiration -Identity <username> -DateTime "<last day> 17:00"

For an immediate or adverse exit: Disable-ADAccount -Identity <username>. The KDC checks account status at every logon, so this is effective as soon as it replicates. Also remove the user from the YubiKey Users group so no new certificate can be enrolled for them. Keep the account disabled rather than deleting it, for audit and file ownership.

3.2 End any live sessions

A session already signed in survives both account disable and revocation. Log it off:

query user /server:<PCNAME>
logoff <SessionID> /server:<PCNAME>

3.3 Collect the key

If the key is returned: revoke the certificate with reason 5 Cessation of Operation (command in 3.4), run ykman piv reset, return it to the spares pool and update the register. With no key in the wild you can skip 3.5 to 3.7.

If the key is not returned: continue with 3.4. A key without its PIN is of little use, but you cannot rely on the PIN staying secret after someone leaves.

3.4 Revoke the certificate

Get the certificate serial from your key register, or find it in certsrv.msc > Issued Certificates (add the Issued Common Name column and search for the user). On the CA:

certutil -revoke <CertSerialNumber> 3

These reasons are permanent. Do not use Certificate Hold for exits.

3.5 Publish a new CRL immediately

Revocation only takes effect once it is in a published CRL:

certutil -crl

If your HTTP CDP is a copy rather than written directly by the CA, copy the new CRL across.

3.6 Flush cached CRLs on the domain controllers

DCs keep using the previous CRL until it expires, which could be days. On each DC:

certutil -urlcache crl delete
certutil -setreg chain\ChainCacheResyncFiletime @now

If you run an Online Responder (OCSP), it picks up the revocation at its next CRL refresh.

3.7 Close the cached logon gap

A device that cannot reach a DC falls back to cached credentials, so an unreturned key plus a known PIN could still unlock a device that user has signed in to before. On always-connected desktops, set "Number of previous logons to cache" to 0 or 1. Laptops need cached logons to work offline, so recover the leaver's laptop (or remotely wipe it via your MDM) and delete their profile from any shared devices they used (System Properties > User Profiles > Delete).

3.8 Verify, record and pursue the key

1. Export the revoked certificate from the CA and run certutil -verify -urlfetch <file>.cer. It should report revoked.
2. Confirm the account shows as disabled or expired in AD.
3. Update the register: exit date, revocation date and reason, key status "revoked, not returned".
4. Follow up in writing for return of the key under your asset policy. If it comes back later, run ykman piv reset and add it to the spares pool; the old certificate stays revoked.

The same process covers a lost key for a continuing employee: revoke with Key Compromise, run 3.4 to 3.8, then provision a replacement (Step 2).

Key considerations and gotchas

Design decisions to make up front

• Identity platform. On-prem AD without Entra follows this guide; if you are on Entra ID, start with FIDO2 and only use certificates where you need them. Local accounts get neither certificate logon nor central revocation. Settle this before anything else.
• Lock vs Force Logoff on removal. Lock suits personal devices. Force Logoff suits shared kiosks, but it terminates everything in the session, including any application the user left running. Test with your line-of-business apps first.
• Per device or per user. Enforce by GPO on device OUs (every sign-in on that device needs a key) or per user with "Smart card is required for interactive logon" (common for admin accounts). The per-user flag rotates the account's password hash, which breaks anything still authenticating that user with a password.
• One key or two per user. A second registered key avoids a lockout when the first is lost, at the cost of two certificates to track and revoke. Many organisations keep a pool of spares instead.

PKI

• CRL availability is logon availability. An expired or unreachable CRL means every smart card logon fails. Monitor CRL expiry, publish well before it lapses, and alert on pkiview.msc errors.
• Revocation is not instant. Clients and DCs cache CRLs. Disable the account first, then revoke, publish and flush (Step 3).
• Strong certificate mapping (Microsoft KB5014754) is enforced on patched DCs. Certificates need the SID extension, which an online Enterprise CA adds when the subject is built from AD. Certificates from a "Supply in the request" template or an external CA need an explicit mapping in the user's altSecurityIdentities or logon fails.
• Never use "Supply in the request" on a logon template. It lets anyone with enrol rights request a certificate as any user, including a domain admin.
• Time sync. Kerberos and certificate validity both break on clock drift. Point every device at the domain time hierarchy.

YubiKey

• Check the key supports PIV. The Security Key Series and YubiKey Bio FIDO Edition do not. Use the YubiKey 5 Series.
• One toolset per key for certificates. Yubico advises against enrolling certificates with the minidriver or Windows dialogs and with ykman or Yubico Authenticator on the same key (Minidriver introduction). ykman is fine for the PIN and PUK prep before enrolment.
• Set the PUK before Windows first touches the key. The minidriver restricts PUK use while it is at the factory value and probes for the default PUK, which can decrement a custom PUK's retry counter (Setting PUK).
• set-retries resets PIN and PUK to defaults. Run it first, not last.
• PIN and PUK lockout. Too many wrong PINs blocks the PIN; the PUK unblocks it. Too many wrong PUKs blocks PIV entirely and the key must be reset and re-enrolled. Keep the PUK with IT.
• Leave the management key alone and let the minidriver protect it. A random management key that Windows cannot read breaks enrolment.
• Firmware cannot be upgraded. Check ykman info. RSA 3072 and 4096 need firmware 5.7 or later. Firmware before 5.7 is affected by Yubico advisory YSA-2024-03 for ECDSA keys (an attack requiring physical possession and specialised equipment). Using RSA 2048, as in the template above, sidesteps it.
• Touch policy. The default is no touch. To require a touch at sign-in, set NewKeyTouchPolicy before enrolment (Setting Touch Policy); it cannot be added to an already enrolled key.
• Keys left in the PC. Users leaving the key plugged in defeats removal policy. A lanyard or key ring helps, and so does using the same key for cloud MFA so users need it with them all day.

Operations

• Break-glass account exempt from the smart card requirement, password vaulted, logons alerted.
• Key register (user, key serial, certificate serial, expiry, PUK reference) is essential for revocation and renewal.
• Pilot first. A handful of users and devices for a week before a wider rollout.

Frequently asked questions

Can I use a YubiKey as a smart card for Windows logon?

Yes. YubiKey 5 Series and YubiKey 5 FIPS Series keys include a PIV smart card application that Windows treats as a standard smart card. With an Enterprise CA and the YubiKey Minidriver, users sign in by inserting the key and entering a PIN.

What is the difference between PIV and FIDO2 on a YubiKey?

PIV is a certificate-based smart card standard: it works with Active Directory, Windows logon, VPNs and document signing, and needs a PKI. FIDO2 is the passkey standard used by websites and cloud identity providers, and needs no PKI. A YubiKey 5 Series key does both at once. Read more in our ultimate guide to FIDO2 and phishing-resistant MFA and what is a FIDO2 security key.

Which PIV slot does Windows logon use?

Slot 9a (PIV Authentication). When you enrol through Windows with the YubiKey Minidriver, the first smart card logon certificate is written there automatically.

Do I need a PKI to use YubiKey smart card logon?

Yes. Certificate-based Windows logon needs a certificate authority the domain trusts, normally Active Directory Certificate Services. If you do not want to run a PKI, consider Windows Hello for Business or FIDO2 passkeys with Microsoft Entra ID instead.

How do I revoke a YubiKey if the user does not return it?

Disable the AD account, revoke the certificate on the CA, publish a new CRL and flush the CRL cache on your domain controllers. You do not need the physical key. See Step 3 above.

What happens if a user forgets their PIN?

After the set number of wrong attempts the PIN is blocked. IT unblocks it with the PUK and sets a new PIN. If the PUK is also exhausted, the key must be reset and re-enrolled.

Does the Security Key by Yubico support smart card logon?

No. The Security Key Series supports FIDO2 and U2F only. For certificate-based Windows logon you need a YubiKey 5 Series, 5 FIPS Series or YubiKey Bio Multi-protocol Edition.

Yubico reference documentation

Rolling out YubiKeys across your organisation?

Trust Panda is a Yubico Gold Partner with local stock and a Sydney support team. We supply YubiKeys for business and government, including FIPS validated keys, with direct-to-employee delivery for distributed teams. For 10 or more keys, request a volume quote or read more about hardware security keys for business.

Related reading: Microsoft is retiring SMS-based MFA: how to roll out passkeys · Ultimate guide to FIDO2 and phishing-resistant MFA · YubiKey 5 Series vs YubiKey Bio