Using Adversary Simulation to Produce IEC 62443 and NERC CIP Validation Evidence

Compliance documentation can show that an OT security control was designed, approved, or configured. It does not always prove that the control can stop a realistic attack path.

Adversary simulation helps close that gap. By modeling how an attacker could move from an initial access point toward critical industrial assets, organizations can collect evidence about segmentation, access restrictions, monitoring, vulnerability exposure, and compensating controls. When simulations run in a cyber digital twin rather than against live production systems, teams can test consequential scenarios without introducing unnecessary operational or safety risk.

This approach does not certify compliance or replace an auditor, applicable standard, legal interpretation, or required assessment. It produces technical validation evidence that can strengthen IEC 62443 and NERC CIP compliance activities.

What adversary simulation compliance means

Adversary simulation compliance is the use of realistic attack scenarios to test whether implemented controls behave as intended and to preserve the resulting evidence for governance, assessment, and audit workflows.

The goal is not to claim that a simulation automatically satisfies a requirement. The goal is to connect four elements:

1. The applicable requirement: The IEC 62443 requirement, NERC CIP obligation, internal policy, or control objective being evaluated.
2. The implemented control: The firewall rule, zone boundary, identity control, monitoring capability, hardening measure, or compensating control intended to meet that objective.
3. The validation scenario: The adversary behavior and attack path used to challenge the control.
4. The evidence: The inputs, assumptions, results, timestamps, affected assets, control outcomes, and remediation records produced by the test.

This creates a traceable line from requirement to control to test to result. It also moves the conversation beyond vulnerability counts. A vulnerability may exist without being reachable, while a chain of ordinary weaknesses and permissive connections may create a viable route to a critical OT zone.

For a broader comparison of technique-level testing and full-path analysis, see [BAS vs adversary simulation](https://frenos.io/resource/bas-vs-adversary-simulation).

Why conventional compliance evidence can leave a validation gap

OT compliance programs commonly collect policies, network diagrams, configuration exports, access reviews, vulnerability reports, change records, and screenshots. These artifacts remain important, but they can leave unanswered questions:

• Can an attacker bypass the documented zone and conduit design?
• Do allowed connections create an unexpected IT-to-OT path?
• Does a compensating control actually interrupt the path it is meant to address?
• Can monitoring detect the behaviors represented in the scenario?
• Did remediation remove the exploitable route, or only address one finding?
• Has the environment changed since the evidence was collected?

Vulnerability scanning alone cannot answer all of these questions. It identifies potential weaknesses, but it does not necessarily establish reachability, prerequisites, lateral movement, or the sequence required to affect a critical asset.

Traditional penetration testing may provide stronger empirical evidence, but live OT testing must account for uptime, safety, fragile devices, legacy protocols, vendor restrictions, and process consequences. Scope restrictions intended to protect production can prevent testers from evaluating the most important paths.

A cyber digital twin offers another option. Available network, asset, vulnerability, and security-control data can be normalized into a model where adversary techniques are evaluated without executing them on production equipment. Model quality and data coverage must still be documented, but the approach allows broader and repeatable analysis without treating the live plant as a test environment. Learn more about [how digital twins support safe OT security testing](https://frenos.io/blog/how-digital-twins-are-changing-ot-security-testing).

Mapping adversary simulation evidence to IEC 62443

IEC 62443 is a family of standards covering industrial automation and control system security across asset owners, service providers, system integrators, and product suppliers. The exact evidence needed depends on the organization’s role, the applicable part of the standard, the assessment scope, and the selected security requirements.

Adversary simulation is especially useful for validating architecture and system-level control objectives.

Zones, conduits, and restricted data flows

A simulation can test whether modeled communication relationships permit movement across intended trust boundaries. Useful evidence can include:

• The source zone, target zone, and conduit involved
• The modeled access point and destination asset
• Required protocols, ports, identities, and intermediary systems
• The boundary control expected to interrupt the path
• Whether the path was blocked, conditionally possible, or validated as exploitable
• The assumptions and source data used to reach the conclusion

This evidence helps teams evaluate whether the implemented architecture reflects the documented zone and conduit model.

Identification, authentication, and use control

Scenarios can examine how compromised credentials, shared accounts, remote access, excessive privileges, or weak trust relationships contribute to an attack path. The output should distinguish between a verified condition and an assumption that requires additional inspection.

System integrity and vulnerability response

Instead of ranking vulnerabilities only by severity, adversary simulation can identify which weaknesses participate in routes to critical assets. This supports risk-based remediation and provides evidence for why a particular vulnerability, configuration, or compensating control received priority.

Network segmentation and least functionality

A simulation can reveal unnecessary services, permissive rules, dual-homed systems, management paths, or connections that defeat segmentation objectives. A post-remediation rerun can then show whether the path was eliminated or redirected.

Adversary simulation does not replace the documentation, governance, secure development, supplier, or lifecycle evidence required by applicable IEC 62443 provisions. It adds technical evidence about whether selected controls withstand modeled adversary behavior.

Mapping adversary simulation evidence to NERC CIP

NERC CIP applies to the security of the Bulk Electric System under defined applicability, categorization, and compliance requirements. Responsible entities should use the currently effective standards, approved guidance, and their own compliance interpretation when determining what evidence is required.

Adversary simulation can support several areas of a NERC CIP program without being represented as automatic proof of compliance.

Electronic Security Perimeters and access paths

For controls associated with electronic access, a modeled attack can evaluate whether reachable services, firewall permissions, remote access routes, or intermediary systems enable an unintended path toward applicable cyber systems.

The evidence package can record:

• The modeled perimeter and access point
• The rules and communication relationships used by the path
• The assets traversed
• The control expected to block access
• The simulation outcome
• Exceptions, uncertainties, and required manual verification

Systems security management and vulnerability assessment

Adversary simulation can add exploitability and attack-path context to vulnerability assessment findings. This helps explain which conditions expose consequential routes and which findings are isolated by effective controls.

For activities associated with vulnerability assessments, teams should preserve the approved scope, date, methodology, model inputs, exclusions, findings, and remediation disposition. Any required live, active, paper, or other assessment method should still be performed as applicable.

Configuration change and transient cyber asset risk

A digital twin can be rerun after a firewall, route, remote-access, asset, or configuration change. Comparing results before and after a change can reveal newly introduced paths and provide evidence that a corrective change had the intended effect.

Incident response and recovery preparation

Threat-informed scenarios can help teams ask whether monitoring and response processes cover realistic routes into operational environments. Simulated results can inform exercises and detection engineering, but teams should not claim a detection succeeded unless the applicable monitoring workflow was actually tested and evidence was captured.

A seven-step workflow for producing defensible evidence

1. Define scope and applicability

Identify the facilities, systems, zones, conduits, Electronic Security Perimeters, requirements, and internal control objectives involved. Record exclusions and ownership.

2. Establish the evidence question

Use a testable question, such as: “Can a compromised enterprise identity reach an engineering workstation through approved or unintended connections?”

3. Build and quality-check the model

Ingest available network, asset, vulnerability, identity, and control data. Document data sources, collection dates, known gaps, assumptions, and model limitations. Perfect visibility is not a prerequisite, but uncertainty must remain visible in the evidence.

4. Select relevant adversary scenarios

Choose behaviors based on architecture, applicable threats, prior findings, and critical functions. Include initial access assumptions, prerequisites, lateral movement, target assets, and the control expected to stop each route.

5. Run the simulation and preserve results

Capture successful and blocked paths, contributing conditions, affected assets, control decisions, timestamps, tool version, and analyst review. Keep raw outputs where retention and handling rules permit.

6. Map results to controls and requirements

Create a matrix connecting each requirement or objective to the implemented control, simulation scenario, result, evidence location, owner, and remediation status.

7. Remediate and retest

Prioritize changes that remove or interrupt consequential attack paths. Rerun the same scenario and preserve before-and-after results to demonstrate whether the control change reduced exposure.

What a compliance-ready evidence package should contain

A useful evidence package should include:

Evidence should be reproducible, time-bound, attributable, and explicit about uncertainty. A polished diagram without source data or test assumptions is weaker than a transparent result another reviewer can understand.

Common mistakes to avoid

• Claiming simulation equals certification: Simulation can support an assessment, but it does not grant IEC 62443 certification or determine NERC CIP compliance.
• Testing generic techniques without architecture context: A technique result is less useful when it is not connected to a route, asset, control, and operational consequence.
• Hiding model limitations: Missing identity, rule, or asset data should be recorded rather than silently treated as proof that no path exists.
• Treating every finding as equally important: Prioritize conditions that participate in reachable paths to critical systems.
• Failing to preserve blocked-path evidence: A blocked path can demonstrate that a control behaved as intended within the model and stated assumptions.
• Skipping retesting: A closed ticket is not the same as evidence that the attack path no longer works.
• Replacing existing teams and controls: Adversary simulation should validate and prioritize monitoring, assessments, segmentation, vulnerability management, and engineering work, not replace them.

How Frenos supports production-safe validation

Frenos uses agnostic data ingestion, operationalized intelligence, and empirical evidence to model OT environments and evaluate adversary attack paths in a cyber digital twin. The approach is purpose-built for OT and designed to validate IT-to-OT and OT attack paths without executing tests against live production systems.

Rather than producing another vulnerability list, Frenos helps teams identify which combinations of vulnerabilities, access relationships, and control gaps create exploitable routes. Results can support remediation prioritization and repeatable validation while leaving final compliance determinations with the responsible organization and its assessors.

For an example of scale rather than a universal performance expectation, Frenos reported simulating 154,000 OT attack paths in 17 minutes at S4x26 and validating 18 exploitable paths. Actual outcomes depend on scope, environment, input data, and assessment objectives.

Turn compliance artifacts into validation evidence

Policies and configuration records explain what controls should do. Adversary simulation helps show how those controls perform against modeled attack paths.

When results are tied to requirements, supported by traceable inputs, reviewed by qualified stakeholders, and repeated after remediation, they can strengthen IEC 62443 and NERC CIP evidence programs without putting production systems at risk.

[Request a demo](https://frenos.io/contact) to see attack paths in your OT environment and assess defenses without production impact.

Frequently asked questions

Can adversary simulation prove IEC 62443 compliance?

No. It can produce technical evidence supporting selected IEC 62443 control objectives, but certification or conformity assessment depends on the applicable standards, scope, process, and authorized assessors.

Does adversary simulation satisfy a NERC CIP vulnerability assessment requirement?

It may support required assessment activities and evidence, but responsible entities must determine whether their methodology satisfies the currently effective requirement. Simulation should not be presented as a substitute for any specifically required method.

Is live OT testing required for useful validation?

Not for every question. A cyber digital twin can evaluate attack paths without executing adversary actions on production assets. Limited live verification may still be appropriate when authorized, operationally safe, and required by the assessment plan.

How often should simulations be rerun?

Useful triggers include material architecture changes, firewall modifications, new remote-access paths, significant vulnerability disclosures, remediation completion, and scheduled compliance review cycles.

What makes simulation evidence defensible?

Defensible evidence identifies the scope, data sources, assumptions, test method, scenario, control objective, result, reviewer, date, limitations, and remediation outcome. It should allow a qualified reviewer to understand how the conclusion was reached.