NTN · 2026-07-27

Inter-Satellite Links as a Trust Mesh: Optical Cross-Links in LEO Constellations and Identity Routing

By J. W. Bouckaert

The ground station assumption is breaking

For a decade, non-terrestrial network diagrams have shown the same picture. A user on the ground talks to a satellite; the satellite talks to a ground station ("gateway"); the ground station talks to a terrestrial backbone; the terrestrial backbone reaches the service. Every packet is bent-piped through a physical earth station that sits in some country, under some regulator, on some fiber.

That picture is no longer accurate for the two constellations that matter most at scale. SpaceX's Starlink has deployed optical inter-satellite links (OISLs) across the majority of its operational fleet since 2023, and Amazon's Project Kuiper has publicly committed to laser-linked satellites from day one of commercial service. When two Starlink or Kuiper terminals are within the same constellation's coverage, traffic between them can traverse a satellite-to-satellite optical path with no ground station in the middle. The gateway becomes optional. The bent pipe becomes a mesh.

For an identity layer whose entire business is where does a signal come from, whose jurisdiction covers it, and who signs it, this is a change in the trust boundary.

This article specifies what identity routing over ISLs actually looks like, what an attestation-layer operator has to build to run on that fabric, and what jurisdictional and lawful-intercept problems appear the moment a packet stops touching a terrestrial gateway.

OISLs in the public record

The published characteristics of the two dominant OISL programs are these.

Sources: Starlink figures are drawn from FCC filings and SpaceX public statements; Kuiper figures from Amazon's technical announcements and FCC coordination documents. The exact numbers move with each hardware generation; the shape does not. Every serious LEO broadband constellation from ~2025 onward is a mesh, not a star.

The consequence for a packet is straightforward. A user in Nairobi talking to a service in Frankfurt over Starlink today can traverse a path where their traffic hops satellite-to-satellite for the majority of the arc and lands at a gateway in, say, Europe rather than at an African one. The user's traffic never touched a Kenyan gateway. It also never touched a Kenyan carrier. The carrier signals we normally rely on for identity do not exist for that session, because there is no terrestrial carrier in the path.

The identity layer's problem statement

An attestation layer produces trust signals about a session. Those signals presume some provenance: an IMSI seen at an HLR/HSS, a carrier-signed authenticator, an edge point of presence in a specific city, a passkey bound to a device with a known secure enclave. All of that provenance metadata is downstream of the physical path the packet took.

Move the packet onto an ISL mesh and the provenance graph fractures in three places.

First, the carrier layer disappears. For a Starlink Direct-to-Cell or Kuiper direct-to-device session that uses ISLs end-to-end, there is no MNO in the path from which to draw an IMSI/IMEI or SIM-swap-detectable signal. The constellation operator becomes the sole source of network-layer identity.

Second, geolocation degrades. The best public-source location an attestation layer can pin for an ISL-routed session is the satellite's ephemeris (a Two-Line Element or SP3 track), well away from any terrestrial cell tower. Ephemeris is precise but the satellite's footprint at the moment of contact can be 500–1,000 km wide; and the ingress user could be anywhere within that footprint.

Third, jurisdiction gets messy. A packet that transits satellite A (US-registered), satellite B (US-registered), and lands at a gateway in Germany has arguably touched three jurisdictions before the service sees it. The bent-pipe model made this a two-jurisdiction problem (source country + gateway country). The mesh model makes it an n-country problem, decidable only if the constellation operator reveals the ISL path.

None of these fractures is unmanageable. All of them require a different architecture than the terrestrial identity stack was designed for.

Identity routing over ISLs: The wire

The specification below is what a zero-PII attestation layer must implement to operate on an ISL mesh, whether as a service running on customer edge (a ground gateway operator, an enterprise VSAT, or a Direct-to-Cell MNO partner) or as a service that consumes constellation telemetry as an input.

1. Attestation envelope

Every attestation event carries the standard fields (hashed subject identifier, session nonce, timestamp, signer chain) plus an ISL provenance block when the network path traversed one or more optical links.

attestation.v1 {
  subject_hash:  sha256(...)      // never plaintext
  session_nonce: 128-bit random
  issued_at:     RFC 3339 UTC (atomic-clock synced)
  signer_chain:  [issuer_kid, ...]
  network:
    path_class:  "bent_pipe" | "isl_mesh" | "hybrid"
    ingress_sat: NORAD_ID | null
    egress_sat:  NORAD_ID | null
    egress_gw:   iso_country_code | null
    isl_hops:    integer >= 0
    ephemeris:   sp3_or_tle_ref
  suite:
    sig:  es256 | ml-dsa-65 | hybrid(es256+ml-dsa-65)
    hash: sha256 | sha3-256
}

The network block is what makes the envelope ISL-aware. The signer chain still terminates at a terrestrial trust anchor (the attestation service's root), but the observed path is now part of the signed statement.

2. ISL-aware signer discovery

On a bent-pipe path, an attestation service reaches its signing keys over standard HTTPS to a KMS. On an ISL path, the signer discovery has to survive the case where the ground gateway is in a different country than the user and the user's home constellation region.

In practice, this means the signing service is regionally replicated (per major landmass) with a session-affinity rule: the region that serves the attestation is the region containing the egress gateway, which may differ from the ingress footprint. This is a subtle but load-bearing detail. If the service picks the region of the user's footprint (which the operator can only estimate), a large fraction of sessions will fail signer resolution when the estimate is wrong. Pinning to egress gateway is deterministic once the packet lands.

3. Path-class assertions

The path_class field is not user-declared. It has to be derived from constellation telemetry the operator either receives from the constellation (Starlink and Kuiper publish gateway-side metadata to enterprise customers) or infers from timing.

The inference heuristic that works in practice: measure the ratio between the user's RTT to the service and the theoretical minimum RTT for the geodesic distance between user and service assuming a single-satellite bent pipe. If observed RTT is lower than the bent-pipe minimum, the path traversed ISLs (because the mesh chord is shorter than the two-hop bent-pipe path once you cross a landmass). If observed RTT is within the bent-pipe range plus jitter, the path was bent pipe. The heuristic proves nothing cryptographically, but it is sufficient to raise path_class as a soft signal that lets a relying party demand stronger session-freshness proofs when ISLs are inferred but no cryptographic anchor for the path exists.

4. Freshness under ISL jitter

ISL paths have a different jitter profile than bent-pipe paths. When a link handover happens (a satellite drops out of the visible window and its ISL peer is replaced by the next satellite in the plane), the packet path may reroute by 200–800 km and add 3–10 ms of latency in a single frame. This is fine for the user's TLS session but a problem for identity systems that treat a sudden latency shift as a re-authentication trigger.

Zero-PII attestations therefore emit an explicit isl_handover_hint in the envelope when the operator observes a plane transition during the session. Relying parties are expected to not raise a freshness anomaly against a session whose latency jumped inside a signed handover window.

The trust boundary

The interesting engineering question is what part of the trust chain leaves the operator's control the moment ISLs are in the path? Routing identity over ISLs is not itself in doubt.

The answer is: the middle. In a bent-pipe world, the trust chain looked like this.

User device ─┬─> RF up ─> Satellite ─> RF down ─> Gateway ─> Terrestrial backbone ─> Service
             │
             └─ Signed by: device, MNO (if any), gateway operator, service

Every hop had a terrestrial accountable operator. Gateway logs were subpoenable. Backbone providers were subpoenable. The satellite was a repeater with limited state.

In an ISL mesh, the middle contracts to a single accountable operator: the constellation.

User device ─> RF up ─> Sat A ─OISL─> Sat B ─OISL─> Sat C ─> RF down ─> Gateway ─> Service
                          └────────── entire path inside constellation ──────────┘

The constellation operator sees the ingress, the routing decisions, the egress, and the timing. No terrestrial carrier or backbone provider sees the middle at all. From an identity perspective, this is a strong signal in one dimension (a single well-instrumented operator can attest to the path with high fidelity) and a weak signal in another (there is no independent second party to corroborate).

An attestation layer that ignores this collapse of the middle is, in practice, trusting the constellation operator's word for everything about the session's provenance. That is a defensible engineering choice; it should be an explicit engineering choice, marked in the envelope so downstream relying parties can score it.

Jurisdictional reach

The ITU Radio Regulations and national licensing regimes were written for a world where the traffic-bearing hop that mattered was the RF path from user to gateway on one country's territory. ISL routing does not fit that model cleanly.

The current legal working assumption, insofar as one can be inferred from FCC and ITU filings, is that:

• The uplink jurisdiction is the country where the user terminal transmits.
• The downlink jurisdiction is the country where the ground gateway receives.
• The middle hops (ISLs) are treated as space-segment under the flag state of the satellite operator, and are not generally considered to be "in" any terrestrial jurisdiction while they are traversing space.

This has two direct consequences for identity.

Data-residency claims collapse for ISL segments. A claim of the form "packets between EU users and EU services never leave the EU" is not enforceable on an ISL path unless the operator explicitly steers the packet to an intra-EU ISL chain, which none of them do by default. Several DORA Article 28 subcontractor assessments are going to have to be rewritten on exactly this basis as ISL usage grows.

Lawful intercept becomes single-point. Interception at a terrestrial backbone catches the terrestrial hops. On an ISL path, the only interception point is the ground gateway or the constellation operator's own network operations center. If both are outside a requesting authority's jurisdiction, the traditional lawful-intercept toolkit does not reach the packet. Whether this is desirable depends on which side of the request you sit on.

An honest identity layer says none of this out loud in marketing copy and does say it explicitly in the attestation envelope, so downstream consumers can encode their own jurisdictional policy.

PasskeyBridge's role

PasskeyBridge is an ITRaaS attestation layer and never a satellite network operator. Our role in an ISL-routed session is downstream of the constellation. What we can and cannot do on that path is bounded accordingly.

We can:

• Detect probable ISL routing from RTT heuristics against a satellite ephemeris table (we already carry a stratum-2 NTP-synced clock and a CelesTrak TLE mirror for the kinematic-handshake telemetry).
• Emit path_class as a soft signal in every attestation, defaulting to bent_pipe and lifting to isl_mesh only when the RTT anomaly and constellation membership both indicate it.
• Downgrade carrier-signal weight to zero on sessions where no MNO is in the path, and require an alternate freshness proof (passkey re-assertion, DPoP-bound token, or explicit device-posture attestation) before the session is treated as high-trust.
• Preserve the ISL provenance in the audit trail so a later reviewer can reconstruct whose accountable chain governed the session.

We cannot:

• Cryptographically prove the ISL path was traversed. Only the constellation operator can, and none of them publish a per-session path attestation today.
• Extract a per-country jurisdictional identifier for the middle hops. That data does not exist in a form we can trust from outside the constellation.
• Substitute for carrier signals with equivalent strength on a session where no carrier is present. We can only be honest that the signal is missing and require alternative anchors.

We are watching two developments closely. The first is whether the 3GPP NTN work items in Release 18 and Release 19 evolve toward a signed path descriptor that a constellation operator could emit to relying parties. The second is whether the constellation operators themselves ship an enterprise API that returns a per-session path summary suitable for consumption in an attestation envelope. Neither exists as a public specification today. Both are technically straightforward. The obstacle is commercial and regulatory.

The trust mesh vocabulary

Two terms of art appear when engineers discuss ISL-routed identity. It is worth naming them precisely so the industry stops using them interchangeably.

Trust mesh refers to the cryptographic topology: the graph of who signs what, with which key, and under which trust anchor. On an ISL path the trust mesh does not automatically match the network topology. Signatures are still terminated at the constellation operator's KMS and the attestation service's KMS, both of which are terrestrial services accessed through the egress gateway. The ISL hops carry the packet; they do not sign the packet.

Routing fabric refers to the network topology: the graph of which satellite forwards to which satellite. This is the mesh people mean when they say "Starlink mesh." It is invisible to the packet's cryptographic layer unless the operator explicitly exports it.

Conflating the two produces bad architecture. An attestation service that treats the routing fabric as if it were the trust mesh will over-attribute trust to the constellation. A service that treats the trust mesh as if it were the routing fabric will under-attribute the constellation's role and miss the collapse of the middle.

The correct model keeps both graphs and cross-references them per session.

Practical recommendations for relying parties

If you are a bank, a healthcare system, or a government service that will receive traffic over ISL-routed satellite links in the next 24 months, three actions are worth taking now.

1. Ask your attestation vendor whether they emit a path_class field or equivalent. If they do not, they cannot distinguish a session that touched carrier infrastructure from one that did not. Any risk model that weights carrier signals will silently misprice ISL sessions.

1. Rewrite data-residency contract language to acknowledge space-segment traversal. Contracts that require "traffic remains within the EU/US/UK" are already unenforceable for satellite-served users on mesh constellations. Either accept the reality or restrict the endpoint to gateway-anchored routing only.

1. Assume lawful-intercept coverage over ISL segments is zero unless you have a specific arrangement with the constellation operator. Plan compliance controls (audit, DLP, incident response) with that assumption baked in.

None of these actions requires waiting for a standards body to catch up. All of them can be implemented at the relying-party layer today, given an attestation service that exposes the primitives.

Direction

The ground station assumption was one of the last remaining terrestrial anchors in the identity stack. It was implicit in every threat model, every carrier partnership, every jurisdictional data-residency clause. It is quietly disappearing.

The identity layer's job over the next 24 months is not to fight the disappearance; the constellations are shipping the mesh whether the identity industry likes it or not. The job is to make the observability of ISL routing a first-class primitive in the attestation envelope, and to be honest with relying parties about which trust guarantees survive the middle collapsing and which do not.

The signal we are watching is what the wire format actually carries about the path, whatever the marketing decks say about "space-based identity."

Read the LEO Doppler telemetry deep dive → See how NTN affects delay-tolerant identity → Explore zero-PII architecture end-to-end → Get started with PasskeyBridge →

Start free · Test the API