IEC 62443 and NIST SP 800-82 are the two documents most OT security programmes cite, yet one is a certifiable requirements series and the other is government guidance, and treating them as interchangeable produces either an audit that proves nothing or a programme nobody can certify. This guide compares the two on the questions that decide which one leads: who is bound, what can be certified, how each scopes and segments a plant, how supplier and asset owner duties split, and how to crosswalk one to the other so a single control set answers both. It is written for OT security leads, control system engineers, integrators and product security teams who have to pick a primary reference or defend a choice to auditors and customers. For each document on its own, see the IEC 62443 Guide and the NIST SP 800-82 OT Security Guide; for the wider field including NERC CIP and the NCSC CAF, see OT Security Standards Compared.
Key takeaways
- 62443 is a requirements series you can be certified against; 800-82 is guidance you tailor. NIST says SP 800-82 should not be used purely as a checklist and is voluntary for non-government organisations, while 62443 parts carry testable requirements and ISASecure certifies against them through ISO/IEC 17065 accredited bodies.
- Role decides more than sector. 62443 assigns parts by role: asset owners, integration and maintenance service providers, and product suppliers each have their own documents. 800-82 is written for the owner and operator of the OT system.
- Zones and conduits are the main structural difference. 62443-3-2 partitions the system under consideration into zones and conduits and sets a target security level for each. 800-82 recommends segmenting by levels, tiers or zones and restricting traffic to adjacent levels, without a formal security level scheme.
- 800-82 brings the SP 800-53 control catalogue. Its Appendix F overlay tailors SP 800-53 Rev. 5 for OT with low, moderate and high baselines, which is what makes it natural for US federal systems and organisations already running the Risk Management Framework.
- Most mature programmes use both. 800-82 itself points to ISA 62443-3-2 for OT risk assessment. A common pattern is 62443 for design, procurement and supplier assurance, and 800-82 with its overlay for programme governance and control evidence.
The short answer
If you build or sell automation products, integrate control systems, or need a certificate a customer will recognise, lead with IEC 62443: it is the only one of the two with a certification scheme and role-specific requirements. If you operate OT inside a US federal agency or an organisation that already authorises systems under the NIST Risk Management Framework and SP 800-53, lead with SP 800-82: its overlay plugs straight into the control catalogue and assessment process you already run. If you are an asset owner outside both cases, use 800-82 as the readable programme handbook and adopt 62443-2-1, 3-2 and 3-3 for the engineering decisions, particularly zone design and what you demand from suppliers.
What each document is
| Attribute | ISA/IEC 62443 | NIST SP 800-82 |
|---|---|---|
| Publisher | ISA (ISA99 committee), adopted by IEC; IEC recognised it as a horizontal standard in 2021 | NIST, US Department of Commerce |
| Form | A series of standards and technical reports, each part with its own edition | One Special Publication with appendices |
| Current status (checked November 2026) | Parts include ANSI/ISA-62443-2-1-2024, 2-4-2018, 3-2-2020, ISA-62443-3-3-2013, 4-1-2018 and 4-2-2018 | Revision 3, final, 28 September 2023; Revision 4 initial public draft released 21 September 2026, comments open to 30 November 2026 |
| Language | Requirements, graded by security level | Recommendations ("should"), to be tailored by risk |
| Audience | Asset owners, integration and maintenance service providers, product suppliers | Owners and operators of OT, plus those who design and support it |
| Control catalogue | Seven foundational requirements broken into system (3-3) and component (4-2) requirements | SP 800-53 Rev. 5 via the Appendix F OT overlay |
| Proof | Third-party certification (ISASecure SDLA, CSA, ICSA, SSA, ACSSA, HCSA) or self-declared conformance | Self-assessment, or agency authorisation under the RMF |
| Cost to read | Paid standards | Free |
IEC 62443 in brief
The ISA Global Cybersecurity Alliance quick start guide sets out the roles. The asset owner is "the organization that is accountable and responsible for the IACS"; the product supplier is "the organization that manufactures and supports a hardware and/or software product"; integration and maintenance service providers sit between them. Each role maps to parts: asset owners to 2-1, 2-2, 2-3, 2-4, 3-2 and 3-3; integration service providers to 2-1, 2-3, 2-4, 3-2 and 3-3; maintenance service providers to 2-2, 2-3 and 2-4; product suppliers to 3-2, 3-3, 4-1 and 4-2. The technical requirements hang off seven foundational requirements: FR 1 Identification and Authentication Control, FR 2 Use Control, FR 3 System Integrity, FR 4 Data Confidentiality, FR 5 Restricted Data Flow, FR 6 Timely Response to Events and FR 7 Resource Availability.
NIST SP 800-82 in brief
Revision 3 is titled Guide to Operational Technology (OT) Security and widens the scope from industrial control systems to building automation, transport, physical access control and environmental monitoring. Section 3 covers programme development (charter, business case, governance, a cross-functional team, OT-specific policies, training, maintenance tracking, incident response and recovery). Section 4 applies the RMF steps Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor to OT. Section 5 describes a defence-in-depth architecture, and Section 6 applies the Cybersecurity Framework functions to OT. Appendix F is the OT overlay of SP 800-53 Rev. 5, with tailored baselines for low, moderate and high impact systems and OT-specific discussion for each control family from AC to SR.
Certifiable standard vs guidance
This is the difference buyers and auditors care about most. ISASecure lists six schemes, all assessed by certification bodies accredited to ISO/IEC 17065:
| ISASecure scheme | Assessed against | Who seeks it |
|---|---|---|
| Security Development Lifecycle Assurance (SDLA) | 62443-4-1 | Product suppliers, for their development process |
| Component Security Assurance (CSA) | 62443-4-2 | Suppliers of controllers, network devices, host and embedded components |
| IIoT Component Security Assurance (ICSA) | 62443-4-2 | Suppliers of IIoT devices and gateways |
| High Criticality Component Security Assurance (HCSA) | 62443-4-2 plus eight additional requirements | Suppliers of components for high-consequence uses |
| System Security Assurance (SSA) | 62443-3-3 | Suppliers of control system products sold as a system |
| ACS Security Assurance (ACSSA) | 62443-2-1, 2-4, 3-2 and 3-3 | Automation solutions as deployed, involving owner and integrator |
SP 800-82 has no certificate. Evidence of alignment is the organisation's own tailoring decisions, a control assessment against the overlay baseline, and, for federal systems, an authorisation decision. That is not a weakness: an authorisation package with assessed controls is strong evidence. It simply means a supplier cannot hand a customer an "800-82 certificate", and any claim of one should be read as marketing.
What this means in contracts: require named parts and, where it matters, named certificates. "Compliant with IEC 62443" means nothing without a part number, a role and a security level. "Aligned with NIST SP 800-82" should be backed by the tailored overlay baseline and the assessment results. See the ISA/IEC 62443 Certification Guide and the OT Product Procurement Guide.
Zones, conduits and levels: how each scopes and segments
62443: risk-driven zones with a target level
The quick start guide defines a zone as "a grouping of logical or physical assets based upon risk or other criteria" and a conduit as "a logical grouping of communication channels that share common security requirements". Part 3-2 runs a sequence of zone and conduit requirements: identify the system under consideration, perform an initial risk assessment, partition it into zones and conduits, run a detailed risk assessment where initial risk exceeds tolerable risk, document requirements, assumptions and constraints, and obtain asset owner approval. The outputs are a cybersecurity requirement specification and a target security level (SL-T) with residual risk for every zone and conduit.
Security levels describe the attacker a zone must resist: SL 1 "protection against casual or coincidental violation", SL 2 against "intentional violation using simple means with low resources, generic skills, and low motivation", SL 3 against "sophisticated means with moderate resources", and SL 4 against "sophisticated means with extended resources". Products declare a capability level against 4-2, the system design achieves a level against 3-3, and the gap between target and achieved is closed with compensating countermeasures that are written down. See the IEC 62443-3-2 OT Risk Assessment Guide and the IEC 62443-3-3 and 4-2 Security Levels Guide.
800-82: defence in depth across levels
SP 800-82r3 Section 5.2.3 treats grouping components "into levels, tiers, or zones" as a precursor activity and uses the Purdue model as its reference figure. Its concrete recommendations are a DMZ as the enforcement boundary between corporate and OT networks, firewall rulesets that "only permit connections between adjacent levels, tiers, or zones" (so Level 4 cannot talk directly to Levels 2, 1 or 0), outbound rules as stringent as inbound rules, unidirectional gateways as an alternative to firewalls, and physical rather than logical separation where safety requires it. It states that "a similar concept would be applied to ISA/IEC 62443" architectures.
Which model to draw
| Question | 62443 zones and conduits | 800-82 levels and DMZ |
|---|---|---|
| Basis for a boundary | Shared risk and security requirements | Function and position in the hierarchy |
| Output | SL-T per zone and conduit, requirement specification | Firewall and DMZ design, tailored control baseline |
| Handles flat or non-hierarchical sites | Yes, zones need not follow Purdue levels | Yes in principle, but the guidance and figures assume layers |
| Supplier can design to it | Yes, a supplier can quote SL-C per component | Indirectly, through owner-specified controls |
| Best use | New builds, major upgrades, integrator handover | Brownfield rationalisation, first segmentation project |
In practice teams start with 800-82's layered DMZ design because it is quick to explain to operations, then refine it into 62443 zones once they need to justify why two cells on the same level need different protection. The OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide covers the build and the OT Zones and Conduits Worksheet Template gives a recording format.
Supplier vs asset owner use
Product suppliers: 62443 is the reference. Part 4-1 governs the secure development lifecycle and 4-2 the technical capabilities of components. 800-82 has nothing equivalent for suppliers; at most, its overlay tells an owner which capabilities to ask for.
Integrators and service providers: 62443-2-4 sets programme requirements for service providers and 3-3 the system requirements they design to. Under 800-82 an integrator works to whatever the owner's tailored baseline demands, so the quality of the result depends on how well the owner wrote it.
Asset owners: both apply. 62443-2-1 sets security programme requirements for asset owners (the 2024 edition is current), and 3-2 drives risk assessment. 800-82 is broader on governance, workforce, incident response and recovery, and easier to hand to plant staff. The IEC 62443-2-1 Asset Owner Security Programme Guide covers the 62443 route.
Regulated US federal operators: 800-82 with its overlay is the natural fit because it uses the same SP 800-53 controls, RMF steps and authorisation process as the rest of the agency's systems.
Crosswalk: making one control set answer both
The two documents meet most cleanly at the control level. The table maps each 62443 foundational requirement to the SP 800-53 Rev. 5 families the overlay tailors, and to CSF 2.0 outcomes. It is an indicative mapping for building a single register, not an official crosswalk from either publisher.
| 62443 foundational requirement | SP 800-53 Rev. 5 (via 800-82 overlay) | CSF 2.0 |
|---|---|---|
| FR 1 Identification and Authentication Control | IA-2, IA-3, IA-5 | PR.AA-01, PR.AA-03 |
| FR 2 Use Control | AC-3, AC-17 | PR.AA-05 |
| FR 3 System Integrity | SI family, CM family | PR.PS outcomes |
| FR 4 Data Confidentiality | SC-8 | PR.DS outcomes |
| FR 5 Restricted Data Flow | SC-7, AC-4 | PR.IR-01 |
| FR 6 Timely Response to Events | SI-4, AU family, IR family | DE.CM-01 |
| FR 7 Resource Availability | CP family, SC-5 | PR.IR outcomes |
| 3-2 risk assessment | RA-3 | ID.RA-01 |
| 4-1 and 2-4 supplier duties | SR-3 | GV.SC-05 |
Two practical rules keep the crosswalk honest. First, the 62443 side is graded: FR 5 at SL 1 and at SL 3 are different requirements, so record the SL with each mapping. Second, the 800-82 side is tailored: an overlay control marked as a candidate for compensating controls in OT must carry the compensating control in the register, not a blank.
Where identity fits
FR 1 and FR 2 are the first two foundational requirements for a reason. Shared operator accounts on HMIs, engineering workstation logins reused across sites, vendor remote access accounts and the service accounts that historians, OPC servers and backup tools use to reach controllers are where both documents' access controls are most often bypassed. 62443 lets you set a stronger identification and authentication requirement for the conduit that carries vendor sessions than for a local cell. 800-82's overlay gives the matching AC-17 and IA controls with OT tailoring. Treat machine and service credentials as in scope for both, with an owner, rotation and logging. See the OT and ICS Identity and Access Guide and the OT Remote Access Guide.
Worked scenarios
A drives manufacturer selling to utilities. Customers write 62443-4-2 security levels into tenders. The manufacturer pursues SDLA for its development process and CSA for its flagship drive, publishes the SL-C per foundational requirement, and maps its hardening guide to 800-82 overlay controls so US federal customers can reuse it in their authorisation packages.
A water utility with a 1990s SCADA estate. There is no budget for a re-platform and no certificate to gain. The utility uses 800-82 Section 3 to stand up the programme, Section 5 to put a DMZ and adjacent-level firewall rules in place, and the overlay moderate baseline as its control register. When it later replaces the telemetry network, it runs a 62443-3-2 assessment on the new design and writes SL-T values into the integrator contract.
A federal research campus with building automation. The building systems are federal information systems, so the campus categorises them under the RMF, selects the overlay baseline and authorises them. 62443 appears only in procurement: new controllers must hold a 4-2 component certificate.
Decision criteria
- You sell products or integration services: 62443, by part matching your role. 800-82 is a mapping exercise for federal customers.
- You must show a third-party certificate: 62443. 800-82 offers none.
- You already run the RMF and SP 800-53: 800-82 and its overlay, with 62443-3-2 for risk assessment where consequence analysis matters.
- You are starting from nothing as an asset owner: 800-82 for the programme (free, readable), 62443-3-2 and 3-3 for design decisions.
- You run many sites with different risk: 62443 zones and SL-T let you justify different controls per site in one framework.
- Small organisation, limited staff: 800-82's Section 5 architecture recommendations deliver most of the early risk reduction; buy the specific 62443 parts only when procurement or a customer demands them.
How to implement a dual-reference programme
- Declare the roles. Write down whether you act as asset owner, integrator, service provider or supplier for each system, and which 62443 parts follow.
- Pick the register. Use the 800-82 overlay baseline (low, moderate or high) as the control list if you are in the NIST ecosystem; otherwise use 3-3 system requirements. Map the other document to it, not both to each other.
- Run 62443-3-2 on one system first. Pilot the zone and conduit assessment on a single line or site, agree SL-T values with operations and safety, and record residual risk.
- Segment to the design. Apply the DMZ and adjacent-level rules from 800-82 Section 5, then tighten conduits to meet SL-T. Change firewall rules in monitor or log-only mode before blocking, during a planned outage window, with a documented rollback to the previous ruleset.
- Push requirements to suppliers. Put part numbers, SL-C and certificates into specifications and renewal contracts.
- Assess and record evidence. Keep one evidence item per control mapping, labelled for both documents.
- Track the revision. SP 800-82 Revision 4 is in public draft and NIST describes it as restructured around CSF 2.0 with added zero trust and network monitoring guidance. Plan a remap when it is final rather than chasing the draft.
Detection and measurement
Both documents expect monitoring: 62443 through FR 6 and 800-82 through its detect guidance and SI-4 tailoring. Log conduit firewall decisions, remote access sessions, engineering workstation logins and controller programme changes. Metrics that show the programme is working:
- Percentage of zones and conduits with an approved SL-T and a current diagram.
- Gap count between SL-T and achieved level, and how many gaps have a documented compensating countermeasure.
- Percentage of overlay baseline controls implemented or formally tailored out.
- Share of new OT purchases with a named 62443 part and certificate in the contract.
- Number of flows crossing more than one Purdue level without passing through the DMZ (target zero).
- Percentage of vendor and service accounts with a named owner and session logging.
Common failure patterns
- Claiming "62443 compliant" with no part, role or SL. Customers and auditors cannot test it, and it often hides a single certified component inside an uncertified system.
- Treating 800-82 as a checklist. NIST warns against this; copying every overlay control without tailoring produces controls that break safety or availability and are then quietly disabled.
- Drawing zones once. A zone model that is not updated through management of change drifts from the plant within a year. See OT Management of Change for Cyber.
- Mapping both documents to each other and to CSF separately. Three crosswalks diverge; keep one register and map outward.
- Leaving service accounts out of FR 1. Human logins get MFA while historian and backup accounts keep shared static passwords across zones.
Practitioner checklist
- Record your role per system and the 62443 parts that apply.
- Choose one control register (800-82 overlay baseline or 62443-3-3) and map the other to it.
- Complete a 62443-3-2 assessment for your highest-consequence system with SL-T per zone and conduit.
- Implement a DMZ and adjacent-level firewall rules per 800-82 Section 5, with tested rollback.
- Write named 62443 parts, SL-C and ISASecure certificates into OT procurement.
- Bring vendor, service and machine accounts under FR 1 and FR 2 controls.
- Review zone diagrams at every significant change and at least annually.
- Diary a remap once SP 800-82 Revision 4 is published as final.
Standards and references
- NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
- NIST: SP 800-82 Rev. 3 full text (PDF)
- NIST: SP 800-82 Rev. 4 initial public draft
- ISA: ISA/IEC 62443 Series of Standards
- ISA Global Cybersecurity Alliance: Quick Start Guide to the ISA/IEC 62443 Standards
- ISASecure: Certification schemes
Related NHI Mgmt Group resources: IEC 62443 Guide · NIST SP 800-82 OT Security Guide · OT Security Standards Compared · IEC 62443-4-1 and 4-2 Secure Product Development Guide · OT Security Guide