RADIUS Authentication for Starlink In-Flight Wi-Fi Security

In-flight Wi-Fi speeds have been improving dramatically, largely thanks to the Starlink network Airlines that once apologized for sluggish satellite connections now advertise speeds comparable to home broadband at altitude. Alaska Airlines selected Starlink for its entire fleet, Air France expects fleet-wide coverage by the end of 2026, and United Airlines has Starlink installed on more than 300 aircraft.

The connectivity problem is largely solved. The security problem is not.

In-flight Wi-Fi networks remain one of the more exposed public wireless environments an enterprise device will ever touch. Most operate without per-user authentication. Crew and passengers frequently share the same broadcast domain.

Fast internet delivered over Starlink is only as useful as the authentication layer governing who can access it, and most airlines have not closed that gap. RADIUS authentication is the security layer that does.

What Is In-Flight Wi-Fi RADIUS Authentication?

In-flight Wi-Fi RADIUS authentication is the application of the Remote Authentication Dial-In User Service (RADIUS) protocol to cabin wireless networks, using 802.1X port-based access control to verify every device before it joins the network. RADIUS is an AAA protocol: it handles authentication (who is this device?), authorization (what can it access?), and accounting (log every session).

In a wireless context, RADIUS works as the backend to 802.1X. When a device attempts to associate with a RADIUS-protected service set identifier (SSID), the access point challenges the device for credentials. The device responds, the access point forwards the challenge to the RADIUS server, and the server approves or denies the connection. Approved devices receive a VLAN assignment based on their identity. Denied devices cannot pass the access point.

RADIUS is not new. It is the authentication standard underpinning enterprise Wi-Fi, VPN, and wired 802.1X deployments globally. What is new is the context: applying in-flight Wi-Fi RADIUS to aircraft networks where the backhaul is a low-latency LEO satellite link rather than a terrestrial fiber connection.

For a detailed breakdown of how 802.1X and RADIUS work together, see What Is 802.1X? IEEE 802.1X Authentication.

How In-Flight Wi-Fi Works Today

Modern in-flight Wi-Fi is a layered system. Understanding each layer clarifies where the security gaps live.

The connectivity layer is the satellite or air-to-ground link connecting the aircraft to the internet:

• Starlink Aviation uses SpaceX’s low-Earth orbit (LEO) constellation, currently more than 10,000 satellites at approximately 340 miles altitude.
• The aircraft terminal is an electronically steered flat-panel phased array antenna that tracks LEO satellites across the sky without mechanical movement.
• Starlink LEO orbital distance produces latency typically under 99 ms (Ookla’s independent testing reported a median of 44 ms), compared to 600 ms or more for legacy geostationary (GEO) satellite systems such as Viasat and Intelsat.
• Download speeds on Starlink-equipped aircraft range from 135 to 310 Mbps in independent testing, well above what passengers and crew need for business tasks.

The distribution layer is the cabin network. ARINC 763 defines the standard for airborne network server systems and wireless access points. Cabin wireless access points (CWAPs) distribute the satellite backhaul to passengers and crew via 802.11 Wi-Fi. Most commercial aircraft operate at least two SSIDs: one for passenger internet and one for crew operational use. On many aircraft, a third SSID handles in-flight entertainment (IFE) streaming.

The authentication layer is where most in-flight deployments fall short. Passenger SSIDs typically operate as open or pre-shared key (PSK) networks with a captive portal for payment or loyalty verification. Crew SSIDs may use a shared WPA2-Personal key. Neither model cryptographically ties access to individual identities. That is the gap RADIUS is built to fill.

Is Airplane Wi-Fi Safe?

Airplane Wi-Fi security is weak by default. Most in-flight networks were designed for convenience and revenue, not identity verification. The main issues come down to three areas:

• Shared credentials: Crew networks that use a single PSK across the fleet mean any crew member, current or former, with the password can connect from any aircraft. There is no per-device credential, no revocation mechanism, and no way to attribute a specific connection to a specific device after the fact.
• No mutual authentication: Open and PSK networks do not require the access point to prove its identity to the connecting device. That creates the opening for evil twin attacks, where a malicious actor runs a fake access point using the same SSID as the airline.
• No identity-based segmentation: Crew and passenger devices cannot be placed into separate VLANs based on identity at the authentication layer. Without 802.1X, segmentation relies on SSID-to-VLAN mapping, a coarse mechanism that is dependent on correct network selection and does not enforce user or device identity.

In May 2024, the Australian Federal Police (AFP) charged a 42-year-old man with nine cybercrime offenses after he ran evil twin attacks on domestic flights and at Australian airports, harvesting email addresses and social media credentials from passengers who connected to his fake Wi-Fi network. The AFP confirmed the attacks occurred during commercial flights. The attacker was later sentenced to more than seven years in prison. This was not a theoretical attack scenario.

Crew vs. Passenger: How Airline Network Authentication Works With RADIUS

The most operationally significant use of RADIUS in airline network authentication is network separation by identity rather than by SSID alone.

Airlines run crew and passenger networks on separate SSIDs. Without RADIUS, the only barrier between a passenger device and the crew SSID is knowing the WPA2-Personal passphrase. With RADIUS and certificate-based authentication (via EAP-TLS), each crew device carries a unique X.509 certificate issued by the airline’s public key infrastructure (PKI). The RADIUS server validates the certificate against the issuing certificate authority (CA) at connection time. A device without a valid, current certificate from that CA cannot connect to the crew SSID, regardless of what Wi-Fi credentials it presents.

This matters for several reasons:

• Role-based access: Crew devices can be assigned to a VLAN with access to operational systems (tablet-based service applications, crew communications). Passenger devices are isolated to internet-only access. The policy is enforced at authentication, not just at the VLAN assignment layer.
• Per-device revocation: If a crew member’s device is lost or stolen, the associated certificate is revoked in the PKI. The next time that device attempts to authenticate, the RADIUS server checks the certificate revocation list (CRL) or Online Certificate Status Protocol (OCSP) responder and denies the connection. No password reset is required, and no fleet-wide credential rotation is needed.
• Auditability: Each connection is logged with device identity, timestamp, and VLAN assignment. That audit trail supports operational security reviews and incident response.

The Rogue Access Point Problem: How EAP-TLS In-Flight Authentication Stops It

The 2024 Australian case is the operational proof of a threat that security researchers have modeled for years. A laptop configured to broadcast the same SSID as the airline’s passenger Wi-Fi is, at the 802.11 layer, indistinguishable from the legitimate network. Devices configured to auto-connect or passengers who manually select the familiar network name will hand the attacker a man-in-the-middle position on every session.

EAP-TLS mutual authentication breaks this attack at the protocol level:

• In a standard EAP-TLS exchange, both the client and the RADIUS server authenticate each other using certificates.
• The client presents its certificate to the server, and the server presents its certificate to the client.
• If the server’s certificate is not signed by the certificate authority the client trusts, the client terminates the handshake before transmitting any credentials.

A rogue access point cannot obtain a certificate signed by the airline’s private CA. When a device configured for EAP-TLS encounters the rogue AP and receives a server certificate it does not trust, it refuses to complete the association. The attack ends before any credentials are exposed.

This is the key difference between EAP-TLS and weaker authentication methods like PEAP-MSCHAPv2. PEAP-based authentication transmits user credentials (in encrypted form) during the handshake, credentials that an attacker can attempt to crack offline. EAP-TLS never transmits passwords. It uses the cryptographic proof of certificate ownership, so there is nothing to intercept and crack.

Starlink and Cloud RADIUS: Why Latency Is Not a Problem

The historical argument against cloud-hosted RADIUS for satellite-connected environments was latency. GEO satellite links introduce 600 ms or more of round-trip latency. An EAP-TLS handshake involves multiple round trips between the access point and the RADIUS server. On a GEO link, those round trips could push authentication times well past what 802.1X clients tolerate before timing out.

Starlink LEO architecture eliminates this concern. With median latency under 99 ms (and frequently under 50 ms in Ookla’s testing), the round-trip overhead for RADIUS packets (typically under 1 KB each) is negligible. An EAP-TLS handshake completes in well under one second, even accounting for the satellite hop.

Cloud RADIUS placement compounds the advantage. A cloud RADIUS server deployed in the nearest Amazon Web Services (AWS) or Azure region to the Starlink ground station adds a few milliseconds of datacenter latency, far less than the GEO satellite overhead that made cloud RADIUS impractical for older in-flight connectivity systems. Airlines no longer need to maintain on-board RADIUS hardware or co-locate servers with in-flight connectivity providers.

System	Typical Latency	Cloud RADIUS Viable?
GEO satellite (Viasat, Intelsat)	600+ ms	No (authentication timeouts)
Air-to-ground (Gogo)	60–150 ms	Marginal
LEO satellite (Starlink Aviation)	Under 99 ms	Yes

The latency profile of Starlink Aviation makes cloud RADIUS the preferred architecture. There is no onboard server hardware to maintain, no patching cycle to manage, and no single point of failure on the aircraft.

The RadSec Challenge

Airlines deploying Starlink face a real tenant-isolation hurdle. Starlink Aviation terminals share global ground stations, and RadSec tunnels between those ground stations and a cloud RADIUS service do not themselves identify which airline a session belongs to.

Modern cloud RADIUS platforms close that gap by validating the client certificate against the tenant airline’s issuing CA, then routing the authentication request using certificate attributes, SNI on the TLS handshake, or operator NAI realms. The result is that an aircraft can roam between Starlink ground stations and still authenticate against the correct airline policy, with no cross-tenant credential exposure.”

How SecureW2 Cloud RADIUS Secures In-Flight Networks

JoinNow Cloud RADIUS is a fully managed, cloud-native RADIUS service built for exactly this architecture. Airlines and in-flight connectivity providers configuring Starlink-connected cabin networks can point their access points at Cloud RADIUS without deploying any on-premises infrastructure.

For crew authentication, JoinNow Dynamic PKI issues and manages X.509 certificates for every crew device. Certificates are issued via modern protocols (ACME, SCEP) and integrate with existing MDM deployments (Intune, Jamf, Workspace ONE) for automated enrollment. Crew devices receive their certificates silently during MDM provisioning, with no helpdesk ticket required.

At connection time, Cloud RADIUS validates the certificate against the issuing CA, checks the CRL or OCSP responder for revocation status, and applies VLAN assignment based on the device’s group membership in the connected Identity Provider (Entra ID, Okta, Google Workspace). If a flight crew device is decommissioned or a crew member leaves, their certificate is revoked and the VLAN policy is updated. The device loses network access on the next authentication attempt.

CertIQ ML Anomaly Detection continuously monitors certificate activity. If a certificate is used from an unexpected IP range or geographic location, the anomaly is flagged. For in-flight networks, a valid crew certificate should only appear from an aircraft in operation, so outliers surface quickly.

SecureW2 Cloud RADIUS operates at 99.999% availability, monitored 24/7. For an airline running in-flight connectivity across hundreds of aircraft, that SLA matters more than any on-premises alternative can deliver.

Ready to see how certificate-based authentication applies to your in-flight or enterprise Wi-Fi environment? Schedule a demo to walk through the architecture with a SecureW2 engineer.

---

Frequently Asked Questions

How does airplane Wi-Fi work?

In-flight Wi-Fi connects aircraft to the internet via satellite (most commonly LEO satellite systems like Starlink or GEO systems like Viasat) or air-to-ground radio links. Onboard access points distribute the connection to passenger and crew devices over 802.11 Wi-Fi. The satellite or ground link is the backhaul; the cabin wireless network is the distribution layer.

Is it safe to use Wi-Fi on a plane?

Airplane Wi-Fi is generally safe for casual use, but it is not a trusted or identity-secured network and should be treated as untrusted infrastructure.

Most in-flight Wi-Fi networks use open or PSK authentication, which provides no per-device identity verification. This creates real exposure to passive interception and evil twin attacks. Using a VPN on open in-flight networks provides session-level protection. For enterprise devices, networks secured with 802.1X/EAP-TLS provide the strongest protection against both credential theft and rogue access points.

What is RADIUS authentication for Wi-Fi?

RADIUS is the server-side protocol that evaluates authentication requests in an 802.1X network. When a device tries to connect to a RADIUS-protected SSID, the access point forwards the device’s credentials or certificate to the RADIUS server. The server approves or denies access and, if approved, assigns the device to the appropriate VLAN or access policy.

How do airlines separate crew and passenger Wi-Fi?

Airlines typically run separate SSIDs for crew and passengers. On networks secured with RADIUS and EAP-TLS, crew devices carry unique digital certificates. The RADIUS server validates the certificate at connection time and assigns the device to the crew VLAN. Passenger devices, which lack valid crew certificates, are directed to the passenger SSID and subject to captive portal or PSK authentication.

What are the security risks of in-flight Wi-Fi?

The primary risks are evil twin attacks (a malicious actor broadcasting a fake SSID that mimics the airline network), passive interception of unencrypted traffic, and lack of device isolation on open networks. Certificate-based RADIUS authentication eliminates the evil twin risk entirely through mutual authentication.

How does Starlink Aviation work?

Starlink Aviation uses SpaceX’s LEO satellite constellation to provide broadband internet to aircraft in flight. The aircraft terminal is a flat-panel phased array antenna that electronically tracks satellites across the sky. The LEO orbital altitude (approximately 340 miles) produces latency typically under 99 ms, compared to 600+ ms for legacy GEO satellite systems.