RC RANDOM CHAOS

SMS 2FA was never authentication

Microsoft is replacing SMS one-time codes with passkeys. M. Hale defines what failed, why it failed, and where the boundary still leaks.

· 8 min read
SMS 2FA was never authentication

Opening position

Microsoft is moving authentication away from SMS one-time codes and toward passkeys. That is the stated change. It is not a feature update. It is a boundary redefinition. The control surface for account access is being moved off the mobile carrier network and onto device-bound cryptographic credentials.

The headline framing treats this as a user convenience shift. It is not. It is an admission that the prior factor was structurally weak. SMS as a second factor was never a cryptographic boundary. It was a delivery channel sitting on infrastructure Microsoft does not control, validated by a possession signal Microsoft cannot verify. Replacing it with passkeys changes what an attacker must compromise to authenticate as the user.

The operator read is direct. If SMS were effective, it would not be retired. The decision itself is the disclosure. Treat the announcement as confirmation that the existing factor failed to enforce the boundary it was deployed to enforce.

What actually failed

SMS-based one-time codes deliver a shared secret over a channel the authenticating party does not own. The code is generated by the service, transmitted through carrier infrastructure, and accepted on return as proof of possession of a phone number. Possession of the number is treated as possession of the user. That equivalence is the failure point.

The observable behaviour is that the code can be received by any party in control of the number at the moment of delivery. Number control is not bound to the device, the SIM hardware, or the user identity in any cryptographic sense. It is bound to a carrier record. A carrier record is a mutable entry in a third-party system. Mutable entries are not authentication boundaries.

The code itself is also a bearer token with no binding to the requesting session, the requesting device, or the requesting origin. Once read, it can be entered anywhere. The factor does not verify who is entering it or where. It verifies that someone entered the correct string within the validity window. That is not identity assurance. That is a string match.

Why it failed

The factor failed because possession was defined at the wrong layer. Authentication requires a boundary the relying party can enforce. The carrier-controlled phone number is not such a boundary. Microsoft, as the relying party, cannot validate the integrity of the channel, the state of the SIM, or the identity of the recipient. It can only validate that the code returned matches the code issued.

The factor also failed because the credential was reusable within its window and transmissible by the user. Any factor a user can read and retype is a factor an attacker can solicit and retype. The control assumed the user would only enter the code into the legitimate prompt. That assumption is not enforced by the system. It is requested of the user. Requested behaviour is not a control.

Passkeys change the enforcement model. The credential is a private key held on the device, released only after a local user verification step, and bound to the origin of the requesting site. The relying party does not receive a secret it must trust the user to handle correctly. It receives a signed assertion tied to the origin and the device. The user cannot retype it. The user cannot forward it. The user cannot be socially engineered into reading it aloud, because there is nothing to read.

Microsoft is removing SMS codes as an authentication option and directing users toward passkeys. That is the stated action. Timeline specifics beyond the announcement are not confirmed in this brief. Scope of accounts affected beyond consumer Microsoft accounts is not confirmed in this brief. Treat both as conditions to verify against Microsoft’s published guidance before operational planning.

What is confirmed is the direction. The default authentication path for the affected accounts will require a device-bound credential with origin binding and local user verification. The trust relationship shifts from carrier plus user discipline to device plus cryptographic protocol. The attacker workload shifts from acquiring a phone number or intercepting a message to compromising a specific device or its unlock factor.

This is a meaningful reduction in remote attack surface. It is not a removal of risk. Device loss, device compromise, and account recovery flows become the new pressure points. Recovery is where most passkey deployments retain weaker fallback factors. If the recovery path still accepts SMS, email links, or knowledge-based answers, the boundary has been moved, not raised. The control is only as strong as the weakest accepted path to the same account. Verify the recovery path before treating the migration as complete.

The mechanism is that the relying party cannot enforce a control it does not own. SMS delivery depends on carrier infrastructure. The carrier defines who holds the number, when the number transfers, and which device receives messages bound to it. Microsoft, as the relying party, has no enforcement point inside that chain. It can only consume the result the carrier returns. When the enforcement point sits outside the trust boundary, the control degrades to the weakest process in the external system. For phone numbers, that process is the port-out procedure and the SIM provisioning workflow held by the carrier. Specific carrier failure modes are not confirmed in the scope of this brief. The structural mechanism is general: a control surface outsourced is a control surface conceded.

The drift continues at the credential layer. A factor that is human-readable is human-transmissible. Once the user can read the value, the user can deliver the value to any party that asks convincingly. The system has no way to distinguish the legitimate prompt from the fraudulent prompt at the point of entry. The relying party observes a correct string within the validity window. It does not observe the origin of the request that produced the string. That gap is not a configuration defect. It is the design.

The deeper drift is the substitution of user judgement for system enforcement. The control was deployed with the implicit assumption that the user would only enter the code into the intended prompt. The system never verified that assumption. It accepted any correct string from any source. Delegation to user judgement is not enforcement. It is a request. Requested behaviour under adversarial pressure does not hold. That is the mechanism. SMS did not fail because of a bug. It failed because the boundary was defined where the relying party could not enforce it.

The same mechanism appears wherever authentication depends on a channel the relying party does not control. Email-based password reset is the most common instance. The reset link is delivered through an email provider the relying party did not vet, to an inbox protected by credentials the relying party did not issue. If the email account is compromised, every downstream account using email reset is compromised at the same moment. The application is not the boundary. The email provider is the boundary. Most relying parties do not treat it that way in their threat model.

Knowledge-based authentication exhibits the same pattern at a different layer. Security questions assume the answer is private to the user. Public records, social media exposure, and historical breach data have made most such answers externally available. The relying party validates a string it cannot confirm originated from the user. The factor became a public secret without the relying party observing the change. Control effectiveness degraded silently because the inputs degraded silently. The system continued to report success while the boundary no longer existed.

Magic links sent over email or SMS inherit both failure modes. They combine a channel the relying party does not own with a bearer token that has no origin binding. The link can be opened by any party in control of the channel, from any device, against any session. The convenience framing masks the structural weakness. Convenience that bypasses the boundary is not convenience. It is a vulnerability with a friendlier label. Any authentication mechanism that sends a string for the user to present back exhibits the same failure surface as SMS, scaled by the integrity of the channel it uses.

Controls that depend on systems outside the relying party are not controls. They are dependencies. A dependency can be modified by the party that owns it, without notice and without the relying party’s consent. Authentication built on dependency fails when the dependency fails. SMS authentication is being retired because the dependency on carrier-controlled identifiers no longer holds under adversarial pressure at scale. The retirement is the disclosure. The mechanism was always weak. The decision confirms it.

The move to passkeys relocates the boundary from the carrier to the device, and from a shared secret to a signed assertion bound to the origin. That is a stronger enforcement position. It is not a finished position. The recovery path remains the surface where the boundary can be reopened to a weaker factor. If recovery accepts SMS, email links, or knowledge-based answers, the boundary has been moved, not raised. The control is bounded by the weakest accepted path to the same account. That is true for Microsoft. It is true for every relying party currently planning the same migration.

Identity is the boundary. The boundary must be enforced by the system that owns the asset, against a credential the system can cryptographically verify, in a context the system can observe. Anything else is a request for the user to behave correctly under attacker pressure. That request has failed across every system that relied on it. The factor being retired today was retired because it failed. The factors still standing on the same mechanism will fail for the same reasons. Treat the announcement as a deadline for the rest of the stack.

Share

Keep Reading

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.