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:

Device possession: The private key is bound to a specific hardware enclave (Secure Enclave, Titan M, TPM).
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:

Signal	What It Tells You	Passkey Awareness
SIM swap event	The SIM module has changed devices	None
Number porting	The phone number has moved to a different carrier	None
Fraud score elevation	The carrier has detected anomalous activity on the subscriber line	None
Call forwarding activation	Calls are being redirected to a different endpoint	None
Device change indicator	The IMEI associated with the subscriber has changed	None

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 ingests carrier signals from Vonage, Twilio, or custom webhooks. When a SIM swap, number port, or fraud indicator is detected, the platform executes a configured response playbook inside the request. Actions can include suspending the account, revoking all active passkeys, invalidating verifiable credentials, and alerting the user through an independent channel.

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). When a carrier signal triggers a revocation cascade, the credential is suspended via StatusList2021. 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, assertion, and parametric revocation. Passkeys are treated as one binding in a multi-layered trust model rather than the trust model itself. When Pillar I detects a compromise, Pillar III's parametric revocation automatically invalidates the affected passkeys and triggers re-enrollment gated by Pillar II credential re-verification.

The three pillars are interdependent. A passkey assertion is valid only when the carrier signal layer confirms that the subscriber's network identity is consistent. A verifiable credential is valid only when the passkey that presented it has not been parametrically revoked. A carrier signal triggers consequences across all three pillars simultaneously.

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 carrier signal exceeds a configured risk threshold, the passkey revocation fires as one step in a multi-action playbook:

Signal received: sim_swap
  risk_score: 0.94
  phone_hash: "a7c3...d91e"

Playbook "High-Risk SIM Swap" executed (47ms):
  ✓ suspend_account       → 200 OK
  ✓ revoke_passkeys       → 2 credentials revoked
  ✓ suspend_vc            → VerifiableId → suspended
  ✓ narrow_agent_scopes   → 3 delegates → read-only
  ✓ email_alert           → sent (independent channel)

The revocation is parametric because it is driven by signal parameters, with no human judgment in the loop. The risk score, the signal type, and the playbook configuration determine the response. 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:

Carrier signal clears: The SIM swap is reversed, the porting event is resolved, or the carrier confirms the subscriber's identity through a separate verification channel.

Verifiable credential re-issuance: The user presents identity evidence through the Pillar II VC issuance pipeline. A new VerifiableId credential is issued, signed with the platform's hybrid PQC signature (ML-DSA-65 + HMAC-SHA-256 on Enterprise plans).

Passkey re-enrollment: With a valid VC in hand, the user registers a new FIDO2 passkey on their current device. The new passkey is bound to the refreshed credential, creating a clean trust chain from biometric to legal identity to network attestation.

Cross-reference re-binding: The Deterministic Cross-Reference engine binds the new passkey credential ID to the new VC subject hash and the current carrier signal hash, restoring the three-pillar trust triangle.

No step in this sequence requires the user to call a support line, answer knowledge-based authentication questions, or wait for manual review. The recovery is self-service, cryptographically verified, and auditable.

The Spatial Binding extension

For organizations that require deeper physical-layer assurance, NF-08 Spatially-Bound Identity Attestation extends the carrier signal model to the device hardware layer. The sensor-capture SDK hashes EMI spectral energy, thermal variance, accelerometer vectors, and network jitter into an Atomic Fingerprint that is bound to the passkey credential.

This creates a fourth verification dimension: even if an attacker obtains a valid SIM, social-engineers a new passkey enrollment, and presents a valid VC, the Atomic Fingerprint from their device will not match the spatial binding on record. The physics of their hardware is different. The binding breaks. The anomaly is detected.

Spatial binding is not required for most deployments. Carrier signals and passkeys cover the majority of threat scenarios. But for high-value targets (trading desks, critical infrastructure operators, government systems), the additional physical-layer entropy closes the remaining gaps.

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 a partial defense, presented as a complete one, is worse than no defense at all, because it 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 for physical-layer assurance. Each layer is independently valuable. Together, they form a trust model that no single-layer solution can replicate.

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