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 sees an LTE cell

When a T-Mobile subscriber leaves terrestrial coverage and the phone connects to a Starlink Direct to Cell satellite, the phone sees an LTE cell. The SIM authenticates as usual, the subscriber's IMSI and temporary identifiers work as designed, and messages flow. Starlink describes these satellites as carrying an eNodeB modem that acts like a cellphone tower in space, with "network integration similar to a standard roaming partner."

Starlink's service announcement says the satellites orbit a few hundred kilometers above Earth and move at tens of thousands of kilometers per hour relative to users on the ground, which the system handles with Doppler and timing corrections. They connect to the rest of the Starlink constellation over laser links. In the United States the service is sold as T-Satellite, which launched commercially on July 23, 2025 after the FCC approved it in November 2024.

For identity systems that read carrier signals, the question is which of those signals change when the radio link is a satellite.

Sources of carrier signals

Carrier-signal APIs answer from the operator's records, not from the radio path. A SIM swap check reads when the SIM behind a number last changed in the operator's subscriber systems (the HSS in LTE, the UDM in 5G). A porting check reads number portability records. Line type and carrier name come from numbering and operator data.

The verifier's request to the API runs from the verifier's servers to the operator's or aggregator's API gateway over the internet. It does not cross the satellite link, and the answer does not depend on whether the subscriber is on a tower or a satellite at that moment.

Verifier -> Carrier API gateway -> Operator subscriber records
Subscriber phone -> Tower or satellite -> Operator core network

A SIM swap made while the subscriber is on satellite updates the same records as one made on the ground. The CAMARA SIM Swap API, offered through GSMA Open Gateway operators such as Telefónica, returns the date of the latest SIM change or whether a change happened within a period. It says nothing about the access network the subscriber is using.

Signals that change on a satellite cell

Some signals that identity systems use alongside carrier checks behave differently when the serving cell is a satellite.

Location from the network. A cell ID on a terrestrial network maps to a tower at a fixed place. A satellite cell is served by a moving spacecraft and covers a much larger area. Location derived from the serving cell is coarser, and a device can appear to move as satellites hand over. 3GPP's NTN work has studied network-verified UE location for satellite access because of this. A rule that flags impossible travel from network location can fire for a subscriber who has not moved.

Session and network identifiers. Handovers between satellites, and between a satellite and the terrestrial network, are network events. Systems that watch temporary identifiers or network attachment for anomalies should expect them for subscribers in satellite coverage.

Reachability and roaming fields. Starlink describes its integration as similar to a roaming partner. How each operator and each carrier API reports reachability, roaming or the serving network for a subscriber on a satellite cell is set by that operator and provider, and published API documentation does not describe it. A verifier that uses these fields should test them before treating a value as a risk signal.

Response time. The verifier's API call does not cross the satellite, so the satellite does not change how long the carrier API takes to answer. Response time is the API provider's processing time plus the internet path to its gateway.

Jurisdiction

A subscriber's traffic on a satellite cell is downlinked at a ground station and carried to the partner operator's core network. Which ground stations serve which subscribers is set by SpaceX and the operator under their licenses and agreements. Carrier APIs do not expose it.

For a verifier, the carrier API response comes from the operator or aggregator it contracted with, wherever that provider processes it. The verifier's own data-protection analysis covers its transfer to and from that provider. Where satellite traffic is downlinked is part of the operator's processing of its subscribers' communications. Under GDPR Article 44, a transfer of personal data to a third country needs an adequacy decision or another safeguard, so a verifier that processes carrier data from EU subscribers can ask its provider and the operator where that data goes.

Adaptations for verifiers

These changes are specific and can be made today:

1. Weight network location lower in satellite coverage

Treat a location jump inferred from network data as weak evidence when the subscriber may be on a satellite cell, and rely on SIM change and porting data, which do not depend on the access path.

2. Ask for an access-path indicator

Carrier APIs could report whether the subscriber was last seen on terrestrial or satellite access. A field with values such as terrestrial, satellite-d2c and satellite-backhaul in CAMARA responses would let verifiers adjust location and session rules. This is a proposal; no CAMARA API defines such a field today.

3. Expect handover events

Session models that watch network events should treat satellite handovers as expected for subscribers in satellite coverage and score them differently from changes that come with a SIM swap or a port.

4. Cache trust proofs between checks

A subscriber on satellite may have limited data. Cached trust proofs let a relying party keep a recent verification result for a set time and re-check the carrier signal when the subscriber is back on a terrestrial network.

PasskeyBridge in a hybrid network

PasskeyBridge's three-pillar architecture uses signals that do not depend on one access path:

  • Pillar I (carrier signals): a carrier lookup asks one provider per request and returns that provider's answer from the operator's records. Satellite access does not change the call.
  • Pillar II (Verifiable Credentials): a W3C Verifiable Credential verifies the same way whatever network delivered it. Its signatures do not depend on the transport.
  • Pillar III (passkeys): a WebAuthn passkey is checked on the device by its authenticator, with user verification such as a fingerprint or face match, whether the phone is on a tower or a satellite.

When network-derived signals are less reliable in satellite coverage, the credential and passkey checks are unaffected. This is why PasskeyBridge does not rely on a single signal.

Timeline

Starlink Direct to Cell uses LTE with unmodified phones. 3GPP's standardized satellite access, added in Release 17 and extended in Release 18, is a separate path that phones and networks support as they adopt those releases.

PasskeyBridge's NTN Kinematic Trust Anchoring R&D program covers identity checks for devices on non-terrestrial networks.

Start free · Test the API