Which IEC 62443 parts should asset owners prioritize first?

Asset owners should usually prioritize the IEC 62443 parts that establish governance, risk assessment, and high-level requirements before going deep into detailed technical controls. The exact sequence depends on your current maturity, installed base, and regulatory constraints, but a practical order for most regulated, brownfield environments is:

1. Start with IEC 62443-2-1/62443-2-1 Ed.2 (security program for IACS)

IEC 62443-2-1 defines the requirements for an industrial automation and control systems (IACS) cybersecurity management system. For asset owners this is usually the highest priority because it frames everything else:

• Roles and responsibilities across engineering, IT, OT, and quality
• Policies for access control, remote access, patching, backups, and incident handling
• Lifecycle processes that fit into existing change control, validation, and qualification
• Integration with existing QMS, safety, and configuration management systems

Without this program layer, technical implementations are hard to sustain, difficult to audit, and often conflict with established manufacturing and validation processes.

2. In parallel or next, IEC 62443-3-2 (risk assessment & system design)

IEC 62443-3-2 focuses on risk assessment and the definition of zones and conduits. For asset owners running mixed-vendor and legacy infrastructure, this is usually the next critical step:

• Identify and classify assets in OT/ICS, including legacy PLCs, DCS, SCADA, HMIs, historians, MES interfaces, and OEM skids
• Define security zones and conduits that respect physical, process, and validation constraints
• Evaluate risks in the context of safety, quality, and regulatory impact, not only confidentiality
• Prioritize where additional controls are feasible without unacceptable downtime or revalidation burden

Because most regulated plants cannot easily re-architect entire networks or replace legacy controllers, 3-2 helps you find realistic, high-leverage changes (for example, segmenting OEM skids or hardening remote access) rather than chasing idealized target architectures.

3. Then IEC 62443-3-3 (system security requirements & SLs)

IEC 62443-3-3 defines system-level security requirements and security levels (SLs). Once you have a program (2-1) and risk-based zoning (3-2), 3-3 lets you:

• Map zones and conduits to target security levels that are realistic for your assets and vendors
• Translate high-level policies into concrete system requirements for integrators, OEMs, and internal engineering
• Align procurement specifications and FAT/SAT criteria with consistent, standard-based requirements
• Identify where legacy equipment cannot meet target SLs and must be compensated with procedural or architectural controls

In brownfield environments, you will rarely achieve uniform SLs across all zones. 3-3 helps document the rationale, compensating controls, and residual risk in a structured way, which is valuable for internal governance and external scrutiny.

4. Introduce product-focused parts as you renew or add assets

After the program and system layers are in place, product-level standards become more useful for asset owners, especially in procurement and vendor management:

• IEC 62443-4-1: Secure development lifecycle requirements for IACS products. Useful to evaluate vendor practices and include in contracts, RFQs, and technical agreements.
• IEC 62443-4-2: Technical security requirements for IACS components (controllers, network devices, software). Useful to define minimum capabilities for new purchases and upgrades.

Trying to drive strict 4-1/4-2 conformance on an existing, heterogeneous installed base usually fails or causes significant disruption and revalidation work. These parts are most effective when applied to new projects, major retrofits, or asset refresh cycles.

5. Use other 2.x parts selectively, based on your gaps

Other parts in the 2.x family can be helpful, but usually after 2-1, 3-2, and 3-3 are in motion:

• IEC 62443-2-3 (if available to you): Often referenced for patch and update management processes across mixed IT/OT environments.
• IEC 62443-2-4: Requirements for service providers. Useful if you rely heavily on OEMs, system integrators, and managed service providers for design, maintenance, or remote support.

The practical value of these depends heavily on your outsourcing model and on how much leverage you have over suppliers and integrators.

Tradeoffs and dependencies in regulated, brownfield environments

In aerospace, pharma, medical devices, and similar sectors, aggressive “start with product conformance” or “rip-and-replace” strategies often underperform because:

• Qualification and validation burdens make frequent hardware/software changes expensive and slow.
• Downtime windows are tightly constrained, especially on bottleneck or validated lines.
• Interdependencies between MES, historians, batch systems, PLCs, and QMS are poorly documented and risky to disturb.
• OEM skids and special machines may not support modern security features without major redesign.

Prioritizing 2-1, 3-2, and 3-3 first allows you to improve cybersecurity posture within these constraints, using zoning, network controls, procedural safeguards, and controlled change instead of wholesale system replacement.

How to choose the starting point for your site

The recommended priority (2-1, 3-2, 3-3, then 4-x) is a strong pattern, but you should still confirm it against your local context:

• If you have no consistent OT security governance, start with 2-1 to align policy, roles, and change control with your existing QMS and engineering processes.
• If you already have basic governance but no clear view of assets and zones, 3-2 may be more urgent to support network changes, remote access control, and firewall rules.
• If you are planning a new greenfield line or major control system replacement, bring 3-3 and 4-2 into the project requirements early, but still anchor them in 2-1 and 3-2 so they fit your enterprise practices.

Whichever part you start with, integration with existing change control, validation, and documentation practices is critical. Treat 62443 adoption as an evolution of your operational and quality systems, not a parallel cybersecurity track.