What is the difference between passkey login and OTP-based step-up for account actions?

Passkey login proves the user has the enrolled device and can complete a phishing-resistant sign-in. OTP-based step-up adds a separate verification event for sensitive actions such as registering or modifying passkeys. In practice, passkeys can secure the primary login path, while OTP can serve as an additional control for higher-risk account management steps.

Why This Matters for Security Teams

Passkey login and OTP-based step-up solve different problems, even though both are used at the account boundary. Passkeys are strongest when the organisation wants a phishing-resistant primary sign-in path. OTP step-up is more about adding a second verification event before sensitive changes, especially when the action itself changes recovery options, credentials, or trust settings. That difference matters because the control is meant to protect two distinct moments in the account lifecycle.

Security teams often overestimate OTP because it still feels like a second factor, but OTP is not phishing-resistant and it does not protect the same way a passkey does during sign-in. The practical value is in placement: passkeys reduce routine login exposure, while OTP can still be used as a friction layer before high-impact account management actions. OWASP Cheat Sheet Series remains useful here because the implementation details around authentication and step-up are usually where teams weaken the design.

In practice, many security teams discover the difference only after an attacker has already used an account recovery or credential-change path that was treated as “just another login.”

How It Works in Practice

Passkey login is typically the primary gate to the account. It binds sign-in to a device-backed cryptographic credential and user presence or verification, so the user proves control of the enrolled authenticator rather than typing a reusable secret. That makes it well suited to everyday authentication, especially where phishing, replay, and password reuse are the main concerns.

OTP-based step-up is different. It is usually triggered only when the user attempts a sensitive action, such as registering a new passkey, changing recovery information, or modifying security settings. The point is not to replace strong login, but to add a separate check before the account state changes in a way that could weaken future authentication. In mature designs, step-up is tied to riskier actions, not to every request.

Use passkeys to protect the main sign-in path and reduce dependency on shared secrets.
Use step-up only for actions that materially change account trust, recovery, or access.
Treat OTP as a higher-friction control for specific actions, not as an equal substitute for phishing-resistant login.
Log the step-up event separately so recovery changes and credential enrollment are auditable.

The most common implementation mistake is to put OTP on top of weak sign-in and call the result “strong authentication”; that adds friction, but it does not erase phishing risk. These controls tend to break down when recovery flows, support desks, or session reset paths bypass the step-up rule entirely.

Common Variations and Edge Cases

Tighter step-up controls often increase user friction and support burden, so organisations have to balance security gains against account recovery complexity. That trade-off becomes sharper when the account controls high-value services, shared access, or delegated administration.

One common variation is to require OTP only for enrollment or removal of passkeys, because those actions can alter the future authentication baseline. Another is to use passkey-first login but still allow OTP step-up for administrative actions when device change, location, or session age increases risk. Best practice is evolving toward fewer OTP prompts overall, but there is no universal standard for exactly when to trigger step-up.

Another edge case is fallback. If OTP is treated as a permanent backup for sign-in, it can become the weakest surviving path in the account. That is acceptable only when the organisation has explicitly decided that recovery convenience outweighs phishing resistance for that user population or account class.

Risk and Threat Considerations

The main risk is confusing a strong primary login method with a strong high-risk action control. Passkeys reduce phishing and credential replay at sign-in, but they do not automatically protect recovery enrollment, credential replacement, or other account-management actions. OTP step-up helps there, but it introduces its own exposure if the OTP channel or recovery path is intercepted, reset, or socially engineered.

Failure mechanism: Attackers often target the weaker adjacent path, not the main login. If passkey enrollment, recovery, or device-change actions can be approved through a simpler fallback, the attacker can pivot from account access to persistent control by changing the authentication setup.

Impact: The account can remain accessible to the attacker even after the original login method is secured, because the trust settings themselves have been altered. That can expose data, administrative actions, and future sign-ins.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
OWASP Agentic AI Top 10	Authentication and authorization abuse	Accounts and step-up actions rely on authentication strength and trust boundaries.
Recommendation — Use phishing-resistant authentication for sign-in and separate stronger checks for security-setting changes.
CIS Controls v8	6 — Access Control Management	The question centers on controlling account actions and sensitive access changes.
Recommendation — Restrict sensitive account actions to approved conditions and verify step-up before changes.
OWASP Non-Human Identity Top 10	Authentication, credential lifecycle, and access governance	Passkey enrollment and step-up govern credential changes and account trust state.
Recommendation — Protect credential enrollment and recovery paths with stronger verification and tighter governance.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	The topic compares authentication methods and access controls for account actions.
Recommendation — Align sign-in and step-up decisions to the sensitivity of each account action.
NIST SP 800-63	Digital Identity Guidelines	Passkeys and OTP step-up are identity assurance and authentication decisions.
Recommendation — Apply assurance-based authentication rules that distinguish sign-in from recovery and step-up.

Practitioner Guidance

What to prioritise: Use passkeys as the default authentication path and reserve OTP step-up for narrowly defined, high-impact account actions. The key design question is not “which factor is stronger,” but “which action changes the account’s future trust posture.”

Decision rule: If an action can add, remove, or replace authentication methods, treat it as higher risk than a normal session action and require a separate verification event. If the action only reads data or performs low-risk routine work, avoid unnecessary step-up that trains users to approve prompts reflexively.

What good looks like: The login path is phishing-resistant, recovery is tightly bounded, and security-sensitive changes are visible, rate-limited, and attributable. The organisation can explain exactly why passkeys protect sign-in while step-up protects the actions that would otherwise weaken sign-in later.

Practitioner takeaway: Strong authentication is only complete when the recovery and credential-management paths are at least as well governed as the login path.