MFA, passkeys, and authentication strength: what the terms mean

Authentication strength depends on more than whether a login is labeled “MFA.” The factors, protocol, device protection, enrollment, recovery, and helpdesk process all affect the result. Clear terminology helps organizations compare options without making absolute security claims.

What the official source says

Source fact: NIST SP 800-63B-4 defines requirements and recommendations for authentication and authenticator management. It describes authentication factors as something you know, something you have, or something you are. At Authentication Assurance Level 2, two distinct factors are required, and applications assessed at that level must offer a phishing-resistant option. NIST states that passwords and manually entered one-time passwords are not phishing-resistant.

Terms in practical language

• MFA: authentication using more than one distinct factor. Two passwords are still one factor type.
• One-time code: a short-lived output from an app, token, text, or other method. It can improve protection over a password alone, but manual entry can still be relayed to a fraudulent sign-in page.
• Cryptographic authenticator: a key-based method that proves control of a protected key without sending that private key to the verifier.
• Passkey: a consumer-facing name commonly used for a FIDO/WebAuthn cryptographic credential. Some credentials remain on one device; others can synchronize through an account or platform.
• Phishing resistance: protection created by the authentication protocol, rather than relying only on a user to recognize an impostor site.

Deployment is a lifecycle

DSE recommendation: begin with privileged administrators, remote access, email, finance, and other high-impact applications. Inventory what each application supports, then pilot the strongest practical option with representative users and devices. Document enrollment, additional authenticators, lost-device handling, replacement, revocation, offboarding, emergency access, and support verification.

Recovery can become the weakest path. A strong sign-in method can be undermined if an attacker can convince support to reset it through a weaker process. Use documented identity-verification steps, limit who can reset strong authenticators, log changes, and review unexpected enrollment or recovery events.

Important distinctions

Not every MFA method is phishing-resistant, and not every passkey deployment has identical risk. Synchronized credentials introduce different availability, account-recovery, and device-ecosystem considerations than device-bound credentials. Application support, licensing, accessibility, shared-device use, offline needs, and business continuity may affect the rollout.

No authenticator is “unhackable,” and stronger authentication does not eliminate malicious software, session theft, excessive permissions, or unsafe recovery. It should be one layer in a broader identity program.

Practical next step: choose the ten most consequential accounts, record the current authentication and recovery path for each, and remediate the most exposed administrator or remote-access path first.