NTN · 2026-03-31
Starlink Direct-to-Cell and Identity: Satellite-Terrestrial Handoff and SIM Attestation
By J. W. Bouckaert
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:
| Scenario | Terrestrial Behavior | Satellite D2C Behavior | Identity Impact |
|---|---|---|---|
| SIM swap while on satellite | HSS updated instantly via core | Same—satellite is backhaul only | Minimal: detection works normally |
| Handoff from tower to satellite mid-session | Session continuity preserved | Session may re-attach with new temporary identity (GUTI reallocation) | GUTI change may trigger false anomaly in session-continuity monitors |
| Carrier API query during satellite handover | Sub-5 ms response | 15–40 ms response with possible timeout during handoff window | Timeout may be interpreted as carrier-side block or network error |
| Device location check post-swap | CGI maps to known tower | CGI maps to moving satellite footprint | Location-based fraud scoring returns undefined or misleading results |
| Ground station jurisdiction mismatch | API processed domestically | API processed via foreign ground station path | Regulatory 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 Question | Terrestrial Answer | Satellite D2C Answer |
|---|---|---|
| Where is the subscriber's signal processed? | Known tower location in subscriber's country | Ground station location is non-deterministic and may be cross-border |
| Which data protection regime governs the carrier API response? | Subscriber's home jurisdiction | Unclear—depends on ground station and inter-satellite routing |
| Can the identity platform guarantee data residency? | Yes, if carrier API is domestic | No, unless ground-station routing is contractually constrained |
| Does the signal path cross a sanctioned jurisdiction? | Verifiable via known infrastructure | Not 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 Segment | Latency Contribution | Variance |
|---|---|---|
| Device → LEO satellite (uplink) | 3–7 ms | ±2 ms depending on elevation angle |
| Inter-satellite laser link (if applicable) | 0–10 ms | Depends on number of hops between satellites |
| Satellite → ground station (downlink) | 3–7 ms | ±2 ms |
| Ground station → T-Mobile core | 5–15 ms | Depends on ground station proximity to core |
| T-Mobile core → carrier API gateway | 1–3 ms | Stable |
| Total additional latency | 12–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 cellsatellite-d2c—Starlink Direct-to-Cell or equivalent NTN servicesatellite-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:
- January 2024: First D2C-capable Starlink satellites launched on Falcon 9
- November 2024: FCC grants supplemental coverage authorization to SpaceX for Direct-to-Cell service
- February 2025: Starlink D2C messaging service goes live in the United States and New Zealand
- July 2025: T-Satellite commercial launch—SMS, MMS, and limited data for T-Mobile subscribers
- Late 2025: Voice support and expanded data capabilities in beta; Qualcomm Snapdragon X80 modem ships with NTN support
- 2026: Data throughput expansion; additional MNO partnerships in Europe and Asia-Pacific including O2 UK satellite trials; 3GPP Release 18 NTN mobility features enable standardized satellite-terrestrial handoff
- 2027: Satellite-connected subscribers as a non-trivial percentage of carrier API queries; identity platforms without hybrid-path handling begin generating measurable false-positive rates
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.