Satellite IoT and Satellite Communications Security Guide: Ground Stations, Terminals and Links

Satellite communications are now ordinary infrastructure for remote sites, ships, aircraft, utilities and IoT fleets, yet the most damaging attack on them so far came through a misconfigured VPN and a management network, not through space. The Viasat KA-SAT incident of February 2022 disabled tens of thousands of terminals across Europe in about an hour by abusing trusted management access on the ground. This guide covers the satellite system segments, ground station and network operations centre security, terminal and modem firmware, link protection, satellite IoT including LoRaWAN over satellite and 3GPP direct-to-device services, supplier and service management, detection, and recovery. It is written for security teams at organisations that buy or operate SATCOM services, satellite operators and service providers, and OT and IoT engineers who depend on satellite backhaul. It complements, and does not repeat, the broader Space and Satellite Cybersecurity Guide.

Key takeaways

• The ground segment is the main attack surface. Operations centres, VPN gateways, terminal management systems and cloud ground stations are conventional IT, and they hold the power to command every terminal in a fleet.
• Terminals are edge devices with firmware. Satellite modems and user terminals need secure boot, signed updates, locked-down management interfaces and an inventory, just like routers.
• Fleet-wide management commands are a single point of failure. KA-SAT showed that a bulk command path, once abused, can disable a whole customer base faster than any response team can react.
• Satellite IoT inherits IoT weaknesses with less bandwidth to fix them. Constrained links make over-the-air updates and frequent key rotation expensive, so design security in before devices ship.
• Plan to operate without the satellite link. Treat SATCOM as a dependency with a failure mode, with tested fallbacks and a recovery plan that includes replacing terminals at scale.

Segments and where they fail

Satellite systems are usually described in segments. NIST's work in this area reflects the same structure: NIST IR 8401 applies the Cybersecurity Framework to the ground segment and satellite command and control, NIST IR 8441 is a CSF profile for hybrid satellite networks whose components are owned and operated by different parties with uneven security maturity, and NIST IR 8270 is an introduction to cyber risk management for commercial satellite operators.

The practical lesson is that most organisations buying SATCOM control only part of the user segment and their own traffic. Everything else depends on the provider, so contract terms and assurance evidence matter as much as technical controls.

Lessons from the KA-SAT incident

Viasat's own incident overview gives the sequence. The attack began at about 03:02 UTC on 24 February 2022, when malicious traffic was seen from modems in Ukraine; at about 04:15 UTC tens of thousands of modems across Europe dropped off the network. Forensic analysis found that the attacker exploited a misconfiguration in a VPN appliance to gain remote access to the trusted management segment, moved laterally to the segment used to manage and operate the network, and used that access to send management commands to large numbers of residential modems at once. The commands overwrote key data in modem flash memory, leaving the modems unable to reach the network. Viasat states it found no compromise of hardware or firmware, and that affected modems could be restored by a factory reset, but it still shipped nearly 30,000 replacement modems to distributors to restore service.

The European Union, in a declaration on 10 May 2022, attributed the operation to the Russian Federation and noted that it took place one hour before the full-scale invasion of Ukraine and affected public authorities, businesses and users in Ukraine and several EU Member States. SentinelLabs researchers reported a wiper they named AcidRain, designed for modems and routers, linked it to the KA-SAT outage and to spillover effects including about 5,800 wind turbines in Germany losing remote monitoring, and assessed with medium confidence that it shares development traits with an earlier VPNFilter component. That technical link is the researchers' assessment.

• Remote access was the way in: a VPN misconfiguration, not a satellite vulnerability. See the VPN Security Guide.
• Flat trust inside the management network: once inside, the attacker reached the systems that command the fleet.
• Bulk commands without guard rails: nothing slowed or stopped a command that affected an unusually large number of terminals.
• Downstream users were not the target but were hit: industrial operators using the service for remote monitoring lost visibility. That is why SATCOM belongs in OT and IoT dependency maps; see the OT Security Guide.

Shortly after the incident, CISA and the FBI issued a joint advisory urging SATCOM network providers and their customers to strengthen security, covering items such as securing remote access, enforcing least privilege, reviewing trust relationships and monitoring for unusual traffic.

Ground station and network operations security

Ground systems run on standard servers, network gear and software, and are reached through the same remote access tools as any enterprise. Treat them as critical OT-like environments.

• Remote access: no direct internet exposure of management interfaces; VPN or zero trust access with phishing-resistant MFA; configuration reviewed against a hardened baseline and change-controlled. Remove vendor and contractor access that is not in use.
• Segmentation by function: separate corporate IT, the NOC, terminal management, TT&C and customer-facing portals. Allow only defined flows between them, and log denied traffic. See the Network Segmentation Guide.
• Command authorisation: require two-person approval for satellite commanding and for any terminal management action above a defined scope (for example, more than a set number of terminals or a whole beam). Rate-limit bulk operations and stage them, so a malicious command reaches a small group first.
• Physical security: teleports and TT&C sites are often remote; protect equipment rooms, antenna control systems and spares.
• Ground-station-as-a-service: managed services let operators schedule contacts and process satellite data without owning antennas (AWS Ground Station describes itself as a fully managed service for controlling satellite communications and processing satellite data). The cloud account then becomes part of the ground segment, so its roles, API keys and data endpoints need the same privileged access control as an operations centre. See the Device and IoT Identity Guide for machine credential handling.
• Backups and gold images: keep offline copies of NOC configurations, terminal management databases and terminal firmware, so a wiper or ransomware does not prevent rebuilding.

Terminal and modem firmware security

User terminals combine an RF front end, a modem and an embedded computer, usually running a Linux-based system. They are frequently deployed in places nobody visits, such as offshore platforms, pipelines and ships, so a compromised or bricked terminal can stay that way for weeks.

For deeper coverage of boot chains and signing keys, see the Firmware and Boot Security Guide; for the wider device lifecycle, see the Edge Device Security Guide.

Link protection: encryption, jamming and spoofing

• Encrypt user traffic end to end: do not rely on the satellite link for confidentiality. Use IPsec or TLS between your sites and applications, so traffic stays protected even if the space or ground segment is compromised.
• Protect command links: satellite TT&C links should use authenticated and encrypted commanding with anti-replay protection. The CCSDS Space Data Link Security protocol is the common standard for this in space data links; ask operators whether command authentication is in place for the vehicles you depend on.
• Plan for interference: jamming and GNSS interference affect both satellite links and the location and timing data many terminals depend on. Monitor link quality and position data for anomalies, and know how your systems behave when timing or position is lost.
• Diversity: where availability matters, use more than one path (terrestrial plus satellite, or two satellite providers on different orbits or bands).

Ships and remote energy sites are where these risks concentrate; see the Maritime Cybersecurity Guide.

Satellite IoT: LoRaWAN over satellite and direct-to-device

Satellite IoT connects sensors and trackers that are beyond terrestrial coverage. Two broad models exist, and they change who holds the security controls.

• Constrained bandwidth: links may carry only small messages at intervals, so firmware updates must be small, resumable and signed, and devices must validate them before applying.
• Identity per device: unique keys or SIM credentials per device, never a shared fleet key, with a way to revoke a single device. See the Device and IoT Identity Guide.
• Back-end exposure: the network server, device management platform and their APIs are reachable from the internet and are where fleet-wide compromise happens. Protect API keys and service accounts, and alert on bulk configuration changes. See the IoT Security Guide.
• Data trust: location and timing from GNSS can be spoofed; for safety or billing decisions, use the network-verified location features where available, or plausibility checks.

Supplier management and information sharing

• Know your chain: a SATCOM service may involve a satellite operator, a wholesale capacity provider, a service provider or reseller, a terminal manufacturer and a cloud ground provider. Map them and who can reach your terminals.
• Contract for security: incident notification times, right to audit or receive assurance reports, control over fleet-wide commands affecting your terminals, firmware support periods and replacement commitments at scale.
• Share intelligence: Space ISAC provides information sharing for the space sector, including a watch centre and membership options for corporations, small businesses, research labs and academia. ENISA's Space Threat Landscape (March 2025) covers threats across the satellite lifecycle from development to decommissioning.

See the Third-Party Risk Management Guide.

Detection and measurement

• Ground systems: authentication logs for VPN and management systems, privileged session recording for NOC tools, and alerts on new accounts, configuration changes and unusual access times.
• Terminal management: log every command with operator identity and scope; alert when a command targets more terminals than a threshold, or when terminals drop off in large numbers.
• Traffic from terminals: unusual outbound traffic from modems towards the management network, as Viasat observed before the outage.
• Link health: signal quality, interference reports and GNSS anomalies.

Metrics:

1. Percentage of terminals with known model, firmware version and owner in the asset inventory.
2. Percentage of terminals on a supported firmware version with secure boot enabled.
3. Percentage of ground management access protected by phishing-resistant MFA.
4. Number of bulk terminal commands executed without second-person approval (target: zero).
5. Time to restore service at a remote site after terminal loss, measured in exercises.
6. Percentage of satellite-dependent sites with a tested alternative communications path.

Implementation roadmap

1. Inventory (month 1): list every satellite service, provider, terminal model, firmware version, management interface and the business processes that depend on each link.
2. Close exposure (months 1 to 2): remove internet-facing terminal management, change default credentials, apply current firmware, and review VPN configurations for ground and NOC access.
3. Segment and gate (months 2 to 4): separate management networks, introduce approval and staging for bulk commands, and pilot changes on a small terminal group before the fleet.
4. Contract (months 2 to 6): add security terms to SATCOM contracts at renewal, and request assurance evidence from providers.
5. Exercise recovery (months 4 to 6): run a scenario where a fleet of terminals is bricked: who notices, how sites communicate, where spares are, how long replacement takes. Hold spare terminals or a replacement agreement for critical sites. Roll back changes through the staged groups if a firmware or configuration push causes faults.
6. Review annually: repeat the inventory, update dependency maps and retest fallbacks.

Decision guidance

• Enterprise SATCOM customers: focus on what you control: end-to-end encryption, terminal hardening, local network segmentation, fallbacks and contracts. You cannot secure the provider's NOC, but you can require evidence.
• Service providers and operators: prioritise management network segmentation, command authorisation, terminal firmware integrity and a recovery partition design; align with NIST IR 8401 for ground operations.
• Satellite IoT fleets: decide early between LoRaWAN-style and 3GPP NTN models based on who must hold the keys and how updates will be delivered; small fleets can rely on platform defaults, large fleets need their own key management and revocation.
• Critical infrastructure users: treat SATCOM as a single point of failure unless you have tested diversity.

Common failure patterns

• Misconfigured remote access to management networks: the KA-SAT entry point.
• Fleet-wide commands without limits: one compromised operator account can disable every terminal.
• Terminals missing from the asset inventory: often bought by operations or facilities teams, never patched and with management interfaces open.
• Relying on the satellite link for confidentiality: user traffic sent unencrypted on the assumption that the link is private.
• No plan for mass replacement: recovery assumes remote fixes, but bricked terminals at unattended sites need physical work.
• Shared keys across IoT devices: a key extracted from one device compromises the fleet.

Framework mapping

Practitioner checklist

• Inventory every satellite terminal, its firmware version, provider and dependent business process.
• Confirm no terminal or ground management interface is reachable from the internet.
• Require phishing-resistant MFA and segmented networks for all ground and NOC management access.
• Require approval, staging and rate limits for bulk terminal commands.
• Verify secure boot, signed updates and a protected recovery image on terminal models in use.
• Encrypt user traffic end to end rather than relying on the satellite link.
• Use unique per-device keys or SIM credentials for satellite IoT devices, with single-device revocation.
• Add security, notification and replacement terms to SATCOM contracts.
• Test a scenario of mass terminal loss, including spares and alternative communications.

Standards and references

• NIST: IR 8401 Satellite Ground Segment: Applying the Cybersecurity Framework to Satellite Command and Control
• NIST: IR 8441 Cybersecurity Framework Profile for Hybrid Satellite Networks
• NIST: IR 8270 Introduction to Cybersecurity for Commercial Satellite Operations
• 3GPP: Non-Terrestrial Networks Overview
• ENISA: Space Threat Landscape
• Viasat: KA-SAT Network Cyber Attack Overview
• Council of the EU: Declaration on Russian cyber operations against Ukraine
• SentinelLabs: AcidRain, a Modem Wiper Rains Down on Europe

Related NHI Mgmt Group resources: Space and Satellite Cybersecurity Guide · IoT Security Guide · OT Security Guide · Device and IoT Identity Guide · Incident Response Guide