Define the operating boundary
A useful definition names the triggering event, required inputs, governing source, accountable owner, decision or action, exception path, evidence retained, and downstream handoff. Buyers should adapt those elements to their own population, jurisdictions, policies, systems, and control model before writing requirements.
The most important distinction is between a label and an operational capability. A provider may document compliance mapping and control evidence while depending on customer-supplied policy, licensed content, third-party data, integration partners, manual review, or services. The demonstration should expose those dependencies rather than hiding them behind a completed interface.
What a demonstration should prove
- Begin with representative source records and a named policy, standard, or controlled rule.
- Show the normal path, an ambiguous case, missing data, an exception, an override, and a material source change.
- Identify who can change rules, who can approve or reject, and how accountability is preserved.
- Trace every output back to inputs, versions, timestamps, user actions, and governing evidence.
- Export the resulting record and reconcile it with downstream systems and retained obligations.
Authority and operating context
NIST SP 800-82 Rev. 3
NIST describes OT topologies, threats, vulnerabilities, safeguards, and risk-management considerations while recognizing performance, reliability, and safety requirements. Provider and architecture claims can be tested against a mature OT-specific control context without pretending the guide certifies a product or environment.
NIST SP 800-82 Rev. 4 pre-draft
NIST initiated revision work to align the OT guide with current frameworks, standards, practices, and threat conditions and asked whether dynamic resources should replace several appendices. Teams should monitor the revision without silently relabeling Rev. 3 mappings as Rev. 4 or presenting proposed structural changes as final requirements.
NIST CSF 2.0
CSF 2.0 organizes cybersecurity outcomes across Govern, Identify, Protect, Detect, Respond, and Recover and can be applied alongside OT-specific guidance. The Govern function and outcome language help connect OT defense evidence to enterprise accountability without replacing the system-specific detail in SP 800-82 or ISA/IEC 62443.
ISA/IEC 62443-2-1:2024
Part 2-1 defines security-program requirements for asset owners across governance, risk, implementation, maintenance, and continuous improvement of IACS security. It creates an owner-specific program lens that product capability lists cannot satisfy by themselves.
IEC PAS 62443-2-2:2025
The specification provides guidance for developing, validating, operating, and maintaining a set of technical, physical, and process security measures for IACS facilities. It focuses the buyer on a maintained protection scheme rather than an isolated product or control purchase.
ISA/IEC 62443-3-2
Part 3-2 addresses system-level risk assessment and the use of zones, conduits, and target security levels in IACS design. It provides the central architecture language for comparing discovery, segmentation modeling, enforcement, remote access, and controlled-transfer products.
ISA/IEC 62443-3-3
Part 3-3 defines system security requirements and security levels for industrial automation and control systems. It helps structure system-level requirements, but capability marketing and certification labels need exact scope, version, and scheme evidence.
ISA/IEC 62443-4-1
Part 4-1 defines secure-development-lifecycle requirements for IACS product suppliers. Buyers need process-scope and certificate evidence rather than assuming one certified product makes an installed system secure.
IEC 62443-4-2
Part 4-2 defines technical security requirements for IACS components using the foundational requirements and security-level framework. Component claims should identify exact product, version, certification scheme, target level, and system dependency.
CISA CPGs
CISA publishes a prioritized set of cybersecurity practices intended to reduce common and consequential risks across critical-infrastructure sectors. The CPGs give buyers a risk-reduction lens for access, segmentation, backups, inventory, monitoring, incident response, and supplier decisions.
CISA Secure by Demand for OT
The guide presents security considerations and questions for OT buyers addressing product configuration, logging, identity, updates, vulnerability handling, support, and secure-by-design behavior. It turns cybersecurity into a procurement and lifecycle evidence decision rather than an after-deployment add-on.
NERC CIP-015-1
CIP-015-1 requires documented processes for internal network security monitoring of specified high- and medium-impact BES cyber-system environments, including data feeds, anomaly detection, evaluation, and evidence. The standard creates a concrete evidence and operating-model test for network telemetry, anomaly detection, evaluation, escalation, and record retention.
TSA Pipeline-2021-02F
The directive continued performance-based requirements covering cyber risk assessment, plans, architecture, access, monitoring, incident response, testing, and related evidence for notified pipeline operators. The expired date and separate proposed-rule path make status verification essential; vendor pages must not present an old mapping as proof of current obligation or compliance.
EU Cyber Resilience Act
The CRA establishes horizontal cybersecurity requirements for products with digital elements, including design, vulnerability handling, economic-operator, conformity, reporting, and market-surveillance provisions. Industrial product and device providers need exact role, scope, support-period, vulnerability-handling, technical-documentation, conformity, and reporting evidence rather than a generic CRA-ready claim.
NIS2
NIS2 establishes cybersecurity risk-management, reporting, governance, supervision, and supply-chain requirements across essential and important entities. OT operators need jurisdiction-specific mappings from legal requirements to accountable controls, reporting, supplier, and evidence workflows.
C2M2 v2.1
C2M2 supports evaluation and improvement of cybersecurity capabilities across domains such as risk, assets, access, threat and vulnerability, situational awareness, response, continuity, third parties, workforce, architecture, and program management. It helps frame program and operating-capability evidence without turning a product feature into a maturity score.
ATT&CK for ICS
ATT&CK for ICS organizes publicly reported adversary tactics, techniques, software, groups, mitigations, and data sources relevant to industrial control systems. Detection claims can name exact techniques, data sources, evidence, and coverage limits instead of claiming complete ATT&CK coverage.
Operating domains
Network architecture, segmentation, and conduits
The design and maintained evidence for security zones, conduits, trust boundaries, routable paths, industrial DMZs, enforcement points, fail states, and allowed communication supporting physical operations.
Vulnerability, exposure, and remediation governance
The operating process that connects a device, product, component, vulnerability, exploit context, exposure path, process consequence, compensating control, vendor guidance, maintenance window, decision, and retained evidence.
Remote access, identity, and third-party control
The operating domain governing who can reach which industrial resource, for which approved task, through which path, with which credential, privilege, device, time window, supervision, file flow, emergency process, and retained session evidence.
Endpoint, removable media, and controlled transfer
The controls and evidence for protecting constrained industrial endpoints and moving software, files, updates, logs, and operational data across security boundaries.
Product security and software supply chain
The lifecycle evidence connecting industrial product design, components, firmware, provenance, secure development, vulnerabilities, updates, support, suppliers, integrators, customers, and end-of-life responsibilities.
Resilience, recovery, and cyber-informed engineering
The integration of cybersecurity with physical mission, safety, reliability, design, spares, configuration baselines, backups, manual capability, tested restoration, and recovery decision authority.
Governance, authorities, and assurance
The system for identifying applicable authorities and commitments, assigning accountable roles, translating requirements into controls, collecting evidence, testing effectiveness, managing exceptions, reporting risk, and preserving change history.
Safety, reliability, and engineering coordination
The decision boundary connecting cyber defense with process safety, functional safety, reliability, operations, maintenance, engineering change, and physical consequence.
Evidence and comparison limits
Official provider documentation can establish product positioning. Provider confirmation can clarify package or availability. Independent observation requires a disclosed scenario, environment, date, inputs, and reproducible result. None of those sources alone establishes buyer-specific legal, clinical, regulatory, quality, or operational fitness.
Buyer questions
- What exact outcome and evidence should compliance mapping and control evidence produce?
- Which source, version, and customer facts govern the workflow?
- Which decisions remain human and who is accountable for them?
- What is native, configured, integrated, service-delivered, or planned?
- How does a changed source affect open and historical records?
Recent changes
EU Cyber Resilience Act Chapter IV begins applying — Industrial product suppliers and buyers need exact legal-role, product, conformity, reporting, support, and evidence records tied to the staged dates.
Dragos releases its 2026 OT cybersecurity year in review — Readers should preserve sample, denominator, method, source population, and provider-research classification beside every reported finding.
NIST begins the SP 800-82 Rev. 4 pre-draft process — Programs should preserve Rev. 3 as current final guidance while tracking the revision through explicit development states.
CISA releases eleven ICS advisories — Asset, vulnerability, engineering, maintenance, and evidence records must connect before an advisory can become a safe, authorized decision.
FERC approves NERC CIP-015-1 — Covered entities need evidence for selected network feeds, anomaly detection, evaluation, escalation, and implementation within controlling scope and dates.
IEC publishes PAS 62443-2-2:2025 — Asset owners should evaluate technology as part of a maintained technical, physical, and process protection scheme.
CISA partners publish Secure by Demand for OT buyers — Security requirements and evidence should be negotiated before purchase and retained through acceptance, operation, support, and end of life.