Manufacturing has been the most attacked industry sector for four years running, and the reason is not mysterious — plants that used to run isolated automation networks now sit connected to vendor VPNs, remote monitoring platforms, and cloud historians, and every one of those connections is a possible entry point. Most plants already hold a folder of security policies, but a policy is not evidence, and auditors, insurers, and customers increasingly ask a different question: can you actually show that a specific control works in practice, on this network, today. A cybersecurity assessment built against IEC 62443 and NIST CSF answers that question directly, mapping real vulnerabilities in your OT environment against the zones, conduits, and security levels the standards define. Book an OT cybersecurity assessment walkthrough to see how the process maps to your specific plant architecture.
Cybersecurity Assessment for Manufacturing: Where You Actually Stand Against IEC 62443 and NIST
A structured vulnerability assessment, risk analysis, and remediation roadmap that turns "we have policies" into documented, testable proof your OT network can withstand the access paths it has today.
Why Two Frameworks, Not One
IEC 62443 and NIST CSF Answer Different Questions — Your Assessment Needs Both
NIST CSF gives you an organization-wide language for cyber risk that IT leadership, insurers, and boards already understand — Identify, Protect, Detect, Respond, Recover. IEC 62443 goes further into the specifics of an industrial automation and control system, defining zones and conduits, security levels from SL 1 to SL 4, and lifecycle requirements that span the asset owner, the integrator, and the product manufacturer. Plants that assess against only one of the two typically end up with either a plant-floor picture that means nothing to the board, or a board-level score that says nothing about whether a contractor's laptop can still reach a PLC. Regulatory pressure has made this a practical rather than academic distinction: manufacturers exporting into the EU are now tracking obligations under the Cyber Resilience Act that reference IEC 62443-4-1 certification directly, while U.S. defense suppliers face CMMC requirements that lean on the same NIST control families used in CSF. A single assessment methodology that speaks to both saves a plant from running two separate, poorly coordinated review cycles that each produce a different answer to the same underlying question.
The practical output of combining them is a single risk register where every finding carries two labels — the NIST function it falls under, for the executive summary, and the IEC 62443 zone and target Security Level it violates, for the engineer who has to fix it. That dual labeling is what makes the same assessment usable in a board deck and in a maintenance work order without translation loss in either direction.
NIST CSF: Enterprise Risk Language
Organizes cybersecurity into five functions that map cleanly to executive reporting and cyber insurance questionnaires, giving leadership a consistent score to track quarter over quarter across every facility in the portfolio, without needing to understand the underlying industrial protocols each site actually runs.
IEC 62443: OT-Specific Depth
Defines zones and conduits architecture, four Security Levels describing the sophistication of attacker a system can resist, and separate obligations for asset owners, system integrators, and automation product vendors, covering the full lifecycle from specification through decommissioning rather than a single point-in-time check.
Where They Overlap
Both frameworks converge on network segmentation as the single highest-leverage control, treating the boundary between IT and OT — and between OT zones themselves — as the line that stops lateral movement after a breach, which is why segmentation testing sits at the center of any assessment built around either standard.
Why Contracts Now Require Both
Customer security questionnaires increasingly ask for NIST CSF maturity scores alongside IEC 62443 zone documentation, and automation suppliers without the relevant 62443-4-1 or 62443-2-4 evidence are starting to lose tender shortlists outright, before price or technical fit is ever discussed.
The Assessment Itself
Six Phases From Asset Inventory to a Prioritized Remediation Roadmap
01
Asset Inventory and Network Discovery
Every production server, historian, MES/ERP database, engineering workstation, HMI, PLC, VPN concentrator, and vendor remote-access tool is identified through passive network discovery, since you cannot assess the risk of an asset you don't know exists. Most plants are surprised by how many devices this step turns up that were never on the official network diagram, including shadow IT installed by a well-meaning technician years earlier.
02
Zone and Conduit Mapping
Assets are grouped into IEC 62443 zones based on function and trust level, and every conduit — the communication path between zones — is documented, including the ones that were never formally approved but exist anyway. This map becomes the reference document every later phase of the assessment, and every future architecture decision, gets measured against.
03
Vulnerability and Exposure Scanning
Passive and safety-aware active scanning identifies unpatched firmware, default credentials, flat network segments, and internet-exposed HMIs, tuned specifically to avoid disrupting live production traffic on the plant floor. Findings are cross-referenced against known vulnerability databases so the severity rating reflects real-world exploitability, not just a generic checklist score.
04
Segmentation and Access Path Testing
Rather than assuming a firewall rule works, the actual reachability from a corporate workstation or a vendor VPN session to a critical PLC is tested directly, producing the technical validation evidence auditors and insurers now ask for by name. This step consistently surfaces the widest gap between documented policy and operational reality.
05
Risk Scoring Against Security Levels
Findings are scored against the IEC 62443 Security Level the zone is meant to achieve, translating a raw vulnerability list into a gap statement — this zone is operating at SL 1 but needs SL 2 given its exposure. This is the step that gives leadership a single defensible number per zone instead of a page of disconnected findings.
06
Prioritized Remediation Roadmap
Findings are sequenced by exploitability and production impact rather than delivered as an undifferentiated list, so the segmentation gap that could halt a line is addressed before the low-severity finding that carries no near-term risk. Each item carries an owner, an estimated effort, and a retest date rather than sitting as an open-ended action.
For a medium-complexity facility, a baseline gap assessment against IEC 62443-3-3 realistically takes four to eight weeks, and that timeline lengthens for multi-site portfolios or plants where segmentation has never been formally tested before — planning the assessment window around a maintenance outage window, rather than live production, keeps active scanning from ever touching a running process. Plants running the assessment for the first time should expect the discovery and mapping phases to take longer than the scoring and roadmap phases, simply because so much of the early time goes into reconciling what the network diagram says against what passive discovery actually finds connected and talking. Involving both the plant's controls engineers and its IT security staff from day one shortens this reconciliation considerably, since each side typically holds half the picture and neither has historically had full visibility into the other's domain.
See Your Own Network Mapped This Way
Get a Zones-and-Conduits View of Your Plant Before You Commit to a Full Assessment
A short scoping call is enough to show you what the zone map, the risk scoring, and the remediation roadmap actually look like for a facility your size, before any commitment to the full engagement.
What Assessments Actually Find
The Findings That Show Up in Nearly Every First-Time OT Assessment
Flat Networks Behind One Firewall
A single perimeter firewall separating all of IT from all of OT, with no internal segmentation between the historian, the HMI network, and the safety systems — meaning one compromised workstation can reach everything, and containment depends entirely on how fast the intrusion is noticed.
Vendor Accounts Never Disabled
Remote access credentials issued to an automation integrator or equipment vendor years ago, still active, still with the same privileges, long after the project that required them ended, and frequently invisible to IT because they were provisioned directly by the OT team.
Unpatched Engineering Workstations
Windows workstations running programming software for PLCs and HMIs that have gone years without a security patch, because patching was deferred to avoid any risk of disrupting a production system it touches — the same aging software is often the single most attacked entry point industry-wide.
Default or Shared Credentials on Controllers
PLCs and HMIs still running factory-default login credentials, or a single shared password used across dozens of devices because rotating individual credentials was never built into the maintenance workflow, turning any one leaked password into access across the whole line.
Undocumented Remote Access Paths
A cellular modem or remote-support tool installed directly on a controller for troubleshooting convenience, invisible to IT security because it was never provisioned or approved through a formal change process, and rarely removed once the original need has passed.
No Tested Incident Response for OT
An incident response plan that reads well on paper but has never been exercised against an OT-specific scenario, leaving the team without a rehearsed answer for whether to isolate a line or keep it running during an active incident, a decision that is far harder to make well for the first time under real pressure.
None of these findings are unusual, and none of them reflect a plant being negligent — they reflect the normal way an OT environment accumulates complexity over years of incremental additions, each individually reasonable at the time, without anyone stepping back to review the cumulative picture. That is precisely the value an outside assessment brings: a fresh, structured look at a network the internal team has become too close to see clearly, run against a framework rather than institutional memory. The findings above also tend to compound each other — a flat network turns one unpatched workstation into a plant-wide exposure, and an undisabled vendor account on that same flat network hands an attacker a ready-made path that requires no exploit at all, just a credential that was never revoked.
Turning Findings Into Priority
How Findings Get Scored: Likelihood vs. Production Impact
| Likelihood / Impact | Low Impact | Moderate Impact | High Impact |
|---|---|---|---|
| Unlikely | Monitor, low priority | Schedule within roadmap | Schedule within roadmap |
| Possible | Schedule within roadmap | Near-term remediation | Near-term remediation |
| Likely | Near-term remediation | Immediate remediation | Immediate remediation |
| Already Exploited Pattern | Immediate remediation | Immediate remediation | Stop-work priority |
This is the same likelihood-versus-impact logic every risk framework uses, but the impact axis in an OT context has to weigh production downtime and safety consequence alongside data exposure — a finding that would be moderate in a pure IT context can move to high impact the moment it sits on a conduit feeding a safety-instrumented system. Documenting the matrix this way also gives the remediation roadmap a defensible, repeatable logic that survives staff turnover, rather than living only in the judgment of whoever ran the original assessment. Insurers reviewing a claim after an incident will often ask to see exactly this kind of documented scoring logic, since it demonstrates the organization was actively managing risk rather than simply hoping nothing would happen — a distinction that can materially affect how a claim is handled.
Security Levels Explained
What SL 1 Through SL 4 Actually Mean for Your Plant
SL 1
Protection Against Casual or Coincidental Violation
The baseline level, appropriate for zones with minimal exposure — an isolated test bench or a non-networked legacy device that has no realistic path to an attacker and carries little consequence if it were ever affected.
SL 2
Protection Against Intentional Violation With Simple Means
Appropriate for most internal production zones — resistant to an insider or opportunistic attacker using generic tools and low skill, but not a targeted, resourced adversary who has specifically chosen your facility as a target.
SL 3
Protection Against Sophisticated Means With Moderate Resources
The level most safety-critical and business-critical zones should target — resistant to an attacker with specific ICS knowledge, moderate resources, and moderate motivation, which covers the profile of most ransomware groups currently targeting manufacturing.
SL 4
Protection Against State-Level or Extended Resources
Reserved for the highest-consequence zones in critical infrastructure — resistant to a well-funded, highly motivated adversary with extended campaign capability, rarely required outside national infrastructure and defense-adjacent manufacturing where a successful breach would carry national-level consequence.
Most manufacturing plants do not need every zone at SL 4 — the assessment's job is to identify the target Security Level each zone actually needs given its exposure and consequence, then measure the gap between that target and where the zone stands today, rather than pushing every zone toward the highest level regardless of cost or operational need. Over-investing in a zone that only needed SL 2 wastes budget that would have closed a real gap somewhere else, which is exactly why the target-setting step comes before any remediation spending is approved.
Practitioner Perspective
The plants that struggle with this are rarely the ones with no security budget — they're the ones that spent the budget on IT-side tools and assumed OT was covered by the same firewall rule that's been sitting untouched since commissioning. What actually moves the needle is the boring part: testing whether a workstation can reach a PLC through the segmentation everyone believes exists, finding the vendor account nobody remembered to disable, and writing all of it down against a framework an auditor or insurer will recognize. None of that requires exotic tooling — it requires someone treating the OT network with the same scrutiny the IT network has had for a decade. The plants that get real value from their first assessment are also the ones that treat the roadmap as a living document, revisiting it every time a new vendor connection or IIoT device gets added, instead of filing the report away until next year's audit forces another look. Ownership matters just as much as the technical work — a roadmap with no named owner per finding tends to stall within a few months, while one built into existing maintenance and change-management workflows keeps moving on its own, closing findings as a routine part of daily operations rather than as a separate, easily deprioritized initiative.
Rosalind Achterberg
OT Security Consultant · 14 years across manufacturing and critical infrastructure · Former lead assessor for multi-site IEC 62443 gap assessment programs
Assessment Questions
Frequently Asked Questions
Will active vulnerability scanning risk disrupting our production systems during the assessment?
A properly scoped OT assessment leads with passive network discovery, which observes traffic without sending anything to production devices, and reserves any active scanning for a defined maintenance window with explicit sign-off from operations. Legacy PLCs and HMIs can be sensitive to unexpected network traffic in a way modern IT servers are not, so the assessment plan should always specify exactly which techniques are used against which device classes before any testing begins, and operations should always retain the authority to pause any step in progress. Book a scoping call to review the testing plan for your specific device inventory before anything is scheduled.
How is a cybersecurity assessment different from a compliance audit we already pay for?
A compliance audit typically checks whether a policy document exists and whether a checklist has been completed, while a technical assessment tests whether the control the policy describes actually functions on the live network — for example, confirming the network segmentation an audit lists as "in place" genuinely blocks the traffic it claims to block. Many plants pass their compliance audit and still fail a technical assessment, because the gap between documented policy and tested reality is exactly where most real incidents originate, and it is exactly the gap an auditor rarely has the access or time to test directly.
Do we need to assess every facility at once, or can this be phased across a multi-site portfolio?
Most multi-site manufacturers phase assessments, starting with the facility carrying the highest production value, the most external connectivity, or the most safety-critical processes, then using the findings and remediation patterns from that first site to accelerate the rest. This phased approach also builds internal expertise and a reusable zone-and-conduit template, so each subsequent facility's assessment moves faster than the one before it, and the roadmap format stays consistent enough that leadership can compare progress across sites on one dashboard.
What happens after the assessment — do we get a report, or ongoing support implementing the fixes?
The deliverable is a prioritized remediation roadmap scored by production impact and exploitability, not just a raw findings list, but the more valuable long-term outcome is the retested evidence trail — each fix confirmed closed through a follow-up check rather than simply marked complete on a spreadsheet. Ongoing support usually covers periodic retesting of the highest-priority findings and updating the zone map as new devices or vendor connections are added. Contact support to discuss how remediation tracking and retesting fit into your specific roadmap.
How often should a manufacturing facility repeat a full cybersecurity assessment?
An annual reassessment is a reasonable baseline for most facilities, but any significant network change — a new vendor connection, a new IIoT deployment, a merger bringing an unfamiliar network into scope — should trigger an interim review rather than waiting for the annual cycle. Security Levels and zone boundaries that were accurate a year ago can silently drift as new devices and connections get added without going through the same architectural review the original assessment applied, which is exactly how a well-scoped plant ends up with an unnoticed gap two years later.
Know Exactly Where You Stand
Get an IEC 62443 and NIST-Aligned Assessment of Your Plant's Real Exposure
Move past policy documents and self-reported checklists to a tested, evidence-backed picture of your OT network — mapped to the zones, conduits, and Security Levels your auditors, insurers, and customers already expect to see, with a remediation roadmap your team can actually execute against.
