Manufacturing & plant security

The same architecture, read as an attacker would: left to right, outside to inside. Click a step to see it. The critical one is step 4 — the IT→OT pivot — which is exactly the boundary the DMZ and segmentation exist to hold.

The right-hand column of the architecture, organized the way NIST frames it: Prevent, Detect, Respond, Recover. These map directly onto the eight domains you score in section 9.

Two lenses on application risk in a plant. The left is classic web/API risk for manufacturing systems; the right is the newer LLM/agent risk that matters as plants adopt AI copilots and agents — where a prompt injection (see the RAG guide) can make an agent take an unsafe action.

Disruption. Ransomware that halts production costs money by the hour. Attackers know a plant will often pay fast because every stopped hour is measurable loss. Downtime is the leverage.

Sabotage. Altering a process — a temperature, a mix ratio, a robot's path, a torque spec — can ruin product or create a safety hazard, sometimes without anyone noticing until it ships. This is the nightmare case for a regulated manufacturer.

A foothold. The plant network is often a soft way into the wider company, or a stepping stone to a customer or partner. Flat networks make one compromised HMI a path to everything.

Plant equipment lives for decades. A press or a filler bought in 2005 may run an operating system that can no longer be patched, and you cannot simply replace it — it is validated, it works, and it cost millions. Availability outranks everything: you often cannot take a line down to patch it, and a reboot at the wrong moment scraps a batch. Much of the gear speaks old industrial protocols with no authentication and no encryption, built for a world where being on the network was the credential.

Add that IT and the plant floor are frequently run by different teams who barely talk, and you get the recurring root cause: nobody owns the cyber-physical risk, so it falls between the desks.

These are systems like PLCs (the small computers that control machines), HMIs (the touch screens operators use), SCADA and historians (that supervise and record the process), and increasingly robots and vision systems. Together they are your OT estate, and they are what plant security is really about.

The rule that makes this work: traffic between IT and OT never flows directly. It stops at the DMZ — a buffer zone — where it is inspected and brokered. An email server (L4) has no business talking straight to a PLC (L1), so the architecture forbids it. Lower is closer to the physical process and more dangerous to disturb, so the deeper you go, the tighter access should be.

If you do only one thing, separate OT from IT. Most damaging plant incidents share a root cause: a flat network where malware that landed on an office laptop reached the plant floor because nothing stood in the way. A well-placed boundary turns "the whole plant is down" into "one office subnet is down." It does not require replacing old equipment — it wraps a boundary around it — which is why it is both the most effective and the most achievable control for a plant full of unpatchable gear.

Beyond the big IT/OT split, micro-segmentation separates critical process zones from each other, so a compromise on one line cannot spread to the next. Think of it as watertight compartments in a ship's hull.

Name an accountable owner for OT security — not "IT will handle it," because IT's instincts are tuned for the office. Assess the plant's cyber-physical risk on a schedule, write security requirements into integrator and supplier contracts, and keep a plant-specific policy. Without ownership, everything below happens inconsistently or not at all.

A live inventory of every OT asset — PLCs, HMIs, historians, robots — with firmware and software versions per device. Maintain an SBOM for software on production systems, and explicitly identify end-of-life gear that cannot be patched so its risk is accepted, not ignored. Nearly every other control depends on knowing what you have.

Section 3 in practice: OT segmented from IT, a DMZ mediating all crossing traffic, remote access brokered behind MFA and logged, and critical zones micro-segmented from each other. This domain carries the most weight in the score because it prevents the most damage per unit of effort.

Individual accounts, not the shared "operator/operator" login everyone knows. Change default and vendor passwords on OT devices. Control and log physical access to the floor and control rooms — physical access is access. Block or scan USB media, still a leading way infections cross the air gap that people assume protects them.

Passive intrusion detection that watches OT traffic for anomalies without interfering, central log collection, alerts that reach someone who can act on the floor around the clock, and a baseline of normal process behavior to compare against. Passive is the operative word: in OT you watch first, because active blocking can stop the line.

Back up OT systems and PLC logic, and test the restore — an untested backup is a guess. Keep an OT-specific incident response plan and exercise it, because IT's playbook does not fit the floor. Have manual or degraded operating procedures for running without control systems, and define how much downtime and data loss production can tolerate.

Integrity-verify firmware and software updates before installing them, security-assess third-party integrators before they get floor access, track provenance of security-relevant components, and have a process to act on supplier vulnerability disclosures. The plant's security is only as good as what you let through the door.

The domain unique to medical-device manufacturing, covered in section 5. It asks whether a cyber event on the line could compromise the safety, quality, or integrity of the device being built — the risk that turns a plant incident into a patient-safety and regulatory event.

Categories, not endorsements — the point is what kind of tool does the job, so you can recognize the capability whatever the vendor. Most plants already own some of these under a different name.

In most factories, the worst manufacturing-security outcome is a stopped line. In medical devices, an attacker who alters a process could ship a device that harms a patient — a wrong dose calibration, tampered firmware, a defeated safety check — and it may pass inspection and reach the field. The manufacturing floor becomes a patient-safety surface.

Concretely, this means identifying the manufacturing systems that could alter device safety or quality, signing and securely provisioning device firmware on the line so only authentic code is loaded, protecting the integrity of manufacturing records (the Device History Record) from tampering, and feeding cyber events that affect product quality into the CAPA and quality system rather than treating them as IT tickets.

Medical-device manufacturers already run a rigorous quality system under FDA regulation. The opportunity — and the expectation — is to connect manufacturing cybersecurity to it rather than bolting on a parallel process. A cyber event that could affect product quality is a quality event: it belongs in the same CAPA, risk-management, and validation machinery that already governs the line. That linkage is what turns plant security from an IT concern into part of the device's safety assurance.

This is also where premarket and postmarket device-security expectations meet the factory: the same rigor applied to the device in the field should extend to how it is built, because a compromise at manufacture is a compromise shipped.

A certificate is a signed statement that says "this key belongs to this device/server, vouched for by this authority (a CA)." It does three jobs across the architecture you saw in section 1:

Identity — a device proves it is a genuine, authorized device before it is allowed to connect (to the cloud, to a gateway, to another device). Encryption — TLS between a device and the cloud, or between plant systems, is set up using certificates. Integrity — firmware and software updates are signed, and the device checks that signature with a certificate before installing, so only authentic code runs (the defense against the Stuxnet-style attack).

A certificate is not "issue and forget." It moves through a lifecycle, and every stage has a way to become an outage or a security gap down the road. Click through them.

An expired certificate on a web server is a bad afternoon: someone reissues it and restarts a service. An expired certificate baked into ten thousand medical devices already in hospitals is a different category of problem entirely, for reasons that compound:

You can't easily reach them. The devices are on hospital networks, sometimes barely connected, sometimes air-gapped. Pushing a new certificate to a fleet you don't physically control is slow and sometimes impossible remotely.

The expiry is set years before it bites. A device shipped today with a 5-year certificate fails in year five — long after the engineer who chose that duration has moved on, and often after the product line itself is in maintenance mode. The decision and the consequence are separated by years, which is why it is so consistently missed.

Failure can be safety-relevant. If a certificate expiry stops a device from communicating with its monitoring service, or blocks a firmware fix from installing, that is not just downtime — for a medical device it can be a clinical and regulatory event. The device didn't break; its identity paperwork lapsed, and it refused to work correctly as designed.

The CA itself can expire. The worst case: the root or intermediate CA that signed every device's certificate has its own expiry. If that lapses, every device that trusts it can fail at once — a fleet-wide outage from a single missed date. This has happened to major products, taking out services for millions of users in one stroke.

The good news: because the failure is predictable, it is preventable. The controls are about designing for the whole lifecycle at manufacture, not reacting near expiry.

Inventory every certificate. You cannot renew what you cannot see. Maintain a live inventory of every certificate in the plant and every certificate shipped in a product — issuer, expiry, what breaks if it lapses. This is the certificate equivalent of the asset inventory in section 6.

Automate renewal and rotation. Manual calendar reminders fail at scale. Use automated certificate lifecycle management (ACME-style protocols, cloud PKI, managed CA services) so renewal happens without a human remembering. Design devices to rotate certificates in the field, not just receive one at the factory.

Choose durations deliberately, and plan the CA hierarchy. A longer device certificate reduces renewal frequency but widens the blast radius if the key is compromised; shorter is safer but demands reliable rotation. Give intermediate and root CAs lifetimes longer than any device that depends on them, and plan their succession before they are ever deployed.

Build field-update capability first. The ability to securely push a new certificate to a fielded device is itself a security requirement — and it depends on a signed-update mechanism that is trustworthy, which depends on… certificates. Get this working before the first device ships, because retrofitting it to a deployed fleet is the nightmare scenario.