Guide

What Is a Passwordless Login? The Case for Hardware-Backed Security

A CISO's guide to identity assurance, FIDO2 architecture, and the compliance requirements that are making hardware-bound authentication increasingly necessary.

Many organizations have begun moving toward passwordless authentication. Single sign-on is deployed. Push notifications replaced SMS codes. Passkeys are rolling out. On paper, the password problem is solved.

The question a CISO is actually sitting with is different. It is whether what was deployed stops the attacks now being run against it.

The answer turns on one distinction, and it is not the one most vendor content covers. It is not passwordless versus passwords. It is hardware-bound versus software-based.

A software passkey lives in a cloud keychain. It syncs across devices. It is available anywhere the account holder signs in, which means it is also available wherever that cloud account is compromised. A hardware-bound credential lives in a tamper-resistant chip. It cannot be copied, extracted, or activated remotely. Possession is physical or it is nothing.

For a general workforce logging into a collaboration tool, that distinction is a preference. For a defense contractor subject to CMMC, a hospital system holding electronic protected health information, or any privileged account inside a bank, that distinction determines whether a control requirement is met or missed.

This guide follows what that distinction decides. What identity assurance actually means. How hardware-bound authentication fits into the IAM, SSO, and PAM you already run. Which attack vectors it removes, and which it does not. And what regulated industries are now required to deploy.

A passwordless login is authentication that never involves a typed shared secret. Instead of something you know, access is granted on something you have, something you are, or both together.

That definition covers a wide range of implementations with very different security properties. Magic links sent to email are passwordless. So are one-time codes, push approvals, and FIDO2 credentials. Grouping them under one label is where most enterprise deployments go wrong.

The category that matters for enterprise security is public key authentication built on FIDO2. Here, a key pair is generated at registration. The public key goes to the service. The private key stays with the user. Authentication is a challenge signed by the private key. Nothing shared is ever transmitted, which removes the entire class of attacks built on intercepting or replaying a secret.

Within that category, there are two types, and the difference between them is the subject of this guide.

Software passkeys. The private key is held in a cloud-synced keychain such as an Apple, Google, or Microsoft account, or a password manager. It replicates to every enrolled device. Recovery is straightforward. Compromise of the cloud account puts the credential in reach.

Hardware-bound credentials. The private key is generated inside a secure element and never leaves it. It cannot be exported, backed up, or synced. There is no software path to it, because there is no software copy of it. Authentication requires the physical authenticator to be present at the moment of the request.

Both run on FIDO2. Both are phishing-resistant at the protocol level. The threat model is not the same.

The FIDO Alliance refers to these two categories as synced passkeys and device-bound passkeys, terminology widely used by analysts and identity platform providers. One distinction is worth holding on to. A device-bound passkey can be bound to a general-purpose phone or laptop, and that device is running everything else the user runs. Where a control requires a non-exportable key, the question is not only whether the credential is device-bound but what kind of device it is bound to.

Property	Password	SMS/TOTP code	Push approval	Software passkey	Hardware-bound credential
Resists secret interception	No	No	Yes	Yes	Yes
Resists lookalike-domain phishing	No	No	No	Yes	Yes
Resists AiTM proxy relay	No	No	No	Yes	Yes
Resists approval fatigue	n/a	Yes	No	Yes	Yes
Key survives endpoint compromise	No	No	n/a	Cloud-dependent	Yes
Requires physical presence	No	No	No	No	Yes
Works with no cloud connectivity	Yes	TOTP only	No	Cached only	Yes
Satisfies NIST AAL3	No	No	No	No	Yes

Is WebAuthn the same as FIDO2?

FIDO2 is the overall standard. It has two components. WebAuthn is the web API, standardized by W3C, that lets a website or application ask a browser to create and use a credential. CTAP2 is the protocol that lets a separate, external authenticator talk to the browser or operating system.

WebAuthn is the part your applications call. CTAP2 is the part that reaches an authenticator the user carries.

Not every hardware-bound credential goes through CTAP2. Authenticators built into the device itself, such as Touch ID, Face ID, or Windows Hello backed by a TPM, are reached through the operating system's own APIs. The key still sits in hardware and still cannot be exported. It is simply hardware the user was already carrying for other reasons, which is the distinction the previous section makes.

Both software passkeys and hardware-bound credentials use the same WebAuthn calls. A relying party sees a FIDO2 credential in both cases. What differs is where the private key lives, whether it can be copied, and whether it can be used without the user physically present. Those properties are what compliance frameworks now test against, and they are invisible unless you look at attestation.

This guide is not an argument for going passwordless. That decision has been made in most enterprises. It is an argument about which kind of passwordless, for which users, and why that choice now carries legal weight in regulated industries.

Identity assurance: proving the right human is present, not just that a credential was used

Authentication answers a narrow question. Was a valid credential presented? Identity assurance answers the question a CISO is accountable for. Was the right human the one who presented it?

The gap between those two questions is where most credential-related breaches still occur, and it is a gap that stronger cryptography alone does not close.

The enrollment integrity problem

This is not a theoretical weakness. A campaign against Microsoft Entra users runs it directly. Attackers stand up a fraudulent enrollment portal, call employees posing as internal IT, and walk them through what looks like a routine passkey setup. Credentials captured on that fake interface are used to reach the real account, where the attacker registers a passkey on hardware they control. The employee carries on working. The attacker holds a valid credential for as long as it goes unnoticed. We covered the mechanics of that campaign in Passkeys are not completely secure without dedicated biometric hardware.

The help desk is the cheaper route to the same outcome. A call reporting a lost device, handled as a support ticket rather than an identity check, issues a fully valid credential to whoever asked for it.

From that moment on, every authentication event is cryptographically perfect. The signature validates. The origin binds. The relying party has no basis to reject anything. The system is working exactly as designed, and it is authorizing the wrong person.

FIDO2 does not detect this. It cannot. FIDO2 secures the authentication event. It says nothing about whether the identity behind the enrollment was ever verified. Phishing-resistant authentication does not produce phishing-resistant enrollment.

This is the weakest link in most passwordless deployments, and it is almost entirely absent from the industry writing on phishing-resistant MFA. Organizations invest heavily in the strength of the credential and treat enrollment as an IT support workflow. Every downstream guarantee inherits the weakness of that workflow.

What is the level of identity assurance?

NIST answers this with Identity Assurance Levels, defined in the SP 800-63 digital identity guidelines. IALs describe how rigorously an identity was proven before any credential was ever issued.

IAL1.

No identity proofing required. Attributes are self-asserted. The system knows an account exists and nothing about who is behind it.

IAL2.

Remote or in-person proofing with evidence. Government-issued documents are verified, and the presenter is matched to the evidence. Suitable for most enterprise access.

IAL3.

In-person or supervised remote proofing, performed by a trained operator, with biometric collection that binds the verified human to the credential being issued. This is the level required where a fraudulent enrollment would be a serious consequence in its own right.

IAL is not about login. It is about everything that happens before login is ever possible. An organization running AAL3-grade authenticators on top of IAL1 enrollment has built a vault door on a tent.

The chain that makes hardware mandatory

Here is the connection that decides deployment in regulated environments, and it is the one that page one of the search results does not make.

Assurance levels do not operate independently. Identity proofing at IAL3 requires authentication at AAL3. You cannot verify a human to the highest standard and then let them authenticate with a credential that can be copied. The chain would break at its last link.

AAL3, defined in NIST SP 800-63B-4 Section 2.3, requires four things:

A non-exportable private key, held in a hardware-protected, isolated environment that prevents the key from being extracted.
Phishing resistance, meaning the authenticator will not produce a valid response to anything other than the genuine relying party.
A replay-resistant authentication protocol.
Authentication intent, meaning the credential cannot be used without a deliberate act by the human holding it.

A synced passkey fails the first requirement by design. Syncing is exportability. That is the feature.

You do not have to infer that conclusion. The standard states it directly:

Since syncable authenticators (described in Appendix B) require the private key to be exportable, syncable authenticators SHALL NOT be used at AAL3.

SHALL NOT is not guidance. In NIST's language it is a prohibition. Revision 4 added syncable authenticators as a defined category and then ruled them out of the highest assurance level in the same breath, which settles an argument that used to be a matter of interpretation.

A hardware-bound FIDO2 credential satisfies all four.

So the chain runs: regulated system, therefore IAL3 proofing, therefore AAL3 authentication, therefore a hardware-bound non-exportable key. Once an organization's data classification lands it at IAL3, hardware stops being the stronger option and becomes the only compliant one.

Closing the enrollment gap with biometric binding

The chain above solves credential strength. Enrollment integrity is solved by binding the credential to a verified biometric at the moment it is issued.

When a fingerprint is captured during supervised proofing and matched on-device at every subsequent authentication, the credential stops representing a device and starts representing a person. A lost authenticator is inert. A stolen one is inert. Neither can be activated by anyone other than the enrolled human.

This is the difference between proving that a credential was used and proving that a specific verified person used it. It is the whole of identity assurance, and it is what TokenCore™ was built to deliver as a layer across existing identity infrastructure rather than a replacement for it.

Integration with IAM, SSO and PAM: an additive trust layer, not a replacement

The most common objection to hardware-bound authentication is architectural. Security leaders assume it means re-platforming identity infrastructure that took years to stabilize.

It does not. A hardware-bound FIDO2 credential is a credential type inside the identity platform you already run. Okta, Microsoft Entra ID, and Ping Identity all support FIDO2 and WebAuthn natively. Registration happens in the existing enrollment flow. Enforcement happens in existing policy. No custom development is required.

IAM and SSO

Do you need MFA if you have SSO?

Yes, and the reason is structural rather than incremental. SSO consolidates access. One successful authentication opens every downstream application in the federation. That is the operational benefit and it is simultaneously the risk profile. SSO does not create a weaker login. It creates a single login worth attacking.

Multi-factor authentication on the SSO session is what closes that exposure. Which factor you choose determines whether it is actually closed.

The AiTM problem

Adversary-in-the-middle attacks do not try to defeat the second factor. They let it succeed. A proxy sits between the user and the real identity provider, relays every step of the authentication faithfully, and captures the session cookie the provider issues at the end. The push notification was genuine. The user approved a real login. The code was correct. None of it helps, because the attacker took the session, not the login.

Push MFA and TOTP are both fully transparent to this. The user experience during an AiTM attack is a normal, successful sign-in.

How origin binding stops it

A hardware-bound FIDO2 credential is registered against a specific relying party identifier. When it signs an authentication challenge, the signed data includes the origin the request actually came from. The identity provider validates that origin against the registration.

A proxy operates on a different domain. It has to, because it is not the real site. The assertion it obtains carries the wrong origin and fails verification at the identity provider. No session cookie is ever issued. There is nothing to steal because nothing was created.

This is prevention at the architecture level, not detection after the fact. The attack does not get harder. It stops working.

Step-up authentication keeps friction proportionate

Existing policy engines already support conditional requirements. Hardware-bound authentication can be required for privileged operations, production access, or sensitive record retrieval, while standard MFA covers routine access. Most organizations start here, then widen the perimeter as rollout matures.

PAM

How does PAM authentication work?

Privileged access management works on a checkout model. Credentials for privileged accounts live in a vault rather than with the administrator. When elevated access is needed, the user authenticates to the vault, checks out a credential or opens a brokered session, performs the work, and the credential is rotated on return. The vault records the session.

The entire model rests on one assumption: that the person authenticating to the vault is the authorized administrator.

Privileged accounts are the primary objective of lateral movement inside a breached network. An attacker with a foothold on a workstation is not looking for files. They are looking for the path to domain administration.

Why software credentials fail here

On a compromised endpoint, credential material is reachable. Memory regions such as LSASS hold authentication artifacts. Credential stores, cached tokens, and browser-held session data are all recoverable with tooling that has been commodity for a decade. Once extracted, that material is used remotely, from the attacker's own infrastructure, at a time of their choosing.

Why hardware-bound credentials do not

The private key never exists outside the secure element. There is no memory region holding it, no store containing it, no cache retaining it. Full administrative compromise of the endpoint yields nothing reusable.

Vault checkout becomes conditional on physical presence. The authenticator has to be there, held by the verified human, at the moment of the request. An attacker inside the network with complete control of the machine still cannot open the vault, because the missing factor is not on the network at all.

CyberArk, BeyondTrust, and Delinea all support FIDO2 and WebAuthn, but set expectations properly here. PAM support for FIDO2 is less mature than it is in the identity providers. Depending on the tool and the version, enforcing it can mean an additional module, an external identity provider handling policy, or some integration work rather than a configuration change. It is a scoping question for the deployment plan, not a blocker. PIV and smart card interfaces are available where government PKI is the requirement.

The four attack vectors hardware-bound FIDO2 eliminates

Phishing and AiTM proxy attacks

What is the most phishing-resistant authentication method?

Authentication that is cryptographically bound to the origin it was registered against. In practice today, that means FIDO2 with a hardware-bound, non-exportable key.

The reason is what phishing and AiTM have in common. Neither needs to break the second factor. Both relay a genuine authentication to the genuine site and capture what comes out the other end. Credential replay for passwords. Session capture for everything else.

Does 2FA stop phishing?

Not on its own. SMS codes, TOTP, and push approvals are all relayable. The user completes a real authentication against a real service, and the attacker holds the result. Two-factor authentication raised the cost of credential theft. It did not remove the mechanism.

Origin binding removes the mechanism. A lookalike domain or an intercepting proxy cannot obtain an assertion that validates, because the origin is part of what gets signed. Phishing at the authentication layer is structurally eliminated.

Session hijacking through malware on an already-trusted device, OAuth consent phishing that tricks a user into granting application permissions, and token theft from a compromised browser all operate after a legitimate authentication has completed. They are addressed by session binding, conditional access, token protection, and endpoint controls.

Vendors who claim otherwise are overstating the control. Hardware-bound authentication closes the authentication layer completely. It is not a substitute for the layers above it.

Remote credential compromise

What is the most common way credentials get compromised?

Reuse and theft of material that was never meant to leave the endpoint. Phishing collects it directly. Infostealer malware harvests it from browsers and credential stores. Memory-scraping tools pull authentication artifacts from running processes. The common property is remote reusability: stolen credential material works without the user, without the device, and without the moment.

A hardware-bound private key has none of those properties. It sits in a tamper-resistant chip that the operating system cannot read. There is no API that returns it. Full endpoint compromise, administrative privilege, and physical access to the machine still produce nothing that can be replayed elsewhere.

No credential to steal is a design property here, not a claim.

How to avoid MFA fatigue?

Remove the mechanism that makes it possible. MFA fatigue works by sending repeated push approval requests until one is accepted, often outside working hours, often paired with a message posing as internal IT to explain the notifications away. The attack requires two things: a push channel that can be triggered remotely, and a human who can approve with a single tap.

Number matching and context display reduce the success rate. They do not remove either condition.

A hardware-bound credential has no push channel. Nothing can be triggered from outside. Authentication begins with the human, at the authenticator, in response to a request they initiated. There is no notification to approve and no way for a remote party to generate one. The attack has no surface to run on.

What happens next matters more. When push fatigue stops working, the effort moves to the enrollment channel. A call to the help desk claiming a lost device is cheaper than any technical attack, and it produces a fully valid credential.

This is why enrollment integrity and identity assurance sit at the top of this guide rather than in a footnote. Removing the push channel closes one door and puts pressure on the next one. Supervised proofing with biometric binding is the control that closes it.

The fourth vector is rarely modeled and routinely observed. Credentials get shared. A contractor is given an account for a short engagement. A clinician on a shared workstation hands off to the next shift. An administrator lends access rather than filing a request.

Every one of these is invisible to conventional authentication, because the credential presented is the correct one. Logs show authorized access. Audit trails attribute actions to a person who was not there.

A credential bound to a verified biometric cannot be handed over. The authenticator without its enrolled human is inert. Attribution in the audit log becomes a statement about a person rather than a statement about a device.

Vector	Conventional MFA	Hardware-bound FIDO2
Phishing and AiTM	Exposed The second factor succeeds. The session is relayed.	Closed The assertion is origin-bound. A proxy on a different domain fails verification.
Remote credential compromise	Exposed Credential material is extractable and reusable elsewhere.	Closed The private key never leaves the secure element. Nothing is extractable.
MFA fatigue	Reduced Number matching lowers the success rate. The push channel remains.	Closed There is no push channel. Nothing can be triggered from outside.
Insider misuse and sharing	Exposed The credential presented is the correct one.	Closed Bound to a verified human. The authenticator alone is inert.

Air-gapped and operationally isolated environments

Air gaps are deployed on a simple premise: a network with no external connectivity cannot be reached from outside. That premise holds. It is also incomplete.

The threat inside an isolated environment is not external intrusion. It is lateral movement after something has already crossed the boundary, through removable media, a supplier's maintenance laptop, or a device brought in for a legitimate reason. Stuxnet is the canonical demonstration that isolated networks are reachable. NotPetya demonstrated the second half of the pattern: once inside, harvested credentials propagate faster than any manual response.

The air gap stopped external communication. It did nothing about credential theft internally.

Why standard MFA does not work here

The MFA most enterprises run assumes connectivity that isolated environments do not have.

Push notifications require the authentication platform to reach the user's phone through a cloud messaging service. Without egress, no notification is delivered.

Cloud-managed MFA platforms require periodic check-in for policy, licensing, and directory synchronization. Extended isolation degrades them.

TOTP functions offline, which makes it the usual fallback. It is also a shared secret displayed on a screen, phishable by anyone already inside the perimeter, which is precisely the threat the environment is defending against.

Why hardware-bound FIDO2 does

The challenge-response exchange happens locally, between the authenticator and the on-premises authentication server. The server issues a challenge, which the browser or operating system passes to the authenticator. The authenticator signs it. The signature returns the same way, and the server validates it against the public key it registered.

No cloud service participates. No notification is sent. No callback is required. The full transaction is local, and it is cryptographically identical to the one that would run on a connected network.

The credential is on the physical authenticator, not on the network. That single property is what makes it work in isolation, and it carries a second benefit that matters just as much in these environments: a credential that lives in a secure element cannot be exfiltrated, because there is nothing to copy. Physical presence is required at every authentication event, which addresses insider risk on the same control that addresses external compromise.

Form factor constraints are real

This is where honest guidance matters more than a strong claim.

USB authenticators are impractical in several of the environments that need them most. Gloved hands cannot operate a fingerprint sensor reliably in a clean room, a cold store, or a procedural setting. Shared workstations across shifts make one-authenticator-per-workstation models fail. Ruggedized and secure facilities often prohibit personal devices entirely, which removes the phone-based options before the conversation starts.

These are not edge cases. They are the normal operating conditions of defense manufacturing, healthcare delivery, and utility operations.

Operating condition Gloved hands, industrial or clean room

USB key No Fingerprint sensors are unreliable through gloves. Ports are often inaccessible.

Phone-based MFA Limited Handling a phone mid-task is impractical and often prohibited.

Wearable or NFC Yes Proximity activation. No free hand required.

Operating condition Shared workstations across shifts

USB key Limited Workable, but repeated physical sign-in is abandoned under time pressure.

Phone-based MFA Limited Personal devices are inconsistent across a shift rota.

Wearable or NFC Yes Per-person credential with biometric match. Attribution holds.

Operating condition Restricted facilities with no personal devices

USB key Yes Permitted, where a port is available at the point of access.

Phone-based MFA No Every phone-based method is unavailable before the conversation starts.

Wearable or NFC Yes On-person credential. No phone dependency, no network callback.

Defense and government: CMMC, NIST SP 800-171 and ITAR

The Cybersecurity Maturity Model Certification is the authentication compliance requirement for the entire US defense industrial base. It appears in none of the widely ranking articles on phishing-resistant MFA, which is a gap worth noting given how many organizations it binds.

CMMC Level 2 inherits the security requirements of NIST SP 800-171 Revision 2, which is the revision the CMMC rule is written against at 32 CFR 170.14(c). Revision 3 was published in May 2024 and renumbers these controls, but it does not yet apply to CMMC assessments, so Revision 2 numbering is the one to use. The relevant control is 3.5.3, expressed in CMMC as practice IA.L2-3.5.3: use multifactor authentication for local and network access to privileged accounts, and for network access to non-privileged accounts.

Read at face value, push notifications appear to satisfy it. Read in the context of federal direction on phishing-resistant authentication, they do not satisfy the intent. Executive Order 14028 and OMB Memorandum M-22-09 both direct federal agencies toward phishing-resistant methods specifically, and assessor expectations for the defense supply chain follow federal direction rather than lagging it.

CMMC Level 3 applies to contractors handling controlled unclassified information at elevated risk and adds requirements drawn from NIST SP 800-172. The direction of travel is toward AAL3-equivalent assurance, which means hardware-bound authenticators with non-exportable private keys.

NIST SP 800-63B-4 Section 2.3 is the control text that defines what that means. AAL3 requires a non-exportable private key in a hardware-protected environment, phishing resistance, a replay-resistant protocol, and authentication intent. Hardware-bound FIDO2 satisfies all four. Cite this section in your control documentation, because it is where the exportability requirement lives and where the standard states that syncable authenticators shall not be used at AAL3.

ITAR and classified environments. Contractors handling technical data under ITAR generally operate under the same CUI protection obligations, which routes back to NIST SP 800-171 and CMMC. Classified systems fall under the DoD Risk Management Framework, which aligns with AAL3 at higher impact levels.

On zero trust. The federal zero trust mandate set out in Executive Order 14028 and OMB M-22-09 names phishing-resistant MFA explicitly as an identity requirement. Hardware-bound authentication satisfies the identity pillar of that architecture more completely than any other authenticator type, because zero trust assumes the network is hostile and hardware-bound credentials are the only ones that stay trustworthy under that assumption. It delivers one of the five pillars, not the other four.

Healthcare: HIPAA and the proposed Security Rule update

45 CFR § 164.312(d) requires covered entities to implement procedures to verify that a person seeking access to electronic protected health information is the one claimed. The control is about the human, not the credential. It has been read loosely for two decades.

The proposed Security Rule update. The HHS Office for Civil Rights notice of proposed rulemaking published in January 2025 would make multi-factor authentication explicit for ePHI system access, and specifies that authentication must remain effective if one factor is compromised.

That second clause is the operative one. Push MFA that an AiTM proxy passes straight through does not remain effective when the first factor is compromised, because the attacker is not defeating the second factor. They are relaying it. If the proposed HIPAA rule is finalized as written, authentication methods vulnerable to AiTM attacks may not meet the new standard.

Where ePHI systems are proofed at IAL3, the chain applies exactly as it does in defense. IAL3 requires AAL3. AAL3 requires a hardware-bound non-exportable key.

Clinical reality. Healthcare has the hardest deployment conditions of any regulated sector. Workstations are shared across shifts by design, because that is how care delivery works. Gloves are worn in procedural settings. A clinician mid-procedure is not going to locate a USB port.

NFC and wearable form factors resolve most of this. Proximity-based authentication with on-device biometric match removes the handling problem entirely. For the rest, step-up deployment is the model that works in practice: hardware-bound authentication for ePHI systems, controlled substance workflows, and administrative access, standard MFA for scheduling and general applications.

Deploy against the workflow that exists rather than the workflow the policy assumes, or clinicians will route around it and the control will exist only on paper.

Financial services: PCI DSS, NYDFS and DORA

PCI DSS v4.0 tightened authentication significantly over v3.2.1. Requirement 8.4.1 mandates MFA for all personnel with administrative access to the cardholder data environment. Requirement 8.4.2 mandates MFA for all access into the CDE, which closed the previous carve-outs for internal and console access. Requirement 8.4.3 covers all remote network access originating from outside the entity's network.

Requirement 8.5.1 is the one most often missed. MFA systems must be resistant to replay attacks. An AiTM proxy relaying a valid authentication is a replay of the resulting session. This means organizations should evaluate whether their MFA method remains vulnerable to credential or session relay and confirm compliance with their assessor.

NYDFS 23 NYCRR Part 500, as amended in November 2023, requires MFA for any individual accessing the covered entity's information systems, with the scope broadened progressively through the phased compliance dates running to November 2025. Privileged accounts and remote access carry the requirement without exception.

DORA, Regulation (EU) 2022/2554, applicable since January 2025, requires financial entities to implement strong authentication mechanisms proportionate to the risk of the system and data concerned. European supervisory guidance maps strong authentication to phishing-resistant methods for critical systems.

Cyber insurance. Carriers now treat phishing-resistant MFA as a rating factor rather than a nice-to-have, particularly for coverage above mid-range limits. Hardware-bound authentication provides something push MFA cannot: auditable proof that a specific verified human was physically present at each privileged authentication event. That evidence changes the risk assessment, and it changes what gets paid on a claim where credential compromise is disputed.

Sector Defense CMMC IA.L2-3.5.3 (NIST SP 800-171 3.5.3)

What it requires MFA for privileged accounts and network access to non-privileged accounts.

Does push MFA satisfy it? Letter only Meets the literal text. Federal direction on phishing resistance points the other way.

Sector Defense NIST SP 800-63B-4 Section 4.3

What it requires AAL3: non-exportable key in hardware, phishing resistance, replay resistance, authentication intent. Syncable authenticators are prohibited.

Does push MFA satisfy it? No Fails the hardware-bound and impersonation-resistance requirements.

Sector Healthcare 45 CFR § 164.312(d)

What it requires Verify the person seeking ePHI access is the one claimed.

Does push MFA satisfy it? Read loosely Accepted in practice for two decades. The text is about the human, not the credential.

Sector Healthcare HHS OCR NPRM, January 2025 (proposed)

What it requires MFA for ePHI access, effective if one factor is compromised.

Does push MFA satisfy it? No An AiTM proxy relays the second factor rather than defeating it.

Sector Financial PCI DSS v4.0 Req 8.4.1 / 8.4.2 / 8.4.3

What it requires MFA for CDE admin access, all CDE access, and remote access.

Does push MFA satisfy it? Yes These requirements specify MFA without naming a method.

Sector Financial PCI DSS v4.0 Req 8.5.1

What it requires MFA must be resistant to replay attacks.

Does push MFA satisfy it? No This is the requirement most often missed. A relayed session is a replay.

Sector Financial NYDFS 23 NYCRR Part 500 (amended 2023)

What it requires MFA for any individual accessing covered information systems.

Does push MFA satisfy it? Letter only Satisfies the text. Supervisory expectation is moving toward phishing resistance.

Sector Financial DORA, Regulation (EU) 2022/2554

What it requires Strong authentication proportionate to system and data risk.

Does push MFA satisfy it? Depends on risk Guidance maps strong authentication to phishing-resistant methods for critical systems.

Who needs hardware-bound authentication, and how to make the case

Not every user needs it. Treating this as an all-or-nothing decision is why deployments stall in procurement.

The decision criteria

Four questions decide it.

What does this account reach? Privileged access, production systems, and administrative consoles sit in a different category from a scheduling tool.
What is the regulatory classification of the data? CUI, ePHI, and cardholder data carry explicit control requirements. General business data does not.
Does the environment have reliable cloud connectivity? If not, cloud-dependent MFA is not an option regardless of preference.
Is the account in PAM scope? If it is vaulted, it is a lateral movement target, and the vault is only as strong as the authentication in front of it.

User population	Recommended authenticator
All privileged and administrative accounts	Hardware-bound, no exception
Access to CDE, ePHI, or CUI at IAL2 and above	Hardware-bound
Remote access to regulated systems	Hardware-bound
Personnel in air-gapped or isolated environments	Hardware-bound
Executives and named high-value targets	Hardware-bound
Developers with production deployment rights	Hardware-bound
General workforce on low-sensitivity applications	Software passkey
Consumer-facing authentication	Software passkey
Contexts with no framework mandate for non-exportable keys	Software passkey

Software passkeys remain a substantial improvement over passwords and are the right answer for the majority of a general workforce. This is not an argument against them. It is an argument about where they stop being sufficient. Passwordless removes the largest attack surface in enterprise identity. Hardware-bound passwordless removes the rest of the authentication layer. Neither removes the need for the controls above it.

Building the business case

Security leaders rarely lose this argument on merit. They lose it on cost, and the cost conversation is usually run on the procurement line alone.

On the cost side

Authenticator procurement, distribution logistics, enrollment time, and replacement for loss and turnover. These are real and they are front-loaded. Budget for them accurately rather than optimistically, because a rollout that runs out of authenticators in month three loses momentum it does not regain.

On the return side

Password reset tickets disappear for the covered population, and password resets are consistently among the highest-volume categories in enterprise service desks. MFA bypass requests and lockout escalations disappear with them. Help desk enrollment fraud, which has no clean cost line but a very large tail, is closed by supervised proofing. Cyber insurance premiums respond to demonstrable phishing-resistant controls. Audit preparation shortens when a control maps cleanly to a citation rather than requiring an argument.

Across a three-year horizon, organizations above roughly 5,000 users generally find the operational savings exceed the deployment cost. Below that threshold, the case is usually made on compliance necessity or risk concentration rather than on cost recovery. Both are legitimate. Know which one you are making before you present it.

Deployment in practice

The mechanics are the least difficult part of this.

Scope the population using the decision criteria above. Start with PAM and privileged accounts. It is the highest risk concentration and the smallest population.
Verify platform support before you commit to a scope. Okta, Entra ID and Ping Identity support FIDO2 and WebAuthn natively. PAM tools and in-house applications are where the gaps appear, so confirm rather than assume. Check attestation specifically, because attestation is how you enforce hardware-bound authenticators rather than accepting any FIDO2 credential, and a platform can support WebAuthn without giving you that control.
Fix enrollment before you fix authentication. Supervised proofing with biometric binding. Without it, the strongest credential in the world is issued through the weakest process in the organization.
Enforce through existing policy. Step-up rules for privileged operations, standard MFA for routine access. Widen scope as the population adapts.
Match the form factor to the working conditions. Test with the people who will use it in the environment where they will use it, before the order goes in.

Two expectations worth setting with the board at the outset. Legacy and custom applications will not all support FIDO2, so passwords and phishing-resistant methods coexist for a period measured in years rather than quarters, and the plan needs to say which systems are in that group. And a full migration is a program, not a project. Scoped to privileged accounts it moves quickly, because that population is small and the risk case is unarguable. Extending it across a workforce takes considerably longer.

The distinction that decides it

Most passwordless deployments answered the question of whether to remove passwords. Fewer answered the question of which kind of passwordless, and that is the question with legal weight attached to it.

A synced credential is available wherever the account that holds it is available. A hardware-bound credential requires the verified human to be present. For a general workforce, that is a preference. For a defense contractor, a hospital, or a privileged account inside a bank, it is the difference between a control that is met and a control that is documented as met.

The enrollment integrity problem and the IAL3 to AAL3 chain are what turn this from a security preference into a compliance requirement. Cryptographic strength secures the credential. Identity assurance secures the human. Only one of those is what the control text is actually asking for.

Authentication checks credentials. TokenCore™ proves the human.

See how identity assurance works across your existing IAM stack. A short session covering your current authenticator mix, the control requirements that apply to your sector, and where hardware-bound assurance closes the gap.