For a decade, IEC 62443 lived mostly as a design reference. Controls engineers drew zone-and-conduit diagrams during a network refresh, filed them next to the electrical prints, and moved on. Nobody outside the plant ever asked to see them. That era is ending. OEMs in automotive, aerospace, and defense-adjacent supply chains are starting to write IEC 62443-3-3 and NIST CSF language directly into supplier contracts and security questionnaires, and they’re asking for something a diagram can’t provide: proof.
This is the same pressure wave that CMMC created in the defense industrial base, just arriving on a different pier. CMMC forced small and midsize defense suppliers to stop treating NIST SP 800-171 as a checkbox and start producing artifacts — system security plans, POA&Ms, evidence tied to specific controls — that a third-party assessor could actually verify. What’s happening now with IEC 62443 flow-down is the manufacturing-floor version of that same shift: voluntary framework becomes contractual gate, and “we follow best practices” stops being an acceptable answer.
If you run plant IT or OT security for a mid-tier manufacturer, the practical problem isn’t understanding IEC 62443. Most engineering teams already grasp zones, conduits, and security levels conceptually. The problem is that almost nobody has the evidence trail an auditor or a customer’s third-party assessor will actually ask for. That’s a different project than asset inventory, and it’s the one most shops haven’t started.
What auditors actually want, versus what you have
Most plants can produce a network diagram and a firewall rule export if pressed. That’s not what’s being asked for anymore. A credible IEC 62443-3-3 assessment, or a customer questionnaire modeled on one, is going to probe for artifacts in roughly these categories:
- Conduit-level traffic evidence. Not “we segmented the network” but logs or flow data showing what actually crosses each conduit between zones — which protocols, which endpoints, and whether traffic matches the documented allow-list. A firewall rule base without corresponding logs proves intent, not enforcement.
- Firmware and software inventory tied to specific assets. This is where SBOM (software bill of materials) expectations are creeping into OT. Auditors increasingly want to know, PLC by PLC and HMI by HMI, what firmware version is running, what known vulnerabilities apply to that version, and when it was last verified — not a generic “Rockwell/Siemens PLCs, patched per vendor guidance” statement.
- Access control evidence, not access control policy. Role-based access is easy to write into a policy document. Auditors want the account list, the last access review date, and proof that a terminated contractor’s credentials to the historian or the engineering workstation were actually pulled.
- Documented compensating controls for what can’t be patched. Every plant has legacy cells running equipment that will never see another firmware update. IEC 62443 doesn’t require the impossible; it requires you to say so explicitly, in writing, with a defined mitigation — network isolation, jump-host access only, enhanced monitoring — rather than silence on the gap.
Notice what’s common across all four: each one requires an artifact generated over time, not a document written the week before the audit. That’s the part that catches teams off guard. You cannot backfill six months of conduit traffic logs the week a customer questionnaire lands.
Start with the conduits that actually matter
Don’t try to instrument every zone boundary in the plant at once — that’s how these initiatives stall out. Prioritize the conduits an auditor or OEM security team will actually ask about first: the IT/OT boundary, any conduit that touches a safety-related zone, and anything carrying traffic to or from a vendor remote-access tool. Those three categories cover most of the real risk and most of the audit attention. Get logging, retention, and an allow-list baseline in place there before you worry about east-west segmentation between production cells that never talk to the outside world.
A practical target for most plants: a managed switch or next-gen firewall at each priority conduit capable of exporting flow logs to a central collector, retained long enough to answer “what happened in the last quarter” without scrambling. You don’t need a full SIEM deployment to start. You need logs that exist, are retained, and are reviewable — which is a lower bar than most vendors will tell you, and a real gap for most plants today.
The SBOM problem is worse in OT than IT
Software bills of materials are becoming standard expectation in enterprise IT procurement, and that expectation is migrating onto the plant floor. The trouble is that OT vendors have historically been far less transparent about component-level firmware contents than modern IT software vendors, and a lot of installed base predates any SBOM practice at all. You’re not going to get a clean SBOM from a PLC that’s been running since before the term existed.
The realistic move is a firmware inventory you build and maintain yourself: asset tag, model, firmware version, install/update date, and a note on known CVEs applicable to that version, refreshed on a schedule. It’s not a true SBOM, but it’s the artifact that answers the question an SBOM is meant to answer — “what’s actually running, and do we know what’s wrong with it” — and it’s achievable without waiting on vendors to change how they ship firmware documentation.
Write down what you can’t fix
The single biggest evidence gap in most plants isn’t a missing control — it’s an undocumented one. Every facility has at least one legacy cell that can’t be patched, segmented as cleanly as the standard wants, or monitored the way a greenfield line would be. Auditors under CMMC learned to expect this in the defense sector and built a formal mechanism for it: the plan of action and milestones. IEC 62443 assessments expect the equivalent — a compensating-controls statement that names the gap, explains why it exists, and documents what’s being done instead.
A one-page compensating-control record per legacy cell — asset, risk, mitigation, review date, owner — is worth more to an auditor than a beautifully drawn zone diagram with no acknowledgment of its own exceptions. Auditors are not looking for a plant with zero gaps. They’re looking for a plant that knows where its gaps are and manages them deliberately.
Don’t wait for the questionnaire
The shops that will struggle in 2026 are the ones treating IEC 62443 flow-down as a future problem, something to deal with when a specific OEM contract renewal forces the issue. By the time that questionnaire lands with a response deadline attached, you’re trying to generate months of evidence in weeks — and that’s exactly the position that turns a manageable compliance request into a genuine threat to a contract.
Building the evidence trail now — conduit logging on the boundaries that matter, a living firmware inventory, an access review cadence, and honest compensating-control documentation for the legacy equipment you’re stuck with — is a real, sustained effort, and it’s not free. But it’s the difference between answering a customer’s security questionnaire with confidence and scrambling to reconstruct six months of history you never captured. The framework didn’t get harder. The expectation that you can prove you’re following it did.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
