Security Programme
IEC 62443-2-1:2024 is the asset-owner security programme part for an IACS in operation. It is a policy and procedure standard for the asset owner, including the operator in this context. It is not a product feature checklist and it does not prove that every legacy system already has every native technical capability.
Asset-owner programme boundary
The page boundary is the operating IACS and the asset owner security programme around it. Older and adjacent IEC 62443 material often uses cyber security management system language. The current public IEC abstract for IEC 62443-2-1:2024 uses security program policy and procedure requirements. In practical terms, the claim is about how the asset owner governs IACS security, not about a single product or a single installation task.
Asset owner and operator
The 2-1 boundary is the organisation accountable for the IACS in operation. The operator is included in the public 2024 IEC description.
Security programme
The programme sets policies and procedures for secure operation, risk treatment, responsibilities, monitoring, and sustained control.
IACS in operation
The subject is an industrial automation and control system in its operating context, including people and work processes.
Policies around technical capability
IEC 62443-2-1:2024 deliberately separates programme responsibility from native technical capability. The asset owner needs policies and procedures around the relevant security topics. The standard does not turn an old controller, unsupported engineering workstation, or long-lived SCADA system into a product that has every modern security feature.
- the asset inventory and IACS boundary the programme applies to;
- roles and responsibilities for operating, maintaining, and changing the IACS;
- risk treatment decisions for IACS-specific constraints such as availability, safety, and patch windows;
- policies for vulnerability handling, access, backup, remote access, malware protection, and change control;
- supplier and service-provider responsibilities that need to align with the asset-owner programme.
Legacy systems and compensating measures
IEC recognises that an IACS can have a lifespan beyond twenty years and that some legacy hardware or software may no longer be supported. That matters because a programme can address a missing capability through risk treatment and compensating measures, but it should not pretend that the capability exists in the product.
Unsupported components
Unsupported software or unavailable backup tooling changes how the asset owner manages risk. It does not make patching or backup capability appear by assertion.
Compensating measures
Compensating measures belong in the programme when native technical capability is not present or cannot be used without unacceptable operational impact.
Boundaries with other IEC 62443 parts
The asset-owner programme coordinates with other IEC 62443 parts, but it does not replace them. The same organisation may hold several roles, yet the claim still needs the correct part and assessment object.
- IEC 62443-2-4 belongs to service-provider security processes for integration and maintenance activities.
- IEC 62443-3-2 belongs to risk assessment for a defined system under consideration, zones, conduits, SL-T, and documented security requirements.
- IEC 62443-3-3 belongs to control system security requirements and system capability.
- IEC 62443-4-1 belongs to the product supplier secure development lifecycle.
- IEC 62443-4-2 belongs to technical component capability for IACS components.
Delegation is not transfer of scope
The asset owner can rely on suppliers, integrators, and maintenance providers for evidence and execution, but the 2-1 programme claim remains about the asset owner security programme for the IACS.
Product-law use remains separate
IEC 62443-2-1 can support product-law or customer evidence when the question involves operating controls, site responsibilities, or long-lived IACS risk management. It does not create a product certificate, a component capability level, or CRA presumption of conformity by itself. A legal file still needs the applicable law, the product or system boundary, the requirement being supported, and the source status of the standard used.