How Satellite Internet Works: LEO, Terminals, Latency and Security

Satellite internet works by relaying your traffic from a dish or flat panel terminal, up to a satellite, and down to a ground gateway that connects to the internet. Low Earth orbit (LEO) constellations fly at roughly 500 to 650 km, so the radio path adds only a few milliseconds, while geostationary (GEO) satellites sit at 35,786 km and add close to half a second per round trip. Security depends less on the satellite than on the ground network, the management plane and the terminal firmware.

This post goes one level deeper than our satellite build explainer and our KA-SAT terminal lessons post. Here we stay with the internet service itself: orbits and the latency they cost, how a flat panel finds a satellite moving at about 7.6 km per second, what a gateway and a laser crosslink do, who hands out the spectrum, how direct to cell service differs, and how a business should wire a satellite backup link so that it fails over cleanly and stays patched. Regulatory facts come from FCC orders and the ITU, orbit facts from ESA and NASA, security guidance from NIST and CISA, and operator facts only from the operators' own public disclosures.

Key takeaways

• Altitude sets the floor on latency. Light covers the 35,786 km up to a GEO satellite and back down in about 239 ms at best, so a request and its reply cannot beat roughly 477 ms. A LEO satellite at 550 km adds a few milliseconds per leg.
• LEO needs many satellites because each one sees only a small patch of Earth and crosses the sky in minutes. The FCC's 2022 Gen2 Starlink order authorised up to 7,500 satellites at 525, 530 and 535 km; the 2020 Kuiper order covered 3,236 satellites at 590, 610 and 630 km.
• Flat panel terminals are electronically steered phased arrays. They point a beam by shifting the phase of hundreds of small antenna elements, and a computer inside runs the schedule, the modem and an update agent. That makes the terminal a networked Linux class device that needs patching like any other.
• Gateways (large ground earth stations) connect the constellation to the internet. Optical inter satellite links let traffic hop between satellites when no gateway is in view, at the cost of extra path length.
• Spectrum is licensed twice: the ITU records frequency assignments and coordinates between countries, and national regulators such as the FCC license the satellites and the earth stations. Bands in use include Ku, Ka, V and, proposed, E band.
• Direct to cell service is different technology: it talks to ordinary phones in mobile bands. 3GPP Release 17 was the first release with normative non-terrestrial network (NTN) support, and the FCC created a "supplemental coverage from space" framework in March 2024.
• The 24 February 2022 KA-SAT incident started on the ground: according to Viasat, an attacker used a misconfigured VPN appliance to reach the management network and sent legitimate management commands that overwrote modem flash memory. The lesson is about management plane access, not about the satellite.
• NIST IR 8270, IR 8401 and IR 8441, CISA advisory AA22-076A and Space Policy Directive 5 are the core public guidance. For a business, the practical work is routing, CGNAT awareness, VPN design and terminal firmware hygiene.

Timeline: the licensing, standards and guidance behind today's satellite internet

Dates below were checked against the primary document linked in Sources.

How do GEO, MEO and LEO satellite internet differ?

The three families differ by altitude, and altitude drives everything else: how long the signal takes, how much of Earth one satellite can see, how many satellites you need, and how the antenna on your roof has to behave.

ESA describes geostationary orbit as a circular orbit above the equator at an altitude of 35,786 km, where a satellite takes one sidereal day to go round and therefore appears to hang over one spot. That is why a traditional satellite TV or broadband dish can be bolted in place and never move. ESA defines low Earth orbit as altitudes below about 2,000 km, with satellites rarely flying below about 180 km because atmospheric drag pulls them down. Medium Earth orbit is everything in between; NASA's orbit catalog notes, for example, that the semi-synchronous orbit used by navigation satellites sits about 26,560 km from the centre of Earth.

Worked latency example 1: GEO

The speed of light in vacuum is 299,792 km per second, which is 299.792 km per millisecond.

A request from your terminal goes up to the satellite and down to the gateway. With the satellite directly overhead of both ends (the best case), that is 35,786 km up plus 35,786 km down, or 71,572 km. Divide by 299.792 km per ms and you get about 238.7 ms one way.

The reply has to make the same trip in reverse. So the round trip time for a single request and response is about 2 × 238.7 = 477.5 ms before any queueing, modem processing, gateway backhaul or server time. In practice the satellite is rarely straight overhead. At low elevation angles the slant range to a geostationary satellite approaches about 41,700 km per leg, which pushes the pure propagation round trip past 550 ms.

Worked latency example 2: LEO at 550 km

Now repeat the sum for a satellite at 550 km. Overhead, up and down is 1,100 km, which is 1,100 / 299.792 = 3.67 ms one way, or about 7.3 ms for the round trip.

The satellite is usually not overhead, so use a more realistic 25 degree elevation angle at both the user and the gateway. The slant range d from a point on Earth (radius R = 6,371 km) to a satellite at altitude h, seen at elevation angle e, is:

d = sqrt((R + h)^2 - (R cos e)^2) - R sin e

With h = 550 km and e = 25 degrees: R + h = 6,921 km; R cos e = 5,774 km; R sin e = 2,692.5 km. So d is the square root of (6,921² minus 5,774²), which is 3,815.9, minus 2,692.5, giving about 1,123 km.

Up and down at 25 degrees each end is about 2,247 km, or 7.5 ms one way and 15 ms round trip. Starlink's own March 2024 latency note gives a consistent figure: it says speed of light propagation from user to satellite and back to the ground is in the range of 1.8 to 3.6 ms per leg, "usually under 10ms" for the round trip. The rest of the latency people actually see comes from scheduling on the radio link, the distance from the gateway to the internet connection point, buffers, and occasional detours over laser links. In the same note the operator reported cutting US median peak hour latency from 48.5 ms to 33 ms, and worst case (99th percentile) peak hour latency from over 150 ms to under 65 ms, mostly through software changes. That gap between the physical floor and the measured median is the part software and network design control.

Worked latency example 3: MEO at 8,000 km

For an illustrative MEO shell at 8,000 km, overhead up and down is 16,000 km, or 53.4 ms one way and about 107 ms round trip. That sits between the two extremes: good enough for video calls, noticeably worse than LEO for gaming or remote desktop.

Why LEO needs so many satellites

A satellite can only serve users that see it above some minimum elevation angle. The lower the orbit, the smaller that footprint, and the faster the satellite moves across it. At 550 km a satellite moves at roughly 7.6 km per second and stays in view of a given user for only a few minutes, so a terminal hands over between satellites all the time. Continuous service needs enough satellites that another is always in view, plus spare capacity for busy regions. That is why the regulatory filings run to thousands of satellites. The FCC's November 2022 Gen2 order granted SpaceX authority for up to 7,500 satellites at 525, 530 and 535 km with inclinations of 53, 43 and 33 degrees, out of 29,988 requested, and said further deployment should happen incrementally. The 2020 Kuiper order describes 784 satellites at 590 km (28 planes of 28), 1,296 at 610 km (42 planes of 36) and the remainder at 630 km.

Low orbits also clear themselves. Atmospheric drag pulls dead satellites down within years, and in September 2022 the FCC shortened its benchmark for post-mission disposal of LEO satellites from 25 years to 5 years. For an internet user that matters indirectly: constellations are replaced continuously, so the satellites carrying your traffic in 2030 will mostly be newer models running newer software than the ones overhead today.

How do phased array user terminals track satellites?

A GEO dish points at one fixed spot. A LEO terminal has to follow a satellite that rises, crosses the sky and sets in minutes, then jump to the next one. Mechanically slewing a dish that fast, all day, for years, is expensive and fragile. So modern LEO user terminals use electronically steered phased arrays: a flat panel made of hundreds or thousands of small antenna elements, each with its own phase control.

The physics of beam steering, with numbers

If every element transmits the same signal in phase, the wavefronts add up straight out of the panel. If each element is delayed a little more than its neighbour, the combined wavefront tilts, and the beam points off to one side. The required phase step between neighbouring elements for a beam steered by angle θ from the panel's perpendicular is:

Δφ = 2π × (d / λ) × sin θ

where d is the element spacing and λ is the wavelength.

Worked example: the FCC Gen2 order grants Ku band user downlinks at 10.7 to 12.7 GHz. At 12 GHz the wavelength is c / f = 299,792,458 / 12,000,000,000 = about 2.5 cm. Arrays are usually laid out with elements about half a wavelength apart, so d = 1.25 cm and d / λ = 0.5. To steer the beam 30 degrees off boresight, sin 30° = 0.5, so Δφ = 2π × 0.5 × 0.5 = π/2, or 90 degrees of phase per element. At 45 degrees, sin 45° = 0.707 and Δφ is about 127 degrees per element.

A second worked example shows why steering far from the perpendicular costs performance. The effective aperture of a flat panel shrinks with the cosine of the steering angle. At 30 degrees cos θ = 0.866, so the panel behaves like one 13 percent smaller; at 60 degrees cos θ = 0.5, half the effective area, which is about 3 dB of gain lost on both transmit and receive. That is one reason terminals prefer satellites high in the sky, and why installation guides tell you to clear obstructions in a wide cone around the panel's view rather than just "point it south".

What runs inside a terminal

Strip the plastic off a modern flat panel terminal and you find a radio front end (the element array, beamformer chips, amplifiers and frequency converters), a baseband modem that handles the air interface, and a general purpose computer that runs an operating system, a scheduler that knows where each satellite will be, a GNSS receiver for time and position, sensors for orientation, and an update agent. The terminal needs the satellites' predicted positions (ephemeris) to know where to point, and it gets told by the network which satellite and beam to use and when to hand over.

For a security team, the important point is that this is a networked computer with a management channel back to the operator. It receives over the air firmware updates, accepts configuration from the network, and in many cases exposes a local management interface or app API on the customer side. The operator's published latency note gives a sense of the update tempo: from the start of 2024 to its March note it reported deploying and testing 193 satellite software builds, 75 gateway builds, 222 terminal ("Starlink") builds and 57 Wi-Fi router builds. A device that changes that often is only as trustworthy as the signing, distribution and rollback process behind those builds, which is the same software supply chain question every product team faces.

Customer side, there is usually a Wi-Fi router, which may be the operator's own or yours in bypass mode. Starlink's note also says it added fq_codel active queue management to its Wi-Fi router to stop one large download from inflating latency for everyone else on the network. If you replace the router, you inherit that responsibility: enable a modern queue discipline such as fq_codel or CAKE on your own edge router.

What are gateways, inter-satellite laser links and the ground segment?

The satellites are only half of the system. Everything on the ground that makes the constellation useful is called the ground segment, and that is where most of the security surface lives.

Gateways

A gateway is a large earth station, often a cluster of tracking dishes behind a fence, that talks to the satellites on feeder links and connects to the operator's fibre backbone. The FCC rules define a non-geostationary fixed-satellite service gateway as an earth station that "is not for the exclusive use of any customer" and may also carry telemetry, tracking and command traffic. The Gen2 order notes that SpaceX proposed Ku band links to user terminals and Ka band links to both user terminals and gateways.

From the gateway, traffic travels over terrestrial fibre to a point of presence (PoP), where the operator connects to the wider internet, assigns IP addresses and applies policy. Starlink's latency note lists ground latency from gateway sites to the internet connection point as one of its main latency drivers and said it was adding six US PoPs in 2024 so traffic could "land" closer to its destination. For a user, this explains a common surprise: your public IP address and geolocation reflect the PoP, which can be in a different city or country from you.

Bent pipe and regenerative satellites

There are two ways a satellite can handle your signal. 3GPP's NTN overview describes them precisely. A transparent or "bent pipe" payload receives the uplink, changes the carrier frequency, filters and amplifies it, and sends it back down: an analogue repeater in orbit. A regenerative payload also demodulates and decodes the signal and can switch or route it on board before re-encoding it. With a bent pipe satellite, the user and the gateway must both see the same satellite at the same time. With a regenerative satellite, the satellite can forward traffic to another satellite.

Inter-satellite laser links

Regenerative satellites with optical terminals can pass traffic to each other by laser. That lets a constellation serve ships at sea, polar regions and aircraft far from any gateway, and route around congested gateways. Starlink's March 2024 note describes laser connectivity as essential for the most remote locations and for routing around congestion, while acknowledging it adds latency compared with going straight down to a nearby gateway.

There is a physics point here that surprises people. Light in optical fibre travels at about two thirds of its vacuum speed, because glass has a refractive index of around 1.47. Light between satellites travels at the full 299,792 km per second. Over long distances, a path through space can therefore be quicker than a path through a submarine cable even though it is longer, if the hops and processing are efficient. Our undersea cable explainer covers the cable side of that trade off.

The ground segment as a security boundary

NIST IR 8401 (December 2022) applies the Cybersecurity Framework specifically to the satellite ground segment, meaning command and control: the mission operations centres, telemetry, tracking and command links, and the networks connecting them. NIST IR 8441 (September 2023) extends the view to hybrid satellite networks, which it describes as an aggregation of independently owned and operated terminals, antennas, satellites and payloads with varying levels of assurance. That last phrase is the heart of the matter for satellite internet: your terminal, the operator's gateways, a ground station as a service provider, and the cloud regions that host network functions may all be run by different organisations.

What spectrum bands are used, and who licenses them?

Satellite broadband uses microwave and millimetre wave bands. The letter names (Ku, Ka, V, E) are engineering shorthand. What a regulator actually licenses is a precise range in hertz, a direction (space to Earth or Earth to space) and a service.

Rain fade is the reason higher bands are mostly used for gateways rather than users. Water droplets absorb and scatter millimetre waves, and the effect grows with frequency. An operator can afford big dishes, site diversity and power margins at a gateway; a consumer panel cannot.

Who licenses what

Two layers of law apply.

The International Telecommunication Union's Radio Regulations are the treaty that allocates bands to services worldwide and sets out how satellite systems coordinate with each other. They are revised at World Radiocommunication Conferences. The ITU's Space Services Department processes and publishes frequency assignment notices submitted by national administrations, sets coordination requirements, and records assignments to space systems and earth stations in the Master International Frequency Register (MIFR). In other words, a constellation reaches the ITU through a national administration, not directly.

National regulators then license operations. In the United States that is the FCC, whose Space Bureau leads policy and licensing for satellites and earth stations through its Satellite Licensing and Earth Station Licensing divisions. Satellite systems are licensed under Part 25 of the FCC rules. A non-US operator that wants to serve US customers asks the FCC for "market access" rather than a licence. Each order sets conditions: the Gen2 grant, for example, carried conditions on orbital debris, astronomy and interference with other systems, and limited the grant to 7,500 satellites at the time.

In the US, non-geostationary systems that apply for the same bands are grouped into processing rounds and then share that spectrum under the FCC's rules; both the Gen2 and Kuiper orders address their place in the 2020 processing round, and the Gen2 grant carries conditions to protect geostationary and other systems from interference.

What is direct to cell, and how is it different?

Everything above describes a dedicated terminal. Direct to cell, also called direct to device or direct to handset, means an ordinary phone connects to a satellite with no special antenna. That changes almost every design choice.

The 3GPP side

3GPP's NTN overview says Release 17, with ASN.1 frozen in June 2022, was the first release with normative requirements for non-terrestrial networks. It covers both NR NTN (5G New Radio over satellite) and IoT NTN (NB-IoT and eMTC over satellite). The overview explains why phones cannot just talk to satellites unchanged: propagation delay is far larger than on terrestrial networks (usually under 1 ms on the ground, up to a few hundred milliseconds for GEO), so random access, timing advance, HARQ, power control and the MAC and RLC layers all need adjustments. LEO satellites also move fast, which creates large and changing Doppler shifts and moving cell patterns. The specification answer is to give the device the satellite's ephemeris and its own GNSS position, so it can pre-compensate timing and frequency itself.

The transparent versus regenerative distinction appears here too. With a bent pipe satellite, the 5G base station (gNB) sits on the ground behind the NTN gateway. With a regenerative satellite, the gNB can be on board, and the gateway becomes a router towards the core network. Either way, the satellite access network plugs into a standard mobile core. Our 5G core explainer covers the AMF, SMF and UPF that serve satellite users exactly as they serve terrestrial ones.

The FCC side

On 14 March 2024 the FCC adopted a Report and Order creating the supplemental coverage from space framework. It lets a satellite operator in partnership with a terrestrial licensee offer service to consumer handsets in spectrum previously allocated only to terrestrial service, as a secondary mobile-satellite service. The listed SCS bands include parts of the 600 MHz, 700 MHz and 800 MHz bands and Broadband PCS (1850 to 1915 and 1930 to 1995 MHz), among others. The order also applied interim 911 call and text routing requirements.

For security, direct to cell inherits the mobile network's model: SIM based authentication, 5G or LTE air interface encryption and the operator's core. It does not create a new local device on your network, which removes one class of risk (terminal firmware on your LAN) while adding reliance on the mobile operator's and satellite operator's shared infrastructure.

What does the 2022 KA-SAT incident teach about ground and terminal security?

This is a summary. Our KA-SAT lessons post covers it in more depth.

According to Viasat's incident overview of 30 March 2022, at about 03:02 UTC on 24 February 2022 high volumes of malicious traffic came from SurfBeam2 and SurfBeam2+ modems and associated customer equipment in Ukraine, served by one consumer oriented partition of the KA-SAT network. From about 04:15 UTC, large numbers of modems across much of Europe left the network over roughly 45 minutes and did not try to come back. Viasat says several thousand customers in Ukraine and tens of thousands of other fixed broadband customers across Europe were affected, and that it shipped nearly 30,000 replacement modems to distributors.

Viasat's account of the mechanism is the instructive part. Its investigation found a ground based intrusion: an attacker exploited "a misconfiguration in a VPN appliance" to reach the trusted management segment, moved laterally to a segment used to manage and operate the network, and then issued legitimate, targeted management commands to many residential modems at once. Those commands overwrote key data in modem flash memory. The modems were not physically damaged and could be restored with a factory reset. Viasat said it found no evidence that the satellite or its ground infrastructure were directly compromised, and no evidence that modem software or firmware images or the normal update process were tampered with. On 10 May 2022, CISA updated advisory AA22-076A to state that the US government attributes the activity to Russian state sponsored actors.

Three lessons generalise:

1. The management plane is the crown jewel. Nothing in the attack required breaking satellite links or cryptography. Access to the system that legitimately manages terminals was enough to disable them in bulk.
2. Remote access appliances are part of the attack surface, not a wall in front of it. A single misconfigured VPN concentrator opened the path. Configuration review, MFA and segmentation behind those appliances matter as much as patching them.
3. Recovery has a physical cost. When thousands of field devices are disabled, restoring them can mean a truck roll or a shipping container of replacements. Plan for that before you depend on a single satellite service for critical sites.

What CISA and NIST guidance exists for satellite and ground segment security?

Here is what each document is for, so you can pick the right one.

CISA AA22-076A in practice

The advisory's "actions to take today" are: use secure methods for authentication, enforce least privilege, review trust relationships, implement encryption, ensure patching and configuration audits, monitor logs, and keep incident response and continuity plans ready. For SATCOM providers it lists specific things to watch at the ingress and egress points of SATCOM equipment: insecure remote access tools such as Telnet, FTP, SSH, SCP and VNC talking to terminals; traffic from SATCOM networks to unexpected segments; unauthorised use of local or backup accounts; unexpected terminal to terminal traffic; internet traffic into closed group SATCOM networks; and brute force logins. Customers are told to use MFA on every account that manages SATCOM services, avoid default and weak credentials, and audit accounts.

NIST IR 8401, 8441 and 8270

IR 8401 maps the Cybersecurity Framework functions (Identify, Protect, Detect, Respond, Recover) to the command and control side: asset inventory of ground systems, access control for operators, protection of telemetry and command data, and recovery planning. IR 8441 handles the more realistic world where a satellite service is stitched together from many parties; its control mappings point to integrity checking of software and firmware and to supply chain references such as SP 800-161 and the Secure Software Development Framework (SP 800-218). IR 8270 is the on ramp: its recommendations for protecting the satellite itself start with secure design and development practices for hardware, firmware, operating system and applications, and point readers to the SSDF.

Space Policy Directive 5

SPD-5, issued on 4 September 2020, sets principles rather than rules. It asks owners and operators to consider, based on risk: protecting command, control and telemetry links with validated authentication or encryption for the whole mission lifetime; protecting against jamming and spoofing; protecting ground systems, operational technology and information systems with practices aligned to the NIST Cybersecurity Framework, including segregation and regular patching; applying hygiene and intrusion detection to elements such as antennas, terminals, receivers and routers; and managing supply chain risk by tracking products and sourcing from trusted suppliers. It also asks operators to share threat, warning and incident information, for example through Information Sharing and Analysis Centers. Terminals and routers are named explicitly, which makes it a useful checklist when you assess a provider.

How should a business use satellite as a backup link?

Most businesses meet satellite internet as a backup or primary link for a remote site: a branch office, a construction compound, a farm, a ship, a field clinic. The decisions that matter are routing, addressing, VPN design and keeping the terminal patched. The walkthrough below uses a Linux edge router because the commands are portable and readable; the same ideas apply to any commercial firewall.

Step 1: know what kind of address you get

Many consumer and some business satellite plans place customers behind carrier grade NAT (CGNAT). RFC 6598 reserves 100.64.0.0/10 as "shared address space" for exactly this use. If your WAN interface gets an address in that range, you have no publicly reachable IPv4 address: inbound connections, port forwards and site to site VPNs that wait for a call cannot reach you over IPv4.

# Show addresses on the satellite-facing interface (here eth1)
ip -4 addr show dev eth1
ip -6 addr show dev eth1

# Is the IPv4 address inside 100.64.0.0/10 (100.64.0.0 to 100.127.255.255)?
python3 -c "import ipaddress,sys; print(ipaddress.ip_address(sys.argv[1]) in ipaddress.ip_network('100.64.0.0/10'))" 100.79.12.34

# Compare with the address the internet sees (use any what-is-my-IP service you trust)
curl -4 -s https://ifconfig.co ; echo
curl -6 -s https://ifconfig.co ; echo

If the WAN address is in 100.64.0.0/10, or differs from what the internet sees, you are behind NAT you do not control. Plans with a public IPv4 address exist but are usually a business tier option; check your provider's documentation. Many satellite services do hand out native IPv6, often a delegated prefix, and that can restore end to end reachability if you firewall it correctly.

Step 2: build failover with route metrics and health checks

The simplest dependable design is two default routes with different metrics, and a health check that removes the primary when it stops passing traffic.

# Primary fibre on eth0, satellite on eth1
sudo ip route add default via 203.0.113.1 dev eth0 metric 100
sudo ip route add default via 192.168.100.1 dev eth1 metric 200

ip route show default

A link can be "up" while the provider upstream is broken, so check reachability beyond the gateway, through each interface separately:

#!/usr/bin/env bash
# wan-check.sh: fail over to satellite if the primary cannot reach two probes
set -euo pipefail
PRIMARY_GW=203.0.113.1
PROBES=("192.0.2.10" "198.51.100.20")   # replace with hosts you control or trust
ok=0
for p in "${PROBES[@]}"; do
  if ping -I eth0 -c 3 -W 2 "$p" >/dev/null 2>&1; then ok=$((ok+1)); fi
done
if [ "$ok" -eq 0 ]; then
  ip route del default via "$PRIMARY_GW" dev eth0 2>/dev/null || true
  logger "wan-check: primary down, satellite carrying traffic"
else
  ip route replace default via "$PRIMARY_GW" dev eth0 metric 100
fi

Run it every 30 seconds from a systemd timer. Add hysteresis (for example, require three good checks before failing back) so a flapping fibre link does not bounce sessions.

Step 3: design the VPN for a NAT on the far side

Because the satellite side may be behind CGNAT, the remote site must dial out to the hub, never the other way round. WireGuard handles this cleanly when the remote peer initiates and sends keepalives so the carrier's NAT mapping does not expire.

# /etc/wireguard/wg0.conf on the remote site router
[Interface]
PrivateKey = <remote-site-private-key>
Address = 10.20.0.2/32
MTU = 1380

[Peer]
PublicKey = <hub-public-key>
Endpoint = vpn-hub.example.com:51820
AllowedIPs = 10.0.0.0/8
PersistentKeepalive = 25

Two details matter on satellite links. First, keep the keepalive: without it, an idle tunnel through CGNAT loses its mapping and the hub cannot reach the site until the site sends something. Second, test the MTU. Encapsulation, plus any tunnelling the provider does internally, can push packets past the path MTU and cause stalls that look like random hangs:

# Find the largest packet that passes without fragmentation (IPv4)
for size in 1472 1452 1432 1412 1392 1372; do
  if ping -M do -s $size -c 2 -W 2 vpn-hub.example.com >/dev/null 2>&1; then
    echo "largest working payload: $size (MTU = $((size + 28)))"; break
  fi
done

Set the tunnel MTU at or below what you measure minus the WireGuard overhead (60 bytes over IPv4, 80 over IPv6).

If you use IPsec instead, enable NAT traversal (UDP 4500) and dead peer detection, and again make the remote site the initiator.

Step 4: steer traffic, do not just fail over

A satellite backup often has a data cap or different cost profile. Policy routing lets you send only the important traffic over it:

# Table 200 uses the satellite link
echo "200 sat" | sudo tee -a /etc/iproute2/rt_tables
sudo ip route add default via 192.168.100.1 dev eth1 table sat
# Point-of-sale VLAN always prefers satellite when the fibre is down; guest Wi-Fi never does
sudo ip rule add from 10.30.0.0/24 lookup sat priority 1000

Combine this with firewall rules that block bulk traffic (backups, OS updates for every laptop, video) from the satellite path during failover, unless you have checked the plan's limits.

Step 5: manage the terminal like a network device

Treat the terminal and its router as infrastructure you own, even though the firmware comes from the operator.

1. Inventory it. Record make, model, serial, account owner, service plan and firmware version for every site. You cannot answer "are we exposed" for a device you do not know you have.
2. Let updates happen, and check they did. Operator terminals typically update over the air. Do not block the terminal's update traffic at your firewall, and check the reported firmware version in the operator's app or portal after any announced update.
3. Lock down the management account. The operator account that controls your terminals is a management plane in exactly the KA-SAT sense. Use MFA, named accounts and least privilege, and remove leavers promptly, as AA22-076A recommends.
4. Put the terminal outside your trusted LAN. Connect it to a dedicated WAN port or VLAN on your own firewall. Do not let devices on the corporate LAN reach the terminal's local management interface unless an administrator needs it.
5. Turn off what you do not use. If you run your own router in bypass mode, disable the operator Wi-Fi so you do not have an extra open access point in the building.
6. Log failovers. Send the health check events and VPN state to your central logs. A link that fails over every afternoon is a capacity problem; a link that fails over when nobody is near the site may be tampering or weather.
7. Plan the bad day. Keep a spare terminal or a different path (cellular, a second satellite provider) for sites that cannot go dark, and test failover once a quarter.

Decision table: choosing the backup design

Common mistakes

• Assuming the satellite is the weak point. The documented large scale incident started at a VPN appliance on the ground. Spend effort on management access, not exotic radio threats.
• Expecting port forwards to work. If the WAN address is in 100.64.0.0/10, inbound IPv4 will not reach you. Design every tunnel to be initiated from the site.
• Skipping keepalives. Idle tunnels through CGNAT die silently. Set a keepalive and monitor tunnel age.
• Ignoring MTU. Stalls on large transfers over an otherwise healthy link are usually MTU problems. Measure and set it.
• Blocking terminal updates. Some firewalls block unknown outbound traffic from the WAN device; that can freeze the terminal on old firmware.
• Sharing the operator account. A shared login with no MFA is the kind of management access CISA told customers to remove.
• Putting the terminal's Wi-Fi on the corporate LAN. It becomes an extra, unmanaged access point inside your trust boundary.
• Testing failover once at install. Links, plans and firmware change. Test on a schedule and after each change.

FAQ

How does satellite internet work in simple terms?

Your terminal sends radio signals to a satellite, which relays them down to a ground gateway connected to the internet. Replies come back the same way. LEO systems hand your connection from satellite to satellite every few minutes and may pass it between satellites by laser.

Why is Starlink latency lower than old satellite internet?

Because its satellites orbit at around 525 to 535 km (per the FCC Gen2 order) instead of 35,786 km. The radio path adds single digit milliseconds rather than about half a second. The operator reported a US peak hour median of 33 ms in March 2024, with the rest coming from scheduling, ground routing and buffering.

How does a flat satellite dish track satellites without moving?

It is a phased array. It shifts the phase of the signal at each small antenna element so the combined beam tilts towards the satellite, and it recomputes those phases continuously from the satellite's predicted position.

Is satellite internet secure?

The radio link and the operator's network can be secure, but your traffic still crosses the operator's ground network and the internet. Use the same protections as on any ISP: HTTPS, a VPN for business traffic, MFA on the operator account and updated firmware. The largest documented incident, KA-SAT in 2022, came through a ground VPN appliance, not the satellite.

Does satellite internet use CGNAT?

Many plans do. If your router's WAN address is in 100.64.0.0/10, the shared address space defined in RFC 6598, you are behind carrier grade NAT and cannot accept inbound IPv4 connections. Check for IPv6 or a public IP option.

Can I run a site to site VPN over satellite internet?

Yes. Have the remote site initiate the tunnel, enable keepalives so the NAT mapping stays open, and measure and set the MTU. WireGuard and IPsec with NAT traversal both work.

What is direct to cell satellite service?

A satellite that talks to ordinary phones in mobile spectrum. 3GPP Release 17 standardised non-terrestrial networks, and the FCC's March 2024 supplemental coverage from space rules let satellite operators use a terrestrial partner's spectrum for this.

Who regulates satellite internet?

The ITU coordinates frequencies internationally through the Radio Regulations and the Master International Frequency Register. National regulators license satellites and earth stations; in the US that is the FCC's Space Bureau under Part 25 of its rules.

Does weather affect satellite internet?

Yes. Heavy rain absorbs higher frequency signals, an effect called rain fade, which is worse in Ka band than Ku band. Snow on a panel can also block the signal. Space weather affects satellites too; see our space weather update.

Where Safeguard fits

Safeguard does not analyse satellite hardware, radio links or terminal firmware, and it cannot patch an operator's terminal or gateway; those fixes come from the operator. Where it does help is the software you build and run around the link: the containers on an edge gateway that run your VPN, monitoring or failover scripts, the services at the hub, and the applications behind them. Safeguard scans repositories, container images and SBOM files for known vulnerabilities in open source components, shows which projects contain a given component and version, ranks findings with reachability analysis, and can open fix pull requests when you switch autonomous remediation on. For location data on mobile devices that use satellite navigation, see our GNSS and location privacy post.

A satellite link does not change how the rest of your stack is built: the edge router image, the VPN containers and the monitoring agents at a remote site all pull open source dependencies, which is why NIST IR 8441 and IR 8270 both point satellite operators to the Secure Software Development Framework. The terminal firmware stays the operator's to fix, so the steps below apply to the software you build and ship around the link, and the fork and patch path among them is early access.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The local runner demo shows setting up the runner on your own machine, approving it with its device code and then scanning from the terminal. The same flow fits an edge gateway build host at a remote site: scan the container images for your VPN and monitoring stack before they ship to sites that only have a satellite link.

Click through it at your own pace, or open it full screen.

The CLI demo is a real session: the assistant reads a finding and its advisory, asks before each command, updates lodash to 4.17.21, runs the install and tests with approval, and pushes nothing. Fixing a vulnerable library in a failover script repository or a hub side service works the same way.

Click through it at your own pace, or open it full screen.

The Claude demo shows connecting Claude to the Safeguard MCP server with OAuth and choosing which tools Claude can use. A network team can then ask which of its edge images carry a given component without leaving the conversation.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard or read the CLI documentation.

Quick check

Sources

• ESA: Types of orbits
• NASA Earth Observatory: Catalog of Earth Satellite Orbits
• FCC 18-38: SpaceX NGSO system authorization, March 2018
• FCC 20-102: Kuiper Systems order and authorization, July 2020
• FCC 22-74: Mitigation of Orbital Debris, Second Report and Order, September 2022
• FCC 22-91: Gen2 Starlink partial grant, November 2022
• FCC 24-28: Supplemental Coverage from Space, Report and Order, March 2024
• FCC Space Bureau
• ITU: Radio Regulations
• ITU-R Space Services Department
• 3GPP: Non-Terrestrial Networks (NTN) overview
• Starlink: Improving Starlink's Latency (March 2024)
• Viasat: KA-SAT Network cyber attack overview (30 March 2022)
• CISA and FBI: AA22-076A Strengthening Cybersecurity of SATCOM Network Providers and Customers
• NIST IR 8401: Satellite Ground Segment
• NIST IR 8441: Cybersecurity Framework Profile for Hybrid Satellite Networks
• NIST IR 8270: Introduction to Cybersecurity for Commercial Satellite Operations
• Space Policy Directive 5: Cybersecurity Principles for Space Systems
• RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space

Last reviewed: 23 October 2026. Constellation sizes, licences and operator figures change often; check the linked FCC orders, ITU records and operator disclosures for the current state.