IEC 62443 assessment vs OT penetration testing

IEC 62443 assessment vs OT penetration testing: which one to commission first

If you own, integrate or supply an industrial system, start by deciding what question you need answered. An IEC 62443 assessment measures the system against the requirements of the ISA/IEC 62443 series and the target security levels you have set for it, while OT penetration testing tests whether an attacker can reach and disrupt the system in practice. The first produces a gap picture against requirements such as those in ISA-62443-3-3 for system security and ANSI/ISA-62443-4-2 for component technical requirements. The second produces evidence of exploitable paths and their operational consequences. Neither result substitutes for the other, so the sequencing question is about which gap you need to close first.

For most asset owners, a documented assessment is the sensible first step when the zones, conduits and target security levels are not yet agreed or written down. Without them, a penetration test has no defined requirement to test against and produces findings that are hard to prioritize. Integrators and product suppliers often need the component-level picture first, since the requirements in 4-2 attach to the parts they supply. Commission penetration testing first when a system is already in service, when a specific exposure such as remote access or a vendor connection is the concern, or when an assessment has already run and you need to confirm that the documented controls hold under attack. Combine the two when the same system must both meet requirements and be proven resistant. Confirm with the testing provider how they will handle active testing, because NIST SP 800-82 Rev. 3 says penetration testing must be used with care on OT networks, and it names replicated or simulated systems as a compensating control. Ask whether a test environment exists and whether production may need an outage window.

How the two approaches differ on goal, scope, method and evidence

This table compares an IEC 62443 assessment with an OT penetration test factor by factor, from the question each answers to the evidence it leaves behind. Read it to decide which one your organization needs first, and note that the two often answer different parts of the same program.

Factor	IEC 62443 assessment	OT penetration test
Primary question	Does the system and its components meet the requirements and target security level set for its zones and conduits?	Can an attacker with a defined starting point reach and affect the control process, and what would it take?
Standards anchor	ISA-62443-3-3 for system requirements and security levels, ANSI/ISA-62443-4-2 for component requirements, within the general, policies and procedures, system and component groups	Scope and rules set by the engagement, often informed by NIST SP 800-82 Rev. 3 and MITRE ATT&CK for ICS (12 tactics)
Who performs it	Assessors with IEC 62443 and OT process knowledge, often with the asset owner, integrator or supplier involved in interviews	Penetration testers with OT experience working under a written rules of engagement agreed with plant and safety staff
Method	Document and interview review, configuration and architecture review, zone and conduit analysis, and evidence sampling	Active attack in a controlled scope, such as exploitation attempts and lateral movement, usually on a replica or within agreed windows
Production impact	Low, because the work is largely passive, although reviewers must not query fragile controllers without agreement	Potentially high, since NIST SP 800-82 Rev. 3 warns that OT is sensitive to timing and resource limits, so tests may need a replica or an outage window
Output	Gap findings against each requirement and security level, with evidence the assessor can trace	Demonstrated attack paths, impact observed in the test scope and remediation priorities, with the conditions under which each path worked

Who asks for an IEC 62443 assessment and who asks for OT penetration testing

The first question to settle is which buyer you are, because the three roles in the ISA/IEC 62443 series need different evidence. Asset owners operate the industrial site and need a program and system view: whether policies, procedures, zones and conduits, and the security levels they have targeted for each system are in place and working. System integrators build and commission the control system and must show that the delivered system meets the system requirements in ISA-62443-3-3, including the security levels agreed in the contract. Product suppliers sell components such as controllers, engineering stations or remote access gateways and need component-level evidence against the technical requirements in ANSI/ISA-62443-4-2.

In practice, asset owners usually ask for a standards-based assessment first, because it shows gaps across people, process and technology. Integrators typically need an assessment of the system they hand over, with penetration testing added where the contract or the asset owner asks for proof that the system resists attack. Product suppliers ask for component-level evidence, and an attack test on one product tells them less about whether it meets the requirements than a structured assessment does. Penetration testing answers a different question: whether a skilled attacker can reach an unsafe state. Confirm with the contracting party which edition of the standard applies and which security level targets are in scope, rather than assuming the most recent document or the widest test. The contract wording decides the deliverable, so have it name the standard, the edition and the evidence expected before work starts.

What each approach finds and what it misses

An IEC 62443 assessment and an OT penetration test answer different questions about the same control system. Read each card as a pair: what the method surfaces, and what it leaves for the other method or for a planned test window to cover.

Assessment findings: requirement gaps

A gap assessment compares the system against the requirements in ISA-62443-3-3 and the component requirements in ANSI/ISA-62443-4-2, then records where the target security level is not met. Typical gaps include missing account management, weak logging, and absent patch processes. Ask the assessor to show each gap mapped to a specific requirement, and to state which target security level the zone or conduit was assessed against.

Assessment findings: documentation and zoning

Much of an assessment concerns process and architecture: whether asset inventories, zone and conduit diagrams, and security policies exist and match the running system. Zoning issues such as a flat network between safety systems and business applications show up here before any packet is sent. Ask for the zone and conduit model and check it against the live network, because diagrams often lag behind changes.

Assessment misses: exploitability and attack paths

An assessment does not prove that a weakness can be exploited, and it rarely shows how several moderate gaps combine into a path from an internet-facing system to a controller. A requirement may read as unmet while the real risk is low, or the reverse. Ask whether the assessor will validate high-impact gaps with a bounded technical test, and where that test sits in the plan.

Assessment misses: detection gaps

Documentation can show that monitoring is required, but it does not show whether alerts fire for the techniques an attacker would use against industrial protocols. A passing requirement may hide blind spots in OT monitoring coverage. Ask the assessor what evidence proves detection works, such as logs from a controlled test, and what remains unverified.

Penetration test findings: exploitable weaknesses and lateral movement

A penetration test shows what an attacker can actually do: credentials reused from an IT jump host, a remote access path into the OT network, or a historian reachable from the corporate domain. NIST SP 800-82 Rev. 3 advises that tests on non-OT networks must not propagate into the OT network, so the scope must define which crossings are tested. Ask for each finding to name the pivot path and the affected zone.

Penetration test findings: segmentation in practice

A test shows whether segmentation holds under real conditions, not only in the design. Firewall rules that permit a protocol the design forbids, or a conduit that bypasses an inspection point, are found by attempting the crossing. Ask the tester to record which boundary was tested, what was allowed, and whether the result was confirmed on the live system or a replica.

Penetration test misses: requirement coverage and policy

A penetration test cannot show that a requirement is met across the whole program. Policies, training, change control, and vendor management stay outside what an attack reveals, and a clean test does not prove IEC 62443 conformance. Ask the provider to state in writing which findings are technical and which items need the assessment. This keeps the two outputs from being mistaken for each other.

Penetration test misses: scope and the test window

Anything outside the agreed scope, or not reached before the test window closes, is absent from the report. NIST SP 800-82 Rev. 3 notes that production OT may need to be taken offline for testing, which limits what can be attempted on live equipment. Ask for the list of excluded assets, the reason for each exclusion, and the compensating controls such as replicas or simulated systems.

Limits of both on fragile controllers

Neither approach is free of risk on fragile controllers. NIST SP 800-82 Rev. 3 says OT systems are highly sensitive to timing and have limited resources, so even a light scan can disrupt a process. Assessment is document-led and safe, but it can miss what a live probe would reveal. Testing on a replica or virtualized copy, or a planned outage, reduces risk but may not match production behavior. Ask each provider how it will handle a controller that stops responding.

Why OT penetration testing needs different safeguards than IT testing

NIST SP 800-82 Rev. 3 says penetration testing has to be used with care on OT networks because OT systems are highly sensitive to timing constraints and have limited resources. A controller that is slow to answer a malformed packet, or a human-machine interface that crashes under a port scan, can stop a process that an IT server would simply restart from. For that reason, live exploitation of production OT is rarely the first step, and many asset owners limit production work to passive observation and carefully bounded checks.

Timing sensitivity: Scan rates and probe patterns that are harmless on a file server can delay or disrupt control traffic.
Limited device resources: Older programmable logic controllers and field devices may have little memory or processing headroom to absorb unexpected input.
Passive first: Traffic observation and asset inventory can reveal much of the attack surface without sending any test traffic to the process.
Planned outages: NIST SP 800-82 Rev. 3 notes that production OT may need to be taken offline for testing, which means the process owner must agree to a window.
Operator presence: Plant operators should be on hand to stop a test and confirm that the process is safe.

Before approving any live step, confirm with the asset owner which devices are safety-relevant, what the rollback plan is, and who has authority to halt the test.

How to sequence an IEC 62443 assessment and OT penetration testing

This sequence moves from knowing what is in the industrial environment to testing it safely, so the assessment findings, the attack results and the detection validation all point at the same zones and assets. The order shifts with the buyer's role and the evidence already on hand, so treat it as a default to adjust.

Define scope and build the asset inventory
The asset owner, with the integrator and the OT operations team, fixes the boundary of the industrial system, names the sites and lines in scope, and records each controller, engineering workstation, historian, remote access path and network segment. Passive discovery is usually preferred here because NIST SP 800-82 Rev. 3 cautions that OT systems are sensitive to timing and have limited resources. The step is done when the scope statement and inventory are signed off by operations and security, and every in-scope asset has an owner and a criticality note. Confirm with the provider how the inventory will be collected without touching fragile controllers.
Run the requirements gap assessment
Assessors compare the system and its components against the requirements in ISA-62443-3-3 and, where products are involved, ANSI/ISA-62443-4-2, at the security level the asset owner has chosen for each zone. This is a documentation and interview-led review of policies, procedures, configurations and vendor evidence, so it can run before any testing touches the network. The output is a gap register that lists each requirement, its status and the evidence reviewed. The step is complete when every gap has a named owner and the chosen security levels are recorded as the target for later steps.
Review architecture, zones and conduits
The assessor checks how the system is divided into zones and conduits, where the boundary to the enterprise network sits, how remote access is granted, and whether any path from a corporate test or IT system could reach the OT network. NIST SP 800-82 Rev. 3 states that tests on non-OT networks must not propagate into the OT network, so this review sets the isolation rules the penetration test must respect. The output is a current zone diagram with the gaps in segmentation marked. Done when the operations team confirms the diagram matches the live network and the test team has a written list of permitted paths.
Plan test scenarios from ATT&CK for ICS
The penetration testers map the scenarios they will run to the 12 tactics in the MITRE ATT&CK for ICS matrix, from Initial Access through Impair Process Control and Inhibit Response Function to Impact. Each scenario names the assets it targets, the expected effect, the safety limit and the stop condition. The plan should be reviewed by operations and, where relevant, the process safety owner. The step is complete when each scenario has an approved test environment, either a replica, a virtualized or simulated system, or a planned outage window, and the rules of engagement are signed by the client.
Execute controlled OT penetration testing
Testing runs in a replicated, virtualized or simulated environment wherever possible, and only in a planned outage window on production OT where that is the sole option, as NIST SP 800-82 Rev. 3 describes. Operators stay on site, rollback and recovery steps are rehearsed beforehand, and testers halt on any sign of process disturbance. The output is an evidence log of each scenario, what was attempted, what succeeded and what the operators observed. Done when every approved scenario is either completed or stopped with a recorded reason, and nothing is left in an unknown state on the live system.
Remediate findings and retest
The asset owner and integrator prioritize the gaps from the requirements review and the successful attack paths, then schedule fixes around process constraints. Some fixes, such as segmentation changes or patching a controller, may require the same outage planning as the test itself. Testers then repeat the scenarios that succeeded to confirm each attack path is closed. The step is complete when the retest report shows each finding as closed, accepted with a documented risk decision, or still open with an owner and a date agreed by the asset owner.
Validate detections against the techniques used
Security monitoring teams check whether their OT monitoring and alerting would have detected the techniques that worked in testing, using the same ATT&CK for ICS technique IDs from the test plan. Where detections are missing, they add rules or monitoring sources, then the tester or the monitoring team reruns the relevant scenario in the approved environment. The output is a detection coverage record that maps each tested technique to the alert that fired or to a documented gap. The step closes when that record is reviewed by the asset owner and feeds the next assessment cycle.

What you receive from each approach

This table sets the assessment deliverables against the penetration test deliverables for an industrial system. Read it to see what each output proves, who uses it, and what to pin down in the written scope before work starts.

Deliverable	IEC 62443 assessment	OT penetration test
Core output	Report mapped to ISA-62443-3-3 system requirements and the target security level for each zone or conduit, with the gaps against each requirement	Report of reproduced findings with attack narratives showing how a tester moved from an entry point to affected assets
Tracking artifact	Gap register listing each unmet requirement, its owner, the affected asset or zone, and a proposed remediation	Findings list with severity, affected assets and reproduction steps, usually feeding the owner's own remediation tracker
Evidence	Evidence package of policies, procedures, network diagrams, asset inventories and configuration records that support each mapped requirement	Captured evidence from the test itself, such as screenshots, logs, tool output and notes on what was touched and when
Safety and operations notes	Notes on where operational constraints affect remediation, such as patch windows and vendor support limits	Safety notes covering which tests ran, which were avoided on fragile controllers, and any planned outage or replica used, per NIST SP 800-82 Rev. 3
Remediation output	Remediation plan sequenced by zone, with options and dependencies, for the asset owner to approve	Remediation guidance per finding, with retest recommendations, but not a full program plan
Retest terms	Confirm whether re-assessment of mapped requirements is included and how updated evidence is reviewed	Confirm whether retest of closed findings is included, the retest window, and whether it runs on the same targets
Format and mapping detail	Confirm the report template, the requirement IDs used, and whether security levels are mapped per zone or per system	Confirm report structure, the level of reproduction detail, and whether results map to MITRE ATT&CK for ICS tactics
Who uses it most	Asset owners and integrators preparing for an assessment or a conformance claim, and product suppliers documenting component capability	Asset owners validating controls, operations teams deciding fixes, and assessors asking for evidence of exploitability

What drives cost and effort for each approach

Assessment against IEC 62443 and penetration testing of an OT environment are paid for in different units of work, so the quote you receive depends on how the scope is drawn. The cards below separate the drivers for each approach, the shared drivers, and the one-time and recurring components to ask about.

Zones, conduits and asset count

An IEC 62443 assessment is priced largely by how many zones and conduits are in scope, and how many assets sit inside each one. Each zone needs its security level target checked against documented controls, so a plant with many small zones can take more work than one large flat network. Ask the provider to list the zones, conduits and asset counts it assumed, and to state which sites and systems are excluded.

Target security level and documentation maturity

The target security level for each zone sets how deep the review goes, and weak or missing documentation adds time before any assessment work starts. If asset inventories, network diagrams and procedures are out of date, the assessor spends effort reconstructing them, which is a cost to plan for in the quote. Ask whether the price assumes a documented baseline or includes gap documentation work.

Interviews and operator access

Assessments depend on interviews with operations, maintenance, integrators and vendors, and on walking the site or reviewing configuration exports. Staff availability across shifts and sites often drives the calendar more than the technical work. Ask who must be interviewed, how many sessions the quote includes, and whether remote or on-site time is priced separately.

Replica availability and outage windows

Active testing on OT is cheapest when a replica, virtualized or simulated copy of the system exists, because testers can work without touching production. NIST SP 800-82 Rev. 3 names replicas as a compensating control and notes that production OT may need to be taken offline. Without a replica, expect planning, shift scheduling and possibly a vendor or integrator on call. Ask whether the quote assumes a replica and who builds it.

Protocols, controllers and rules of engagement

Penetration test effort rises with the number of industrial protocols, controller types and engineering workstations in scope, because each needs safe test methods and specialist knowledge. The written rules of engagement, including which tests are forbidden on controllers and what stops a test, set how much of the plan can be executed. Ask for the protocol list, the controller models and a copy of the draft rules of engagement before accepting a price.

One-time work versus recurring work and the quote

Initial assessment, gap analysis, and a first penetration test are one-time work, while periodic re-assessment, retesting after changes and continued monitoring recur. Shared costs include site count, which multiplies travel and interviews, and the safety review that most OT owners require before any active test. Ask the provider to split the quote into one-time and recurring lines, name the roles doing the work, and state what is excluded, such as remediation.

Questions buyers ask before hiring OT security help

Does an IEC 62443 assessment alone prove an industrial system is secure?

No. An assessment checks a system against requirements in the ISA/IEC 62443 series, such as the system security requirements and security levels in ISA-62443-3-3 and the technical component requirements in ANSI/ISA-62443-4-2. It shows whether controls are designed and documented against those requirements. It does not show that an attacker could move through the network or disrupt a process. A penetration test tries that path under agreed limits, so the two answer different questions. Ask the provider which requirements the assessment covers, which evidence it reviews, and whether any control claims will be tested in practice.

Can penetration testing run safely on production OT networks?

Only with careful planning. NIST SP 800-82 Rev. 3 says penetration testing is used with care on OT networks because these systems are highly sensitive to timing and have limited resources. It also says tests on non-OT networks must not propagate into the OT network. The guide lists a replicated, virtualized or simulated system as an example compensating control, and it notes that production OT may need to be taken offline for testing. In practice, teams often test a replica or a simulated environment first, then run any production work in a planned outage window with the operations team present. Confirm the test plan, the stop criteria and the rollback steps in writing before any active work starts.

What drives the cost of an IEC 62443 assessment or OT penetration test?

The main drivers are the number of zones and conduits in scope, the number of distinct asset types, whether the work includes a replica or lab, and how much documentation exists. An assessment is mostly review work, so its effort rises with the amount of policy, architecture and procedure evidence the team must read and interview on. A penetration test rises with the number of targets, the complexity of the safe test method, and any need for outage windows or a test environment built for the work. Recurring costs appear when the scope repeats or when remediation is validated. Ask for a quote that lists each zone, asset group, test method and deliverable separately, and state who provides the replica and who staffs the outage windows. No supplied source gives a price for either service, so compare quotes on scope rather than headline figures.

How long do an OT assessment and an OT penetration test take, and what do they need from operations staff?

The duration depends on scope, access and how many outage windows the plant can allow, and no supplied source gives a standard timeline, so ask each provider for a schedule tied to the written scope. Operations staff usually need to provide network diagrams, asset lists, change records, access to walk-throughs of the control room or site, and a named contact who can approve active steps. For penetration testing, they also need to schedule replicas or downtime, confirm which equipment must not be touched, and be ready to halt testing. Plan the calendar around shift patterns and maintenance freezes. Ask the provider for a list of client inputs and approvals before signing.

Can our own team run an IEC 62443 assessment or OT penetration test in-house?

A team can run parts of this work in-house, but the two activities need different skills. Assessing against IEC 62443 requires familiarity with the series, the ability to map zones, conduits and security levels, and the discipline to keep evidence organized. Penetration testing of OT requires safe method selection, understanding of industrial protocols, and experience with fragile controllers, with ATT&CK for ICS as a common planning reference. Many asset owners have strong operations staff but limited testing experience on industrial equipment. Decide which parts you own, such as asset inventory and change control, and which need an outside tester. Ask any provider for evidence of OT-specific experience and for its approach to replicas and outage windows.

Which edition of the ISA/IEC 62443 series should we specify in a contract?

Specify the parts that match your scope, and name the edition in the statement of work. The series is organized into four groups: general, policies and procedures, system, and component. Asset owners often reference the system requirements in ISA-62443-3-3 and product suppliers reference the component requirements in ANSI/ISA-62443-4-2, while integrators often need both. The supplied facts do not list current edition dates or revision numbers, so confirm the exact document versions with ISA and your procurement team before writing them into a contract. Also confirm which security level target applies to each zone, since the assessment checks against those targets.

In what order should we run an assessment and an OT penetration test?

Most teams run the assessment first, then the penetration test. The assessment builds the asset inventory, zone and conduit model, and documented controls, which tell the tester what to target and what to expect. The penetration test then checks whether the controls hold under attack, and its findings feed back into the assessment record. Passive monitoring to build the inventory can start earlier because NIST SP 800-82 Rev. 3 treats passive methods as lower risk than active testing. Repeat the penetration test after significant changes, and validate that detections cover the techniques the testers used. Agree this sequence with both providers before scheduling any work.

How the two approaches combine in one OT security program

Start with the assessment, because its gaps decide what the penetration test should try to prove. An IEC 62443 gap assessment maps each zone and conduit against the requirements in ISA-62443-3-3 and the component requirements in ANSI/ISA-62443-4-2, and against the security level the asset owner has targeted. Every shortfall becomes a test objective. A missing or weak control on a remote access conduit, for example, becomes a question the tester answers directly: can an attacker reach the engineering workstation through that path? Without this link, the test tends to repeat generic scanning and the findings do not map back to the standard.

The loop closes in the other direction. A penetration test result that shows a route into a zone is evidence of a requirement gap, even if the assessment scored that requirement as met. Record each successful step against the requirement it defeated, update the zone and conduit model, and re-rate the affected security level. NIST SP 800-82 Rev. 3 adds a constraint on the test itself: active testing on OT networks needs care, and a replicated, virtualized or simulated system can serve as a compensating control. Ask the testing provider to show which steps ran against the replica and which, if any, touched production, and confirm the outage window before any production step is approved.

NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, and that principle applies here. An assessment alone is enough when the goal is design conformance, the asset owner has not yet built the system, or the program is still deciding its target security levels. A penetration test alone can answer a narrow question, such as whether one exposed service is reachable, but it cannot show that the wider program meets its requirements. Confirm with the asset owner and the integrator which situation applies before committing budget to either one.

How DeployOpen scopes, delivers and supports OT security testing

DeployOpen plans, tests and documents OT security work inside the client's own infrastructure, including air-gapped networks. Assessment against IEC 62443 requirements and active testing of an industrial environment are scoped separately, so each produces the evidence its reader needs.

How we scope

Written scope fixes which zones, conduits and components are in view before any work starts.
Scope states whether testing touches production OT or only a replica, virtualized or simulated system.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Scope names which 62443 requirements or security levels the assessment covers, and which it does not.

How we build

Assessment work maps existing controls against the requirements the client has chosen to measure against.
Active tests run only in agreed windows, with safety and timing constraints reviewed with the asset owner first.
Tests that could reach OT from non-OT networks are bounded in the rules of engagement before execution.
Testing findings are traced to the controls, zones and components they affect so remediation has clear owners.

How we hand over

Deliverables separate assessment findings against requirements from exploitation results and attack paths.
Documentation records methods, tools, test windows and any compensating controls used during active work.
Evidence packages are prepared for the client's compliance assessment, which auditors or certification bodies then review.
Handover includes a walkthrough so the client's operations and security staff can act on the results.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial engagement.
Retesting after remediation can be scoped in writing, so fixes are checked against the same findings.
Clients should confirm retainer terms, response expectations and update cadence in the written proposal.
DeployOpen prepares evidence and systems for assessments but does not issue audit reports or certifications.

IEC 62443 assessment vs OT penetration testing