PasskeyBridge

NTN · 2026-03-31

Starlink Direct-to-Cell and Identity: Satellite-Terrestrial Handoff and SIM Attestation

By J. W. Bouckaert

Starlink Direct-to-Cell and Identity: Satellite-Terrestrial Handoff and SIM Attestation

The phone doesn't know it left the ground

When a T-Mobile subscriber steps outside terrestrial tower coverage and their device connects to a Starlink Direct-to-Cell satellite, something architecturally significant happens: nothing—from the phone's perspective. The device sees what appears to be a standard LTE cell. The SIM authenticates normally. The IMSI attaches. SMS and MMS flow. The subscriber has no indication that their signal path now includes a 550 km orbital hop to a satellite traveling at 7.6 km/s, a downlink to a Starlink ground station, and a backhaul connection into T-Mobile's terrestrial core network.

This transparency is an engineering triumph. It is also an identity-layer problem that the carrier-signal verification ecosystem has not yet solved.

The Direct-to-Cell service, commercially launched as T-Satellite in July 2025 following FCC approval in November 2024, operates on SpaceX's V2 Mini satellites. These satellites carry eNodeB-equivalent payloads—functionally, each satellite is a cell tower in low Earth orbit. The phone's baseband processor handles the connection identically to a terrestrial macro cell. The SIM, the SUPI, the GUTI—all the identity primitives that carrier-signal verification depends on—function as designed.

But the infrastructure behind those primitives has fundamentally changed. And identity systems that rely on assumptions about that infrastructure are now operating on stale models.

The signal path

Terrestrial carrier-signal verification follows a well-understood path:

Device → Cell Tower → RAN Backhaul → Core Network → Carrier API Gateway → Identity Platform

Every node in this chain is geographically fixed, jurisdictionally known, and latency-predictable. When Vonage Number Insight or Twilio Lookup returns a SIM-swap status check, the response reflects a query against a carrier database that was updated by infrastructure in the same regulatory jurisdiction as the subscriber.

Starlink Direct-to-Cell introduces a different path:

Device → LEO Satellite (550 km) → Inter-Satellite Laser Link → Ground Station → T-Mobile Core → Carrier API Gateway → Identity Platform

This path introduces three variables that terrestrial-only identity models do not account for:

1. Orbital transit latency. The round trip from device to satellite and back adds 5–15 ms of propagation delay, depending on elevation angle. This is well within tolerance for most identity flows. But the variance matters more than the magnitude. Terrestrial cell handoffs introduce sub-millisecond latency changes. Satellite handoffs—which occur every 5 to 10 minutes as the serving satellite moves out of view—introduce 2–8 ms latency spikes during the handover window. Identity systems that interpret latency spikes as anomalous behavior may generate false-positive threat signals during routine orbital handoffs.

2. Ground station jurisdiction. When a device connects via a Starlink satellite, the signal is downlinked to the nearest ground station with available capacity. That ground station may not be in the same country, state, or regulatory jurisdiction as the subscriber. A T-Mobile subscriber in Montana could have their signal path traverse a ground station in Alberta. A subscriber in the Florida Keys could route through a ground station in the Bahamas. The GSMA Open Gateway SIM Swap API does not currently expose the ground-station jurisdiction in its response payload—meaning the identity platform receiving the SIM-status response has no visibility into where the signal was physically processed.

3. Non-deterministic cell identity. In a terrestrial network, Cell Global Identity (CGI) values are stable and geographically anchored. A given cell ID maps to a known tower at a known location. In Starlink's D2C network, the "cell" is a moving satellite. The CGI equivalent changes as the orbital footprint shifts. Identity systems that use cell-tower location as a fraud signal—flagging an authentication attempt as suspicious because the device appears to have moved 200 km in 30 seconds—will generate false positives for satellite-connected subscribers whose serving satellite has simply moved overhead.

SIM-swap detection in a hybrid network

SIM-swap detection is the carrier-signal primitive that identity platforms depend on most heavily. The detection mechanism is straightforward: carrier APIs expose the timestamp of the most recent SIM change event for a given MSISDN. If the SIM was swapped within a configurable window (typically 24–72 hours), the identity platform treats the authentication attempt as elevated risk. The GSMA's CAMARA project has standardized these APIs across 86 operator groups representing over 300 networks globally.

This mechanism works because, in terrestrial networks, the SIM-change event and the carrier API query traverse the same infrastructure. The carrier's Home Subscriber Server (HSS) or Unified Data Management (UDM) function is updated in real time when a SIM is provisioned, and the API gateway queries that same database.

In a hybrid satellite-terrestrial network, three edge cases emerge:

ScenarioTerrestrial BehaviorSatellite D2C BehaviorIdentity Impact
SIM swap while on satelliteHSS updated instantly via coreSame—satellite is backhaul onlyMinimal: detection works normally
Handoff from tower to satellite mid-sessionSession continuity preservedSession may re-attach with new temporary identity (GUTI reallocation)GUTI change may trigger false anomaly in session-continuity monitors
Carrier API query during satellite handoverSub-5 ms response15–40 ms response with possible timeout during handoff windowTimeout may be interpreted as carrier-side block or network error
Device location check post-swapCGI maps to known towerCGI maps to moving satellite footprintLocation-based fraud scoring returns undefined or misleading results
Ground station jurisdiction mismatchAPI processed domesticallyAPI processed via foreign ground station pathRegulatory compliance assumption violated—data may traverse non-domestic infrastructure

SIM-swap detection itself does not fail. The core issue is that the confidence metadata surrounding the detection—latency, location, session continuity—degrades in ways that identity platforms are not currently designed to interpret.

Jurisdiction

The jurisdictional implications of satellite-terrestrial handoff deserve dedicated analysis, because they affect regulatory compliance as well as signal routing.

Consider a European subscriber whose MNO has deployed a Starlink D2C integration (several European operators are in active trials as of 2026). When that subscriber is connected via satellite, their signal may be downlinked through a ground station outside the European Economic Area. Under GDPR Article 44, the transfer of personal data to a third country requires an adequacy decision, standard contractual clauses, or another safeguard.

The MSISDN itself is personal data. The SIM-swap status is personal data. The device location derived from the satellite footprint is personal data. If any of this data is processed through a ground station in a jurisdiction without an adequacy decision, the identity platform's compliance posture may be unknowingly violated—not by the platform's own infrastructure, but by the signal path it cannot control.

Jurisdiction QuestionTerrestrial AnswerSatellite D2C Answer
Where is the subscriber's signal processed?Known tower location in subscriber's countryGround station location is non-deterministic and may be cross-border
Which data protection regime governs the carrier API response?Subscriber's home jurisdictionUnclear—depends on ground station and inter-satellite routing
Can the identity platform guarantee data residency?Yes, if carrier API is domesticNo, unless ground-station routing is contractually constrained
Does the signal path cross a sanctioned jurisdiction?Verifiable via known infrastructureNot currently exposed in carrier API metadata

This is a compliance gap that will surface in audit findings the moment satellite-connected subscribers represent a non-trivial percentage of carrier API queries.

Latency variance as a threat signal

Identity platforms that implement behavioral risk scoring use carrier API response latency as one input to their anomaly-detection models. A carrier API response that arrives in 200 ms when the baseline is 15 ms may indicate a man-in-the-middle interception, a carrier-side processing anomaly, or a network under attack.

Satellite-connected subscribers introduce a new baseline. The expected latency for a carrier API query routed through Starlink D2C includes:

Path SegmentLatency ContributionVariance
Device → LEO satellite (uplink)3–7 ms±2 ms depending on elevation angle
Inter-satellite laser link (if applicable)0–10 msDepends on number of hops between satellites
Satellite → ground station (downlink)3–7 ms±2 ms
Ground station → T-Mobile core5–15 msDepends on ground station proximity to core
T-Mobile core → carrier API gateway1–3 msStable
Total additional latency12–42 ms±8 ms variance

The variance is the problem, not the magnitude. A consistent 30 ms addition is trivially accommodated by adjusting the baseline. An 8 ms variance window that overlaps with the existing terrestrial variance creates a noise floor that reduces the signal-to-noise ratio of latency-based anomaly detection.

For identity platforms processing millions of carrier API queries per day, even a 2% satellite-connected subscriber base introduces enough latency noise to increase false-positive rates in behavioral scoring models by an estimated 5–12%, based on the variance overlap with terrestrial anomaly thresholds.

Required adaptations

The identity-layer adaptations required for satellite-terrestrial hybrid networks are specific and implementable:

1. Signal-path metadata in carrier API responses

Carrier APIs must expose whether the queried subscriber was connected via terrestrial or satellite infrastructure at the time of the query. The GSMA Open Gateway CAMARA specification should include a signalPath field in SIM Swap and Number Verification responses indicating:

  • terrestrial—standard macro cell or small cell
  • satellite-d2c—Starlink Direct-to-Cell or equivalent NTN service
  • satellite-backhaul—terrestrial RAN with satellite backhaul

This single field would enable identity platforms to adjust confidence scoring, latency baselines, and jurisdiction assumptions based on the actual signal path.

2. Ground-station jurisdiction disclosure

For regulatory compliance, carrier APIs should expose the ISO 3166-1 country code of the ground station that processed the query. This enables identity platforms to enforce data-residency policies and flag cross-border processing for audit purposes without requiring real-time knowledge of Starlink's ground-station topology.

3. Handoff-aware session continuity

Identity platforms must implement handoff-aware session models that distinguish between:

  • Terrestrial cell handoff: Expected, sub-millisecond, same network
  • Satellite handoff: Expected every 5–10 minutes, 2–8 ms spike, same network via different orbital path
  • Terrestrial-to-satellite handoff: Infrequent, higher latency step-change, same IMSI but different signal path
  • Satellite-to-terrestrial handoff: Return to ground-based infrastructure, latency step-down

Each handoff type should carry a different risk weight in behavioral scoring models. A GUTI reallocation during a satellite handoff should not trigger the same anomaly response as a GUTI reallocation during a suspected SIM swap.

4. Cached Trust Proofs for handoff windows

During the 100–500 ms window of a satellite-to-terrestrial or terrestrial-to-satellite handoff, carrier API queries may fail or timeout. Identity platforms should implement cached trust proofs that maintain session validity during handoff windows without requiring real-time carrier API confirmation. The cached proof should carry a TTL that matches the maximum expected handoff duration, and the platform should re-verify the carrier signal once connectivity stabilizes.

The architecture that survives handoff

PasskeyBridge's three-pillar architecture is positioned for the satellite-terrestrial hybrid environment because it was never architecturally dependent on a single signal path:

  • Pillar I (Carrier Signal Ingest) processes signals through a multi-provider correlation model that already handles provider disagreement and latency variance. Extending this model to account for satellite-path variance is an instrumentation change.
  • Pillar II (Verifiable Credentials) operates independently of the carrier signal path. A W3C Verifiable Credential issued via terrestrial infrastructure remains valid when presented via satellite infrastructure. The credential's cryptographic proof does not depend on the transport layer.
  • Pillar III (Biometric Binding) via WebAuthn passkeys is device-local. The biometric attestation occurs in the device's Secure Enclave, independent of whether the device is connected via terrestrial tower or LEO satellite.

The multi-pillar model means that degradation in any single signal path—including the carrier-signal uncertainties introduced by satellite handoff—does not collapse the entire identity verification. When Pillar I confidence degrades during a satellite handoff, Pillars II and III continue to provide independent trust signals. This is the resilience model that single-signal architectures lack.

The timeline

Starlink's Direct-to-Cell deployment trajectory makes this an operational concern today:

The carriers building NTN integrations today are asking which identity platforms can handle the hybrid signal path without degradation. Whether satellite subscribers need identity verification is settled.

PasskeyBridge is building that platform. The NTN Kinematic Trust Anchoring R&D program, the multi-provider correlation engine, and the three-pillar resilience model are the architectural foundations for an identity layer that does not care whether the signal came from the ground or from orbit.

The phone doesn't know it left the ground. The identity platform must.

Start free · Test the API