Your organization's private cellular network isn't a security perimeter. It's a highway between your facilities, and if you're treating it as trusted infrastructure, you've already failed a critical control assumption.
An investigation by CERT Polska into a December attack on a Polish heat plant revealed something most GRC leaders haven't addressed: attackers moved from compromised wind farm firewalls to a cellular router, then across a private cellular network to reach a heat plant controller still running factory-default credentials. The entire attack path exploited the assumption that private cellular networks are inherently secure.
This checklist helps you audit private cellular networks connecting your operational technology, distributed energy sites, or industrial control systems. If you're relying on these networks to connect remote facilities, verify every item below.
Prerequisites
Before starting this audit, confirm you have:
- Complete network topology documentation showing all devices connected to private cellular networks, including routers, controllers, and gateways.
- Administrative access to cellular routers, firewalls, and industrial controllers on these networks.
- Vendor contact information for cellular network providers and equipment manufacturers.
- Current configuration baselines for all network devices. If you don't have these, creating them is your first task.
Security Audit Checklist
1. Map All Private Cellular Network Connections
Done when: You have a verified diagram showing every device with cellular connectivity, which facilities they connect to, and what other devices they can reach on the same network.
Document routers at wind farms, substations, remote monitoring stations, and any facility using cellular for operational data. The Polish investigation found attackers moving between unrelated facilities on the same private network. Your map must show these lateral movement paths.
What good looks like: A network diagram that reveals cross-facility connectivity risks, with clear segmentation boundaries marked and documented.
2. Verify No Device Uses Factory-Default Credentials
Done when: You've confirmed through login testing or configuration review that every cellular router, industrial controller, and network device has unique, non-default credentials.
The heat plant controller compromised in Poland was still running factory-default login credentials. CERT Polska warned this misconfiguration was common across Poland and likely widespread internationally. Check Siemens controllers, cellular routers, and any device on these networks.
What good looks like: A spreadsheet listing every device, its credential change date, and the person who verified it, with no exceptions.
3. Implement Network Segmentation Controls
Done when: Devices on your private cellular network cannot communicate freely with all other devices. You've implemented firewall rules or VLANs that restrict lateral movement.
The attack succeeded because any device on the private cellular network could reach any other device. This is the architectural flaw you're fixing. Apply the same segmentation you'd use for internet-facing networks.
What good looks like: Firewall rules that permit only necessary traffic between specific source and destination pairs, with all other traffic denied by default. Test by attempting unauthorized connections between facilities.
4. Remove Cellular Networks from Trusted Zones
Done when: Your firewall policies, access control lists, and security monitoring treat private cellular connections as untrusted, equivalent to internet connections.
CERT Polska explicitly called for organizations to "stop treating private cellular networks as trusted infrastructure." This means cellular-connected devices sit outside your trust boundary and require authentication, encryption, and monitoring.
What good looks like: Cellular network interfaces classified in your firewall as "external" or "untrusted" zones, requiring VPN or other authentication for access to internal systems.
5. Enable and Centralize Logging for All Network Devices
Done when: Every cellular router, firewall, and controller sends logs to a central SIEM or log management system, and you've verified log retention through a test factory reset.
Investigators only reconstructed the Polish attack because one router ran older software that preserved event logs through a factory reset. The attackers wiped configurations and corrupted devices to destroy forensic evidence. Your logging must survive device compromise.
What good looks like: Logs flowing to an external system within minutes of generation, with a tested backup process and retention period matching your incident response requirements (minimum 90 days for most frameworks).
6. Include Cellular Networks in Penetration Testing Scope
Done when: Your next scheduled penetration test explicitly includes private cellular network infrastructure, with testers attempting lateral movement between facilities.
These networks have been invisible to most security testing programs. Add them to your scope for both external penetration tests and red team exercises. Test whether an attacker who compromises one facility can reach others.
What good looks like: A penetration test report that documents attempted lateral movement across cellular networks, identifies reachable devices, and validates your segmentation controls.
7. Establish Reporting Requirements for Unexplained Disruptions
Done when: Your incident reporting policy requires notification of operational disruptions even when the cause is unclear, and your Computer Security Incident Response Team reviews these reports for potential security implications.
The heat plant attack was initially blamed on contractor error during routine maintenance. It was only reported for informational purposes, but CERT Polska's investigation of this low-priority report uncovered the attack. Your reporting threshold must be low enough to catch these signals.
What good looks like: An incident reporting form that captures operational disruptions separately from confirmed security incidents, with a defined review process and escalation criteria. Track unexplained failures during maintenance windows, especially.
Common Mistakes
Assuming vendor-managed networks are vendor-secured: Your cellular provider manages connectivity, not security architecture. Segmentation, access control, and monitoring remain your responsibility.
Treating private networks as air-gapped: Private cellular networks connect to the internet for management and may share infrastructure with other customers. They're not isolated.
Skipping cellular infrastructure in compliance audits: ISO/IEC 27001 Annex A 8.20 (network security) and NIST Cybersecurity Framework (CSF) 2.0 2.0 PR.AC-5 (network segmentation) both apply to these networks. If your SOC 2 Type II audit doesn't cover them, your scope is incomplete.
Delaying remediation until the next maintenance window: The Polish attackers spent 11 days conducting reconnaissance before striking. Default credentials and missing segmentation are active vulnerabilities.
Next Steps
Start with items 1, 2, and 5, mapping, credentials, and logging. These create immediate visibility and close the most exploitable gaps. Schedule penetration testing that includes cellular networks within the next quarter.
If your organization operates distributed energy sites, industrial control systems, or any remote facilities connected via private cellular networks, this audit should be complete within 30 days. The assumption that these networks are secure is now a documented control failure.
