When you buy cloud SCADA, the vendor's audits cover most of the running system. When you install the same software on your own servers, that coverage collapses to the software itself - and everything else becomes your program to build, document, and defend. This guide maps the certification landscape for self-hosted SCADA: what IEC 62443-2-1 and 62443-3-3 expect of you, where ISO 27001 and NIST SP 800-82 fit, when FIPS 140 and Common Criteria matter, which industry overlays are legally binding, what credentials the software vendor should still hold, and a hardening checklist for the deployment itself.
Part of the Merobix OT security guide collection - vendor vetting to industry compliance.
The short answer on on-premise SCADA certifications: four frameworks define the expected program - IEC 62443-2-1 (the asset-owner security program), IEC 62443-3-3 (technical system requirements), ISO 27001 (certifying the organization that runs it), and NIST SP 800-82 (the implementation playbook) - plus legally binding sector overlays such as NERC CIP, AWIA, and FDA 21 CFR Part 11. Why the burden lands on you takes a little longer to explain.
Certifications attach to organizations and systems, not to software licenses. A SCADA vendor's SOC 2 report - a CPA attestation under the AICPA's SOC suite - or ISO 27001 certificate describes the vendor's environment - its cloud service, its development pipeline, its corporate controls. The moment you take the installer and run it on your own hardware, the audited environment ends at the software artifact. Your operating systems, hypervisors, network segmentation, firewall rules, backup jobs, account lifecycle, and patch schedule are outside every certificate the vendor holds.
This is not an argument against self-hosting. Plenty of operators have good reasons to run SCADA on-premise or fully air-gapped: data residency mandates, corporate policy, latency, or regulation that simply will not permit a cloud dependency. It is an argument for going in with clear eyes. The honest comparison is not "cloud vs on-premise security" as a single verdict - it is a question of who runs which parts of the program, and we work through that split in detail in our cloud vs on-premise SCADA security comparison. This post covers the on-premise side of that split: the standards, certifications, and programs the operator must bring.
A useful mental model: the vendor certifies the product and its development process; the operator certifies the running system and the organization around it. Every framework below falls on one side of that line or the other.
The ISA/IEC 62443 series is the international standards family for industrial automation and control system security, and it is deliberately split by role. Two parts matter most when you host SCADA yourself:
This part defines the security program an asset owner must establish and maintain: risk assessment, security policies, organizational responsibilities, training and awareness, supplier and service-provider management, incident response, and continuous improvement. It is the OT equivalent of running a management system - not a one-time project but a standing function. If you self-host, 62443-2-1 is the description of the job you have taken on. Conformance is typically demonstrated through assessment against the standard rather than a mass-market certification scheme, and many operators use it as an internal blueprint even when no auditor ever asks.
This part defines technical system requirements across seven foundational requirement families - identification and authentication control, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability - graded at four security levels, SL1 through SL4, based on the sophistication of the attacker the system must resist. When you deploy on-premise, you (or your integrator) are responsible for assembling a system that meets your target security level: the SCADA software contributes capabilities such as MFA, role-based access, and audit logging, but segmentation, host hardening, and backup infrastructure are yours to supply. Our OT network security guide walks through the SL levels and the zone-and-conduit model in more depth.
ISO 27001 certifies an information security management system (ISMS) - the governance machinery of the organization, not a specific product. For an operator self-hosting SCADA, it is the most recognizable way to demonstrate to customers, insurers, and boards that a real security program exists. The 2022 revision, published jointly by ISO and IEC and available for purchase from the IEC webstore, organizes 93 Annex A controls into four themes (organizational, people, physical, technological), and OT assets can and should be brought inside the ISMS scope.
The process is well-trodden and worth knowing before you commit:
Realistic expectations: 6–18 months from a standing start depending on size and maturity, external audit fees commonly in the low tens of thousands of dollars for small and mid-size organizations, and a larger internal cost in staff time. These figures vary widely by scope, registrar, and country - treat every number as a range, and get quotes from accredited certification bodies for your actual scope.
NIST Special Publication 800-82 (Revision 3, retitled the Guide to Operational Technology Security) is not a certification at all - and that is precisely its value. It is a freely available, US-government-maintained handbook for securing OT environments: architecture patterns, segmentation guidance, control catalogs mapped to NIST SP 800-53, and OT-specific tailoring of IT security practice. For a self-hosting operator, 800-82 is the implementation manual that sits underneath the 62443 requirements: 62443 tells you what a conformant program and system look like; 800-82 tells you, in plain engineering terms, how US operators typically build them. If your team is writing its first OT security plan for a self-hosted deployment, start there - the price is right and auditors across every sector recognize it.
Two product-level validation schemes appear in on-premise procurement, almost always driven by government requirements:
For most private operators, neither is mandatory. But the underlying questions - what cryptography does this product use, who maintains it, how are keys managed - belong in every vendor evaluation regardless of sector.
Everything above is best practice or contractual. Sector rules are different - they carry legal force, and they attach to the operator, not the software:
The pattern repeats across sectors: the regulator holds the operator accountable. The software can make compliance easier or harder, but it cannot be compliant on your behalf.
| Standard / Scheme | Who It Attaches To | What It Covers | How Conformity Is Shown |
|---|---|---|---|
| IEC 62443-4-1 / 4-2 | Software vendor | Secure development lifecycle; component technical requirements | Assessment or certification (e.g., ISASecure-style schemes); vendor evidence |
| IEC 62443-3-3 | The deployed system (operator + integrator) | System security requirements at SL1–SL4 | System assessment against target SL |
| IEC 62443-2-1 | Operator (asset owner) | The standing OT security program | Program assessment; internal conformance |
| ISO 27001 | An organization (vendor or operator - separately) | Information security management system | Accredited certification, 3-year cycle |
| SOC 2 | Service organization (vendor's cloud service) | Trust services criteria over the audited service | CPA attestation report - does not transfer to your servers |
| NIST SP 800-82 | Operator (guidance) | OT security implementation practice | No certification - self-applied playbook |
| FIPS 140-3 | Cryptographic modules in the product | Crypto implementation quality | NIST CMVP validation certificate |
| NERC CIP / AWIA / Part 11 | Operator (legally) | Sector-specific obligations | Regulatory audit, inspection, enforcement |
Self-hosting reduces the vendor's operational scope, but the quality of the software you install still depends entirely on the vendor's engineering discipline. Before you sign, ask for:
That last point cuts both ways, so here is our own framing: Merobix runs a SOC 2 readiness program and maps its controls to IEC 62443, with independent penetration testing part of its ongoing validation program rather than a finished checkbox. The platform ships the technical controls a 62443-3-3 assessment looks for - TOTP and FIDO2 multi-factor authentication, six-tier role-based access, signed telemetry with replay detection, immutable chained audit records, and an outbound-only gateway - and supports fully on-premise and air-gapped deployment for operators whose policy requires it. The details are on our security architecture page.
Certifications describe the program; this is the floor for the deployment itself. Whatever SCADA software you run on your own iron:
Key takeaway: No certificate ships in the box. When you self-host SCADA, the vendor's credentials cover the software and its development process - everything operational (IEC 62443-2-1 program, ISO 27001 scope, NERC CIP or AWIA or Part 11 duties, hardening, patching, backups, audits) transfers to you. Budget for the program, not just the servers. If that budget looks uncomfortable, weigh the alternative honestly: a guided demo can show you exactly which of these controls a managed deployment takes off your plate - and which remain yours either way.
There is no single mandatory certification for running SCADA on-premise, but four frameworks define the expected program: IEC 62443-2-1 describes the security program an asset owner must operate, IEC 62443-3-3 defines the technical requirements the deployed system should meet, ISO 27001 certifies the management system of the organization running it, and NIST SP 800-82 provides the implementation playbook. On top of these sit industry overlays that can be legally binding - NERC CIP for bulk power, AWIA for water utilities, and FDA 21 CFR Part 11 for pharmaceutical manufacturing. The software vendor holds product-level credentials; everything about the running deployment becomes your responsibility.
IEC 62443-2-1 addresses the asset owner: it defines the security program requirements - policies, risk assessment, training, incident response, supplier management - that the organization operating an industrial control system must establish and maintain. IEC 62443-3-3 addresses the system itself: it defines technical security requirements (identification and authentication, use control, data integrity, restricted data flow, timely event response, resource availability) at four security levels, SL1 through SL4. When you self-host SCADA, you need both: 62443-3-3 tells you what the deployed system must be capable of, and 62443-2-1 tells you what your organization must do around it, every day, for the life of the system.
Only partially, and less than most buyers assume. A vendor's SOC 2 report or ISO 27001 certificate covers the systems and processes inside its audit scope - typically the vendor's cloud service, corporate environment, and software development practices. When you install that vendor's software on your own servers, your operating system hardening, network segmentation, backup discipline, access control, and patching are outside the vendor's scope entirely. The vendor's secure development practices still matter, because they determine the quality of the software you install, but the operational attestation for the running system has to come from your own program - which is why self-hosting shifts certification burden from the vendor to the operator.
FIPS 140 is the US government standard for validating cryptographic modules, administered by NIST through the Cryptographic Module Validation Program; FIPS 140-3 is the current revision. It matters when your deployment must satisfy US federal requirements - federal facilities, defense-related sites, and some state or municipal contracts flow it down. In those environments, the SCADA stack should use FIPS-validated cryptographic modules for TLS, storage encryption, and password handling. Most private operators are not legally required to use FIPS-validated modules, but the underlying question - which cryptographic libraries does this product use, and are they maintained - is worth asking every vendor regardless.
Plan on 6 to 18 months from a standing start, though it varies with organization size and how much of a security program already exists. The typical path is: gap assessment against the 93 Annex A controls of the 2022 revision, remediation and documentation of the ISMS, an internal audit, then a stage 1 audit (documentation review) and stage 2 audit (implementation evidence) by an accredited certification body. Expect external audit fees in the low tens of thousands of dollars for small and mid-size organizations, plus significant internal effort; the certificate then requires annual surveillance audits and full recertification every three years. Costs vary widely by scope and country, so treat any fixed quote you read online as an estimate.
Cloud, on-premise, or fully air-gapped - Merobix ships MFA, role-based access, signed telemetry, and immutable audit trails either way, and shows you exactly where the responsibility line sits before you buy.