This page is part of the IEC 62443 compliance hub.
IEC 62443 certification is becoming a commercial and regulatory reality for UK industrial organisations. Whether you are a product vendor preparing for third-party assessment, a system integrator responding to customer audit requirements, or an asset owner demonstrating compliance to a regulator, understanding what certification actually involves and what evidence is required is the starting point for any serious programme.
This guide explains the IEC 62443 certification landscape in the UK, what different certification schemes require, and how structured protocol testing with ProtoCrawler helps organisations build the evidence base they need to get there
In This Guide
- What Does IEC 62443 Certification Mean?
- Who Needs IEC 62443 Certification in the UK?
- IEC 62443 Certification Schemes Explained
- What Certification Bodies Look For
- The Role of Protocol Testing in Certification
- How ProtoCrawler Supports Your Certification Programme
- Common Certification Challenges and How to Avoid Them
- Building Your Certification Evidence Package
- How Long Does IEC 62443 Certification Take?
What Does IEC 62443 Certification Mean?
IEC 62443 certification means that a product, system, or development process has been assessed by an accredited third party and found to meet the requirements of the relevant part of the standard. It is not a single certificate. Different parts of the standard address different roles, and certification scope varies accordingly.
The three most common certification targets are:
Product certification under IEC 62443-4-2, which assesses whether a device or software component meets the technical security requirements for a stated security level. This is most relevant for manufacturers and vendors supplying products into IACS environments.
SDL certification under IEC 62443-4-1, which assesses whether a vendor’s development process meets the requirements for a secure product development lifecycle. This is process-focused rather than product-focused and provides assurance about how products are built, not just what they do.
System certification under IEC 62443-3-3 and IEC 62443-2-4, which assesses whether an integrated IACS system and its integration process meet system-level security requirements. This is most relevant for system integrators and asset owners.
Understanding which certification applies to your situation is the first step. Getting this wrong wastes time and money.
Who Needs IEC 62443 Certification in the UK?
IEC 62443 certification is not a UK statutory requirement, but the practical pressure to achieve it is growing rapidly across several sectors.
UK critical national infrastructure operators in energy, water, transport and digital infrastructure face regulatory expectations under the Network and Information Systems Regulations and the NCSC Cyber Assessment Framework. Demonstrating IEC 62443 alignment, including through certification, is increasingly seen as evidence of proportionate risk management.
Product vendors supplying into regulated sectors are facing IEC 62443 certification requirements in procurement contracts and supply chain security programmes. Customers who are themselves subject to regulatory scrutiny are passing that requirement down the supply chain. If you sell products deployed in IACS environments, your customers may already be asking for IEC 62443 evidence.
System integrators and managed service providers working in critical infrastructure are encountering IEC 62443-2-4 and IEC 62443-4-1 requirements in tenders and framework contracts, particularly in the public sector and regulated utilities.
For a broader overview of how IEC 62443 intersects with UK regulation, see the IEC 62443 UK compliance guide.
IEC 62443 Certification Schemes Explained
Several certification schemes assess compliance with IEC 62443. The main ones relevant to UK organisations are:
IECEE CBTL testing is the primary international certification route for product and SDL assessments under IEC 62443. Accredited testing laboratories assess products against IEC 62443-4-2 and development processes against IEC 62443-4-1. Accredited bodies operating in the UK include SGS, TÜV Rheinland UK and Bureau Veritas.
ISASecure is a programme operated by the ISA Security Compliance Institute that certifies products, systems and development processes against IEC 62443 requirements. ISASecure certification is widely recognised in the US and is increasingly accepted in European and UK procurement contexts.
NCSC CPA (Commercial Product Assurance) is a UK-specific scheme operated by the NCSC that assesses security products against a defined protection profile. While CPA is not an IEC 62443 certification scheme directly, achieving CPA builds significant credibility in UK government and critical infrastructure procurement. Cytal offers CPA testing services as part of its assurance portfolio.
Customer-led assessment is the most common form of IEC 62443 compliance verification in practice. Customers, procurement teams and framework bodies assess vendors against IEC 62443 requirements directly, without formal third-party certification. The evidence requirements are essentially the same as for formal certification: structured testing records, audit-ready reports and traceability to specific clauses.
What Certification Bodies Look For
Regardless of the certification scheme, assessors consistently look for the same four things.
Scope definition. A clear statement of what has been tested, which protocols and interfaces are in scope, and which security level is being claimed. Vague or incomplete scope definitions are one of the most common reasons assessments stall.
Empirical testing evidence. Documentation showing that systems and components have been tested under real conditions, not just that policies exist or architectures have been designed. For protocol security requirements, this means structured test records showing what was tested, how it was tested and what the results were.
Findings management. A record of vulnerabilities identified during testing, how they were scored, what remediation was undertaken and how that remediation was verified. Assessors do not expect zero findings. They expect evidence that risks are managed proportionately.
Repeatability. Evidence that the testing process is sustainable and that compliance is maintained over time as products and systems change. IEC 62443-4-1 is explicit that security testing must be repeated through the development lifecycle.
For a full breakdown of what IEC 62443 compliance testing involves and what audit-ready evidence looks like, see the IEC 62443 compliance testing guide
The Role of Protocol Testing in Certification
For any certification assessment that touches IEC 62443-3-3, IEC 62443-4-2 or IEC 62443-4-1, protocol-level testing is not optional. It is where the gap between documented intent and empirical evidence is most commonly found.
IEC 62443-3-3 SR 7.1 and SR 7.2 require that systems demonstrate denial-of-service protection and resource availability under adverse conditions. IEC 62443-4-2 CR 3.5 requires component-level input validation. IEC 62443-4-1 Practice 6 requires robustness and boundary testing as part of the secure development lifecycle. All of these requirements are most effectively met through systematic protocol fuzz testing.
The specific vulnerabilities that protocol testing is designed to uncover include denial-of-service risks from malformed packet handling, authentication bypass from missing or improperly validated headers, input validation failures that trigger buffer overflows or state machine errors, and information disclosure from unexpected device responses. These are not theoretical risks. They are consistently found in industrial protocol implementations that have never been subjected to structured fuzz testing.
For a detailed technical breakdown of which IEC 62443 clauses require protocol testing and what the evidence should look like, see the IEC 62443 fuzz testing guide.
How ProtoCrawler Supports Your Certification Programme
ProtoCrawler is Cytal’s automated protocol fuzz testing platform, built specifically for OT and industrial environments. It supports IEC 62443 certification programmes in three direct ways.
It generates the empirical testing evidence that certification assessors require. ProtoCrawler tests industrial protocols including Modbus, DNP3, IEC 61850, IEC 60870-5-104 and others against thousands of malformed and edge-case inputs, producing structured, scored outputs that map directly to the relevant IEC 62443 clause requirements.
It produces audit-ready reports that can be shared directly with certification bodies, customer procurement teams and regulatory assessors. The reports include scope documentation, test configuration records, scored findings and coverage traceability: the four components that assessors consistently look for.
It supports ongoing compliance as products and systems change. ProtoCrawler integrates with CI/CD pipelines so that fuzz tests run automatically against new builds, maintaining certification evidence without requiring full test programmes to be repeated from scratch each time firmware is updated.
Common Certification Challenges and How to Avoid Them
Starting too late is the most common mistake. Certification is not a final step. It is the outcome of a process that starts at design. Organisations that begin thinking about IEC 62443 evidence only when a customer or regulator asks for it consistently find gaps that take months to address. Building protocol testing into the development lifecycle from the start makes certification straightforward rather than remedial.
Confusing documentation with evidence is equally common. Policies, architecture diagrams and risk assessments are necessary but not sufficient. Assessors want proof that systems behave securely under real conditions. The earlier you start generating empirical testing evidence, the stronger your certification package will be.
Testing too narrowly creates gaps that assessors will find. A common mistake is testing only the primary control protocol while leaving management plane protocols like SNMP, SSH or HTTPS untested. Certification scope should reflect the full attack surface, not just the most visible interfaces.
Not planning for regression means certification achieved on a specific firmware version may become invalid when that firmware is updated. Organisations that treat certification as a one-time activity rather than an ongoing programme create compliance gaps that are expensive to close. ProtoCrawler’s repeatable test configurations make regression testing efficient and sustainable.
Building Your Certification Evidence Package
A well-structured IEC 62443 certification evidence package typically contains the following components.
A scope document defining the system or component under assessment, the protocols and interfaces included, the security level being claimed, and the parts of IEC 62443 against which the assessment is made.
Protocol testing records produced by a structured fuzz testing programme, including test configurations, inputs applied, device responses observed and scored findings. These should be traceable to specific IEC 62443 clauses.
A findings register documenting vulnerabilities identified, their severity scores, the remediation undertaken and verification that remediation was effective.
A regression testing record demonstrating that testing has been repeated when the product or system has changed, with traceability showing which test cases were re-executed and what the outcomes were.
For SDL certification under IEC 62443-4-1, additional documentation is required covering development process controls, security requirements management, threat modelling and security review practices.
How Long Does IEC 62443 Certification Take?
Timelines vary considerably depending on scope, security level and the maturity of existing practices.
For product certification under IEC 62443-4-2 at SL 2, organisations with structured development processes and existing testing evidence can typically complete a formal assessment in three to six months. Organisations starting from scratch, without structured testing records or a defined secure development process, should plan for six to twelve months to build the evidence base before engaging a certification body.
SDL certification under IEC 62443-4-1 is a process assessment rather than a product test. Organisations with mature development practices may complete it in two to four months. Those that need to establish or document secure development processes first should allow six to nine months.
The single most effective thing you can do to reduce certification timelines is to start generating empirical protocol testing evidence early, using a tool that produces audit-ready outputs from the outset.
Ready to start your IEC 62443 certification programme? Book a demo to see how ProtoCrawler generates the protocol testing evidence that certification assessors require.
Book a demo
Or explore the full IEC 62443 resource hub at cytal.co.uk/iec-62443/.