Token Code, Smart Card or FIDO Key: What a VPN Accepts

Three devices with the same connector and the same keyring loop participate in three unrelated exchanges. One displays a code that a server checks, one signs with a key that never leaves the device, and one approves a browser sign-in through a protocol of its own. Asking whether a VPN should use certificates or hardware tokens therefore compares a format with a device class. The answer depends on which of the three you actually bought.

Name the Proof Before the Device

A one-time code token produces a value that an authentication service validates through its own mechanism. The VPN may reach that service through RADIUS or a federated identity provider, and the token never needs to hold anything belonging to the tunnel itself. What it proves is that the person holds the device that generates the code. It proves nothing about the machine the code was typed on.

A smart-card style token stores a private key and performs the signing operation on request, which is how a certificate identity is proved without exporting the key. The certificate beside it is public material, and handing out that certificate is a very different act from handing out the key.

A FIDO key speaks a third protocol again. A browser-based sign-in can use it at the identity provider, but success on that website does not mean the same key will appear through a VPN client's smart-card interface.

Some devices implement several of these applications side by side, and vendor documentation lists the modes separately for that reason. It is not evidence that every key on the market supports every mode.

Hardware Protects the Key, Not the Policy

A PIN on a certificate-backed device usually authorises local use of the key, and it is not the password the VPN account system checks. Guidance such as the NIST authenticator guidance calls that local input an activation secret, distinct from the authenticator itself. Assurance comes from the whole design, not from the number of prompts on screen.

Enrollment, renewal and removal stay with the identity owner either way. Someone still decides who may enrol, binds the credential to the right person, and makes replacement possible when a device is lost. Buying a new key does not revoke the old one.

Describe the sign-in ceremony before choosing hardware: does the user type a code, unlock a signing key, or approve a browser prompt? Each answer implies a different client, a different gateway setting and a different help-desk script.

Where the Flows Diverge in Practice

A code token is the easiest to roll out and the weakest against a convincing lookalike page, because a typed code can be relayed in real time. A certificate-backed key resists that class of attack and costs more to operate, since issuance and revocation become part of the service. A FIDO key sits with the web sign-in and depends entirely on whether the identity provider supports it for this application.

Mixed estates are common, and they are not automatically wrong: a certificate for the tunnel plus a code token for the administrative console is a coherent split, provided both are enrolled against the same identity. What breaks is a split nobody documented, where the help desk cannot tell which factor a user is missing.

Make the Decision Concrete

Write the ceremony down as a sequence of steps a real user performs, then check that the client, the gateway and the identity provider all support that sequence. A mismatch usually appears at the last step, where the client cannot address the device at all.

Then confirm what happens when the device is lost or the certificate expires. If that answer is not written down, the rollout has a gap that will be discovered on a Monday morning.

pkcs11-tool --list-slots
pkcs11-tool --list-objects --type cert