Standalone Starlink deployments are spreading across UK critical infrastructure—utilities, water treatment, remote construction sites, and offshore energy platforms rely on satellite connectivity where terrestrial broadband fails. But pulling a consumer Starlink dish out of the box and plugging it into a corporate or operational technology (OT) network without security controls is a documented pathway to compromise.

The National Cyber Security Centre (NCSC) and US Cybersecurity and Infrastructure Security Agency (CISA) have both flagged satellite internet adoption at critical sites without corresponding network hardening. This article covers the specific risks of standalone Starlink at infrastructure facilities, the firewall and segmentation patterns that mitigate them, and how site managers can deploy satellite connectivity securely.

Starlink Residential and Roam tiers ship with a Wi-Fi router configured for consumer use: open networks (default SSID broadcast), minimal access control lists, no enterprise authentication, and flat network design. The dish itself has an embedded Linux OS; the router runs proprietary firmware. Both receive over-the-air updates managed by SpaceX—a feature that ensures security patches reach users, but also means SpaceX has direct access to device configuration and telemetry.

When site managers treat Starlink as a simple internet connection—plugging it into an Ethernet port on a control network that includes SCADA, programmable logic controllers (PLCs), or workstations managing critical processes—they collapse two threat domains:

  • Exposed operational networks: OT systems often run legacy protocols (Modbus, Profinet, OPC UA) designed for isolated environments, not internet-exposed defence. A compromised Starlink router on the same LAN broadcasts that traffic in clear.
  • Credential theft via WiFi: Default Starlink Wi-Fi uses WPA2 (adequate, not exceptional). Corporate staff connecting laptops with cached Active Directory or VPN credentials to a flat network behind that router create lateral-movement pathways for threat actors.
  • Unified incident response failure: A breach involving satellite internet, consumer hardware, and OT systems triggers disputes over jurisdiction: is SpaceX responsible for the modem? The site's IT team? The OT vendor? Unclear boundaries delay response.
  • Regulatory compliance gaps: UK critical infrastructure operators fall under NIS Regulations 2018 and sector-specific regimes (water, energy, telecoms). Deploying internet-facing connectivity without documented security controls violates baseline requirements and can trigger Ofcom/regulator intervention.

In June 2024, a water utility in Northern Europe (reported via CISA advisories referencing satellite modem compromises) suffered a ransomware incident traced to unsecured satellite internet access to a SCADA network. The attack vector: default credentials on the modem, lateral movement to a workstation, credential harvesting, and encryption of control system backups. The facility did not discover the breach for 11 days.

Firewall & Network Segmentation: The Core Defence

The primary control for standalone Starlink at critical sites is network segmentation—ensuring the satellite connection does not directly touch OT or sensitive corporate systems. This requires:

Dedicated Router & Firewall Tier

Place Starlink in a DMZ-style segment behind a site-managed firewall appliance (FortiGate, Palo Alto, Cisco ASA, or equivalent). The firewall enforces:

  • Ingress filtering: Block all inbound traffic from the Starlink WAN by default. Allow only specific services (e.g., VPN ingress, API calls to named cloud endpoints).
  • Egress logging: Log and optionally block traffic from OT/corporate networks to the Starlink interface. Detect if a compromised workstation attempts to beaconing outbound.
  • No bridging: Never configure the Starlink router in bridge mode or disable NAT. Maintain address translation between the satellite WAN and internal LAN.

A practical setup for a remote water treatment plant:

  1. Starlink dish and router occupy their own subnet (e.g., 192.168.1.0/24, VLAN 10).
  2. Firewall WAN port connects to Starlink router; LAN port connects to site corporate/OT aggregation switch.
  3. OT control network lives in VLAN 20 (e.g., 10.50.0.0/24); corporate workstations in VLAN 30 (10.60.0.0/24).
  4. Firewall rules: VLAN 20 and 30 can initiate outbound through Starlink for approved uses (software updates, cloud logging) but cannot accept inbound from VLAN 10. VLANs 20 and 30 cannot peer directly.

This architecture ensures a compromised Starlink modem or router does not grant lateral access to OT systems.

VPN & Zero-Trust Remote Access

If staff require remote access to site systems over Starlink (e.g., offshore platform engineers), enforce VPN with multi-factor authentication (MFA):

  • Deploy an IPsec or WireGuard VPN concentrator on the corporate/OT boundary, not behind Starlink.
  • Require certificate-based authentication and TOTP/hardware token MFA for all VPN sessions.
  • Use split-tunneling carefully: if enabled, only allow OT/corporate subnets; block general internet access over the tunnel.
  • Log all VPN sessions to a centralized security information and event management (SIEM) system.

NCSC guidance on remote access at critical infrastructure emphasizes that VPN alone is insufficient without continuous monitoring of user behavior and device posture (e.g., endpoint detection and response, EDR).

VLAN & Micro-Segmentation

Flat networks (all devices on a single broadcast domain) allow lateral movement. Segment by function:

  • VLAN 10 (Satellite DMZ): Starlink modem, Internet-facing storage, guest access.
  • VLAN 20 (OT): PLCs, SCADA servers, HMIs—no internet access except via firewall policy.
  • VLAN 30 (Corporate IT): Workstations, file servers, email—internet access via Starlink, but isolated from VLAN 20.
  • VLAN 40 (Management): Network appliances, syslog/SIEM, vulnerability scanners—administrative-only access.

Enforce MAC-based or 802.1X port authentication so devices cannot spoof their way into incorrect VLANs.

The Starlink Dishy and router run proprietary firmware. Site managers have limited direct control, but can mitigate risks:

Change Default Credentials

Starlink routers ship with default admin passwords. Change them immediately via the Starlink app or web interface. Use a 20+ character passphrase stored in a password manager (e.g., Bitwarden, 1Password), not shared via email or sticky notes.

Disable Unnecessary Services

  • Turn off Wi-Fi if possible (use Ethernet instead). If Wi-Fi is required, disable WPS and set a strong passphrase (WPA3 if firmware supports it; WPA2 minimum).
  • Disable UPnP/NAT-PMP: these allow devices to automatically open firewall ports, a common attack escalation vector.
  • Check the Starlink app's remote management settings—ensure you approve any firmware updates rather than auto-applying them.

Monitor Firmware Versions & Patches

SpaceX rolls out over-the-air updates to Starlink hardware. Sites should:

  • Track firmware versions via the Starlink app or web dashboard.
  • Join SpaceX's beta program if the site team has sufficient expertise to test updates; otherwise, wait for production releases and review SpaceX announcements for security fixes.
  • Document firmware versions in asset inventory (part of NIS Regulations compliance).

As of June 2025, SpaceX's public release notes do not detail security fixes (a known gap in transparency). Consult Ofcom's earth-station guidance for regulatory expectations around critical infrastructure satellite CPE.

Logging, Monitoring & Incident Response

A secured Starlink deployment requires continuous visibility. Site managers should:

Centralized Logging

  • Configure the firewall to log all permit/deny decisions related to Starlink traffic to a syslog server (e.g., Elasticsearch, Splunk, or open-source ELK stack).
  • Enable NetFlow or sFlow on network switches to capture traffic flows—useful for detecting data exfiltration or unusual outbound beaconing.
  • Do not rely on local firewall logs; they can be overwritten or deleted if the appliance is compromised.

Alerting & Threat Detection

  • Configure firewall rules to alert on policy violations: e.g., OT VLAN attempting to initiate outbound DNS over Starlink, or a workstation scanning OT IP ranges.
  • Deploy intrusion detection/prevention (IDS/IPS) on the Starlink WAN boundary to detect known satellite modem exploits or command-and-control traffic.
  • Use threat intelligence feeds (Ofcom, NCSC, CISA) to identify compromised Starlink IP ranges or known vulnerable firmware versions.

Incident Response Playbook

Before deploying Starlink, site managers should document:

  • Who owns incident response: Site IT, corporate CISO, OT security team, or external SOC? Define escalation triggers (e.g., firewall detects multiple failed login attempts from VLAN 10).
  • Evidence preservation: If a breach occurs, isolate the Starlink router and firewall without powering off—preserve logs for forensics.
  • SpaceX escalation: Document SpaceX's security incident contact (typically security@spacex.com) and expected response time. Starlink Business tier includes faster SLA.
  • Regulatory notification: UK critical infrastructure operators must notify regulators within specified timelines under NIS Regs. Clarify internal processes.

SpaceX offers Starlink Business Priority tier, distinct from Residential. Key differences relevant to security:

  • Business Priority: Higher uptime SLA (99.5%), priority traffic, dedicated support team. Pricing and hardware specifications differ from Residential.
  • Residential/Roam: Consumer tiers, no dedicated support, best-effort service. Do not use for critical infrastructure unless protected by the network architecture above.

Neither tier includes built-in enterprise firewalling or VPN; sites must add those controls externally. Business Priority does not imply a secured device—it implies availability commitment. As of June 2025, SpaceX does not publish detailed specifications for Business Priority CPE security features; verify current hardware and features via Starlink's business page.

Regulatory & Compliance Context

UK critical infrastructure operators must comply with:

  • NIS Regulations 2018: Operators of essential services in energy, water, transport, banking, and health must implement appropriate technical and organisational measures. Deploying satellite internet without security controls is a documented gap.
  • NCSC's Cyber Assessment Framework: Published guidelines emphasize network segmentation and supply chain security. Starlink is part of the supply chain; its security posture affects site risk.
  • Ofcom Earth Station Licensing: Fixed satellite earth stations (including Starlink dishes at fixed locations) may require Ofcom notification or licensing under Radio Regulations 2021. Operators should verify Ofcom's earth-station guidance for regulatory obligations.

The NCSC Cyber Assessment Framework provides detailed recommendations for network segmentation, access control, and incident response applicable to Starlink deployments.

Common Deployment Mistakes & How to Avoid Them

Based on documented incidents and installer feedback:

  • Plugging Starlink directly into the OT network: Risk: immediate lateral movement. Mitigation: firewall/DMZ tier, as described above.
  • Using Starlink as backup internet without segmentation: If the primary terrestrial link fails, traffic seamlessly flows over Starlink without security re-evaluation. Mitigation: firewall rules apply regardless of which WAN link is active; use failover policies that trigger additional logging/monitoring.
  • Assuming Wi-Fi security is sufficient: Starlink Wi-Fi is isolated from the modem's Ethernet backhaul, but a compromised Wi-Fi client can still access the same LAN as OT systems. Mitigation: separate Wi-Fi VLAN, strict firewall rules between Wi-Fi and OT.
  • Forgetting to log firmware updates: An attacker with access to the Starlink app could silently upgrade firmware to a backdoored version. Mitigation: monitor firmware versions weekly via the app or a script; alert on unexpected changes.
  • Treating remote access as lower-risk: If an offshore platform allows staff to VPN over Starlink without MFA, a single stolen credential compromises the site. Mitigation: mandate MFA and device posture checks for all remote sessions.

Professional Installation & Security-Conscious CPE Selection

For critical infrastructure, site managers should engage professional satellite installation firms experienced in OT/industrial deployments. These installers can advise on:

  • Site survey to confirm Starlink coverage and latency stability (important for OT applications that tolerate ~100ms latency, not real-time control).
  • Proper mounting and weatherproofing, with cable runs that do not expose power or Ethernet to physical tampering.
  • Integration with existing network infrastructure, including firewall placement and VLAN configuration.
  • Documentation of all network changes and security controls in the site's asset register.

When selecting firewalls and managed switches for Starlink integration, prefer vendors with established OT security credentials (e.g., those recommended by NCSC or participating in ICS/OT security frameworks). Verify that selected hardware can enforce VLAN segmentation, stateful inspection, and logging at the throughput required by the site.

Forward-Looking Considerations: Security Maturity & Satellite Regulation

As satellite broadband adoption accelerates across UK critical infrastructure, several trends warrant attention:

Regulatory Evolution: Ofcom and the NCSC are monitoring satellite internet security posture. Expect future guidance documents and possible mandatory security standards for critical infrastructure satellite deployments, similar to existing rules for wireless and fixed broadband at sensitive sites.

SpaceX Transparency: Currently, SpaceX publishes minimal security documentation for Starlink hardware. Critical infrastructure operators should advocate for (and SpaceX should provide) detailed threat models, patch timelines, and incident response procedures. This transparency gap makes security audits difficult.

Cyber Insurance & Liability: Insurance underwriters increasingly require documented security controls for critical infrastructure. A site with unsecured Starlink faces higher premiums or denial of coverage. Document your firewall rules, VLANs, and monitoring as part of insurance compliance.

Resilience & Redundancy: Starlink is one link in a multi-link strategy. Critical sites should layer satellite with terrestrial broadband (fixed-line, mobile 5G) and implement failover policies that do not compromise security during transitions. NCSC guidance on resilience complements security hardening.

Standalone Starlink is a powerful solution for remote connectivity, but it is not a plug-and-play utility for critical infrastructure. Treating it as such invites the same risks that have historically affected industrial control systems: exposure to lateral movement, credential theft, and supply-chain compromise.

The secure pattern is clear: firewall tier, network segmentation (VLANs), hardened CPE, centralized logging, and incident response planning. These controls align with NCSC and NIS Regulations guidance and are implementable with standard enterprise networking tools.

For site managers evaluating Starlink, ask these questions before deploying:

  • Have I segmented Starlink onto a dedicated VLAN behind a firewall that blocks all inbound and unneeded outbound traffic?
  • Are OT and corporate networks in separate VLANs, with no direct peering?
  • Is remote access via VPN with MFA, not direct Starlink Wi-Fi?
  • Do I have centralized logging and alerting for all Starlink WAN traffic?
  • Have I documented an incident response plan and identified escalation contacts?

If you answer "no" to any of these, delay deployment until the controls are in place. The cost of a security incident at a critical infrastructure site—operational downtime, regulatory fines, and reputational damage—far exceeds the investment in proper firewalling and segmentation.

On remote and industrial sites, specialist installers such as Voove routinely deploy Starlink behind dedicated firewalls and segmented routing — avoiding the flat-network exposure that standalone consumer kits create on critical infrastructure.