Do We Really Need All Three? Using NIST CSF 2.0, NIST SP 800-82 Rev. 3, and IEC 62443 Without Creating Framework Overload
- ICS cyber security, iec 62443, industrial cybersecurity, nist sp 800-82, ot cybersecurity, risk assessment
OT Cybersecurity Fundamentals — Estimated reading time: 10 minutes
Introduction
In Article 6, “Putting OT Cybersecurity Frameworks to Work: From Risk to Requirements,” we discussed how NIST CSF 2.0, NIST SP 800-82 Rev. 3, and IEC 62443 can support one OT cybersecurity operating model.
That discussion raises an important practical question:
Do organizations really need to use all three references?
Would this approach create unnecessary work?
Would it be more practical to select one standard, such as IEC 62443, and use it for the entire OT cybersecurity program?
These are reasonable questions.
Using several frameworks can create confusion when their roles are unclear. Teams may conduct overlapping assessments, maintain several control registers, collect the same evidence repeatedly, and produce reports that use different terminology for similar activities.
However, the main problem is usually not the number of references.
The problem is treating every reference as a separate cybersecurity program.
A more practical approach is to establish one operating model, then use each reference only where it provides useful guidance or requirements.
Different references answer different questions
NIST CSF 2.0, NIST SP 800-82 Rev. 3, and IEC 62443 overlap in several areas, but they were not developed to serve exactly the same purpose.
A simple way to understand their relationship is:
NIST CSF 2.0
What cybersecurity outcomes should the organization achieve?
NIST SP 800-82 Rev. 3
How should cybersecurity practices be interpreted within an OT environment?
IEC 62443
How should an industrial automation and control system security program, risk assessment, architecture, and security requirements be structured?
Each reference operates at a different level.
NIST CSF 2.0: Organizing the cybersecurity program
NIST CSF 2.0 provides a common language for managing cybersecurity risk through six Functions:
• Govern
• Identify
• Protect
• Detect
• Respond
• Recover
These Functions help management and technical teams communicate about cybersecurity outcomes.
For an OT organization, CSF 2.0 can help answer questions such as:
• Who owns OT cybersecurity risk?
• How are critical assets and dependencies identified?
• What safeguards should be established?
• How will abnormal activity be detected?
• How will the organization coordinate its response?
• How will trusted operations be restored?
CSF 2.0 is intentionally flexible. It describes desired outcomes without prescribing one architecture, technology, or implementation method.
This makes it useful for:
• Enterprise governance
• Cybersecurity program planning
• Current and target profiles
• Management reporting
• Coordination between IT, OT, safety, engineering, and management
Its flexibility is also its limitation. CSF 2.0 does not provide a complete engineering method for designing zones, conduits, or system security requirements.
NIST SP 800-82 Rev. 3: Interpreting cybersecurity for OT
NIST SP 800-82 Rev. 3 provides guidance for securing OT while accounting for performance, reliability, and safety requirements.
It discusses areas such as:
• OT architectures and system topologies
• Common threats and vulnerabilities
• Network segmentation
• Remote access
• Identity and access management
• System hardening
• Patch and vulnerability management
• Network monitoring
• Incident response
• Backup and recovery
This guidance is valuable because a general cybersecurity outcome may require a different implementation in an OT environment.
For example, an organization may decide that a vulnerable system requires treatment. In enterprise IT, the expected action might be immediate patching.
In OT, the decision may also require:
• Vendor confirmation
• Compatibility testing
• Engineering review
• A maintenance window
• Operational validation
• A rollback procedure
• Temporary compensating controls
NIST SP 800-82 helps teams understand these OT-specific considerations.
It is primarily a guidance document. It does not replace a complete asset-owner security program or a system-design risk-assessment standard.
IEC 62443: Structuring the industrial cybersecurity lifecycle
IEC 62443 is a family of standards addressing industrial automation and control system cybersecurity.
Different parts of the series apply to different activities and stakeholders.
For an asset owner, three parts are particularly relevant to this discussion.
IEC 62443-2-1
IEC 62443-2-1 defines security-program requirements for IACS asset owners.
It addresses the organizational policies, procedures, and responsibilities needed to establish and operate an industrial cybersecurity program.
This makes it more relevant to program-level assessment than IEC 62443-3-3.
IEC 62443-3-2
IEC 62443-3-2 addresses security risk assessment for system design.
It provides a structured approach to:
• Define the system under consideration
• Identify assets and system boundaries
• Partition the system into zones and conduits
• Identify threats, vulnerabilities, and consequences
• Assess risk
• Establish target security levels
• Develop cybersecurity requirements
This standard is especially useful during new projects, major modifications, segmentation programs, and detailed system assessments.
IEC 62443-3-3
IEC 62443-3-3 defines system security requirements and security levels.
It helps organizations determine which system requirements should apply based on the target security levels established through the risk assessment.
It supports activities such as:
• System requirement definition
• Technical gap assessment
• Security architecture review
• Design verification
• Evaluation of implemented security capabilities
There is an important distinction:
IEC 62443-3-3 is not an organizational cybersecurity maturity-assessment standard.
It can help determine whether a system satisfies applicable security requirements. It does not, by itself, determine the maturity of the entire OT cybersecurity program.
System security level and program maturity are different
A security level describes security requirements or capability in relation to a defined system, zone, conduit, or component.
Program maturity describes how consistently and effectively an organization governs and performs cybersecurity activities over time.
An organization could have a well-designed zone with strong technical controls but weak program maturity because:
• Access reviews are inconsistent
• Changes are poorly documented
• Incident exercises are not performed
• Supplier obligations are unclear
• Backup restoration is not tested
• Exceptions remain open without accountable owners
The reverse is also possible. An organization may have established governance processes but still operate legacy systems with significant technical gaps.
Therefore, a system-requirement assessment and a program-maturity assessment should not be treated as the same activity.
Is using all three too burdensome?
It can become burdensome when an organization creates:
• Three assessment programs
• Three control catalogues
• Three sets of evidence
• Three risk registers
• Three reporting structures
• Three separate groups responsible for similar activities
That approach creates duplication without necessarily improving security.
A better model is:
One governance structure
The organization defines common ownership, risk acceptance, escalation, and reporting arrangements.
One asset and architecture record
The same inventory and architecture information supports program management, risk assessment, engineering, and assurance.
One risk register
Risks are recorded once using a consistent method, even when several references support the assessment.
One requirements library
Requirements can include mappings to NIST CSF outcomes, IEC 62443 requirements, and relevant NIST guidance (e.g. NIST SP 800-82).
One evidence repository
Access records, test results, architecture diagrams, recovery exercises, and other evidence are collected once and reused.
The references become complementary views of the same program rather than separate programs.
A practical example
Consider unauthorized vendor access to an engineering workstation that can modify PLC logic controlling a transfer pump.
The organization identifies the risk scenario:
An unauthorized remote session could allow an unapproved PLC logic change, causing the pump to operate incorrectly and contributing to an unsafe tank-level condition.
NIST CSF 2.0 helps organize the desired outcomes:
• Governance defines who approves access and accepts risk.
• Identification establishes which assets and connections are involved.
• Protection controls the remote-access path and engineering privileges.
• Detection monitors sessions and controller changes.
• Response coordinates cyber investigation with process management.
• Recovery restores approved logic and verifies safe operation.
NIST SP 800-82 Rev. 3 helps the team evaluate practical OT considerations:
• How will stronger authentication affect emergency maintenance?
• Could a firewall rule interrupt required communication?
• How will the change be tested?
• What happens if the remote-access platform becomes unavailable?
• How will the team reverse the change if it creates an operational problem?
IEC 62443-3-2 structures the system assessment:
• Define the system under consideration.
• Identify the vendor connection and engineering workstation.
• Establish zones and conduits.
• Assess the risk.
• Determine the applicable target security level.
• Develop the cybersecurity requirements specification.
IEC 62443-3-3 helps define the relevant system security requirements.
The resulting evidence might include:
• An approved remote-access architecture
• Named accounts and access roles
• Multifactor authentication records
• Session logs
• PLC change records
• Firewall configurations
• Tested logic backups
• Operational validation results
• Documented remaining risk
This is one risk decision supported by several references. It is not three separate assessments.
When using one primary standard is practical
Organizations do not always need to apply every reference with the same level of detail.
The right approach depends on the objective.
For a system-level risk assessment
IEC 62443-3-2 can serve as the primary method.
IEC 62443-3-3 can then support the definition and assessment of system security requirements.
NIST SP 800-82 may be used as supporting guidance when the team needs additional OT implementation considerations.
A full CSF 2.0 assessment may be unnecessary if the immediate purpose is limited to one system-design decision.
For an enterprise OT cybersecurity program
NIST CSF 2.0 can provide the overall program structure.
NIST SP 800-82 can help interpret the outcomes for OT.
IEC 62443 can be applied selectively to asset-owner program requirements, detailed system assessments, architecture, procurement, and supplier obligations.
For an organization committed to IEC 62443
IEC 62443 can become the primary foundation.
The organization could use:
• IEC 62443-2-1 for the asset-owner security program
• IEC 62443-3-2 for system risk assessment
• IEC 62443-3-3 for system security requirements
• IEC 62443-2-3 for patch management guidance
• IEC 62443-2-4 for service-provider requirements
• IEC 62443-4-1 and 4-2 for product and component considerations
In this model, CSF 2.0 can remain a management and enterprise-risk communication layer. NIST SP 800-82 can remain a source of implementation guidance.
A proportionate adoption model
Organizations should match the approach to their size, risk, and capability.
Early-stage OT cybersecurity program
Begin with:
- Establish governance and ownership.
- Identify critical processes and assets.
- Use CSF 2.0 to organize the program.
- Use NIST SP 800-82 to understand OT considerations.
- Apply IEC 62443-3-2 first to the most critical systems.
Developing program
Expand into:
- Formal system boundaries and architecture records.
- Zones and conduits.
- Risk-based cybersecurity requirements.
- Remote-access and change-control assurance.
- Incident exercises and recovery testing.
- Supplier and lifecycle requirements.
Mature program
Integrate:
- Asset-owner program requirements.
- Repeatable system risk assessments.
- Requirements traceability.
- Technical verification.
- Control-effectiveness monitoring.
- Supplier assurance.
- Portfolio-level management reporting.
The organization does not need to implement everything at once.
Avoid assessment by document number
A common mistake is organizing the program around publications:
• The NIST CSF assessment
• The NIST SP 800-82 assessment
• The IEC 62443 assessment
This makes the documents more visible than the risks they are intended to manage.
A more useful structure is organized around operating activities such as:
• Governance
• Asset management
• Architecture
• Risk assessment
• Access management
• Vulnerability management
• Monitoring
• Incident response
• Recovery
• Supplier management
• Assurance and improvement
Each activity can reference whichever publication provides the most useful outcome, requirement, or guidance.
Key takeaway
Using NIST CSF 2.0, NIST SP 800-82 Rev. 3, and IEC 62443 together can strengthen an OT cybersecurity program.
The benefit comes from assigning each reference a clear role:
• NIST CSF 2.0 organizes program outcomes and communication.
• NIST SP 800-82 Rev. 3 provides OT-specific implementation guidance.
• IEC 62443 provides industrial security-program, risk-assessment, architecture, lifecycle, and system-requirement structures.
The practical objective is not to implement three independent frameworks.
It is to establish:
One operating model
One risk register
One requirements library
One evidence set
Several complementary references
For a system-level assessment, IEC 62443-3-2 and IEC 62443-3-3 may be sufficient as the primary standards.
For an asset-owner cybersecurity program, those two parts alone do not completely address organizational governance, program management, and maturity.
The right answer is therefore not always “use all three” or “choose only one.”
The right answer is:
Use the smallest combination that covers the decisions, responsibilities, and evidence your organization actually needs.
References
NIST Cybersecurity Framework 2.0
https://www.nist.gov/cyberframework
NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
https://csrc.nist.gov/pubs/sp/800/82/r3/final
ISA/IEC 62443 Series of Standards
https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards
ANSI/ISA-62443-2-1-2024, Security Program Requirements for IACS Asset Owners
https://www.isa.org/products/ansi-isa-62443-2-1-2024-security-industrial-automa
ANSI/ISA-62443-3-2-2020, Security Risk Assessment for System Design
https://www.isa.org/news-press-releases/2020/september/new
