Combining Smartcard and FIDO2 at Windows logon, even offline

A regional public-sector organisation in Europe came to us with a Windows estate that was already secured by smartcard logon. Its users carry smartcards, and some of them log in where there is no network: laptops that leave the building and spend hours with no route back to any authentication backend.

At sign-in, Windows exposes different native credential paths through its credential providers, including password, PIN, smartcard and Windows Hello, and each is a strong method in its own right. But those paths are not designed to be freely chained into the exact sequence this organisation wanted: the smartcard certificate first, a separate FIDO2 assertion second, no second PIN forced on the user, the whole flow working offline, and a controlled MFA fallback for the day a card is lost or forgotten.

Each of those requirements collides with a different assumption about how Windows sign-in works.

Why add FIDO2 when a smartcard and PIN are already two factors?

A smartcard logon is not weak, and it can meet the classic definition of multi-factor authentication: something you have, the card, and something you know, the PIN. So the objection is fair: why add anything at all?

The answer is in where the PIN goes. A smartcard used for Windows logon typically holds a user certificate and the matching private key on a hardware token. The user inserts the card, Windows reads the certificate, and the user types a PIN. That PIN never travels to a server; it unlocks the card locally so the private key can be used to prove possession of the certificate. What the backend verifies is the certificate-based authentication, backed by the private key on the card, not the PIN itself. The PIN protects that single credential rather than adding a second proof verified in its own right.

This organisation wanted a second assertion, verified in its own right and bound to the person rather than to the token alone. On these tokens the FIDO2 step is verified by a fingerprint on the token, so the login combines something you have (the token), something you know (the smartcard PIN) and something you are (the fingerprint). That closes the obvious gap: a smartcard and a shared or disclosed PIN are not enough on their own, because the FIDO2 step still needs the enrolled fingerprint.

Adding a separate factor after smartcard login, without replacing the cards

OpenOTP, our authentication server, adds the factor on top of the existing smartcard logon through its Windows credential provider, working with the cards already deployed rather than requiring new hardware. After the smartcard certificate is validated, it sends a second authentication request for an additional factor: one check confirms the certificate from the card, the other validates the added factor.

In this project the added factor was FIDO2, with WebADM, the central console that runs the suite’s services, acting as the relying party that verifies the FIDO2 assertion. What changed was a second cryptographic proof sitting behind the smartcard, verified in its own right and governed by OpenOTP and WebADM policy.

The two assertions were separate at the authentication layer, even if, in this deployment, they were carried by the same physical token: the smartcards also held the FIDO2 credential, so a single token did double duty. That simplifies procurement and user handling, but it also changes what happens when the token goes missing.

One PIN and a fingerprint, not two PINs

A token that is both a smartcard and a FIDO2 authenticator can ask for two PINs at logon: the smartcard PIN to unlock the certificate, then a FIDO2 PIN to unlock the key. Two PINs at every login is the kind of friction that generates user complaints and puts the IT team on the back foot.

FIDO distinguishes two things: User Presence, the physical touch that proves someone is there, and User Verification, a PIN or biometric on the key itself. They can be required independently. These tokens have a fingerprint sensor, so FIDO User Verification is satisfied by a fingerprint rather than a second PIN. The user enters the smartcard PIN once, then touches the sensor: one gesture that both proves presence and verifies the fingerprint on the token. There is no second PIN, and the FIDO2 response remains phishing-resistant.

A second factor that keeps working offline

Many second factors need connectivity: an OTP by email or SMS, a push, a cloud call. For users who work off the network, that is the failure point.

The OpenOTP credential provider switches to offline mode automatically when the backend is unreachable, and both smartcard and FIDO2 can work in that mode. FIDO2 suits this because it relies on asymmetric cryptography: once the endpoint has been seeded during a prior online login, the authenticator answers a challenge and the response is checked locally according to the offline policy.

The prerequisite is worth stating, since it affects rollout: offline use requires at least one prior successful online login per user and per machine, which seeds the offline data on the endpoint. After that, a user on a disconnected laptop completes the same card-and-touch login they would on the network.

This is why FIDO2 fit the offline requirement where an emailed or texted code would not: it can be verified on the endpoint, without reaching anything.

What happens when a user loses or forgets the smartcard

Because one token carried both the certificate and the FIDO2 credential, losing or forgetting the card removes both factors at once, which without a fallback means lockouts for the IT team to clear. That is the case the fallback exists for.

A second credential provider lives on the endpoint, next to the smartcard one. When the card is absent, the user picks the other tile and authenticates with username and password, but the fallback is still multi-factor: the password alone is not enough, and the user must complete an emergency one-time code delivered through the OpenOTP Token app or by email. The smartcard path stays the default. Because a delivered code has to arrive, this recovery route is online, unlike the offline card-and-FIDO2 path.

What this Windows smartcard MFA setup gives the user, and the administrator

The user gets a Windows login that asks for one PIN and a fingerprint, runs the same way on a disconnected laptop as on the network, and still lets them in when their card is missing. The smartcard logon is kept, with a separate factor that is verified in its own right and bound to the person, and identity stays on-premise.

For the administrator, the factors, the offline behaviour and the fallback are governed as policy in WebADM, the console the rest of the suite already runs from, and no new cards or tokens had to be issued to add the second factor.

Further reading

• Windows Login & RDS: https://www.rcdevs.com/solutions/windows/
• Login & NAC using PKI: https://www.rcdevs.com/solutions/pki/
• FIDO2 authentication: https://www.rcdevs.com/solutions/fido2/
• License and features: https://www.rcdevs.com/license-features/