NTN · 2026-10-15

3GPP Release 19 NTN Security: The Satellite Becomes the Base Station

By J. W. Bouckaert

Release 19 is finished, and the operators have named it

3GPP's own table dates Release 19's functional freeze to September 2025 and its protocol-stable milestone to 12 December 2025; the release page says that with fully implementable specifications available at the end of December 2025 the second 5G-Advanced release "is now complete". The operators building direct-to-device services have said which release they are aiming at. SpaceX's Michael Nicolls, quoted by RCR Wireless in March 2026, said that "Starlink Mobile will use the 3GPP Release-19 NR-NTN standard". AST SpaceMobile's public FAQ says the "3GPP Release-19 L- and S-band RF and conformance packages are now stabilized". Iridium's NB-IoT service entered the Release 19 work plan in 2024 and went into on-air trials in January 2026.

So Release 19 is the version of non-terrestrial networking that will carry real subscribers, and the question this post set out to answer was what it says about authenticating them. The honest answer took some finding, because the release's security work is small and lives in an unexpected specification. Here it is, clause by clause, followed by what it means for anyone who treats a carrier's view of a subscriber as evidence.

The Release 17 baseline: a repeater in the sky

Satellite access arrived in Release 17 with what the specifications call a transparent payload. TS 38.300's description is exact: "The NTN payload transparently forwards the radio protocol received from the UE (via the service link) to the NTN Gateway (via the feeder link) and vice-versa." The gNB sits on the ground behind the gateway; the satellite may shift the carrier frequency and does nothing else with the signal. The core network sees a new radio access type, and TS 23.501 gives it names, NR(LEO), NR(MEO), NR(GEO) and NR(OTHERSAT), so that policy can differ by orbit.

Nothing about security changed, and the specifications are quiet about it in a way that is itself the evidence. TS 38.300's NTN clause has no security subclause. TS 23.501's satellite clauses cover RAT types, location verification, network selection and tracking areas, and no security. The Release 18 security study on satellite access, TR 33.700-28, examined one key issue, the protection of satellite coverage information, and concluded that "no normative work is needed". A phone on a Release 17 satellite cell authenticates with 5G AKA or EAP-AKA' to a core on the ground exactly as it would on a terrestrial cell, because from the security architecture's point of view the satellite is a piece of transport.

The base station moves into orbit

The work item that defines Release 19's NR-NTN scope, RP-234078 from December 2023, lists the assumptions (FDD, and terminals with GNSS) and the objectives: better downlink coverage, more uplink capacity, broadcast service areas, support for the reduced-capability device classes, and "support of regenerative payload", with the instruction to "specify the support of gNB on board in TS 38.300" and to handle mobility "over feeder link or over ISL". TS 38.300 V19 now defines the payload either way: "The NTN payload may be a TNL node (transparent payload) or a gNB (regenerative payload)." The regenerative payload "terminates the Uu (via the service link), NG and Xn interfaces" and may terminate inter-satellite links to other regenerative payloads. It can ask the core to remove its NG interface "based on e.g. ephemeris information" as it leaves an AMF's service area, and the release assumes a subscriber keeps the same AMF across a feeder-link switch.

That is the whole base station, in orbit. Release 16's study had considered splitting it, with a distributed unit on the satellite and the central unit on the ground, and had noted that "DU on board different satellites may be connected to the same CU on ground". Release 19 chose the full gNB instead, and the choice is what makes the NG and Xn interfaces cross the feeder link and the inter-satellite links.

For the IoT variant on LTE, Release 19 went further. Store-and-forward operation, specified in TS 23.401, is for "delay-tolerant communication services (e.g. CIoT/MTC, SMS, etc.)" on a satellite that is out of contact with the ground while it is in contact with the device; "eNodeB and some network functionalities need to be deployed on the satellite", in one of two models, a split MME or a full EPC per satellite. The 5G side got a requirement in TS 22.261 for UE-to-UE communication through the satellite without transiting the ground and for service "independently of the UE's GNSS capability", and TS 23.501 specifies the first of those for IMS voice and video within one PLMN; the second stayed a Stage 1 requirement, with the radio study on GNSS-resilient operation on Release 20's agenda.

The security work, as written

The Release 19 security study for satellite access is TR 33.700-29, approved in March 2025 under the work item 5GSAT_Ph3_SEC. Its scope names three things: the security and privacy of the regenerative payload architecture, of store-and-forward operation, and of UE-satellite-UE communication, plus the impact on lawful interception. Its body contains two key issues, and both are about store and forward. The first is security protection when the feeder link is intermittently unavailable: the AKA procedure "may not get fully completed", the NAS security mode command may be interrupted, and uplink data stored on the satellite during an outage means "the storage capacity can be easily exhausted by spoofed data with the attack over the air". The second is privacy: a device that cannot be authenticated until the feeder link returns cannot establish the context that protects its responses, so it can be linked and tracked.

The conclusions are short. "The normal security procedures are used as security can be established using legacy security procedures (e.g. AKA, NAS security mode command, etc.) using the security credentials in the HSS onboard the satellite." As an operator option, "IOPS-based keying which is captured in the informative Annex F in TS 33.401 can be used to limit the impact of exposing the long-term key in the HSS in the satellite". "The NAS security is terminated on the MME on-board the satellite", which obtains authentication vectors while the feeder link is up and stores them for use while it is down. Synchronising the NAS security context between the ground MME and the on-board MME "is out of the scope of 3GPP". Protection against denial of service before a security context exists was left "to be determined during normative work", and the normative conclusion for both store-and-forward architectures was that no normative work is needed.

What did get written is Annex N of TS 33.401, the LTE security specification, added in June 2025 and revised in September. It is normative and it is one page. "Regular LTE procedures shall be used to provide the security between the UE and network." "The security of communications between the proxies on satellite and the ground station(s) is out of 3GPP scope." NAS security terminates on the on-board MME, and the ground segment ensures the latest context or a vector is available there. A note records that "a malicious entity can flood satellites with spoofed Attach Requests", consuming on-board storage before authentication, and that "addressing said (D)DoS attack in the Split MME deployment is left to implementation". IOPS keying is adopted so that "only a satellite-specific subscriber key" needs to be stored on the satellite, limiting what a captured or compromised spacecraft exposes.

And TS 33.501, the 5G security specification, in its August 2026 version, contains no occurrence of the word satellite, or of NTN, anywhere, including in its change history. For a 5G phone on a Release 19 satellite cell, the authentication procedure is the one every terrestrial phone runs.

The authenticated bearer, then

The calendar entry for this post promised an "authenticated satellite bearer" and "satellite-aware AKA variants". There are no such variants, and it is worth being plain about that rather than writing around it. The radio bearer between a phone and a Release 19 satellite is authenticated exactly as it was in Release 15: 5G AKA or EAP-AKA' to the core, keys derived from the subscriber's long-term key, NAS and AS security established from them. What Release 19 changed is where those keys live and what the transport between the pieces looks like.

The trust boundary of the network now includes the spacecraft. In Release 17 a satellite that was captured, spoofed or compromised could relay or jam radio; in Release 19 it holds gNB keys and, on the LTE side, subscriber-specific keys and unencrypted stored traffic, and terminates NAS security. The standards' answer is to reuse the mechanisms built for a base station on a rooftop, with an IOPS-style keying so that the on-board key is not the subscriber's real one, and to leave the rest to operators. That is a defensible engineering choice, and it is one to know about, because the phrase "3GPP-standard security" now covers a base station that orbits through other countries' airspace every ninety minutes, which our earlier post on inter-satellite links as a trust mesh approached from the routing side.

Consequences for an identity verifier

An identity or fraud platform never sees any of this directly. What it sees is what the carrier exposes: whether a number's SIM changed, whether it was ported, whether the subscriber is reachable, and, through the core's RAT type, that the session is on a satellite cell. Three consequences follow from Release 19.

First, the carrier state a verifier consumes is the same state, produced by the same authentication, and a satellite-attached subscriber's SIM-swap or port-out signal is as good as a terrestrial one. Nothing in Release 19 weakens the possession evidence that a carrier check rests on. The direct-to-cell post covers how the surrounding metadata, latency and location, degrades even when the detection does not.

Second, store-and-forward on the IoT side introduces a class of device whose authentication completed on a satellite, against a stored vector, with the context reconciled to the ground later. For a verifier that is a freshness question: a carrier's answer about such a device describes the last reconciliation, and the TTL argument applies with the satellite's orbit as the clock.

Third, the denial-of-service gap the annex names is a gap in availability rather than in authentication, but availability is what a fail-closed verifier depends on. A satellite whose on-board storage has been exhausted by spoofed attach requests is a cell that answers nobody, and a platform that fails closed on carrier unavailability will see that as a burst of unverifiable subscribers over one region for the duration of one pass. Knowing that the standard left this to implementation is knowing that it will vary by operator.

Left open

The specifications leave three things unwritten. The regenerative payload appears in the security study's scope and in none of its key issues, so there is no normative text specific to gNB key handling in orbit beyond the generic base-station rules. UE-satellite-UE communication has no key issue either. And GNSS-independent operation, which would remove the position-as-input property that makes orbital timing evidence so unusual, is a Release 19 requirement whose radio work belongs to Release 20. Each of those is a place where an operator's implementation, rather than 3GPP, will decide what a verifier can rely on. The technical whitepaper places the orbital work within the three-pillar architecture; the specifications cited above are the ones to read before believing any vendor's summary of them, ours included.

Start free · Test the API