IEC 62443: the industrial cybersecurity standard explained

For MSPs supporting industrial clients, business leaders responsible for operational risk and OT engineers implementing the standard, IEC 62443 is ultimately about securing OT and ICS environments without undermining availability or safety. Unplanned downtime, legacy systems that cannot be patched, air-gapped facilities with limited or no local IT support, and the need for predictable recovery are the day-to-day realities behind requests to demonstrate IEC 62443 alignment. This guide explains the standard in practical terms so readers can go directly to the section that matters most, whether they are preparing for a compliance review, evaluating a supplier's security claims or designing a segmented network.

Quick definition: what is IEC 62443?

IEC 62443, more precisely called ISA/IEC 62443, is a series of international standards that defines requirements and processes for securing industrial automation and control systems (IACS) throughout their lifecycle. It was developed by the ISA99 committee of the International Society of Automation and is co-published by the International Electrotechnical Commission's technical committee 65.

• ISA/IEC 62443 is an international standard written specifically for industrial automation and control system (IACS) security. It is organized into four tiers covering general concepts, asset owner and service provider policies, system requirements, and component or product requirements.
• The standard's graded security levels run from SL 1 through SL 4. SL 0 is not a formal level; it is shorthand used in some materials for "no specific security requirements."
• Zones and conduits, defined in IEC 62443-3-2, form a core architectural model used throughout the standard's system-level requirements.
• IEC 62443 is frequently referenced alongside NIS2 and NIST SP 800-82 Revision 3 as a practical way to address their OT-related security expectations.
• Acronis has achieved IEC 62443-4-1 certification for its secure development lifecycle. The certification covers how Acronis builds software; it does not certify Acronis Cyber Protect for OT itself as an industrial automation product.

ISA/IEC 62443 is an international standard for industrial automation and control system security. It defines requirements and processes for protecting IACS: the hardware, software and networks that monitor and control physical processes across manufacturing, energy, water, transportation and other industrial sectors.

The series was developed by the ISA99 committee of the International Society of Automation and adopted by the International Electrotechnical Commission's technical committee 65. ISA publishes the American editions as ANSI/ISA-62443-x-y, while IEC publishes the international editions as IEC 62443-x-y. Their technical content is identical; only non-normative material such as copyright notices and forewords differs. That is why "ISA/IEC 62443" is the more precise name, although "IEC 62443" is the shorthand most people use.

In November 2021, ISA designated the series a horizontal, or base, standard. In practical terms, that means it is technology-independent and can serve as the foundation for future sector-specific security standards rather than being tied to one industry.

The 62443 series is divided into four main tiers, with each one aimed at a different role in the IACS lifecycle.

Key published documents include 62443-2-1, which covers security program requirements for asset owners and was revised in 2024 to restructure requirements into security program elements and remove duplication with ISO/IEC 27001; 62443-2-4, which covers service provider requirements and was published in 2023; 62443-3-2, which covers security risk assessment and system design and was published in 2020; 62443-3-3, which covers system security requirements and security levels and was published in 2013; 62443-4-1, which covers the secure product development lifecycle and was published in 2018; and 62443-4-2, which covers technical security requirements for components and was published in 2019. In 2024, the series expanded from four to six categories, with category five reserved and a sixth category covering evaluation guidance.

This role-based structure matters because an asset owner, system integrator and product supplier do not need to work through the entire standards library in the same way. Each has a narrower set of documents that applies directly to its responsibilities.

IEC 62443-3-3 defines four graded security levels, SL 1 through SL 4, based on the capability of the attacker a system is designed to resist. SL 0 is not one of those four formal levels. It appears in explanatory materials as an informal baseline meaning that no specific security requirements are in place, so readers should not treat "SL 0 through SL 4" as the standard's official range.

The standard also distinguishes three ways of looking at a security level. SL-T is the target level that a risk assessment says a zone or conduit needs. SL-C is the capability a component or system can support when it is configured correctly. SL-A is the level actually achieved after deployment. The distinction is important in the real world: a component capable of supporting SL 3 can still deliver a much lower SL-A if it is installed on a flat, unsegmented network. A certificate for a component's capability is not the same as proof of the protection achieved at a specific site.

Zones and conduits are the segmentation model defined in IEC 62443-3-2 and used throughout the standard's system-level requirements. A zone groups assets that share common security requirements. A conduit is the logical or physical communication path between zones, and it carries its own assigned security requirements independently of the zones it connects.

The process, sometimes described as zone and conduit requirements, starts by defining the system under consideration. The organization then partitions that system into zones and conduits, assesses the risk for each one, assigns a target security level (SL-T) to every zone and conduit, and documents the resulting requirements. This creates a structured basis for network segmentation and other OT security controls instead of applying the same level of security everywhere, which is rarely practical in a live industrial environment.

IEC 62443-3-3 organizes its requirements under seven foundational requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events and resource availability. Together, these seven areas break down into 51 system requirements, each scaled across SL 1 through SL 4 with additional requirement enhancements at higher levels.

Backup and recovery appear explicitly under resource availability. SR 7.3, control system backup, calls for up-to-date, integrity-protected backups that are available for full system recovery, including audit and forensic information. It also requires the system to remain in a safe state during the backup process so that the backup itself is not corrupted. SR 7.4, control system recovery and reconstitution, calls for a way to recover the control system quickly and safely to a known secure state after a failure, typically by restoring the latest backup, including for stateful devices such as managed switches.

For MSPs and internal IT or OT teams, these requirements turn OT backup and recovery into a measurable part of IEC 62443 rather than a general best practice. When evaluating tooling against SR 7.3 and SR 7.4, teams should look for a way to verify that a backup is not corrupted before restoration begins and for recovery capabilities that can restore a system to different hardware or a virtual environment if the original hardware has failed. Acronis, for example, points to Universal Restore and backup integrity checks as capabilities that support these requirements. That does not make a deployed system fully conformant by itself; conformance still depends on how backups are configured, tested and integrated into the site's recovery procedures.

IEC 62443-4-1 focuses on the process requirements behind a supplier's secure development lifecycle. It does not test or certify the security of a specific product, and its requirements apply to the developer and maintainer of that product, not to the integrator or end user. The standard covers eight practice areas: security management, specification of security requirements, secure by design, secure implementation, security verification and validation testing, management of security-related issues, security update management and security guidelines.

Certification against 62443-4-1 is a process assessment rather than a product test. It uses a four-level maturity model: ML1 initial, ML2 managed, ML3 defined and ML4 improving. Accredited third-party certification bodies include TÜV SÜD, TÜV Rheinland, TÜV NORD, Bureau Veritas, exida, SGS, DNV, UL and LCIE. One widely used route is ISASecure SDLA, or Security Development Lifecycle Assurance, run by the ISA Security Compliance Institute. ML2, or managed, is often presented as a practical starting point because it requires documented and repeatable practices across all eight secure development lifecycle areas.

As documented in the Acronis Trust Center, Acronis has achieved IEC 62443-4-1 certification for its secure development lifecycle, alongside ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018 and CSA STAR Level 2. As with any supplier certification, IEC 62443-4-1 covers a development process rather than a product. A certified supplier's automation or backup product is therefore not automatically "62443 certified." The closing section below explains Acronis's certification and standards alignment within that narrower scope.

Certification types at a glanceProcess certification (IEC 62443-4-1 / ISASecure SDLA): assesses a supplier's secure development lifecycle. It applies to how a product is built, not to the product itself.Component certification (IEC 62443-4-2 / ISASecure CSA): assesses a specific component's technical security capability at a stated security level.System certification (IEC 62443-3-3 / ISASecure SSA): typically assesses a specific deployed or reference system architecture against the standard's system-level requirements.Conformance: an organization's own assessment that its practices align with the standard, without a third-party certificate. It can be a useful starting point, but it is not verifiable in the same way as a registered certification.

IEC 62443 is not an alternative to NIS2 or NIST SP 800-82. In OT-heavy sectors, organizations often use it to translate those broader cybersecurity outcomes into practical industrial security measures.

The EU's NIS2 Directive is outcome-based. It states what organizations must achieve, including risk management, supply chain security and business continuity measures under Article 21, without prescribing exactly how to achieve them. ENISA's EU-level technical guidance is narrower than it may first appear: it interprets Commission Implementing Regulation (EU) 2024/2690, which applies specifically to digital infrastructure and ICT service management entities such as DNS providers, cloud and data centre providers, managed service providers and similar organizations. Its standards mapping cites ISO/IEC 27001, ISO/IEC 27002 and NIST CSF 2.0, but not IEC 62443.

For OT-heavy sectors such as manufacturing and energy, NIS2's technical requirements are instead set at national level. France's ANSSI provides a confirmed example: its November 27, 2025 industrial cybersecurity guidance, ANSSI-PA-108 version 2.0, explicitly "introduces equivalences with the IEC 62443 standard" and maps individual recommendations to specific 62443 system and component requirements. For manufacturers and the MSPs that support them, NIS2's supply chain language is also relevant because it covers suppliers' secure development processes, which maps closely to what IEC 62443-4-1 certifies. Member states were required to transpose NIS2 into national law by October 17, 2024.

NIST SP 800-82 Revision 3, published September 28, 2023, is complementary guidance rather than a competing framework. It explicitly references ISA-62443-2-1 as a suitable OT cybersecurity program standard, organizes OT architecture around the Purdue model together with the 62443 zones and conduits concept, and includes appendices mapping its controls to ISA/IEC 62443.

IEC 62443-3-2 sets out a clear sequence for applying the standard to a real system, and most implementation guidance follows the same order.

First, define the system under consideration and perform an initial risk assessment. Second, divide the system into zones and conduits based on shared security requirements. Third, perform a detailed risk assessment for each zone and conduit, assign a target security level (SL-T), and document the result in a cybersecurity requirements specification. Fourth, implement controls from 62443-3-3 for systems and 62443-4-2 for components to meet the assigned SL-T, supported by the security program required under 62443-2-1. Fifth, verify that the achieved security level (SL-A) actually meets the target and address any gaps.

Organizations new to the standard often want to move directly to control implementation. IEC 62443 puts zone and conduit definition and SL-T assignment first for a reason: without that work, there is no reliable way to judge which controls are proportionate to the risk in each part of the system.

What this means for OT teams and MSPs: The practical starting point is usually not buying a certification. It is building an honest zone and conduit map of what is actually running today, including the legacy, unpatched and air-gapped systems that first-pass inventories often miss. The quality of that map determines whether later controls reduce real operational risk or simply create more paperwork.

When evaluating a supplier, component or system against IEC 62443, ask for details rather than accepting a broad claim of conformance. Start by confirming which certification type applies to the role being evaluated, which scheme was used, and the maturity or security level achieved. Check the scope carefully, because a certificate may cover an entire development organization, one division or a single product family, and peer certificates normally state that scope explicitly.

Next, confirm that the certification body is accredited under ISO/IEC 17065 and check the appropriate public registry. ISASecure maintains separate registries for SDLA, CSA and SSA certificates. Ask for evidence of the underlying practices as well, including software bill of materials and dependency management, signed and integrity-checked updates, and a coordinated vulnerability disclosure process. A finished-product penetration test alone does not satisfy 62443-4-1. Finally, match the component's supported security level to the target level of the zone in which it will operate, because capability and achieved protection are not the same thing.

IEC 62443 conformance depends on the whole deployed system, including its zones, conduits and configuration. Backup and recovery tooling contributes to specific resilience objectives within that larger program; it does not deliver conformance on its own. Acronis Cyber Protect for OT is one example of how that contribution can work in practice.

Acronis Cyber Protect for OT is designed around a straightforward outcome: secure backup and fast, self-service recovery for the PC-based systems that keep OT operations running, including legacy and air-gapped environments where downtime can be especially expensive and local IT support may be limited or unavailable.

• Protects the PCs, servers and workstations that run HMI, SCADA, historian and engineering applications, not embedded PLCs, RTUs or other non-PC industrial hardware.
• Supports operating systems back to the Windows XP era.
• Functions without an external network connection in air-gapped sites.
• Lets authorized local personnel trigger recovery without waiting for remote IT.
• Recovers systems to dissimilar hardware or virtual environments through Universal Restore.

Acronis OT and industrial customer references include ABB, Tata Steel and Sasol. Sasol's case study describes eliminating compatibility issues and restoring to dissimilar hardware during plant modernization, making it the closest match to the dissimilar-hardware recovery capability described above.

Two more specific claims need clear boundaries:

• Acronis has achieved IEC 62443-4-1 certification for its secure development lifecycle, alongside ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018 and CSA STAR Level 2. This is a process certification: it describes how Acronis builds and maintains software, not a certification of Acronis Cyber Protect for OT as an automation product.
• Acronis's Universal Restore capability, together with capabilities that verify backup integrity before a restore, supports the backup (SR 7.3) and recovery (SR 7.4) requirements defined in IEC 62443-3-3. Meeting those requirements at the tool level is not the same as having a certified deployment, which still depends on how each site configures and tests its backups.

Visit the Acronis Cyber Protect for OT product page to see how this fits into a broader OT resilience plan. An OT resilience specialist can help map it to your own environment.

Is IEC 62443 legally mandatory?

IEC 62443 is a voluntary standard. In practice, it can become a requirement through regulation or contract terms. The EU's NIS2 Directive does not name IEC 62443 directly, and the standards ENISA maps at EU level do not include it. National frameworks for OT-heavy sectors can reference it directly, however, as France's ANSSI does in its industrial cybersecurity guidance. Many asset owners also write IEC 62443 conformance into supplier contracts even where no regulation strictly requires it.

How much does IEC 62443-4-1 certification typically cost?

There is no standardized price. Cost depends on the scope of the assessment, whether it covers one product line or an entire development organization, the target maturity level, and the accredited certification body carrying out the work. Suppliers should request a scoped quote directly from a certification body rather than relying on an industry average.

How long does IEC 62443-4-1 certification take?

The timeline depends on how mature the supplier's development process is before the formal audit begins. A gap assessment against the standard can help the supplier build a realistic plan for reaching its target maturity level instead of relying on a general estimate.

What is the difference between IEC 62443 conformance and certification, and how can a buyer verify a claim?

Conformance means that an organization's practices align with the standard, usually based on an internal or self-assessment. Certification means that an accredited third-party body has formally assessed those practices against a defined scheme, such as ISASecure SDLA, CSA or SSA, and issued a certificate that appears on a public registry. The certification types box above explains how the schemes differ. To verify a claim, ask which part of the standard it covers, which accredited body issued the certificate, and whether it appears in a public registry such as ISASecure's.

How is IEC 62443 conformance actually audited?

Certification bodies accredited under ISO/IEC 17065 assess an organization, product or system against the applicable part of the standard through document review, process interviews and, for component certification, technical testing. ISASecure maintains public registries of certified development organizations, components and systems.

If I use IEC 62443-4-2 certified components, do I still need to worry about system-level security?

Yes. Certification under 62443-4-2 confirms that a component can support a stated security level. It does not prove that the system in which the component is installed achieves that level. The achieved level still depends on zone and conduit design, network segmentation and configuration.

Do system integrators need their own IEC 62443 certification?

Not through the ISASecure-branded SDLA, CSA or SSA schemes, which do not include a scheme built specifically for integrators. Certification against 62443-2-4, covering security program requirements for IACS service providers, is available from accredited bodies such as TÜV SÜD, Bureau Veritas and exida, often through the IECEE Certification Body Scheme. Major integrators including Schneider Electric, Siemens and GE Vernova have obtained it for their engineering and integration processes. Asset owners can therefore ask an integrator for this certification directly rather than relying only on a general claim of alignment.

How does the 2024 update to IEC 62443-2-1 affect organizations that already have ISO/IEC 27001?

The 2024 edition reorganized 62443-2-1 into security program elements and specifically removed duplication with the information security management system requirements in ISO/IEC 27001. Organizations that already have an ISO/IEC 27001 program should therefore face less duplicated documentation than they did under the 2010 edition. IEC 62443-2-1 still adds IACS-specific requirements that a general ISMS does not cover.