Security · 2026-03-14

Passkeys Need a Carrier Signal Layer

By J. W. Bouckaert

The passkey promise

The FIDO Alliance and its platform partners (Apple, Google, Microsoft) have positioned passkeys as the successor to passwords. The technical foundation is sound: FIDO2 and the W3C WebAuthn Level 3 specification replace shared secrets with asymmetric key pairs, bind private keys to hardware security modules, and gate access behind on-device biometrics (fingerprint, face, iris).

The result is a credential that cannot be phished, cannot be replayed, and cannot be used without biometric proof of presence. Compared to passwords, SMS OTP, and TOTP authenticator apps, passkeys represent a genuine leap in authentication security.

The industry narrative, however, has overshot the evidence. Passkeys are described as the "end of passwords," the "final solution," and the authentication mechanism that "eliminates account takeover." These claims are incomplete.

A passkey proves two things:

1. Device possession: The private key is bound to a specific hardware enclave (Secure Enclave, Titan M, TPM).
2. Biometric presence: The user presented a valid biometric to unlock the key.

A passkey does not prove:

• That the SIM card in the device is the original SIM
• That the phone number associated with the account has not been ported
• That the carrier network path has not changed
• That the device's relationship to the cellular network is consistent with prior sessions

These are the precise attack vectors exploited in SIM-swap fraud, number porting attacks, and carrier-level social engineering. None of these is an edge case. The FCC's 2023 Report and Order on SIM Swapping and Port-Out Fraud and the long-standing NIST SP 800-63B deprecation of SMS as a restricted authenticator both acknowledge the same underlying gap: device-bound authentication does not see what happens to the subscriber identity upstream of the device.

The gap between biometric and network identity

Consider a concrete scenario.

A financial services firm deploys FIDO2 passkeys for all customer-facing authentication. The implementation is textbook: WebAuthn registration with attestation: "direct", resident credentials stored in the platform authenticator, biometric verification required for every assertion. The firm's security team declares password-based account takeover eliminated.

Six weeks later, an attacker social-engineers a carrier retail employee and swaps the SIM for a high-value customer. The attacker inserts the SIM into their own device. They do not attempt to authenticate with the firm's passkey-protected application because they cannot: the passkey is bound to the original device's Secure Enclave.

Instead, the attacker uses the swapped SIM to intercept an SMS-based password reset at a different service, one that still uses SMS as a recovery channel. From that foothold, they pivot laterally to compromise the customer's email, which is the recovery address registered with the financial services firm. They initiate a "lost device" recovery flow, register a new passkey on their own device, and authenticate successfully.

The passkey system worked exactly as designed. Every assertion was cryptographically valid. Every biometric check passed. The account was still compromised.

The failure was not in the passkey. The failure was in the identity model that treated the passkey as sufficient.

Carrier signals passkeys cannot see

Carrier signals, increasingly exposed through standardized programmes like the GSMA Open Gateway and the CAMARA project, operate at a layer of the identity stack that biometrics cannot reach. They observe the relationship between a subscriber identity (SIM), a network (carrier infrastructure), and the physical/logical path between them.

When PasskeyBridge's Pillar I signal ingest receives a carrier event, it captures information that no biometric system produces:

Each of these signals represents a change in the subscriber's network identity that is invisible to the passkey. The passkey's security model begins and ends at the device boundary. Everything upstream of the device, the SIM, the carrier relationship, the network path, is outside its scope.

This is not a criticism of the FIDO2 specification. The specification explicitly scopes itself to device-bound authentication. The problem is the industry narrative that treats device-bound authentication as the complete solution.

The three-pillar correction

PasskeyBridge's architecture exists because biometric binding (Pillar III) is one-third of the trust equation, not the whole of it.

Pillar I: Network Attestation takes carrier signals from a SIM swap check through your own Vonage application, from answers you record after querying any provider yourself, Twilio included, or from signals your systems post to the ingest endpoint. When a SIM swap, number port, or fraud indicator arrives, the platform executes a configured response playbook inside the request. Actions can include invalidating the organization's cached passkey proofs, suspending its agent delegates, revoking their agent-to-agent sessions, and alerting your team; each acts on the whole organization rather than on the affected user, and none disables a registered passkey or a verifiable credential.

Pillar II: Legal Identity issues and verifies W3C Verifiable Credentials using PasskeyBridge's native VC engine. A VerifiableId credential binds the subscriber's verified identity to a DID (Decentralized Identifier). A carrier signal does not suspend the credential today: neither the revocation it triggers nor any playbook action touches verifiable credentials. Recovery requires re-verification through the VC issuance pipeline, not just re-enrollment of a new passkey.

Pillar III: Biometric Binding manages FIDO2/WebAuthn passkey registration and assertion, as a hosted relying party on the Enterprise plan. Passkeys are treated as one binding in a multi-layered trust model rather than the trust model itself. When Pillar I detects a compromise, parametric revocation deactivates the organization's agent delegates and leaves passkeys alone; a playbook's freeze_credentials action is what invalidates cached passkey proofs, and it does so for every user in the organization rather than only the affected one.

The pillars are independent checks that a relying party combines. A passkey assertion is verified on its own; PasskeyBridge does not consult a carrier signal before accepting one, and a carrier signal does not suspend a credential. What a carrier signal changes automatically is the organization's agent delegations and A2A negotiations; anything further, such as invalidating cached passkey proofs, is an action its playbook runs.

Parametric revocation: The mechanism

Traditional passkey revocation is manual. An administrator identifies a compromised credential, locates it in the WebAuthn credential store, and deletes it. The user re-enrolls on their next visit. The time between compromise and revocation is measured in hours or days.

Parametric revocation is automatic. When a hard signal such as a SIM swap arrives with the phone number or its digest, the organization's agent delegates are deactivated and its live A2A negotiations revoked before the playbook runs, and the playbook's actions then fire in parallel. Playbooks match on the signal type, and the risk score is recorded without triggering anything:

Signal received: sim_swap
  risk_score: 0.94          (recorded, triggers nothing)
  phone_hash: "a7c3...d91e"

Before the playbook (every hard signal):
  ✓ parametric_revocation → active agent delegates deactivated,
                            A2A negotiations revoked (organization-wide)

Playbook "High-Risk SIM Swap" executed (actions in parallel):
  ✓ freeze_credentials    → cached passkey proofs invalidated (organization-wide)
  ✓ suspend_agents        → delegate scopes cleared (organization-wide)
  ✓ email_alert           → sent to the recipients listed in the action

The revocation is parametric because it is driven by signal parameters, with no human judgment in the loop. The signal type and the playbook configuration determine the response; the risk score does not. No human is in the loop between detection and revocation.

This is the difference between a passkey system and a passkey system integrated into a carrier-signal-aware identity platform. The passkey alone is inert in the face of a SIM swap. The passkey within PasskeyBridge's three-pillar model is one of several trust bindings that respond as a coordinated system.

The recovery path

Revocation without recovery is a denial-of-service attack on your own users. PasskeyBridge's recovery architecture ensures that legitimate users can restore access after a compromise event without exposing the platform to re-compromise.

The recovery sequence after a carrier-signal-triggered revocation:

1. The event is resolved: the tenant establishes that the SIM swap or port was legitimate or has been reversed. PasskeyBridge receives no 'cleared' signal from carriers, so this step is the tenant's decision.

1. Verifiable credential re-issuance: The user presents identity evidence through the Pillar II VC issuance pipeline. A new VerifiableId credential is issued as an ES256 or ES384 JWS with a detached ML-DSA proof.

1. Passkey re-enrollment: with a valid VC in hand, the user registers a new FIDO2 passkey on their current device.

1. Cross-reference re-binding: on the Enterprise plan, the tenant creates a fresh deterministic cross-reference that binds the current carrier signal digest, the new VC subject digest and the new passkey.

The first and last steps are the tenant's to run, and the middle two are the user's. Neither of the user's steps needs a support call or knowledge-based questions.

The Spatial Binding extension

For organizations that require deeper physical-layer assurance, NF-08 Spatially-Bound Identity Attestation adds a device check on the Enterprise plan. PasskeyBridge's browser capture module hashes network jitter, accelerometer and magnetometer readings, environmental thermal signals and a device identifier on the device, and the server compares those digests with the baseline the user enrolled. A binding can name the passkey credential it belongs to.

This adds a fourth check: if an attacker obtains a valid SIM, social-engineers a new passkey enrollment and presents a valid VC, a capture from their device still carries a different device digest from the enrolled baseline, which is enough on its own to return anomaly_detected. The relying party decides when to request a capture and what to do with the result.

Spatial binding is not required for most deployments. Carrier signals and passkeys cover most threat scenarios. It is meant for high-value uses such as trading desks, critical infrastructure operators and government systems.

Credit where due

This article is not an argument against passkeys. FIDO2/WebAuthn is the most significant improvement in authentication technology in two decades. The elimination of shared secrets, the phishing resistance, the biometric binding to hardware enclaves: these are genuine, meaningful advances.

The argument is against the narrative that passkeys are sufficient. They are necessary. They are not complete.

A passkey without carrier-signal awareness is a lock on a door with no alarm system. It prevents unauthorized entry at the point of authentication. It says nothing about whether the building's phone lines have been rerouted, whether the security cameras are feeding live or replayed footage, or whether the identity of the person standing at the door has been compromised upstream.

PasskeyBridge treats the passkey as Pillar III: the biometric binding layer. It earns that designation because it is excellent at what it does. But Pillar III without Pillar I is a partial defense, and presenting it as complete creates a false sense of security.

Building the complete trust model

The identity industry will converge on multi-layer trust architectures. The question is whether organizations build that architecture proactively or reactively, after a SIM-swap-driven breach bypasses their passkey deployment.

PasskeyBridge provides the architecture today: carrier signals for network attestation, verifiable credentials for legal identity, passkeys for biometric binding, and optional spatial binding as a device check. Each layer is independently valuable, and a relying party combines them.

The passkey is one pillar of three.

Explore the Three-Pillar Architecture → | MFA Alternative Deep Dive → | Read the SIM-Swap Response Deep Dive → | Start building →

Start free · Test the API