Why do phishing-resistant credentials still need session controls?

Why phishing-resistant sign-in is only the first control

Passkeys and FIDO2 materially raise the bar against phishing, but they only prove the user completed a strong initial authentication event. They do not by themselves govern what happens during the rest of the browser or app session, where token theft, device compromise, risky location changes, and abnormal behaviour can still create exposure. Session controls close that gap.

The practical distinction is between phishing-resistant authentication and ongoing session trust. Authentication answers "who signed in", while session control answers "should this session still be trusted". That second question becomes more important as access lasts longer and as applications hold sensitive actions behind the same token or browser session.

Session control is also where many real-world defeats move after the login step. A strong credential can still sit inside a live browser session, a mobile app session, or an SSO session that is later abused through theft, token replay, device handoff, or a compromised endpoint. The authentication factor may remain uncompromised while the session becomes the attacker’s easiest path.

What session controls actually add after passkeys

Session controls add context-aware decisions after sign-in. Common examples include session time limits, inactivity timeout, reauthentication for sensitive actions, device binding, risk-based step-up, IP or geolocation checks, token revocation, and continuous evaluation of whether the device or user context has changed enough to invalidate trust.

This matters because phishing-resistant authentication removes one class of attack, credential submission to a fake login page, but not every post-authentication abuse path. If an attacker obtains an active session cookie, OAuth token, refresh token, or device session, they may not need to break the passkey flow at all. For that reason, the best control posture combines strong sign-in with controls over token lifetime, session scope, and session revocation.

That is why session design and token handling are a core part of OWASP ASVS expectations for authentication, session management, and authorization. It is also why deployment guidance such as the OWASP Cheat Sheet Series remains relevant even when the login method itself is modern and phishing-resistant.

Why attackers still target the session after the factor challenge

Attackers often prefer the session because it can be cheaper to abuse than to defeat strong authentication again. Once a user is signed in, a stolen session may let an attacker move laterally within the application, approve transactions, access data, or impersonate the user until the session expires or is revoked. In other words, phishing-resistant credentials reduce one entry path, but they do not remove the post-login attack surface.

That is especially true in environments where sessions are long-lived, step-up checks are rare, or the application trusts a session too broadly across devices and locations. A good session control model therefore treats sign-in as one event in a broader trust lifecycle, not as a permanent proof of identity. The control objective is to keep the session narrowly scoped, short enough in duration, and observable enough to be interrupted when risk changes.

For a concrete standards anchor, NIST SP 800-63 Digital Identity Guidelines is useful because it pairs phishing-resistant authenticators with assurance concepts that still depend on session and reauthentication decisions. Strong sign-in is necessary, but it is not the full trust model.

Risk and Threat Considerations

The main risk is over-trusting a session after a strong login. If the browser, device, or token is compromised later, the attacker can act as the user without needing to defeat the passkey again. Long-lived or over-broad sessions increase blast radius because they widen the window in which token replay, endpoint compromise, or session hijacking can succeed.

Failure mechanism: A valid session token, cookie, or refresh token is stolen, replayed, or retained after the user’s device or context changes, so the authentication event remains valid while the attacker inherits the session’s authority.

Impact: Sensitive actions, data access, and account control remain exposed until the session expires, is stepped up, or is revoked, which can turn a phishing-resistant login into a persistent compromise.

Practitioner Guidance

What to prioritise: Treat session lifetime, token scope, and revocation as first-class controls, not as postscript settings. If a session can reach sensitive data or privileged actions, require shorter duration, stronger reauthentication on risk change, and explicit invalidation paths.

What to verify: Confirm that the application can revoke active sessions quickly, that refresh tokens do not silently preserve access too long, and that sensitive actions force revalidation when device, location, or risk context changes. If you cannot prove those behaviours, the control is weaker than the sign-in method suggests.

Practitioner takeaway: Phishing-resistant credentials reduce how attackers get in, but session controls determine how long they stay effective once inside.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• Why do phishing-resistant MFA controls still fail against social engineering?
• Why does phishing-resistant MFA still need help desk verification controls in Scattered Spider style attacks?
• Why do passkeys still need strong recovery controls even though they are phishing-resistant?