Satellite Internet Security: Running LEO Broadband Safely at Business Sites

Low Earth orbit (LEO) broadband such as Starlink is now plugged into business networks faster than security teams can review it, often by a site manager with a credit card and a mobile app. A terminal on a roof can become a second internet edge that bypasses the firewall, the proxy and the logging the rest of the estate relies on. This guide covers the business side of satellite internet: who owns and manages the terminals, how to place the service in the network so it is treated as untrusted transport, how to run it at remote and temporary sites, and how to detect unofficial installations. It is written for network, security and infrastructure teams in organisations that use LEO links for primary, backup or temporary connectivity. Satellite operator, ground segment and satellite IoT topics are covered in the Satellite IoT and Satellite Communications Security Guide and are not repeated here.

Product details in this guide come from Starlink's public installation and router setup guides as of November 2026. Other LEO and GEO services have their own hardware and management tools, so confirm settings against your provider's current documentation.

Practice recommendations in this guide (network patterns, rollout timings, metrics and targets) are NHI Mgmt Group recommendations; regulatory and incident details are attributed to the sources linked in the text, as checked in November 2026. Confirm against the official text before relying on it.

Key takeaways

• Treat the satellite link as untrusted transport. Terminate it on your own firewall or SD-WAN edge, never directly on a user or OT network, and send business traffic through an encrypted tunnel or your secure web gateway.
• Put the provider account under corporate identity control. The mobile app account that manages terminals is an administrative identity: register it to a shared mailbox, protect it with strong authentication and keep an owner and a deputy.
• Inventory every terminal as a network edge. Record serial numbers, site, account, router mode and which firewall it connects to, and reconcile that list with billing every month.
• Design failover so it does not lower the bar. When the primary circuit fails, the satellite path must apply the same filtering, logging and segmentation, not a flat "just get online" configuration.
• Hunt for shadow terminals. Unofficial dishes bought locally create unmanaged exits; expense data, egress IP ranges and wireless surveys find them.

Why LEO broadband changes the edge

Traditional satellite services were bought centrally, installed by specialists and managed by a network team. LEO consumer and business kits arrive in a box, work within minutes and are managed from a phone. That convenience is the security problem: the device that decides how a site reaches the internet is often configured by someone outside IT, with a personal account and the provider's default router settings.

Three properties matter for defenders:

• It is a separate internet edge: traffic leaves through the satellite provider's network and appears on the internet from the provider's address ranges, not your own. Controls attached to your corporate egress IPs, such as allowlists in SaaS tenants, do not see it unless traffic is routed back through your gateway.
• The kit includes its own router and WiFi: Starlink's enterprise kit guide prompts the user to set a new network name (SSID) and password, a step it describes as optional but recommended. A site that skips this step keeps the provider's default WiFi settings next to the business LAN.
• Management sits in a cloud app: statistics, terminal settings, alerts, outages and obstruction checks are handled through the Starlink App, so control of the account equals control of the service.

The KA-SAT incident of 24 February 2022 shows why the management plane deserves the same care as the data plane. Viasat's overview reports that an attacker used a misconfigured VPN appliance to reach the trusted management network, then issued legitimate management commands that overwrote flash memory on tens of thousands of residential modems, and that Viasat shipped nearly 30,000 replacement modems to distributors. Customers had no control over the provider side; in our view a second, independent path is the main customer-side mitigation for that kind of event. The operator view of that incident is in the satellite communications guide linked above.

Ownership, accounts and terminal management

Most early LEO deployments fail on governance before they fail on technology. Decide who may order, who owns the account and who may change settings before the first terminal arrives.

The account is a privileged identity even though it lives in a consumer-style app. Apply the same joiner, mover and leaver discipline as for any other administrative login, and review who can sign in at least quarterly. See the Privileged Access Management Guide for the wider model.

Network design: where the terminal plugs in

The single most important decision is what the satellite kit is allowed to touch. The provider router is designed for homes and small offices; a business site needs its own firewall or SD-WAN edge between the satellite service and anything you care about.

Router modes

Segmentation rules

• Untrusted zone: place the satellite WAN in its own firewall zone with deny-by-default inbound and an explicit outbound policy, as you would for any broadband circuit (NIST SP 800-53 SC-7 and SC-7(5)).
• No direct attachment: never connect the provider router or terminal to an OT, payment or building management network. If an industrial site needs satellite backhaul, route it through the OT DMZ firewall. See the Manufacturing Identity and OT Access Guide for remote access into OT.
• Tunnel business traffic: carry corporate traffic over IPsec or the SD-WAN overlay to your hub or security service edge, so inspection, DNS filtering and logging are the same as on the primary circuit. See the SD-WAN Security Guide.
• Guest and crew traffic: where a site offers internet to visitors, crews or residents over the satellite link, give them a separate VLAN or SSID that exits locally and cannot reach business systems.
• Management access: allow access to the terminal's local management address only from a named management host or jump box, and log it.
• No inbound exposure: do not publish services from the site over the satellite link; use outbound-only tunnels or a cloud relay for remote support.

Primary, backup or temporary: decision guidance

How you use the link changes which controls matter most.

Small organisations: a single business-grade firewall in front of the kit, a corporate account with strong sign-in and a written list of terminals covers most of the risk. Large estates: integrate satellite as one more SD-WAN transport with central policy, tie the provider accounts into joiner and leaver processes, and feed terminal and failover events into the SOC. Telecommunications diversity is a contingency planning control in its own right (NIST SP 800-53 CP-8 and CP-8(2)), so record which sites rely on satellite as their only path.

Remote and unattended site risks

Satellite links are most common where nobody from IT visits. That raises physical and operational risks that office networks rarely face. The Branch, Remote and Temporary Site Security Guide covers the general case; the satellite-specific points are below.

• Physical access: the dish, cable and power supply are visible and reachable. Starlink's enterprise guide notes that mounts are not designed for high winds and require tethering; plan for theft and weather too, and keep the router and firewall in a locked cabinet (NIST SP 800-53 PE-3).
• Unauthorised hardware: an attacker or contractor can plug a device into an exposed Ethernet run between the power supply and router (ATT&CK T1200 Hardware Additions). Use cabinet locks, port security and alerts on new MAC addresses at the firewall.
• Remote support paths: engineers often add remote desktop or vendor access tools to reach equipment at satellite sites. These are external remote services (ATT&CK T1133); route them through your remote access platform with MFA and session logging.
• Service loss: obstruction, weather, power loss or provider outage all look the same to the site. Keep a local log buffer on the firewall, define what operations continue offline, and test that the site degrades safely. Network denial of service (ATT&CK T1498) is one cause among many, so treat availability as a design requirement rather than an attack scenario only.
• Interception on local WiFi: a weak or default provider SSID invites adversary-in-the-middle attacks on the local network (ATT&CK T1557). Disable provider WiFi when your own access points serve the site, and require WPA3 where you keep it. See the WPA3 Migration and Transition Mode Guide.

Where identity fits

Satellite internet introduces three identities that usually escape review. The first is the provider account in the mobile app, covered above. The second is the set of machine credentials on the site firewall or SD-WAN appliance that establish tunnels back to the hub: certificates or pre-shared keys that should be unique per site, stored centrally and rotated, and revoked when a kit is lost. The third is any API or service account used to pull telemetry from the provider into monitoring tools; give it read-only scope, store the token in a secrets manager and record an owner. See the Secrets Management Guide for storage and rotation patterns.

Implementation steps

1. Discover what you already have. Search expense and purchasing data for satellite kits and subscriptions, ask regional managers, and look for traffic from the provider's address ranges in SaaS sign-in logs.
2. Set policy. Publish a short standard: who may order, approved kit types, mandatory firewall, account ownership, and that terminals may not connect to OT or payment networks.
3. Consolidate accounts. Move terminals into corporate accounts with shared mailboxes, turn on the strongest sign-in protection available and remove personal accounts.
4. Build a standard site kit. Terminal, power, a firewall or SD-WAN edge with a prebuilt tunnel profile, and documented router mode. Test it in a lab, including a factory reset, before shipping.
5. Pilot at two sites. One primary and one backup deployment. Confirm that traffic exits through your gateway, that logs reach the SIEM, and that failover applies the same rules.
6. Roll out by risk. Fix sites where a terminal touches OT or payment networks first, then primary-link sites, then backups.
7. Plan rollback. Keep the previous firewall configuration exported and a documented path to return a terminal to the provider router (for Starlink bypass mode, a factory reset), so a failed change at an unattended site can be reversed remotely or by a local contact following a script.
8. Operate. Monthly reconciliation of terminals, accounts and billing; quarterly failover test and account access review.

Detection and measurement

Most satellite risks show up in data you already collect. Monitor for:

• Sign-ins from provider address ranges: corporate users authenticating to SaaS or identity providers from satellite provider egress ranges at sites that should tunnel traffic indicate either a split tunnel or a shadow terminal.
• Failover events: SD-WAN or firewall alerts when a site switches to the satellite path, with the policy applied.
• New WAN gateways or DHCP servers: a provider router appearing on a LAN segment, seen through DHCP snooping or network access control alerts.
• Wireless surveys: SSIDs matching provider defaults at business premises.
• Account activity: changes to router mode, WiFi or service plan in the provider account, where the provider exposes them.

See the Networking Fundamentals for Defenders Guide for how NAT and flow logs affect what you can see at a double-NAT site.

Framework mapping

NIST IR 8441, the Cybersecurity Framework Profile for Hybrid Satellite Networks, applies the same framework to the wider satellite system and stresses the interfaces between independently owned components, including user terminals; use it when you need to argue requirements with a provider.

Common failure patterns

• Terminal on a personal account: the site manager who set it up leaves, and nobody can change the WiFi password or cancel the service.
• Provider router plugged straight into the LAN: the site gains a second default gateway and an exit with no filtering, logging or DLP.
• Failover profile that drops inspection: to make backup "just work", the satellite path sends traffic straight out, so attacks during an outage go unseen.
• Satellite link on the OT network: a plant installs a dish to give a vendor remote access to a controller, creating an unmonitored path into OT.
• Default WiFi left on: the provider SSID broadcasts alongside the corporate network with a weak or shared password.
• No single point of failure review: several critical sites rely on one provider as both primary and backup, so a provider-side event like KA-SAT takes them all offline together.

Practitioner checklist

• Publish a satellite internet standard covering ordering, account ownership, approved kits and prohibited connections.
• Move every terminal to a corporate account on a shared mailbox with the strongest available sign-in protection and a named owner and deputy.
• Record each terminal's serial, site, router mode and upstream firewall, and reconcile monthly with billing.
• Terminate the satellite link in an untrusted firewall zone and tunnel business traffic to your inspection point.
• Disable or harden provider WiFi and keep guest or crew traffic on a separate network.
• Restrict access to the terminal's local management address to a named management host.
• Use unique, centrally stored tunnel credentials per site and revoke them when a kit is lost.
• Test failover quarterly and confirm the same policy and logging apply on the satellite path.
• Hunt for shadow terminals using expenses, provider egress ranges in sign-in logs and wireless surveys.
• Track provider security updates and include the provider in supplier risk reviews.

Standards and references

• NIST: IR 8441 Cybersecurity Framework Profile for Hybrid Satellite Networks
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• CIS: Critical Security Controls v8.1
• Starlink: Enterprise Kit Installation Guide
• Starlink: Gen 3 Router Setup Guide
• Viasat: KA-SAT Network Cyber Attack Overview
• MITRE ATT&CK: Hardware Additions

Related NHI Mgmt Group resources: Satellite IoT and Satellite Communications Security Guide · Branch, Remote and Temporary Site Security Guide · SD-WAN Security Guide · Space and Satellite Cybersecurity Guide