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 firmware, SBOM, and component intelligence 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
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.
Joint OT asset inventory guidance
The joint guide describes a regularly updated OT asset inventory and taxonomy tied to function and criticality as a foundation for risk, vulnerability, architecture, and incident-response work. It raises the evaluation bar from device counts to governed identity, taxonomy, criticality, ownership, dependency, lifecycle, and use across operating functions.
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.
Operating domains
Asset inventory, context, and lifecycle
The maintained operating record for each OT asset's identity, role, location, owner, criticality, communications, dependencies, versions, configuration, support state, exposure, and recovery relevance.
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.
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.
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 firmware, SBOM, and component intelligence 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
Accenture announces agreements involving Dragos, runZero, and NetRise — The proposed combination could alter ownership, packaging, data, services, partner relationships, and the OT security market architecture.
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.
IEC publishes PAS 62443-1-6:2025 — IIoT reviews need explicit device, gateway, edge, cloud, identity, data, update, supplier, and owner responsibilities.