Building a Common OT Architecture for a Diverse Mining Industry

Mining operations are becoming more connected, more automated and more dependent on digital systems. Autonomous equipment, private LTE and 5G networks, remote operations centres, cloud analytics and AI-enabled maintenance are increasingly part of the modern mine.

Yet the operational technology environments supporting those capabilities remain extraordinarily diverse.

A new operation designed today may begin with a highly segmented network, modern automation and remote operating capabilities. A mine that has operated for decades may contain several generations of equipment, operating systems and communications technology—much of it built before cybersecurity became a design consideration.

Both operations need to be secure. Both need to be resilient. And both need an architecture that reflects the realities of mining rather than simply importing an enterprise IT model into an industrial environment.

That is why MM-ISAC established the Reference Architecture Working Group.

Built by the mining and metals industry

The MM-ISAC Mining OT Reference Architecture was developed through the participation of 12 mining and metals companies.

That matters.

This is not an abstract architecture created for an idealized industrial facility. It was shaped by organizations that operate mines, processing plants and metals facilities—and that understand the practical challenges of securing remote, complex and long-lived operating environments.

Working-group participants brought different commodities, operating models, technologies, geographies and levels of cybersecurity maturity to the discussion. That diversity helped us distinguish between what should be common across the industry and what must remain specific to each operation.

The result is not a prescribed product list or a requirement that every mine look the same.

Instead, the architecture establishes a common security boundary, a consistent set of capabilities and a set of outcomes that organizations can apply to both new and existing operations. Below that common boundary, each site can retain the technologies and topology required by its processes.

In simple terms: standardize the boundary and the security outcomes, while engineering the operational environment for the site.

Designed around how mining actually operates

Several principles guided the working group.

The first was site survival first.

A mine should not become unsafe or immediately inoperable because its connection to the enterprise or cloud is unavailable. The architecture is designed around the ability of a site to sustain safe production and local security operations for up to 30 days while disconnected from external services.

That does not mean focusing only on PLCs, HMIs and control servers.

A control system may remain technically operational, but the mine will still stop if it cannot access maintenance procedures, issue work orders, obtain fuel, order reagents or identify critical spare parts. Operational resilience therefore has to account for the business and supply-chain services that production depends upon—not only the systems that directly control equipment.

The architecture consequently addresses local authority, identity, monitoring, recovery, maintenance information, essential operational records and continuity arrangements for externally hosted systems.

The second principle was a common Level 3.5 boundary with site-specific control environments.

Mining companies often operate portfolios of sites acquired or developed at different times. Attempting to make every network below the supervisory level identical is rarely practical. Establishing a consistent protected boundary and common security services, however, creates a repeatable model that can be governed, monitored and improved across the enterprise.

The third principle was secure enablement of modern mining.

The architecture accounts for capabilities that are already changing operations, including:

• Integrated Remote Operations Centres managing one or more sites
• Private LTE and 5G carrying multiple classes of mine traffic
• Autonomous haulage and other autonomous systems
• Vendor and third-party access
• Cloud-based analytics and AI workflows
• Physical security and access-control systems
• Cloud-based ERP, maintenance and supply-chain platforms

These technologies should not be treated as exceptions bolted onto the architecture later. They need defined trust boundaries, controlled communication paths and safe failure modes from the beginning.

Resilience includes the ability to separate

Mining companies regularly acquire and divest individual operations. Unfortunately, the technology supporting those operations is not always designed with separation in mind.

A mine may depend on enterprise identity, licensing, monitoring, remote access, cloud services or shared infrastructure owned by its parent company. Those dependencies can make a transaction significantly more difficult and create risk for both the seller and the buyer.

The reference architecture introduces permanent severability as a design requirement.

A site should be capable of being securely separated from its current owner, transferred with the operational authority and records required to continue operating, and connected to a successor organization without rebuilding the core OT environment.

This improves more than transaction readiness. The same characteristics—local services, documented dependencies, controlled conduits and clear ownership—also improve incident containment, disaster recovery and day-to-day operational resilience.

Useful for both new and established operations

We wanted the architecture to serve two very different audiences.

For a junior practitioner or engineering team planning its first mine, it should provide a practical picture of what needs to be built: where services belong, how the major zones interact and which capabilities are essential from the beginning.

For an established mining company, it should provide a target state against which existing operations can be assessed: a way to say, “Yes, this is where we need to get to,” even if reaching that state requires a multi-year program.

Not every site can implement every capability immediately. For that reason, the architecture distinguishes between critical requirements, important requirements and recommended enhancements. The intention is to help organizations prioritize meaningful risk reduction—not create a checklist where everything appears equally urgent.

A shared foundation for improvement

No reference architecture will eliminate the need for site-level engineering or risk assessment. Mining operations are too varied, and the consequences of poorly planned change are too significant.

What a common architecture can do is give the industry a shared starting point.

It can help mining companies communicate expectations to engineering partners and technology providers. It can give security and operations teams a common language. It can support investment decisions, guide new projects and provide a practical target for modernizing existing sites.

Most importantly, it can reduce the need for every company—and every site—to solve the same foundational problems independently.

I want to thank the members of the MM-ISAC Reference Architecture Working Group and the 12 participating mining and metals companies for contributing their operational experience, technical knowledge and time to this effort. The strength of this architecture comes directly from that collaboration.

This is what an ISAC should enable: competitors working together on shared risks so the entire sector becomes stronger.

The complete MM-ISAC Mining OT Reference Architecture and its accompanying white paper are linked bellow. 

We look forward to sharing it—and to continuing the industry conversation about what secure, resilient and operationally practical mining technology should look like.

 Download the Architecture White Paper

Download the full Reference Architecture

R