FMS Network Security

FMS Network Security

How to segment, monitor, and defend FMS environments against the threats covered in the Cybersecurity for Mining FMS overview.

The Legacy Architecture Problem

A site IT manager opens a firewall audit report and finds 47 rules that nobody can explain. Half were created during the FMS go-live three years ago. None have been reviewed since.

Most FMS platforms trace their architectural roots to the late 1990s and early 2000s. Modular Mining’s DISPATCH has lineage going back to the 1970s. “Network security” meant a locked comms room and an isolated site network.

Running services with elevated privileges, flat network topologies, shared credentials on equipment, open port ranges between modules. None of this was unreasonable when the systems lived behind a physical air gap with no internet connectivity.

ERP integration, cloud analytics, vendor remote support, mobile devices, and autonomous haulage have all dissolved what used to be a hard boundary. But the underlying FMS architectures were not redesigned for this new reality. They were extended, incrementally, over decades, through integration layers, VPN tunnels, and API gateways bolted onto architectures that assumed implicit trust.

This is not a vendor failing. It is a historical reality. Demanding that a vendor retrofit modern security architecture into a production system that has evolved over 25 years is not realistic without a ground-up rewrite. The practical consequence is that compensating controls, network segmentation, and monitoring sit primarily with the mine operator and their IT/OT teams.

FMS and the Purdue Model

The Purdue Enterprise Reference Architecture segments industrial networks into hierarchical levels. In a strict implementation, each level communicates only with its immediate neighbours. FMS architectures routinely violate this hierarchy.

Purdue Level	Function	Standard Mining OT	FMS Component
Level 0	Physical process	Motors, actuators, hydraulic valves	Engine control units, steering actuators (below the FMS network boundary; FMS does not interact directly with Level 0)
Level 1	Intelligent devices	PLCs, RTUs, basic sensors	GPS/GNSS receivers, payload sensors, tyre pressure monitors, onboard telemetry gateways (FMS network boundary starts here)
Level 2	Local control	HMIs, operator panels	In-cab ruggedised tablets running FMS client software, machine guidance interfaces
Level 3	Site operations	MES, local historians	FMS dispatch engine, central database, site reporting servers
Level 3.5	Industrial DMZ	Security buffer, proxies, jump hosts	Firewalls, application proxies, forward/reverse web proxies terminating IT/OT connections
Level 4/5	Enterprise IT	ERP, email, cloud analytics	Mine planning software (Deswik, Maptek), SAP/ERP integration, cloud-hosted predictive maintenance

The Cross-Level Spanning Problem

An onboard vehicle gateway (Level 1/2) streams geospatial data, payload metrics, and telematics over wireless mesh directly to a dispatch server at Level 3. That dispatch server continuously exchanges production tallies, maintenance fault codes, and personnel rostering with ERP systems at Level 4 or cloud environments at Level 5.

This cross-level integration requires firewall transversals that punch holes through the iDMZ. The iDMZ is supposed to be a sterile buffer zone. Proxies terminate connections from the IT side and initiate new, separate connections into the OT side. No direct path should exist between Level 4 and Level 3.

In practice, many mining deployments reduce the iDMZ to a single firewall with overly permissive rules established during vendor commissioning. “Any-to-Any” rules get created to ensure the FMS works without latency during the pressure of go-live. These rules become permanent because nobody documents what should be tightened, and production teams resist changes to a working system.

The common failure is allowing “temporary” exceptions that become permanent. A vendor needs remote access for troubleshooting, so a port gets opened. A reporting dashboard needs real-time data, so a direct database connection bypasses the proxy. Each exception erodes the architecture. Most mines find that an annual audit of firewall rules reveals dozens of exceptions that nobody remembers approving.

The Physical Perimeter Erosion

Open-pit mines rely on expansive private LTE, 5G, or 802.11 Wi-Fi mesh networks for fleet connectivity. These wireless networks physically blanket the operational area. The traditional concept of a secure physical perimeter does not translate when radio signals extend beyond the pit rim and site fence line.

As mining fleets transition to 5G infrastructure, the reliance on Software-Defined Networking introduces API-level vulnerabilities that must be actively managed. The SDN control plane, which dynamically provisions network slices and manages traffic routing, becomes a high-value target. Compromise the SDN controller and you control the network.

Attack Vectors in Detail

GPS Spoofing and Time Synchronisation

GPS spoofing against civilian receivers is well documented. Gaber et al. (2021) demonstrated that broadcasting counterfeit signals can introduce subtle, time-stepped positional deviations that evade standard anomaly detection and dead-reckoning alarms.

For manned operations, GPS spoofing is a nuisance. Trucks appear in the wrong dig block on the dispatcher’s screen. For autonomous haulage, it is a safety failure. No documented GPS spoofing attack on a mine site has been reported, but the feasibility is proven.

The less obvious vulnerability is time synchronisation. Many FMS and SCADA architectures use GNSS signals as a primary stratum-1 time source to synchronise servers, databases, and field gateways. If GPS time is spoofed, the impact goes beyond positioning:

Predictive maintenance fails. Algorithms relying on millisecond-accurate sensor telemetry produce false positives or miss genuine failures when timestamps drift.
Forensic auditing is blinded. SIEM event correlation depends on accurate, sequential timestamps. Corrupting the time source makes it effectively impossible to reconstruct an attack chain during incident response.
Database consistency breaks. Transaction ordering, replication, and scheduled tasks across the FMS environment depend on synchronised clocks.

Mitigation requires Assured Positioning, Navigation, and Timing (A-PNT) architectures: multi-GNSS receivers, anti-jamming ASICs, and cross-checks against independent terrestrial or inertial navigation systems. At minimum, FMS time synchronisation should not depend solely on GNSS. An independent NTP source from the corporate network provides a cross-check.

VNC/RDP on Every Machine in the Fleet

FMS vendors frequently require remote access software on every vehicle’s onboard computer. VNC, RDP, or proprietary equivalents allow maintenance teams to remotely view and control vehicle-level systems for diagnostics.

Placing a remote access service on every machine in the fleet drastically expands the attack surface. Dragos has identified remote access tools as one of the most common initial access vectors in verified OT intrusions. Compromising a single engineering workstation can yield hardcoded, default, or shared VNC credentials, giving an attacker remote control of every equipped unit in the pit.

Mitigations:

Unique, rotated credentials per machine (not shared across the fleet)
MFA-protected jump servers as the only path to vehicle remote access
Full session recording for forensic auditing
Network-level access controls restricting which source IPs can initiate remote sessions
Disabling remote access services when not actively in use

Wireless De-Authentication

Wi-Fi de-authentication attacks force client devices to continuously disconnect from access points. The attack is trivially simple using commercially available equipment. On autonomous sites, loss of communication triggers fleet-wide safety stops. Correct fail-safe response, but also an easy production disruption vector.

Enabling Management Frame Protection (MFP / IEEE 802.11w) on all Wi-Fi infrastructure is mandatory for any site running autonomous equipment. MFP cryptographically protects management frames, preventing spoofed de-authentication and disassociation packets.

Physical Access to Onboard Equipment

FMS-equipped vehicles carry onboard computers, network switches, and telemetry gateways that are physically accessible to anyone who can climb into the cab or open a service panel. While rare, it is sometimes possible to plug into diagnostic ports or network switches onboard equipment and gain access to the FMS network from inside the vehicle zone.

Most onboard systems were designed for maintainability, not security. Unsecured Ethernet ports on switches, diagnostic interfaces that grant OS-level access, active USB ports. Once connected at the vehicle level, an attacker is inside the OT network, bypassing every perimeter firewall between corporate IT and the fleet.

Mitigations include disabling unused ports on onboard switches, requiring 802.1X port-based authentication before granting network access, physically securing service panels where practical, and ensuring that onboard systems do not grant administrative access through diagnostic interfaces without authentication. Wenco’s hardware partner Motium, for example, ships ruggedised onboard computers with locked-down USB ports, secure boot, and TPM 2.0 as standard.

Supply Chain and Third-Party APIs

Third-party involvement in data breaches rose from 15% to 30% in 2025. The Rio Tinto breach via GoAnywhere is the canonical mining example. The attackers exploited a zero-day in a third-party tool, not in Rio Tinto’s own infrastructure.

FMS integrates with ERP, tyre monitoring, fuel management, maintenance software, mine planning, and autonomous OEM platforms. Each integration point is a potential ingress route. Attackers target tertiary software providers because breaching one vendor yields authenticated access to dozens of downstream clients.

Many FMS architectures maintain continuous automated outbound data flows: application snapshots, system logs, configuration states uploaded to the vendor’s cloud for remote support. This means sensitive production data routinely leaves the OT environment. Vendor risk management must cover:

What data is transmitted, how often, and where it is stored
Encryption in transit and at rest
Vendor’s data retention and deletion policies
Vendor’s incident notification obligations
Contractual right to audit

Network Segmentation with IEC 62443

IEC 62443 is the international standard for industrial automation and control system cybersecurity. Its zones and conduits model is directly applicable to FMS.

The principle: divide the network into security zones based on function and criticality. Control every connection between zones through monitored conduits. For FMS, this means at minimum:

Vehicle zone. Onboard computers, gateway modules, mesh radios. Isolated from everything except the FMS server zone through a controlled conduit.
FMS server zone. Dispatch engine, database, historian. Restricted access, hardened hosts, no direct internet connectivity.
Integration zone. Where FMS talks to ERP, mine planning, and other business systems. Data diodes or application-layer proxies control what crosses the boundary.
Management zone. Administrative access, system monitoring, backup. Separate from operational traffic.

Security levels range from SL1 (protection against casual or unintentional violation) to SL4 (protection against state-sponsored attack). Most mining FMS deployments should target SL2 or SL3. No mining-specific profile (Part 5) has been published, so operations must adapt the general standard.

A DNV Cyber case study documented a Middle East mining company seeking IEC 62443 compliance and finding “significant cybersecurity gaps with few protective measures” at the outset. That is a common starting point. The standard provides the roadmap, not the destination.

The Latency Trade-Off

Not all zone boundaries get equal treatment. Some FMS architectures route traffic between the in-pit wireless mesh and the FMS server VLAN without stateful firewall inspection.

The rationale is not raw latency. A properly sized stateful firewall adds microseconds to low milliseconds of inspection delay, which dispatch cycle times (typically 1-5 seconds) can absorb.

The real concern is what happens when the firewall fails. Stateful inspection maintains a connection table for every active session. A fleet of 200 trucks sending continuous telemetry means 200+ concurrent sessions. When a firewall reboots or fails over, it drops every session in that table. Re-establishing 200+ connections simultaneously causes a cascade that can stall dispatch and trigger safety stops on autonomous equipment. It is the failover behaviour, not steady-state latency, that drives the architectural decision.

The trade-off is that the vehicle zone becomes implicitly trusted at the network level. If a vehicle onboard computer is compromised, it has a clean network path to the FMS servers. This should be documented as an accepted risk with explicit sign-off, not just treated as a technical trade-off. Where inline inspection is not feasible, compensating controls (network anomaly detection, behavioural baselining, and strict application-layer whitelisting) must fill the gap.

Vendor-Mandated Security Relaxations

This is the section that makes IT security teams uncomfortable. Depending on the FMS vendor and architecture, deployment requirements may include configurations that directly weaken host security.

Get the Architecture on Paper First

FMS procurement decisions are typically made on operational capability, vendor relationships, and commercial terms. Cybersecurity requirements are rarely part of the evaluation criteria, and IT/OT security teams are often not involved until after contract award. By that point, the vendor is selected, the budget is committed, and the project team is under pressure to deploy. The conversation shifts from “does this meet our security requirements?” to “how do we make this work?” That is how insecure architectures get built and accepted.

Getting cybersecurity representation into the requirements phase, before vendor shortlisting, is the single most effective point of intervention. Once the contract is signed, your leverage to demand architectural changes drops to near zero.

A related warning: every FMS vendor will tell you their system works with any network architecture. In practice, they do not. Different vendors have different requirements for port ranges, database access, remote support connectivity, and real-time latency thresholds that can conflict directly with your security architecture.

Before deployment, create a detailed technical architecture document that maps every FMS component, every network path, every integration point, and every firewall rule. Have the vendor review it. They will almost certainly not sign off on it formally. That is normal.

But make sure they have it, have read it, and have had the opportunity to flag conflicts. Without this document, you will discover architecture incompatibilities during go-live when the pressure to open ports and create exceptions is at its highest. That is how “temporary” rules become permanent.

This document also becomes the baseline for your annual firewall audit. If a rule exists that is not in the architecture document, it needs to be justified or removed.

Common Relaxations

Antivirus and EDR exclusions. Vendors require FMS application directories to be excluded from real-time scanning. File-locking behaviour from heuristic scanning can degrade or break the application. The result: the most operationally critical directories on the dispatch server are invisible to your primary malware detection tools.

User Access Control disabled. Vendor guides may require Windows UAC set to “never notify” and Admin Approval Mode turned off via registry edits on all FMS servers and workstations. This removes the operating system’s primary privilege escalation control. Threat groups like BianLian actively exploit weakened UAC and AMSI configurations.

Host-based firewalls opened. The local Windows Firewall on FMS servers may need to allow all inbound TCP and UDP traffic, or open vast, undocumented port ranges. This neutralises the host firewall, leaving network-level firewalls as the sole boundary.

Automated patching disabled. Vendors may require WSUS to be turned off to prevent unexpected reboots. Patching is relegated to manual processes aligned with maintenance windows, sometimes monthly. This creates known vulnerability windows where publicised exploits remain unpatched on critical servers.

None of these are malicious. They are pragmatic trade-offs for operational reliability in systems whose architectures predate the current threat landscape. But accepting them blindly is negligent.

The CrowdStrike Precedent

The July 2024 CrowdStrike incident validated one of the core concerns behind these vendor relaxations. A faulty channel file update pushed to CrowdStrike’s Falcon EDR agent caused approximately 8.5 million Windows machines worldwide to enter a boot loop. The systems crashed and could not restart without manual intervention. Estimated global financial impact: over US$5 billion.

This was not an attack. It was an endpoint security agent auto-updating and bricking the hosts it was installed to protect. For OT environments, the implications are direct: any software agent running on a dispatch server that auto-updates from an external source is a single point of failure.

This does not justify abandoning endpoint protection. It means endpoint protection on FMS servers must be managed differently than on corporate IT:

Staged rollouts. Never deploy security agent updates to FMS production servers in the first wave. Establish a canary group of non-critical OT systems that receive updates 24-48 hours ahead. Only promote to production after canary validation.
Update control policies. Disable automatic agent updates on FMS servers. All updates go through a controlled change management process aligned with maintenance windows.
Tested rollback procedures. Document and rehearse the procedure for reverting a security agent update on FMS servers. Know how to boot into safe mode and unload a faulty agent before it matters.
NDR over endpoint agents where possible. Network Detection and Response monitors traffic passively from the network. It cannot crash a server because it does not run on the server. For FMS server zones where vendor relaxations already limit endpoint visibility, NDR is the safer primary detection tool.

Required Compensating Controls

Application control (whitelisting). If AV cannot scan FMS directories, enforce strict application whitelisting instead. Only cryptographically signed, explicitly hashed, pre-approved FMS binaries execute on dispatch servers. Any unknown executable is blocked by default. This is the single most effective compensating control for EDR exclusions.

File Integrity Monitoring (FIM). Deploy FIM to continuously monitor excluded directories for unauthorised modifications. If a DLL, configuration file, or executable in an unscanned directory changes outside an approved maintenance window, a critical alert fires immediately. The excluded directories should be the most closely watched, not the least.

Network Detection and Response (NDR). Because endpoint visibility is blinded by EDR exclusions, NDR fills the gap. NDR passively analyses deep packet traffic, API calls, and industrial protocol anomalies across the FMS server zone. It detects lateral movement and exfiltration behavioural signatures without requiring agents on the FMS servers themselves.

Privilege access management. If UAC is disabled, implement a PAM solution that controls and audits all administrative access to FMS servers. No standing admin access. Elevation is just-in-time, time-limited, and fully logged.

Zero Trust for Mining OT

Traditional OT security relies on the castle-and-moat paradigm. Keep threats out of the iDMZ and trust everything inside. As FMS increasingly integrates with cloud, mobile, and third-party networks, this perimeter has eroded to the point of obsolescence.

Zero Trust assumes the network is already compromised. Nothing is trusted by default. The US Department of Defense published Zero Trust guidance for OT environments in late 2025 (DTM 25-003), and the Cloud Security Alliance published complementary guidance for OT in manufacturing the same month. Both are worth reading for the frameworks they provide.

The practical challenge for mining is availability. Enterprise IT puts confidentiality first. A system locks you out if authentication fails. OT puts availability and safety first. Inline authentication in a real-time machine guidance loop could stall an autonomous truck, forcing a fleet-wide safety stop.

The pragmatic approach: fail-open for safety-critical telemetry, fail-closed for everything else.

Real-time dispatch commands and machine guidance data must flow without inline authentication blocking the path. Apply strict enforcement to administrative interfaces, remote vendor access, API integrations, data exports, and non-real-time user authentication. These are the exact pathways that threat actors actually exploit. Locking them down while keeping the real-time safety loop unimpeded is the right trade-off.

For SaaS deployments where authentication traverses the internet, MFA should be mandatory for all user accounts.

Mining is early in this journey. No documented mining-specific Zero Trust deployment exists in public literature. But the direction is clear. Start with network segmentation, device identity (even basic MAC/IP binding on brownfield fleets), and least-privilege access for non-operational functions.

On-Premise vs SaaS: Different Security Models

The security architecture differs fundamentally between deployment models.

On-Premise / Hybrid

You own the servers, the network, and the risk. The vendor supplies software; infrastructure security is your problem. All the compensating controls discussed above (application whitelisting, FIM, NDR, PAM) are your responsibility to implement and maintain. You control the data, the patching schedule, and the monitoring.

The advantage is control. The disadvantage is that most mine sites do not have dedicated OT security expertise. The compensating controls are well understood but require skilled people to implement and maintain.

SaaS / Cloud-Hosted

The vendor owns the infrastructure. Patching, hardening, and server-level security shift to them. A well-run SaaS vendor will do these things better than most mine sites can. Security at scale, dedicated security teams, automated patching without maintenance windows.

The trade-off is trust and data sovereignty. Your production data (dispatch records, GPS tracks, payload data, equipment telemetry) resides in the vendor’s cloud tenancy. For Australian operations, this raises Privacy Act and potentially SOCI Act considerations depending on where the data physically resides.

Minimum requirements for SaaS FMS vendors:

Requirement	Why It Matters
ISO/IEC 27001 certification	Independently audited information security management system. Non-negotiable baseline.
SOC 2 Type II report	Ongoing auditor verification of security, availability, and confidentiality controls for cloud operations.
Data residency disclosure	Where production data physically resides. Critical for regulatory compliance and data sovereignty.
Penetration test summary	Evidence of regular third-party security testing. Ask for the executive summary, not just a checkbox.
Incident notification SLA	Contractual obligation to notify you of security incidents within a defined timeframe.
Data encryption	At rest and in transit. AES-256 and TLS 1.2+ minimum.
Right to audit	Contractual right to audit or receive evidence of the vendor’s security posture.

Currently, Wenco is the only FMS vendor with publicly confirmed ISO 27001 certification for its ISMS. Caterpillar has confirmed NIST CSF and ISO 27001 alignment in SEC filings. These are the benchmarks. Any SaaS FMS vendor who cannot demonstrate at minimum ISO 27001 should be treated as a procurement risk.

Authentication Architecture

FMS authentication on mine sites is often weaker than it should be. Contractor turnover is high and de-provisioning lags behind departures. Vendor support accounts sit with broad access and no expiry date. If this sounds familiar, you are not alone.

Many FMS platforms implement dual-layer authentication. Active Directory handles infrastructure access (server logins, RDP sessions). The FMS application maintains its own separate identity store for application-level roles. A departing user needs de-provisioning in both systems. In practice, the application account often gets missed when IT disables the AD account. This is one of the most common access control gaps on mine sites.

For system-to-system communication, certificate-based authentication is stronger than API tokens alone. Each consuming system gets a unique certificate. The FMS validates it on every request. Wenco’s approach (TLS-encrypted, certificate-authenticated communications with role-based access controls) is a good reference model for what to look for.

Service accounts are often a bigger risk than user accounts. FMS environments accumulate service accounts for database queries, integration scripts, scheduled tasks, and vendor access tools. These accounts typically have broad privileges, static passwords that are never rotated, and no expiry. They are rarely inventoried and almost never reviewed. If you audit one thing in your FMS authentication architecture, audit the service accounts.

Least privilege sounds obvious but is rarely implemented well. A production planner does not need access to individual vehicle GPS coordinates. A maintenance system does not need write access to dispatch assignments. Access rights accumulate over time and are never pruned. Quarterly access reviews, actually enforced rather than just documented, are the minimum.

Monitoring and Incident Response

What to Monitor

Effective OT monitoring for FMS environments:

Authentication failures. Patterns suggesting credential stuffing or brute force, especially against the FMS application’s own identity store.
Unusual data flows. Large exports, queries outside normal patterns, communication with unexpected external addresses, spikes in outbound data to vendor cloud.
Configuration changes. Firewall rule modifications, new user accounts, permission escalations, changes to EDR exclusion lists.
Integration traffic. Spikes in API calls, new integration endpoints, failed authentication from partner systems.
FMS-specific anomalies. Dispatch commands outside normal patterns, bulk data queries against production databases, changes to grade or material destination assignments.

Many FMS deployments go live with no centralised monitoring at all. Audit logs are written to local flat files on the server with no SIEM integration. Correlation between FMS security events and broader network activity is impossible. If your monitoring plan is “we’ll set it up after go-live,” treat that as a risk to be escalated, not a task to be deferred.

Dragos tracks 23 threat groups targeting industrial organisations. BAUXITE has demonstrated the ability to compromise PLCs, modify ladder logic, and deploy custom backdoors natively on OT devices, bypassing IT security monitors entirely. GRAPHITE focuses on deep reconnaissance and industrial espionage via spear-phishing and credential theft. A Security Operations Centre that understands OT protocols, not just IT traffic, is increasingly important.

Incident Response Architecture

The Copper Mountain response (isolate, switch to manual, shut down preventatively) remains the benchmark. Build your incident response plan around three capabilities:

Rapid isolation. Pre-plan the network disconnection points. Know exactly which cables to pull, which firewall rules to activate, and which services to shut down. Do not figure this out during an incident.

Island mode. ACSC guidance recommends that critical infrastructure operators build the capability to isolate OT systems from IT and the internet for up to three months while maintaining essential operations. This is not a binding compliance requirement under SOCI, but it is the benchmark the regulator expects. For FMS, this means independent localised dispatching that does not rely on cloud analytics, ERP synchronisation, or vendor licensing verification. Establish predefined thresholds for triggering isolation and rehearse the switchover.

Evidence preservation. There is a tension between isolating fast and preserving the evidence you need to understand what happened. Before pulling cables and shutting down servers, capture volatile memory and network state where possible. Disk images should be taken before remediation begins. If the incident may trigger reporting obligations under the Cyber Security Act 2024, or if law enforcement involvement is likely, chain of custody matters from the first minute. Build evidence capture into the isolation procedure, not as an afterthought.

Bare-metal recovery. Maintain trusted, fully offline (air-gapped) backups of FMS databases, server firmware, hypervisor configurations, and network switch states. The ability to rebuild the entire OT environment from scratch, without relying on potentially compromised online backup repositories, is the ultimate fail-safe. Test the recovery process. An untested backup is not a backup.

Relevant Standards and Guidance

The following standards and guidance documents are directly applicable to FMS network security. This article does not attempt to interpret these frameworks in detail. Engage a qualified OT security consultant for formal gap assessments and compliance programmes.

IEC 62443. The primary international standard for industrial control system cybersecurity. The zones and conduits model referenced throughout this article comes from this standard. No mining-specific profile exists yet, but GMG and MM-ISAC are developing mining-specific guidance.
NIST CSF 2.0. Added the Govern function in 2024, making cybersecurity a board-level concern. The Supply Chain Risk Management category is useful for holding FMS vendors accountable.
Australia’s SOCI Act. Mining is not explicitly listed among the 11 critical infrastructure sectors. However, operations that generate electricity, run rail, or operate port infrastructure may be captured. The Cyber Security Act 2024 introduced mandatory ransomware payment reporting within 72 hours for businesses with AUD $3M+ turnover, with active penalty enforcement since 1 January 2026.
ACSC Principles of Operational Technology Cybersecurity (October 2024). Jointly published with CISA, FBI, NSA, and international partners. Freely available and directly applicable to mining FMS.
ACSC Critical Infrastructure Uplift Program (CI-UP). Practical OT hardening guidance for Australian operators.

Autonomous Equipment Considerations

Autonomous haulage elevates cybersecurity from a network management issue to a functional safety imperative. A compromised dispatch system affecting manned trucks is a production problem. A compromised system controlling autonomous trucks is a safety problem.

The key additional controls for autonomous sites:

Management Frame Protection (MFP) on all Wi-Fi infrastructure. Mandatory to defend against de-authentication attacks that trigger fleet-wide safety stops.
Sensor fusion for GPS spoofing mitigation. Current AHS platforms cross-reference GNSS positioning with onboard LiDAR, radar, and inertial gyroscopes to detect anomalies.
Jump servers for remote access rather than direct VPN connections to autonomous equipment. Full session recording for any remote access to AHS components.
Network edge controls. Policy enforcement at the edge gateway, not just at the data centre firewall.

The MM-ISAC AHS Working Group and GMG’s Guideline for Implementation of Autonomous Systems v2 (2024) both provide detailed cybersecurity guidance specific to autonomous haulage deployments. Engage these resources directly for the depth this topic requires.

Key Takeaways

Segment first. If your FMS server zone, vehicle zone, and integration zone are on the same flat network, fix that before anything else. IEC 62443 zones and conduits is the framework.
Compensate for vendor relaxations. Application whitelisting, File Integrity Monitoring, and Network Detection and Response are not optional extras. They are mandatory compensating controls when your vendor requires you to disable EDR, UAC, and host firewalls.
Audit integration points annually. Map every system that connects to FMS. Each one is a potential entry path. Demand ISO 27001 from SaaS vendors and contractual incident notification SLAs from all integration partners.
Apply Zero Trust where it matters. Fail-open for real-time safety telemetry. Fail-closed for admin interfaces, vendor access, API integrations, and data exports. Start with network segmentation and device identity.
Build and drill island mode. Engineer the FMS network with deliberate, testable isolation points. Rehearse severing IT/OT connections and operating locally for extended periods. Do not wait for an incident to find out if it works.
Get FMS logs into the SIEM. If your FMS audit logs are flat files on the server that nobody looks at, fix that. Centralise OT logs, firewall events, and wireless telemetry. Behavioural anomaly detection catches what signature-based tools miss.
Test bare-metal recovery. Maintain air-gapped backups of everything: databases, firmware, hypervisor configs, switch states. Test the rebuild process. An untested backup is a hope, not a plan.