Passwordless MFA and hardware tokens are not opposites. A FIDO2 security key can support passwordless login.
Choose based on assurance, audit evidence, recovery risk, and user environment. Convenience alone is not enough.
Passwordless and tokens can be one control
Hardware tokens are authenticators. Passwordless describes a login flow without a typed password.
A roaming FIDO2 key can do both. The user unlocks it with a PIN or biometric check.
Passwordless does not mean password-free risk. The real issue is how you enroll, recover, and audit each authenticator.
What makes FIDO2 phishing-resistant?
FIDO2 and WebAuthn create unique public-key pairs for each relying party. A relying party is the site that checks the login.
Origin binding ties a key to the real site address. A key for login.company.com should reject login-company.com.
This blocks phishing attacks that can beat SMS, TOTP, and push approvals. Think of it as a key that fits one door only.
Platform passkeys live on phones or computers. Roaming FIDO2 keys are portable USB, NFC, or Lightning devices.
PIV cards use PKI, which means digital certificates. Push, TOTP, and SMS usually lack FIDO-style origin binding.
Enterprise rollout takes more than enabling a WebAuthn button. Public-key login needs correct relying-party IDs and approved browser support.
It also needs operating-system support, user-verification rules, and safe enrollment. Enrollment must bind the authenticator to the right person.
Organizations must decide whether passkeys can sync to personal accounts. They may instead limit passkeys to managed devices and approved accounts.
Device attestation can improve inventory evidence in some cases. It also creates privacy, compatibility, and lifecycle tradeoffs.
The common mistake is trusting a phishing-resistant login flow without testing enrollment and recovery. Attackers will use the weaker path.
A staged rollout reduces this risk. Start with managed workforce SSO, then move to high-risk apps and privileged access.
This lets teams test help-desk work, recovery risk, logs, and exceptions. Remove passwords from critical workflows only after those tests.
This distinction sets the baseline. The next section shows what auditors can actually validate.
Test assurance and evidence, not vendor labels
A method is compliance-ready only when its full control system meets the governing rule. A FIDO2 key alone does not prove compliance.
PCI DSS, HIPAA, CJIS, SOC 2, GLBA, and CMMC have different demands. Each rule looks at more than the login method.
An auditor needs proof of identity binding, revocation, recovery, and review. A vendor claim cannot replace those records.
Map access to NIST assurance levels
NIST SP 800-63B defines Authenticator Assurance Levels, called AALs. They describe how much trust a login process can support.
AAL2 usually needs two factors or one multi-factor authenticator. AAL3 adds stronger cryptographic and verifier-resistance rules.
Review the NIST Digital Identity Guidelines. Map each access path before selecting an authenticator.
Evidence an auditor can retrieve
| Control or cost | Platform passkey | FIDO2 hardware key | PIV/smart card |
|---|
| U.S. Unit price | Usually included with managed device | About $29 to $85 per key | About $40 to $150, plus PKI support |
| Phishing resistance | Strong with WebAuthn | Strong with WebAuthn | Strong with certificate validation |
| Inventory evidence | Depends on MDM and IAM logs | Key serial and assignment records | Card issuance and certificate records |
| Typical replacement delay | Hours to 2 days | 1 to 5 business days with shipping | 2 to 10 business days |
| Best fit | Managed knowledge workers | Admins, remote staff, contractors | PIV or government-mandated access |
Start compliance mapping with users, system scope, and needed evidence. Do not start with claims that one authenticator is compliant.
PCI DSS 4.0 requires MFA for access into the cardholder data environment. HIPAA uses a risk-based approach for access controls, records, and reviews.
SOX programs often need proof that financial-system access was approved. They also need periodic reviews and quick revocation.
DORA adds ICT risk and resilience expectations for covered financial firms. NIST SP 800-63B offers a useful assurance benchmark.
Evaluate AAL2 and AAL3 with enrollment, binding, recovery, and monitoring. CJIS policies and internal rules may add further limits.
The evidence model should drive the choice. Next, match that evidence need to each user group.
Match regulated users to the right model
Use platform passkeys for managed workforce access. Use roaming FIDO2 keys for privileged or high-risk access.
Use smart cards where PIV, CAC, CJIS, or contract rules require them. A mixed design is often the most defensible choice.
A practical assurance path
Managed workforce
Platform passkey
MDM + SSO logs
Privileged access
FIDO2 key
PAM + spare key
Mandated federal use
PIV/CAC
PKI + issuance records
Platform passkeys cut shipping and replacement work. They fit employees with assigned managed devices, MDM, and SSO logs.
They work well when the company controls the device. That control links sign-ins to a known device record.
Pros of roaming hardware keys
Roaming keys are portable, separate authenticators. They support serial-number inventory, assignment records, revocation, and physical backups.
They are useful when the endpoint is not under company control. The key travels with the user, not the computer.
Avoid passkey-only access for unmanaged contractors or offline emergency roles. Avoid hardware-key-only access when shipping creates uncontrolled exceptions.
A regulated access model must reflect where each person works. Managed workforce access can favor platform passkeys under MDM control.
The organization must keep identity, device, and sign-in logs. Privileged access should usually require a separate phishing-resistant MFA authenticator.
A roaming FIDO2 key plus a controlled spare is a strong pattern. Third parties may need company-issued keys because their endpoints are unmanaged.
A common failure is giving contractors the same recovery path as employees. Their unmanaged devices make that path much harder to defend.
Deskless workers may need NFC keys or shared-terminal patterns. Each person still needs an individual authenticator.
Users without a corporate mobile device may need PIV smart cards. Remote emergency roles need approved backup methods before an incident.
Those methods must preserve identity checks, revocation, and audit evidence. The next risk is recovery, where strong MFA often fails.
Do not let recovery defeat strong MFA
Recovery is a new authentication event. It needs the same assurance review as normal access.
A lost key does not justify a weak fallback. Otherwise, recovery becomes the attacker’s easiest route.
Build loss and break-glass controls
Lost keys need immediate reporting and IAM revocation. IAM is the system that controls identities and access.
For privileged accounts, require documented identity checks and two approvers. Grant temporary access and review the event afterward.
Price the exception path
Budget for tracked shipping, spare stock, enrollment, and help-desk work. Include IAM or PAM licensing in the total cost.
PAM controls privileged accounts, such as administrator accounts. The weakest fallback still defines your real security level.
A recovery plan may work well in theory, but practice exposes staffing gaps. A spare key without recorded custody is not a controlled backup.
This comparison matters less for low-risk consumer access with no regulated systems. It also does not change a mandatory standard. If a government or industry rule requires PIV, CAC, or a named token model, that rule decides the authenticator choice before cost or convenience.
Recovery design decides whether the control survives real-world pressure. The questions below address the most common design concerns.
Your questions answered
Is a hardware token passwordless MFA?
A FIDO2 key can be passwordless MFA with WebAuthn. The user must also pass a local PIN or biometric check.
Which is better for PCI DSS 4.0?
FIDO2 keys suit privileged cardholder-data access under PCI DSS 4.0. PCI DSS also requires logs, reviews, and secure recovery.
Platform passkeys can support AAL2 when required controls are met. Those controls include enrollment, device management, and recovery.
Hardware tokens work best for privileged staff and unmanaged endpoints. They also fit third parties and auditable physical backup needs.
Are push notifications phishing-resistant MFA?
Push notifications are generally not phishing-resistant MFA. Number matching helps, but it lacks FIDO2 origin binding.
What happens if a user loses both keys?
Use documented, high-scrutiny recovery when a user loses both keys. Require identity proofing, separate approvals, logs, and a post-recovery review.
Which choice is defensible now?
The defensible default is a combined design. Use platform passkeys for managed workforce SSO.
Use FIDO2 hardware keys for privileged and higher-risk users. Use PIV or CAC where federal rules require them.
Choose the combined design unless a mandated smart-card standard already decides the issue. It gives each user group the control it can support and prove.
Platform passkeys have limits. They depend on managed devices, sound enrollment, and safe account recovery.
Hardware keys also have limits. They add shipping, inventory, spare-key custody, and replacement delays of 1 to 5 business days.
- The essential point: Passwordless is a login flow, while a hardware key is an authenticator that can support that flow.
- For managed employees: Platform passkeys often give strong protection with lower handling cost.
- For privileged and external users: Roaming FIDO2 keys give clearer portability, inventory, and backup control.
- For compliance: Evidence of binding, revocation, recovery, and exceptions matters as much as the authenticator itself.
Related sources
These articles can help you explore the topic in more depth:
