Passkeys authenticate the moment, not the session

1. Opening Claim

MFA, passkeys, and trusted IP enforcement do not stop the attack class they are most often sold against. Each control authenticates a moment. Each control assumes that moment is the boundary worth defending. In the category of attacks under discussion, the moment is not the boundary. The control fires, succeeds, and is irrelevant to what happens next.

This is not a failure of cryptography. Passkeys do what they were designed to do. MFA challenges resolve correctly. Trusted IP allow-lists evaluate as intended. The position is narrower and more uncomfortable: the controls operate at the wrong layer for the threat. Authentication strength is being asked to carry weight it was never engineered to carry.

The operator-level claim is this. If your detection and response strategy assumes that strong authentication closes the door, you are defending the door while the attacker is already inside the building. The control set named in this topic enforces who logs in. It does not enforce what the resulting session is permitted to do, where it travels, or who later inherits it. Specific attack mechanisms beyond that mechanism are not confirmed here, and will be treated as not confirmed throughout.

2. The Original Assumption

The deployment logic behind MFA is straightforward. A password can be stolen. A second factor raises the cost of unauthorised login. Organisations adopted MFA on the assumption that compromise begins at the login prompt and that proving possession of a second factor terminates the attack path. That assumption holds for password reuse and basic credential stuffing. It does not extend further on its own merit.

Passkeys were positioned as the structural fix. Phishing-resistant by binding, scoped to origin, no shared secret to capture. The assumption layered on top of that design is broader than the design itself. Organisations began treating passkey enrolment as evidence that the identity boundary was sealed. The cryptographic property is real. The boundary claim is an extrapolation from it.

Trusted IP enforcement carries the oldest assumption in the stack. If the request originates from a known network, the requester is trusted. This treats network location as a proxy for identity and intent. It assumes the network perimeter still exists as a meaningful control surface, and that an authenticated session inside that perimeter behaves the way the original authenticated user would behave. Both halves of that assumption require continuous validation that trusted IP, as a control, does not perform.

3. What Changed

The attack surface moved past the login event. Once a session is established under MFA, under a passkey, from a trusted IP, the resulting credential material is a session, a token, or a grant. That material is what gets operated against. The login control set does not re-evaluate the session after issuance. If the session is acquired, replayed, or inherited by a process the user did not authorise, the original authentication strength contributes nothing to detection or prevention. The specific acquisition path in any given case is not confirmed unless stated.

What this reframes is the location of the boundary. The boundary is not the login prompt. The boundary is wherever the session is presented, accepted, and acted upon. Every system downstream of authentication is making a trust decision based on a token whose holder it cannot independently verify. MFA does not travel with the session. Passkey binding does not travel with the session. Trusted IP only travels with the session for as long as the request originates from the same network, which is a condition the attacker can satisfy by operating from inside it or by routing through a host that already does.

The operational consequence is that the controls in scope here are login controls, not session controls, not authorisation controls, not behavioural controls. They were deployed against a threat model where compromise equals unauthorised login. The threat model in this category is different. Compromise here does not require defeating authentication. It requires operating after authentication has already succeeded, against the artefacts authentication produces. The control set named in this topic does not address that layer. Whether any given environment has compensating controls at that layer is not confirmed and must be established per system, not assumed.

4. Mechanism of Failure or Drift

The mechanism is straightforward and structural. Authentication produces an artefact. That artefact, a session cookie, a bearer token, an issued grant, is presented to downstream systems as proof. Downstream systems do not validate identity. They validate the artefact. The control set in scope authenticates the issuance of that artefact. It does not authenticate any subsequent presentation of it. The drift is from a control that gated a login to an assumption that the control extends across every request the resulting session makes. That extension is not performed by MFA. It is not performed by passkey binding. It is not performed by trusted IP enforcement as configured at the authentication layer.

The architectural reason this drift exists is cost. Re-challenging MFA on every request, re-signing every action with a passkey, re-evaluating IP origin on every API call, was deemed operationally unacceptable in the systems that deployed these controls. The decision is real and visible across standard SSO, OIDC, and SAML deployments. The result is a single strong evaluation at issuance, followed by a long-lived artefact whose trust is no longer being re-derived from the original authentication. The control did its job at the moment it was asked to act. The system stopped asking after that moment.

The failure surfaces wherever the artefact is presented by a holder the system cannot independently distinguish from the original user. The downstream consumer is not equipped to challenge the bearer. It accepts the token because the token is valid. Validity, at that layer, is a property of the artefact, not the holder. The MFA challenge that produced the token is not replayed. The passkey signature that authorised issuance is not re-verified at consumption. The trusted IP check that gated authentication does not gate use unless explicitly re-applied at the request layer, and whether such re-application exists in any given environment is not confirmed. Where it is absent, the controls in scope contribute nothing to the decision the downstream system is making.

5. Expansion into Parallel Pattern

The same mechanism appears wherever a control converts an authentication event into a portable artefact. OAuth refresh tokens follow the pattern directly. Issuance is gated by a strong flow. The refresh token, once issued, is a bearer credential. The system that accepts a refresh token to mint a new access token is not re-running the original authentication. It is validating the artefact. The strength of the original flow does not transfer to the holder of the refresh token at time of use. The control evaluates a moment. The artefact outlives the moment.

Kerberos ticket-granting tickets exhibit the same property. Cloud STS tokens, signed assertions, long-lived API keys, application-issued session identifiers, all share the structure. Strong evaluation at issuance, bearer semantics afterwards. The control authenticates the request that produced the credential. The credential is then accepted by consumers that have no mechanism to re-derive the original authentication. The trust boundary is the issuance, not the presentation. Any system that treats presentation as equivalent to authentication is making a claim the control did not make.

The pattern is structural, not incidental. Any control that produces a portable credential assumes the credential will remain with the holder. That assumption is not enforced by the control. Enforcement, if it exists, lives at a different layer: session binding to device posture, token binding to TLS channels, continuous evaluation against behavioural signals, scope reduction at consumption. Whether any such layer is present and operating in a given environment is not confirmed and must be established per system. The controls named in this topic do not perform that enforcement. Treating them as if they do is the drift the pattern produces.

6. Hard Closing Truth

Login controls are login controls. MFA enforces who is permitted to authenticate. Passkeys enforce that authentication occurs against the correct origin with the correct key material. Trusted IP enforces that authentication originates from a permitted network. None of the three extends past issuance on its own merit. Treating them as session controls, as authorisation controls, or as behavioural controls is a category error. The category error is the exposure. The control set is not failing. It is being asked to defend a layer it does not operate on.

The defensive question is not whether MFA is enabled. The defensive question is what re-authenticates between session issuance and any privileged action the session is permitted to perform. If nothing does, the authentication strength at the front door is a single evaluation in a system that does not consume it again. If something does, that something is the actual control protecting the layer the topic describes, and its presence, scope, and effectiveness must be established explicitly, not inferred from the strength of the login flow upstream of it.

Controls that are not enforced past their issuance moment are not session controls. Identity is the boundary, and identity must be re-validated wherever a session crosses a trust edge. If the architecture does not perform that re-validation, the control set named in this topic does not compensate for its absence. The operator position is that MFA, passkeys, and trusted IP must be deployed for what they are, and the layer they do not protect must be addressed by controls designed for that layer. Anything else is a deployment claim the controls themselves were never built to support.