IEC 62443-4-1 and 4-2: what an OEM must actually prove

If you buy, specify or operate industrial kit — a PLC, an RTU, an HMI, an industrial switch, a SCADA gateway, an engineering workstation — you have almost certainly seen a supplier brochure that claims to be "compliant with IEC 62443", "aligned with 62443-4-2", or "designed to 62443 principles". Those phrases can mean almost anything, from a well-audited international certification to little more than wishful thinking on a slide deck.

The two parts of the standard that almost always get name-checked are IEC 62443-4-1 (about how the product was built) and IEC 62443-4-2 (about what the product can do). This article explains both in plain English, and — most importantly — sets out what an OEM must objectively demonstrate to back up a compliance claim, so that you can verify it rather than trust it.

This piece sits in the OEM/product corner of the IEC 62443 family. The system layer — how an asset owner sizes the security requirement (3-2) and how the system integrator delivers against it (3-3) — is covered in IEC 62443-3-2 and 3-3: what asset owners and integrators must prove . The management-system layer — the policies, programmes, service providers and patch discipline that wrap around the technical work — is covered in IEC 62443-2-x: the management system behind a secure industrial plant .

It also sits alongside two regulatory companions: the entity-side scope question, Does NIS2 apply to your EU project? , and the product-side scope question, Does the Cyber Resilience Act apply to your product? . When an industrial OEM ships into the EU, the CRA's essential requirements increasingly lean on IEC 62443-4-1/4-2 evidence as the practical proof, and NIS2 asset-owners under Annex I cascade those same demands back through their supply-chain contracts. The documents are different audiences, but the chain of evidence runs through all of them.

You can purchase the official standards from the IEC Webstore: IEC 62443-4-1:2018 and IEC 62443-4-2:2019 .

A two-minute orientation: the IEC 62443 family

IEC 62443 is a series of standards for the cybersecurity of Industrial Automation and Control Systems (IACS). It is published jointly by the International Electrotechnical Commission (IEC) and the International Society of Automation (ISA), and it is organised into four tiers, each aimed at a different audience.

flowchart TB
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef tier fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef focus fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:2px;

    A[IEC 62443 series
Cybersecurity for IACS]:::entry

    A --> G[Part 1 — General
Concepts, terminology, models]:::tier
    A --> P[Part 2 — Policies & Procedures
For the asset owner & operator]:::tier
    A --> S[Part 3 — System
For the system integrator]:::tier
    A --> C[Part 4 — Component
For the product supplier / OEM]:::tier

    C --> C1[62443-4-1
Secure Product
Development Lifecycle
PROCESS]:::focus
    C --> C2[62443-4-2
Technical Security
Requirements for Components
PRODUCT]:::focus

The two we care about here both sit in Part 4 — Component, and they are the product supplier's responsibility:

• IEC 62443-4-1 governs how the product is developed — the engineering process, the people, the controls behind the scenes.
• IEC 62443-4-2 governs what the product itself can technically do — its built-in security features.

Think of it this way: 4-1 is the kitchen and the chef; 4-2 is the meal on the plate. A hygienic kitchen does not guarantee a brilliant meal, and a tasty-looking meal can still come from a filthy kitchen — which is why serious buyers want assurance about both.

What IEC 62443-4-1 actually is

IEC 62443-4-1:2018, titled "Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements", defines a Secure Development Lifecycle (SDL) for industrial products. According to the IEC's own description, the standard covers "security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life" and applies to the developer and maintainer of the product, not to the integrator or end user.

In other words: 4-1 is process-focused. It does not ask "is the firmware secure?" It asks "did you build it in a way that makes secure firmware likely, repeatable and improvable over time?"

The 8 Practices

The standard groups its requirements into eight named Practices. Together they cover the entire arc from initial product idea through to end-of-support.

flowchart LR
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef step fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;

    SDL[Secure Product
Development Lifecycle]:::entry

    SDL --> SM[Practice 1 — SM
Security Management]:::step
    SDL --> SR[Practice 2 — SR
Specification of
Security Requirements]:::step
    SDL --> SD[Practice 3 — SD
Secure by Design]:::step
    SDL --> SI[Practice 4 — SI
Secure Implementation]:::step
    SDL --> SVV[Practice 5 — SVV
Security Verification
& Validation Testing]:::step
    SDL --> DM[Practice 6 — DM
Management of
Security-Related Issues]:::step
    SDL --> SUM[Practice 7 — SUM
Security Update
Management]:::step
    SDL --> SG[Practice 8 — SG
Security Guidelines
for end users]:::step

Across these eight Practices, the standard defines 47 top-level requirements, which in turn unfold into hundreds of sub-requirements. The certification body Baker Hughes notes this explicitly in its public white paper on its own IEC 62443-4-1 process assessment: "there are a total of 47 top-level requirements, this actually consists of hundreds of sub-requirements" — and helpfully publishes its own scoring against all 47.

Maturity Levels 1 to 4

IEC 62443-4-1 borrows from the Capability Maturity Model Integration (CMMI) tradition. Rather than asking "do you do X?" it asks "how well do you do X?" There are four Maturity Levels (MLs):

A critical point that catches many buyers out: under 62443-4-1 you do not "cherry pick" — to claim a given Maturity Level, all the relevant requirements must be satisfied at that level. ML 2 across some practices and ML 3 across others is not "ML 3 overall"; it is at best ML 2 organisation-wide.

What 4-1 means practically for an OEM

Translated out of standards-speak, here is what each Practice means for the people building the product.

1. Security Management (SM) — "Someone is in charge, and it's their day job"

The OEM must have appointed roles for product security, allocated budget, defined responsibilities, and integrated security activities into the formal product development plan. Confidential information (source code, signing keys, threat models) must be controlled. Subcontractors and suppliers must be held to the same standard.

Analogy: it is the difference between a factory where someone is the named Safety Officer with authority, training and a budget, and one where "safety" is whoever happens to think of it that week.

2. Specification of Security Requirements (SR) — "Write down what 'secure' means for this product"

For every product (or product family), the OEM must produce a written security context: where will this device live, what threats does it face, what trust boundaries does it cross, what data flows in and out, what target Security Level (SL-T) is expected? These requirements must be approved and version-controlled.

3. Secure by Design (SD) — "Bake security in, don't bolt it on"

This is where threat modelling lives. The architecture and detailed design must be analysed for threats (STRIDE, attack trees, or equivalent), and the resulting mitigations must be designed in before a line of production code is written. Defence-in-depth, least privilege and secure default settings must be explicit architectural choices, not afterthoughts.

Analogy: in modern car-making, crumple zones, airbags and ABS are designed into the chassis from the first sketch. You cannot achieve the same crash safety by welding extra plates onto a finished car at the end of the line. Same logic.

4. Secure Implementation (SI) — "Write the code properly, and check the writing"

Adopted coding standards (e.g. CERT C, MISRA, SEI guidance), peer code review, static application security testing (SAST) and rules about handling untrusted input. Crucially, this also covers third-party and open-source components: the OEM must know what is in the product, where it came from and whether it is still supported.

5. Security Verification & Validation Testing (SVV) — "Try to break it before someone else does"

A documented testing programme that includes, at minimum: functional security testing, vulnerability scanning, fuzz testing, penetration testing, and attack surface analysis. The results are written up, defects are tracked and the test plan is repeatable.

6. Management of Security-Related Issues (DM, defect management) — "When something is found, what happens?"

A documented vulnerability handling process: how reports are received (a published security contact, ideally a coordinated disclosure policy), how they are triaged, how root-cause analysis is done, how fixes are produced and tracked, and how customers are informed. CVE assignment and a track record of CVE handling are key forms of evidence here.

7. Security Update Management (SUM) — "Patches that actually reach the field"

A documented patch and security-update process. This must cover testing of patches before release, secure delivery (signed updates), customer notification, support timelines and end-of-life policy.

8. Security Guidelines (SG) — "Tell the user how to use it securely"

User-facing documentation: hardening guides, secure configuration guidance, defence-in-depth recommendations, account-management advice, decommissioning instructions and a clear statement of which security functions exist and how to turn them on. This is the practice that most directly links 4-1 to 4-2 — because 4-2 capabilities are only useful if the customer can find and configure them.

What an OEM must objectively demonstrate for 4-1

Demonstrating compliance with IEC 62443-4-1 is the heart of the OEM's claim — and it should not be a marketing assertion. It should be a position the OEM can defend with documents on the table. Here is what those documents look like.

Documentary and procedural evidence

• A written, version-controlled Secure Development Lifecycle policy that maps onto all eight Practices and the 47 requirements.
• An organisation chart showing who owns product security, with named roles, training records and security expertise of key staff (developers, testers, architects).
• Security training records for development, test and product-management staff — typically annually refreshed.
• A product security plan for the specific product in scope, including the security context, target SL, threat model and trust boundaries.
• A threat model document for each product in scope (STRIDE, DREAD, attack trees or equivalent) with traceability into design and tests.
• Security requirements traceability from the threat model → design decisions → implementation → test cases. A buyer can ask: "Show me how threat T-17 in the threat model is mitigated in the design, where in the code, and which test confirms it."
• Written secure coding standards that staff use, plus code review records and static analysis tool output.
• Software Composition Analysis (SCA) records or an SBOM-style inventory of third-party / open-source components, with evidence of vulnerability monitoring against them.
• A documented testing programme with reports: vulnerability scans, fuzz test campaigns, penetration test reports, attack-surface review.
• A published vulnerability handling and coordinated disclosure policy, plus a track record of CVEs handled (timelines, advisories, fixes shipped).
• A patch and security-update procedure with a real history of advisories and updates.
• End-user security guidelines, hardening guides and product security advisories that the OEM publishes and maintains.

Third-party certification — the gold standard

The most credible objective evidence is a third-party certificate issued by an accredited certification body. For 62443-4-1, the two principal schemes are:

• ISASecure SDLA (Security Development Lifecycle Assurance), operated by the ISA Security Compliance Institute (ISCI). According to the ISASecure scheme description, SDLA "applies to the development lifecycle processes of suppliers for control system products" and "certifies compliance to ISA/IEC 62443-4-1". SDLA is offered at four levels — SDLA Level 1, 2, 3 and 4 — corresponding to the four Maturity Levels of the standard. The certifier "evaluates the specific documented version of the organization's process to assess whether it meets the requirements stated in the SDLA specification" and "reviews representative artifacts to verify that each ISASecure SDLA requirement is being followed for products under the scope of the process."
• The IECEE CB Scheme for industrial cybersecurity, which provides equivalent certificates of conformity issued by IECEE-recognised CBTLs (Certification Body Test Laboratories). See www.iecee.org .

Two scope traps to watch for

Two details on any 4-1 certificate matter more than the headline:

1. The scope of the process — exactly which development site, which business unit and which product line is covered. A vendor that operates in five countries may only have one site certified. The certificate will say so; the brochure usually won't.
2. The Maturity Level claimed — and whether the assessor recorded any practices as "out of scope" or "not applicable". The Baker Hughes public certificate, for example, transparently states it was assessed at ML 2 and that 46 of the 47 practices were in scope (one was excluded, with rationale). That is the kind of clarity to look for and to ask for.

What IEC 62443-4-2 actually is

IEC 62443-4-2:2019, "Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components", defines what an individual industrial component must technically be able to do to claim a given Security Level. Per the IEC's own scope statement, it "provides detailed technical control system component requirements (CRs) associated with the seven foundational requirements (FRs)" and defines the Capability Security Level for components, SL-C(component).

Where 4-1 looks at the development organisation, 4-2 looks at the product itself — its identification mechanisms, its access control, its cryptography, its logging, its update mechanism, its hardening, its resilience.

The four component types

The standard recognises that "a PLC" and "a Windows engineering workstation" are not the same animal, and not all requirements apply equally to both. So requirements are split into a common core (designated CR, for Component Requirement) plus a layer of type-specific requirements:

flowchart TB
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef type fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;

    CR[Common Component
Requirements — CR]:::entry

    CR --> SAR[SAR
Software Application
Requirements
e.g. HMI software,
engineering tools]:::type
    CR --> EDR[EDR
Embedded Device
Requirements
e.g. PLC, RTU, IED,
safety controller]:::type
    CR --> HDR[HDR
Host Device
Requirements
e.g. HMI workstation,
engineering PC, server]:::type
    CR --> NDR[NDR
Network Device
Requirements
e.g. industrial switch,
firewall, gateway]:::type

The seven Foundational Requirements

All requirements in 4-2 are derived from the seven Foundational Requirements (FRs) introduced way back in IEC TS 62443-1-1:

flowchart LR
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef fr fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;

    FR[7 Foundational
Requirements]:::entry

    FR --> FR1[FR1 — IAC
Identification &
Authentication Control]:::fr
    FR --> FR2[FR2 — UC
Use Control]:::fr
    FR --> FR3[FR3 — SI
System Integrity]:::fr
    FR --> FR4[FR4 — DC
Data Confidentiality]:::fr
    FR --> FR5[FR5 — RDF
Restricted Data Flow]:::fr
    FR --> FR6[FR6 — TRE
Timely Response
to Events]:::fr
    FR --> FR7[FR7 — RA
Resource Availability]:::fr

Under each FR sit a number of Component Requirements (CRs), each of which may have one or more Requirement Enhancements (REs) that kick in at higher Security Levels. The total number of CRs is around 60–70 (commonly cited as 67) before counting REs and component-type-specific variants; the precise count depends on how you tally type-specific EDR/HDR/NDR/SAR rules. Some published summaries (such as Security Compass's overview) refer to "more than 140 specific cybersecurity requirements" when REs and component variants are included.

Security Levels 1 to 4 — graded by threat model

The genius of 4-2 is that the same requirement can apply with increasing strictness depending on who you expect to attack you. The four Security Levels are:

flowchart TB
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef sl1 fill:#fff8dc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;
    classDef sl2 fill:#ffe9b3,stroke:#cc7a00,color:#5a3300,stroke-width:1px;
    classDef sl3 fill:#ffc987,stroke:#b35900,color:#4a2200,stroke-width:1px;
    classDef sl4 fill:#ff9966,stroke:#992600,color:#3a0d00,stroke-width:1px;

    T[Security Levels
under IEC 62443]:::entry

    T --> S1[SL 1
Protect against
casual or coincidental
violation]:::sl1
    T --> S2[SL 2
Protect against intentional
violation using simple means,
low resources, generic skills,
low motivation]:::sl2
    T --> S3[SL 3
Protect against intentional
violation using sophisticated means,
moderate resources, IACS-specific
skills, moderate motivation]:::sl3
    T --> S4[SL 4
Protect against intentional
violation using sophisticated means,
extended resources, IACS-specific
skills, high motivation
i.e. nation-state class]:::sl4

Analogy: think of Euro NCAP crash-test ratings for cars. A one-star car is street-legal, but you do not want to put your family in it on the motorway. A five-star car is engineered to absorb a serious impact. SL 1 to SL 4 work the same way: you pick the level your operating environment justifies, and you pay (in cost, complexity and configuration overhead) accordingly. For most general industrial environments, ISASecure has publicly argued that SL 2 is a sensible minimum baseline for new procurement.

What 4-2 means practically for an OEM

Each FR translates into product features that a user can actually see and configure. A non-exhaustive selection:

• FR 1 – Identification & Authentication Control (IAC): unique user accounts, role-based identities, multi-factor authentication, password policy, account lockout, device-to-device authentication using cryptographic credentials, public-key infrastructure support.
• FR 2 – Use Control (UC): role-based access control, session management, session timeout, restricted execution of mobile code, USB-port control, wireless access management, audit log generation and protection.
• FR 3 – System Integrity (SI): signed firmware, secure boot, integrity-protected updates, malware protection, input validation, error handling that does not leak internals, tamper detection.
• FR 4 – Data Confidentiality (DC): encrypted communications (TLS or equivalent), protection of cryptographic keys, encryption of data at rest where relevant.
• FR 5 – Restricted Data Flow (RDF): zoning, segmentation, the ability to participate in a Zones & Conduits architecture, restriction of unnecessary network services.
• FR 6 – Timely Response to Events (TRE): audit logging with sufficient detail, log time-stamping, log forwarding (e.g. to syslog/SIEM), continuous monitoring hooks.
• FR 7 – Resource Availability (RA): denial-of-service resistance, fail-secure behaviour, resource exhaustion protection, backup and restore.

What changes between SL 1 and SL 4 is essentially the rigour and depth of those mechanisms. SL 1 might require "the component shall support authentication"; SL 3 will require unique per-user authentication with cryptographic mechanisms; SL 4 will add tamper-resistant credential storage and resistance to sophisticated attack.

The component type also matters. A PLC (EDR) is expected to have integrity-protected firmware and a hardware root of trust; an HMI workstation (HDR) is expected to support enterprise account management, anti-malware and OS hardening. Requirements are scoped to what is reasonable for the device class.

What an OEM must objectively demonstrate for 4-2

For 4-2 the evidence is per-product and per-version. There is no such thing as "our company is 4-2 certified" — only "this exact product, at this exact firmware version, achieves SL-C n against IEC 62443-4-2".

What "good" looks like

• The specific product identifier: model number, hardware revision, firmware/software version.
• A statement of the claimed Security Level Capability (SL-C) — usually one SL-C value per FR, sometimes published as a vector such as SL-C (2, 2, 2, 1, 2, 2, 2) across FR1–FR7.
• A declaration of which component type the product is assessed as (SAR, EDR, HDR or NDR) — and if it is a composite device, how the parts have been classified.
• Test reports demonstrating that each applicable CR and RE is met. Independent test reports are far stronger than self-declarations.
• A Security Functional Specification for end users: what each security feature does, how to enable it, and what residual risks remain if it is disabled.
• A hardening / secure configuration guide that tells the integrator exactly how to deploy the product so that the SL-C claim is achievable in the real installation.

The SL-C / SL-T / SL-A distinction — vital to understand

These three abbreviations get mixed up constantly and cause real procurement mistakes:

• SL-C (Capability) — what the product is technically able to provide when properly configured. This is what 4-2 and ISASecure CSA certify.
• SL-T (Target) — what the asset owner has decided is needed in a given zone of their plant, based on their risk assessment.
• SL-A (Achieved) — what is actually delivered once the product is installed, configured and integrated into the live system.

A product can be SL-C 3 capable but deployed as SL-A 1 if the asset owner switches off the features. Conversely, you cannot exceed your weakest component: a zone built from SL-C 2 components cannot achieve SL-A 3 just by wishful thinking.

Third-party certification — the gold standard

The principal scheme is ISASecure CSA (Component Security Assurance). From the ISASecure CSA-100 scheme document: CSA "focuses on the security of software applications, embedded devices, host devices, and network devices, as defined by the ISA/IEC 62443-4-2 standard" and is "designed to certify to international standards ISA/IEC 62443-4-2 and ISA/IEC 62443-4-1". The programme defines four certification levels — CSA Capability Security Level 1, 2, 3 and 4 — and the certification examines three things in addition to the development process:

• SDA-C (Security Development Artifacts for Components) — the development outputs for this product.
• FSA-C (Functional Security Assessment for Components) — the security capabilities the product actually exposes.
• VIT-C (Vulnerability Identification Testing for Components) — scanning the product for known vulnerabilities.

Crucially, the CSA scheme requires the supplier to hold a current ISASecure SDLA certification for the development process. As the ISASecure SDLA documentation puts it: "application of ISA/IEC 62443-4-1 practices as verified by SDLA certification is intended to provide confidence that the component or system has security commensurate with its expected level of risk throughout the product's life-cycle." In short: no SDLA, no CSA.

A live registry of CSA-certified components is maintained at isasecure.org/end-users/iec-62443-4-2-certified-components — a good first stop for any verification exercise. There is also an IIoT-specific extension, ISASecure ICSA, for IIoT components and gateways, with Core and Advanced tiers.

The IECEE CB Scheme also issues certificates against 62443-4-2 and 62443-4-1, recognised internationally between IECEE member bodies.

How 4-1 and 4-2 fit together

flowchart LR
    classDef entry fill:#1f6feb,stroke:#0b3a8c,color:#ffffff,stroke-width:1px;
    classDef proc fill:#e6f4ea,stroke:#1e8e3e,color:#0b3d20,stroke-width:1px;
    classDef prod fill:#fff4cc,stroke:#d39e00,color:#5a3d00,stroke-width:1px;

    O[OEM / Product Supplier]:::entry

    O --> P[62443-4-1
SDLA certifies the
development process
at Maturity Level 1–4]:::proc
    O --> Q[62443-4-2
CSA certifies the
specific product version
at SL-C 1–4]:::prod
    P -.prerequisite for.-> Q

Two practical truths follow:

1. You can in principle imagine a 4-2-compliant product from a vendor without 4-1 certification, but in real third-party schemes — and in ISASecure CSA in particular — the development process must be assessed too. CSA explicitly requires SDLA (or equivalent SDLPA-C process assessment) as a prerequisite. So the question to ask a supplier is rarely "either 4-1 or 4-2"; it is "show me both".
2. A vendor that holds only SDLA tells you their process is sound, but not that any particular product reaches a particular SL-C. A vendor that claims CSA without underlying SDLA is making a claim that does not fit the certification scheme — treat with caution.

This is also where the EU regulatory chain joins up. Under the Cyber Resilience Act , Annex I essential requirements for products with digital elements lean heavily on demonstrable secure development and component capabilities — exactly what 4-1 and 4-2 codify for the industrial domain. And under NIS2 Article 21(2)(d), the asset owner's supply-chain security obligations cascade contractual demands back through their suppliers: in practice, that often arrives at the OEM as a request for 4-1 and 4-2 evidence.

Common pitfalls and red flags

Certain phrases and situations in an OEM's compliance claim should slow a buyer down before the contract is signed.

A buyer's checklist for procurement

Use this as a contract annex or as a supplier questionnaire.

Questions to put to the OEM in writing

1. Does the company hold a current ISASecure SDLA certificate (or equivalent IECEE 62443-4-1 certificate)? At what Maturity Level? Issued by which certification body, on which date, expiring when?
2. What is the scope of that SDLA certificate — which development sites, which business units, which product lines?
3. For the specific product being quoted, does it hold an ISASecure CSA certificate (or equivalent IECEE 62443-4-2 certificate)?
4. What is the exact model number and firmware/software version covered by the certificate?
5. What is the claimed SL-C for each of the seven Foundational Requirements (the SL-C vector)?
6. Which component type has been certified — SAR, EDR, HDR or NDR?
7. Please provide the certificate PDF, the public certification report (where available), and the hardening guide / security functional specification for the product.
8. Please provide the vulnerability disclosure policy URL and a list of CVEs handled in the last 24 months for this product family.
9. What is the support and patch lifetime of the product, and the documented end-of-life policy?
10. Please describe the SBOM or third-party component inventory available for this product.

Documents to demand on file

• SDLA / IECEE 62443-4-1 certificate.
• CSA / IECEE 62443-4-2 certificate per product and version.
• Product Security Functional Specification.
• Hardening / secure configuration guide.
• Vulnerability disclosure policy.
• Sample security advisory (to confirm a real disclosure process exists in practice).

Verification steps

• Cross-check the certificate number on the ISASecure certified products registry at isasecure.org/end-users/iec-62443-4-2-certified-components .
• For IECEE certificates, verify on the IECEE CB Scheme certificate database at iecee.org .
• Confirm the certificate is in date and the scope statement matches the model and firmware you are actually buying.
• Compare the SL-C vector against your own SL-T from your risk assessment.
• Ask for evidence that the product as shipped to you matches the certified version — patches and minor releases can move the product outside the certified scope.

IEC 62443-4-1 asks the OEM "Are you the sort of organisation that can build secure products, repeatably, and keep them that way?" IEC 62443-4-2 asks the same OEM "Does this exact product, at this exact version, have the technical security features needed to resist the threats in its operating environment?"

Together they form one of the most rigorous answers the industrial world has to "how do I know this OEM is serious about cybersecurity?" — but only if you read past the brochure to the certificate, and past the certificate to its scope.

Treat them as the foundation, not the finish line. A certified product, badly deployed and never patched, is no more secure than an uncertified one. And an uncertified product, however well-intentioned the vendor, is asking you to take all the assurance on trust.