Passkeys, MFA Fatigue and Session Theft: Protecting the Whole Sign-In Journey

01 / Field notes

Executive Summary

A passkey can make a fake login page much less useful to an attacker, but it does not make every later action in the account trustworthy. Once a service issues a session, the browser carries evidence that authentication already happened. If an attacker obtains usable session material, the service may see an authenticated request without asking for the original password or second factor again.

That is not a reason to abandon MFA. It is a reason to protect the complete journey: enrollment, sign-in, session lifetime, sensitive actions, recovery and revocation. A strong front door still matters when you also need to control the keys issued after entry. For everyday readers, the priority is a supported passkey or security key where available, a clean updated device, carefully reviewed recovery settings and prompt reporting of unexpected account activity.

MFA fatigue usually refers to repeated approval requests intended to make a person accept one they did not initiate. Time-based one-time codes avoid that particular approval flood but remain codes a user can disclose or enter into a deceptive flow. Passkeys use public-key authentication associated with the relying party, which changes the phishing problem substantially. Session controls address a different phase. [1][2]

The practical question for a defender is therefore specific: which credential or permission is being abused, at which point in the flow? A stolen password, an approved device authorization, a malicious OAuth grant and a copied session cookie can all lead to account access, but they need different investigations and fixes.

This guide provides a defensive review and a proposed test plan for an application you own. It does not include cookie-stealing code or instructions for taking over another person's session. The goal is to verify that authentication state has a bounded lifetime, that risky operations demand fresh evidence and that revocation actually ends access.

02 / Field notes

Prerequisites / Lab Setup

Use a staging application with two disposable accounts and a separate administrator account. Prepare two browser profiles so you can distinguish sessions clearly. Keep account data synthetic and use the application's own session-management interface rather than extracting credentials from a real person's browser.

Record the authentication methods supported by the service, how session identifiers are stored, the idle and absolute timeout values, and the events that invalidate sessions. Include password changes, MFA enrollment, recovery-code use, account suspension and role changes. If the application uses an identity provider, identify which state belongs to the provider and which belongs to the application.

Write the expected behavior before the test. For example, “after an administrator suspends the test user, its existing application session must be rejected on the next authenticated request.” That is a useful assertion. “The login page looks secure” is not.

Avoid weakening a production timeout simply to make a test faster. Staging fixtures should make timing controllable without changing the live security policy. If a third-party provider limits what can be simulated, record that limit explicitly and test the integration's observable behavior instead of claiming coverage you do not have.

03 / Field notes

Technical Analysis

What does a passkey protect?

FIDO describes passkeys as phishing-resistant because authentication is bound to the legitimate relying party rather than to a reusable secret typed into any page. That makes a lookalike domain a different problem from a password form. The security benefit is substantial, but it applies to the authentication mechanism, not to every component on the device or every recovery route. [1]

Enrollment deserves the same attention as sign-in. If an attacker can add a new authenticator using an already compromised session, a strong authenticator may become a persistence mechanism for the wrong person. Require appropriate fresh authentication, notify the account owner and provide a clear list of registered methods with removal controls.

Also review fallback. An account advertised as passkey-protected may still allow a weaker recovery flow. That can be a practical necessity, but it should be an explicit decision with protections against impersonation and social engineering. Usable recovery and strong authentication must be designed together; treating recovery as an afterthought often creates the easiest route into the account.

How do common methods compare?

NIST's digital-identity guidance distinguishes phishing resistance and authenticator properties rather than treating every second factor as equivalent. Use those distinctions when selecting a method for an organization's risk level. Avoid assuming that a six-digit screen, a biometric gesture or a vendor's “passwordless” label tells the whole story. [2]

What does session theft change?

Many web applications use bearer-style session credentials: possession is enough to present the session to the server. That is convenient for normal requests, but a copied credential may remain useful until it expires or is revoked. The attacker is targeting already-issued authorization rather than repeating the original sign-in ceremony.

Cookie attributes reduce particular risks. Secure restricts transmission to secure transport, HttpOnly prevents ordinary page JavaScript from reading the cookie, and SameSite influences cross-site request behavior. None is a complete defense against a compromised browser or endpoint. An XSS bug can also perform actions through the user's browser even when it cannot read an HttpOnly cookie. [3]

Treat session state as a capability with a lifecycle. Generate unpredictable identifiers, rotate them after authentication and privilege changes, and reject expired state on the server. Keep sensitive data out of the identifier itself. Review where sessions are cached and how quickly invalidation reaches every application node.

What did a documented phishing campaign show?

Microsoft's Storm-2372 report describes device-code phishing: victims were induced to complete a legitimate authorization flow that gave the attacker useful access. The report has been updated as Microsoft's attribution assessment evolved. The defensive point here is the flow, not a claim that the user typed a password into an obviously fake page. [4]

A familiar domain can host a legitimate authorization screen while the overall request is still unwanted. Teach users to ask what device or application they are authorizing and whether they initiated the action. Administrators should restrict unused authentication flows where their platform supports it and investigate unexpected application grants alongside sign-in events.

This is why a single “MFA passed” field is insufficient for incident review. Preserve context such as the authentication method, application, device posture, grant type and subsequent actions. An accepted second factor does not automatically establish that the resulting authorization matched the user's intent.

Which actions should require fresh authentication?

Start with operations that can turn temporary access into durable control: adding an authenticator, changing recovery details, creating API tokens, granting external applications access, exporting sensitive data and elevating another user's role. The exact list depends on the product, but the principle is consistent: risk should influence how recent and strong the authentication evidence must be.

Fresh authentication should be bound to the operation and have a short useful lifetime. A generic “recently verified” flag that lasts for hours can become a broad bypass. Show the user the actual change, and invalidate the approval if its important parameters change. Notify through an independent established channel when recovery or authentication settings change.

Do not turn every harmless click into a challenge. Excessive friction encourages workarounds and makes meaningful prompts harder to recognize. Group low-risk activity sensibly, explain consequential prompts and make cancellation safe. Security review should include usability tests with people who do not know the application's internal terminology.

How can session revocation be tested?

Create two sessions for a test user. Revoke one through the product's session list and verify that the other remains usable if that is the documented behavior. Then use an account-wide security event, such as suspension, and verify that both are rejected. Repeat through every relevant application entry point, including APIs and background requests.

For a server-side implementation, a session-version field can support account-wide invalidation. The application compares the version stored at authentication with the current account version. Incrementing the account value makes older sessions fail their next check. This is an illustrative design pattern, not a substitute for checking all token types and caches in your architecture.

Authenticate request
Load current account status and session version
Reject disabled account or mismatched version
Check idle expiry and absolute expiry
Authorize the requested operation
Record a safe audit event for consequential changes

Test recovery codes as independent credentials. They should be generated unpredictably, stored as one-way hashes and consumed atomically so concurrent requests cannot reuse the same code. Replacing the recovery-code set should invalidate the previous set. Never include usable recovery codes in ordinary application logs or analytics.

What can device-bound sessions add?

Google's DBSC work describes binding session renewal to possession of a key associated with the device, reducing the usefulness of copied cookies elsewhere. Availability depends on the browser, operating system and participating service; verify the current supported configuration rather than assuming every website benefits automatically. [5]

Device binding is one layer. It does not remove the need for endpoint protection, application authorization or incident response. If malicious activity runs inside an already authorized device, the threat differs from replaying a cookie on a separate machine. Ask vendors which attack paths their feature addresses and what remains outside its scope.

04 / Field notes

Mitigation / Defense

For an individual, begin with the accounts that can reset other accounts: primary email, password manager, cloud identity and mobile-provider access. Use passkeys or security keys where supported, keep a separate recovery option securely stored and remove authenticators or sessions you no longer recognize. Do not approve a prompt simply to make repeated notifications stop.

Keep the browser and operating system updated, limit extensions to those you need and avoid running unknown software on a device used for sensitive accounts. If a session may have been stolen, change credentials from a trusted device and use the service's account-wide sign-out or revocation controls. A password change alone may not invalidate every existing token.

For application owners, prioritize evidence that the whole lifecycle works:

During an incident, preserve a timeline of grants and actions before resetting everything indiscriminately. Determine whether the attacker still has a recovery method, application grant or API token after the visible browser session ends. Recovery is complete when the unwanted access paths have been removed and the legitimate owner has a safe way back in—not simply when a password has changed.

05 / Field notes

References

Drafted with AI assistance; no independent credential verification is claimed. Sources checked in October 2026. The method comparison, staging checks and session-version walkthrough are original defensive analysis. No session theft experiment or compromise of a live account is claimed.

1. Passkeys and Phishing Prevention, Part 3 ↗FIDO Alliance · accessed 2026-10-21
2. Digital Identity Guidelines: Authentication and Authenticator Management ↗NIST · accessed 2026-10-21
3. Session Management Cheat Sheet ↗OWASP · accessed 2026-10-21
4. Storm-2372 Device Code Phishing Campaign ↗Microsoft · accessed 2026-10-21
5. Protecting Cookies with Device Bound Session Credentials ↗Google · accessed 2026-10-21

Questions readers ask