IEC 62443 is the one security standard actually written for the systems SCADA buyers run - PLCs, RTUs, HMIs, historians, and the software that supervises them. It is also the most misunderstood: a sprawling series of documents, four security levels, three different "SL" vocabularies, and multiple competing certification schemes. This guide untangles it for buyers and vendors alike: what the parts of the standard cover, what SL1 through SL4 really mean, how ISASecure and assessor-based certification works step by step, what it realistically costs, and how to evaluate a vendor that is aligned but not certified - which is most of the industry.
Explore the full security & certification article series - 60+ practitioner guides.
IEC 62443 certification is a formal third-party assessment - under the ISASecure scheme or by assessor firms such as exida and TUV - of a product, system, or development lifecycle against specific parts of the standard at a target security level (SL1–SL4). Typical efforts take 6 to 18 months and cost five to six figures per product. To judge any certificate, start with the standard itself: IEC 62443 grew out of the ISA99 committee's recognition that IT security standards do not translate to plant floors. An IT framework can mandate aggressive patching and confidentiality-first design; an operating pipeline or chemical unit cannot reboot a controller mid-batch, and its first priority is availability and safety, not secrecy. So the industrial world wrote its own series of standards - published by the IEC, developed with ISA - that treats the control system as the object of security engineering rather than an awkward exception to office IT policy. The same recognition of OT's distinct performance, reliability, and safety requirements is why NIST maintains a separate SP 800-82 Rev. 3 guide to operational technology security apart from its IT guidance.
The series' genius is that it assigns requirements to every role in the ecosystem rather than dumping everything on the asset owner. A product supplier must build securely; an integrator must assemble securely; an operator must run securely. When a buyer asks a cloud SCADA vendor "where do you stand on 62443?", the answer should reference the specific parts that apply to a vendor - chiefly the secure development lifecycle and the technical requirements for systems and components.
The full series spans more than a dozen documents; four of them do most of the work in vendor conversations:
| Part | Who It Binds | What It Requires |
|---|---|---|
| 62443-2-1 | Asset owners (you) | A security program for the operating organization - policies, risk assessment, training, incident response |
| 62443-2-4 | Service providers & integrators | Security capabilities and practices for firms that install and maintain control systems |
| 62443-3-2 / 3-3 | Systems | Risk assessment into zones and conduits (3-2), then system security requirements per security level (3-3) |
| 62443-4-1 / 4-2 | Product suppliers | A certified-quality secure development lifecycle (4-1) and technical component requirements per security level (4-2) |
The technical requirements in 3-3 and 4-2 (published by the IEC, with full texts available for purchase from its webstore) are organized under seven foundational requirements: identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. This structure is why 62443 conversations get concrete fast - a vendor mapping its controls to the standard must say, per foundational requirement, what the platform actually does. Multi-factor authentication and role-based authorization land under the first two; signed telemetry and replay detection under system integrity; TLS and encryption at rest under data confidentiality; an outbound-only gateway under restricted data flow; security alerting and SIEM delivery under timely response; store-and-forward buffering and rate limiting under resource availability. That is exactly the shape of the control mapping Merobix maintains against the standard, documented on its security page.
The security level is 62443's core risk language - a rating of the adversary the system is designed to resist:
Three variants of the term matter when reading vendor claims. SL-T (target) is the level an asset owner selects for each zone through risk assessment under 62443-3-2. SL-C (capability) is the level a product or system is capable of supporting - this is what product certifications attest. SL-A (achieved) is what the deployed system actually attains, which depends on configuration and operations, not just products. A vendor can honestly claim SL-C for a component while your deployment achieves less because of how it is installed - which is why the standard insists on all three vocabularies. Higher levels also demand qualitatively different controls: SL3-class requirements pull in hardware-backed and phishing-resistant authentication (FIDO2 falls in this family), cryptographic integrity protection of data in motion, and stronger compartmentalization.
Unlike ISO 27001, there is no single accreditation pyramid. The main routes:
Because schemes differ, a certificate is only meaningful with four qualifiers attached: which scheme, which parts of the standard, which security level, and which product version. A component certificate at SL1 for a firmware version three releases old is a very different claim from an SSA certificate at SL2 for the system you are buying today. Ask for all four every time - the same discipline our certification pillar guide recommends for SOC 2 and ISO 27001 claims.
For a product supplier - which is the case most relevant when you are evaluating a SCADA platform - certification typically unfolds like this:
Honest answer: it varies more than any vendor blog admits. Publicly discussed experience puts a typical single-product or lifecycle certification at 6 to 18 months end to end, with total costs - assessment fees, lab evaluation, and the internal engineering time that dwarfs both - commonly reaching five to six figures per product. Higher target levels, broader system scope, and weaker starting maturity push both numbers up. The durable cost is cultural: the vendor must keep operating a certified development lifecycle after the certificate is framed, which is precisely why the certificate carries signal.
Here is the market reality buyers should internalize: full 62443 certification is still the exception across the SCADA industry, including among large incumbents, where certificates often cover selected products rather than whole portfolios. "Not certified" is therefore not disqualifying - but it moves the burden of proof onto evidence. A credible uncertified vendor should hand you:
This is the posture Merobix takes: the platform maps its shipped controls to IEC 62443 per foundational requirement, runs continuous internal validation with independent penetration testing as part of the ongoing program, and is building toward formal attestations - starting with a SOC 2 readiness program for the cloud operations side - while stating plainly that it holds no certificate today. Compare that with vague "62443-compliant" claims that dissolve under the four-qualifier test, and the difference in seriousness is obvious within one meeting. For how the enterprise-side frameworks complement this, see our ISO 27001 guide.
Key takeaway: IEC 62443 certification is real, scheme-based, and expensive - which is why most SCADA vendors are aligned rather than certified. Judge any 62443 claim by four qualifiers (scheme, part, security level, product version) and, where no certificate exists, demand a per-foundational-requirement control mapping with architectural evidence. A vendor that can produce the mapping has done the engineering; a vendor that can produce neither has done the marketing.
62443 covers the control system; it says little about how the vendor's cloud business is run - access reviews for the vendor's own staff, corporate change management, availability commitments, customer-data handling in the SaaS layer. Those live in SOC 2 (an attestation of service-organization controls, dominant in North America) and ISO 27001 (a certified security management system, dominant internationally). A complete cloud SCADA evaluation demands both layers: 62443 alignment for the product and OT architecture, SOC 2 or ISO 27001 evidence for the operating organization. Sector rules increasingly assume this pairing - API 1164 for pipelines and EPA/AWIA guidance for water utilities both lean on 62443 concepts while procurement teams simultaneously demand enterprise attestations. The side-by-side comparison of all three frameworks is in our certification pillar guide.
Fifteen minutes of these questions separates engineered platforms from decorated ones. If you want to run them against Merobix live, request a demo - the answers come with screenshots.
IEC 62443 is the international series of standards for the cybersecurity of industrial automation and control systems (IACS). Developed by the ISA99 committee and published by the IEC, it assigns requirements to every party in the ecosystem: asset owners (62443-2-1), service providers (62443-2-4), system-level security requirements (62443-3-3), secure product development lifecycles (62443-4-1), and technical component requirements (62443-4-2). Its central concepts are zones and conduits for network segmentation and security levels SL1 through SL4, which rate the sophistication of attacker a system is designed to resist. It is the reference standard behind most sector rules for OT security, including pipeline and water-sector guidance.
IEC 62443 defines four security levels. SL1 protects against casual or coincidental violation, such as misconfiguration. SL2 protects against intentional attack using simple means and low resources - commodity malware and opportunistic scanning, the practical baseline for most industrial operations. SL3 protects against sophisticated attackers with moderate resources and IACS-specific knowledge, such as organized ransomware crews. SL4 protects against attackers with extended resources - state-level actors. Levels are assessed per foundational requirement, and the standard distinguishes target levels (SL-T) chosen by the asset owner through risk assessment, capability levels (SL-C) a product can support, and achieved levels (SL-A) measured in the deployed system.
Published experience and scheme guidance suggest a typical product or lifecycle certification effort runs 6 to 18 months, driven mostly by how much remediation the gap assessment uncovers rather than the audit itself. Costs vary widely and are usually quoted per product and per scheme; total spend combining assessment fees, lab evaluation, and internal engineering effort commonly reaches five to six figures, and complex systems certified to higher security levels cost more. Ongoing costs continue after certification because certificates are tied to product versions and development processes, requiring reassessment as products evolve. Treat any precise figure with skepticism - scope is everything.
There is no single global registry. The most established route is the ISASecure scheme, which accredits certification bodies to award certifications such as CSA (Component Security Assurance) and SSA (System Security Assurance) against 62443-4-1/4-2 and 62443-3-3, and SDLA (Security Development Lifecycle Assurance) against 62443-4-1. Independent assessment firms such as exida and the TUV organizations also certify products and development processes against the standard. Because schemes differ in scope, a buyer should always ask which scheme issued a certificate, which parts of the standard and which security level it covers, and which product versions it applies to.
Certification is rarely a legal requirement, and full certification remains uncommon across the SCADA industry - many credible vendors are aligned to the standard rather than certified. What buyers should require is a substantive position: which security level the architecture targets, a mapping of platform controls to 62443-3-3 or 62443-4-2 per foundational requirement, and evidence behind the mapping. Merobix takes this approach - it maps its platform controls to IEC 62443 and runs a SOC 2 readiness program for its cloud operations, stating readiness honestly rather than claiming certificates. A vendor with neither a certificate nor a defensible mapping has not done the engineering work the standard describes.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Outbound-only data flow, device identity, signed telemetry, per-role use control - walk the foundational requirements against the actual platform, not a slide deck.