Secure and Running: How One Mining Operation Got Ahead of OT Cyber Risk

Most stories about cybersecurity in industrial operations start the same way: something broke. A breach, a ransomware note, a line down, a scramble. They're cautionary tales, and the lesson is always the same — you should have acted sooner.

This isn't one of those stories. This is the other kind — quieter, harder to tell, and far better to live through. A mining and milling operation in northern Canada decided to get ahead of the risk before anything went wrong, and our team has spent most of this year on site helping them do exactly that.

That decision deserves more credit than it usually gets.

Proactive is a choice — and it's the harder one

It might seem easy, yet painful, to fund security after an incident. The damage makes the case for you. It is much harder to invest in hardening a system that is, by every visible measure, working fine. There's no fire to point at, no headline to react to — just the quiet understanding that the control systems running a modern mine are increasingly connected, increasingly targeted, and increasingly built on equipment that was never designed for today's threat landscape.

This client's leadership made the harder choice. They looked at their operational technology — the PLCs, drives, relays, cameras, meters, switches, and HMIs that keep the operation safe and productive — and decided that running well today wasn't the same as secure for the next decade. So they went looking for a partner who could do something genuinely difficult: improve the cybersecurity of a live, running plant without putting that plant at risk.

You cannot patch a mine like a laptop

That's the catch with OT cybersecurity, and it's why generic IT security shops struggle with it. You cannot and should not push updates and reboot. These systems run continuous, safety-critical processes. A careless firmware flash or a misconfigured firewall rule doesn't cause an annoying outage — it can take down production or compromise safety. The very fragility that makes the work necessary is what makes it dangerous to do.

So here is what the work actually looked like, step by step. Not because the steps are secret, but because the order is the whole point.

Step 1: Know what you own

The first weeks were spent on something unglamorous: building a device list you can trust. Not the spreadsheet in the engineering folder. The real one.

That meant walking the plant with an electrician, opening cabinets, and pulling serial numbers, firmware revisions, and MAC addresses off hundreds of devices — PLCs, drives, overload relays, power meters, protection relays, cameras, switches. It meant discovering that there were several asset lists, each updated by different people at different times, and reconciling them into one working copy. It meant redlining the network diagram against what was physically in the racks.

Nothing downstream is any better than this list. If you don't know a controller exists, you can't know it's vulnerable.

Step 2: Find out what's actually wrong with it

With a real inventory in hand, the research starts. Every device and firmware version gets checked against published vulnerability advisories and vendor bulletins. This is where a generic checklist falls apart: the question isn't "are PLCs vulnerable" but "is this controller, at this firmware, exposed to this advisory, and does the fix exist yet."

At this site, the honest answer was that most of the controllers and a good share of the network equipment had advisories against them. That is not unusual. It's the normal state of a plant that has been running reliably for years. The difference is that now someone had a list, ranked by what mattered.

Step 3: Listen to the network without touching it

Before changing anything, you want to see what's really talking to what. The site had a commercial OT monitoring platform, which was a good start. But monitoring platforms only see the traffic that reaches their sensors.

Our engineers set up a field laptop for passive capture and plugged it in at each managed switch, area by area, looking for traffic the platform might be blind to. Then they compared what they captured against the platform's history and the device list, and automated the comparison so discrepancies got flagged on the spot. Any active scanning was done with device-safe methods, because an aggressive scan can knock an older PLC offline just as surely as a bad patch can.

The output of this step wasn't an exploit. It was a list of ports that should be closed and a set of network recommendations the client could fold into their own configuration standards.

Step 4: Prove it on the bench first

This is the step that separates OT work from IT work. Nobody flashes firmware on a running production controller as a first attempt.

The client provided spare PLCs and a drive, and the team built a test bench. Every upgrade procedure was run there first, then written up as a step-by-step document with photographs, then run again to prove the document was right. Each procedure got a check sheet with sign-offs — specifically so that if a shift change landed in the middle of a swap-over, the next person could see exactly where things stood.

When a firmware mismatch concern came up on an I/O card, it got tested on the bench before anyone went near the field. Boring. Correct.

Step 5: Land it in a window

Then, and only then, the changes go out. Each one is planned against the area shutdown schedule, laid out on a timeline with operations, and walked through a hazard assessment with the people who actually run that part of the plant. More than once, operations asked for more hazard review before a window, and the team did it.

The pattern was always the same: one area, one window, validate, then the next. The first plant upgrade was done on one process train, left to run overnight, and confirmed healthy before the second train was touched. Area by area, that pattern carried across the whole site over the following months.

Step 6: Leave them better than you found them

Alongside the upgrades, the team moved controller backups onto a proper versioning platform, updated the engineering software, applied security updates to the HMIs and servers, and handed over the procedures, device list, and network recommendations as living documents. They also stood up at the site's monthly safety meetings and gave cyber-awareness talks, because the best patch in the world doesn't help if someone plugs an unknown USB stick into an HMI.

Why it takes months — and why that's the point

This program has run from early spring into autumn with two engineers rotating through on alternating shifts. To anyone expecting cybersecurity to be a weekend project, that sounds slow. It isn't. It's the discipline working as designed.

Phasing the work means every change lands in a planned window, gets validated before the next one begins, and never stacks unproven changes on top of each other. It means the operation keeps producing the entire time. A live mine doesn't get to stop while you secure it, so you secure it around the operation, one careful step at a time. Months of steady, methodical progress is exactly what "we did this without an incident" actually means.

The empowering part

Here's what we want operators to take from this: you are not stuck choosing between a secure facility and a running one. The work can be done on a live operation, by people who understand both the cyber risk and the process risk, without betting the plant to get there.

The operation we have been working with isn't reacting to a breach. They're not in the news. They made a decision to keep their facility running tip-top — secure, current, and resilient — for years to come, and they brought in people who knew how to make that decision real and safe. That's not a story about technology failing. It's a story about good people making a good call.

If you've been looking at your own control systems with that same quiet concern — knowing the risk is real but unsure how to act on it without disrupting production — start with Step 1. Go find out what you own. And if you want company for the rest, that's precisely the conversation we're built for.

Solving operational challenges in ways others have only imagined.

Links and resources

Step 2 only works if you know where to look. These are the sources our engineers checked the device list against, and the ones worth subscribing to for your own site.

Government advisories

• Canadian Centre for Cyber Security: Alerts and advisories — Canada's national authority on cyber security. Publishes alerts and advisories, including ones aimed at critical infrastructure operators.

• CISA: Industrial Control Systems advisories — the US Cybersecurity and Infrastructure Security Agency's ICS feed. Vendor-neutral, searchable by product, and the most complete single list of published OT vulnerabilities. Its general advisories page covers the IT side.

Vendor security pages

• Rockwell Automation: Security advisories — covers Allen-Bradley controllers, FactoryTalk software and Stratix networking.

• Schneider Electric: Security notifications — covers Modicon PLCs, EcoStruxure software, and the power and metering lines.

• Siemens: ProductCERT — covers SIMATIC, SCALANCE and the rest of the Siemens industrial portfolio, with RSS and machine-readable feeds.

Most vendors offer an email or RSS subscription. Sign up, filter by what is actually on your device list, and the research step turns from a project into a habit.