OT Security Assessment Guide: CSET and IEC 62443-3-2

An OT security assessment that is badly scoped tells you nothing useful, and one that is badly executed can trip a process that was running safely. Asset owners need assessments for regulators, insurers, boards and their own planning, but the methods used in IT, such as active scanning of every address, do not transfer safely to controllers and safety systems. This guide explains how to choose between a questionnaire-based assessment with CISA's Cyber Security Evaluation Tool (CSET), a CISA Cross-Sector Cybersecurity Performance Goals (CPG) review, an IEC 62443-3-2 risk assessment and technical testing, and how to scope, staff, run and report them without endangering operations. It is written for OT security leads, site engineers and the consultants who assess them. Maturity scoring is covered in the OT Security Maturity Model and the zone-by-zone method in the IEC 62443-3-2 OT Risk Assessment Guide.

Key takeaways

Decide the question before the method. A compliance gap list, a risk-based design input and a technical test answer different questions, and mixing them produces long reports with no decisions.
CSET structures the conversation. CISA's free tool guides asset owners through standards-based questions on hardware, software, policies and user obligations and produces recommendations, but its answers are only as good as the evidence behind them.
IEC 62443-3-2 produces design requirements. It defines the system under consideration, partitions it into zones and conduits, and sets a target security level per zone, which is what engineering needs.
Passive first, active only by agreement. Collect configuration, architecture and passive traffic data before any active probing, and run active tests only on agreed targets, in agreed windows, with operations present.
Evidence beats interviews. Validate answers with firewall rules, switch configurations, account lists and traffic captures, and record which findings were verified.

Assessment types and when to use them

Type	Question it answers	Inputs	Output	Operational risk
CSET standards or questionnaire assessment	How do our practices compare with a chosen standard?	Interviews, documents, optional network diagram	Compliance view and prioritised recommendations	None (no contact with systems)
CPG review	Have we implemented CISA's baseline goals for IT and OT?	CPG checklist or matrix, evidence per goal	Goal-by-goal status and gaps	None
Architecture and configuration review	Does the network actually enforce the intended separation?	Firewall and switch configs, remote access design, account exports	Verified conduit list, rule findings	Low (read-only exports)
Passive traffic assessment	What assets exist and what is talking to what?	SPAN or tap captures analysed with tools such as CISA's Malcolm	Asset inventory, communication map, unexpected flows	Low (sensor placement only)
IEC 62443-3-2 risk assessment	What security level does each zone need, and what must be built?	SUC definition, consequence data, threat assumptions	Zones and conduits, SL-T per zone, documented requirements	None
Active vulnerability scan or penetration test	Can identified weaknesses actually be exploited?	Rules of engagement, test or replica systems where possible	Validated vulnerabilities and attack paths	Medium to high on live systems

First assessment of a site: CSET or CPG review plus architecture review and a passive capture. This gives a defensible baseline in weeks.
New build or major modification: IEC 62443-3-2, because the output feeds the design and supplier requirements.
Mature site or after remediation: targeted technical testing to validate that controls hold. See the OT Penetration Testing Guide.
Small organisations: a CPG review and a one-day architecture walkdown cover most of the value. Large estates should standardise one method across sites so results are comparable.

Using CSET well

CSET is developed by CISA and Idaho National Laboratory and is free. It collects facility-specific information on hardware, software, administrative policies and user obligations, compares it with relevant standards and regulations, assesses compliance and provides recommendations linked to actions. The current source repository on GitHub (version 12.4 at the time of writing) offers a standalone Windows installer, an enterprise deployment on Windows Server and Docker for Mac and Linux.

Choose the question set deliberately: CSET offers several standards and maturity models (including CPG and a ransomware readiness module). Pick the one that matches your obligation or goal, and avoid selecting many standards at once, which multiplies questions without adding insight.
Use the network diagram: drawing the architecture in CSET, with zones and the components in them, ties questions to real assets and exposes undocumented links.
Run it as a facilitated workshop: operations, control engineering, IT networking and the site manager answer together. Answers given by one person in an office are the main source of false confidence.
Mark evidence: record for each "yes" which document, configuration or observation supports it. Unverified answers should be reported as such.
Protect the output: a completed CSET assessment is a map of your weaknesses. Store the assessment file and database with the same controls as network diagrams, and restrict who can export it. The standalone install keeps data on the assessor's machine; agree where it lives before the workshop.

Using IEC 62443-3-2 for risk-based assessment

IEC 62443-3-2:2020 (edition 1.0, published June 2020) sets requirements for defining a system under consideration (SUC), partitioning it into zones and conduits, assessing risk for each, establishing a target security level (SL-T) for each zone and conduit, and documenting the resulting security requirements. The steps, ZCR 1 to ZCR 7, are covered in depth in the IEC 62443-3-2 OT Risk Assessment Guide. For an assessment project the practical points are:

Define the SUC tightly: one production line, one substation or one plant control system, with its boundary and all external connections listed. A whole enterprise is not a SUC.
Use real consequence data: process safety studies (HAZOP, LOPA) and business impact figures give the initial risk assessment its credibility. Assessors should not invent consequences.
Compare with tolerable risk: the asset owner's tolerable risk statement must exist before ZCR 4. If it does not, the assessment stops and becomes a governance finding. See the IEC 62443-2-1 Asset Owner Security Programme Guide.
Translate SL-T into requirements: the deliverable engineering uses is a list of requirements per zone and conduit, mapped to IEC 62443-3-3 system requirements, not a heat map.
Get approval: ZCR 7 requires asset owner approval of results and residual risk. Make that sign-off a named deliverable.

Scoping and rules of engagement

Scope and safety are agreed in writing before anyone arrives on site.

Scoping item	What to agree
Objective	Compliance gap, design input, baseline, or validation of controls
Boundary	Sites, lines, zones and external connections in and out of scope
Method per zone	Interview only, configuration review, passive capture or active testing; safety instrumented systems are interview and configuration review only unless the safety owner agrees otherwise
Timing	Maintenance windows, outages and periods to avoid (start-up, batch changes, peak demand)
Stop conditions	Who can halt the work, the signals that trigger a halt, and the contact path to the control room
Data handling	Where captures, configurations and reports are stored, how long, who sees them, and secure destruction at the end
Access	Named assessor accounts, time-limited, through the site's normal remote or local access path; no personal laptops on OT networks without inspection

Team, roles and evidence

OT assessments fail more often for lack of the right people than for lack of tools. Name these roles in the statement of work.

Asset owner sponsor: accepts scope and residual risk, and signs off the results (ZCR 7 in IEC 62443-3-2 terms).
Site operations lead: has authority to stop work and decides timing around production.
Control and safety engineers: explain the process, the consequences of failure and which systems are safety related.
IT and network owners: provide firewall, switch, directory and remote access exports, and place sensors.
Integrators and vendors: explain remote support paths and the configuration of the systems they maintain. See the OT Third-Party and Integrator Access Guide.
Assessor: independent of the team that designed the controls where the result will be used for assurance, with OT experience and, ideally, IEC 62443 training. See the ISA/IEC 62443 Certification Guide.

Evidence type	Examples	Strength
Observed	Packet captures, physical walkdown, live screen of a firewall rule set	Strongest: shows what is actually happening
System export	Configuration files, account lists, patch levels, backup logs	Strong, if exported during the assessment
Document	Policies, procedures, drawings, contracts	Medium: shows intent, not operation
Interview	Answers in workshops	Weakest: use to direct where to look, not as proof

Record the evidence type for each finding and each "implemented" answer. When a later assessment or an auditor reviews the work, the evidence trail is what makes the result defensible, and it also shows the site which answers rested only on memory.

Running the assessment safely

Document review: network drawings, asset lists, firewall rule sets, remote access design, account and password procedures, backup and incident plans.
Site walkdown: confirm what is physically there: cabinets, unmanaged switches, cellular modems, engineering laptops and vendor remote access boxes. Undocumented connections found here are often the most important findings.
Passive data collection: place sensors on SPAN or tap ports agreed with network owners, capture for long enough to see batch cycles and shift changes, and build the asset and communication map. NIST SP 800-82 Rev. 3 treats passive and active scanning separately (Appendix E.2.2 and E.2.3); start passive. See the OT Asset Visibility Guide.
Configuration review: export firewall, switch and remote access configurations read-only and compare them with the intended conduits.
Workshops: CSET or CPG sessions with the right people, answers marked verified or unverified.
Active testing (only if agreed): on test benches, spares or replica systems first. On live systems, use rate-limited, protocol-aware tools against named targets with an engineer watching the HMI, and stop at the first abnormal behaviour.
Analysis and validation: combine findings, remove duplicates, rate by consequence and likelihood, and check every high finding with the site before the report is issued.
Closing and clean-up: remove sensors and accounts, return or destroy captured data under the agreed terms, and record what was done.

Frequency and triggers

Cycle: set a fixed cycle per site based on criticality, with the most critical sites assessed most often, and keep the same method so results can be compared.
Change triggers: new connections to IT or cloud, a new remote access path, a major control system upgrade, a merger or new integrator, and any significant incident.
Light-touch interim checks: between full assessments, re-run the CPG checklist and re-export firewall and account data annually; these catch drift cheaply.
Revisions to guidance: NIST has released an initial public draft of SP 800-82 Rev. 4 for comment, and CISA has said it is updating the CPGs to align with NIST CSF 2.0. Check the current versions when you plan the next cycle.

Where identity fits

Identity findings dominate most OT assessments: shared operator logins, vendor accounts that never expire, service accounts used by historians and OPC servers with passwords unchanged for years, and remote access without multi-factor authentication. Make sure the assessment asks for account exports from domain controllers, jump hosts and engineering stations, and assesses machine credentials as well as people. Assessor accounts are themselves a risk and must be removed at the end. See the OT and ICS Identity and Access Guide and the OT Remote Access Guide.

Reporting and measurement

A useful OT assessment report has a one-page summary of the main risks in business terms, a findings table with consequence, evidence and verification status, and a remediation plan with owners and dates. Map each finding to the framework the site reports against.

Finding area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ATT&CK for ICS
Unknown or unmanaged assets	ID.AM-01	CM-8	T0846 Remote System Discovery
Internet-exposed devices or remote access	PR.IR-01	SC-7, AC-17	T0883 Internet Accessible Device, T0822 External Remote Services
Weak or shared accounts	PR.AA-01	IA-2, IA-5	T0859 Valid Accounts
Missing monitoring	DE.CM-01	SI-4	None (detection gap)
Unpatched, exploitable services	ID.RA-01	RA-5, SI-2	T0866 Exploitation of Remote Services
Assessment process itself	ID.IM-01, ID.IM-02	CA-2, CA-5, RA-3	Not applicable

Metrics

Coverage: percentage of sites or zones assessed within the agreed cycle (for example every three years, or after major change).
Verification rate: percentage of findings and "yes" answers backed by evidence.
Remediation progress: high findings closed within the agreed period.
Repeat findings: findings that reappear in the next assessment, a sign of fixes that were not sustained.
Operational incidents caused by assessments: should be zero; any non-zero value triggers a method review.

Common failure patterns

Running an IT scanner on the control network: broad active scans can make fragile devices stop responding. Keep active work to agreed targets and windows.
Questionnaire without evidence: a CSET or CPG result built on unchallenged interview answers that overstates controls.
Scope that misses the real paths in: assessing the control network but not the vendor remote access, cellular modems or the IT systems that production depends on. The Colonial Pipeline ransomware attack began with an unused VPN account on the IT side and still stopped the pipeline as a precaution, which is why dependencies between IT and OT belong in scope.
No tolerable risk statement: starting a 62443-3-2 assessment without the asset owner's risk criteria, so SL-T values are guesses.
Reports that never reach engineering: findings written for auditors, with no requirements per zone and no owners.
Leaked assessment data: captures, diagrams and reports left on consultants' laptops or in shared drives after the project.

Practitioner checklist

Write down the question the assessment must answer and pick the method to match.
Agree scope, method per zone, stop conditions and data handling in writing before site work.
Include vendor remote access, wireless and cellular links, and IT dependencies in scope.
Collect documents, configurations and passive traffic before any active testing.
Run CSET or CPG reviews as facilitated workshops and mark each answer verified or unverified.
Use IEC 62443-3-2 for new builds and major changes, with real consequence data and an approved tolerable risk.
Limit active testing to test systems or named targets in agreed windows with operations present.
Assess human and machine accounts, and remove assessor accounts at the end.
Deliver findings with owners, dates and framework mapping, and track repeat findings.

OT Security Assessment Guide: Scoping and Running CSET and IEC 62443-3-2 Assessments Safely