IEC 62443-4-1 Is Showing Up in Every OT RFP — Here’s What the Certification Actually Promises

If you’ve sent out a PLC, HMI, drive, or industrial gateway RFP in the last year, you’ve probably noticed a new line item creeping into vendor responses, usually somewhere near the top: “IEC 62443-4-1 certified.” It sits next to the UL marks and the CE declarations like it’s always been there. It hasn’t. This is a recent shift, and it’s happening because buyers started asking a question vendors couldn’t answer with a datasheet: how do we know your product wasn’t just built fast and patched later?

The honest answer is that 4-1 certification doesn’t fully answer that question either. It answers a narrower, still-useful one. If you’re evaluating vendor responses this renewal season, you need to know exactly which question is being answered, because the certification badge on a cover page is doing a lot of work it may not have earned.

What 4-1 actually certifies — and what it doesn’t

IEC 62443-4-1 is a process standard. It certifies that a vendor’s secure product development lifecycle — the internal engineering process used to design, build, test, and maintain products — meets defined practices across areas like threat modeling, secure coding standards, security testing, vulnerability handling, and patch management. An auditor from an accredited certification body reviews the vendor’s documented lifecycle and, ideally, evidence that it’s actually followed on real projects, not just written down in a binder.

What it does not certify is any individual product. A vendor can hold a shiny 4-1 certificate covering their whole PLC product line and still ship a firmware release with a serious flaw in it. That’s not a failure of the standard — it’s the standard doing exactly what it says on the tin. 4-1 is about the kitchen, not the meal. A well-run kitchen with the right food-safety procedures still occasionally sends out a bad plate; the point is that the process for catching and fixing that is in place and repeatable.

This is where the standard gets confused with two adjacent parts of the IEC 62443 family, and vendors are not always eager to clear up the confusion:

4-1 vs. 4-2 vs. 3-3

• IEC 62443-4-1 — process certification for the vendor’s development lifecycle. Applies to the vendor as an organization (or a specific product line’s development process). Tells you how the sausage is made.
• IEC 62443-4-2 — technical requirements for a specific component (PLC, HMI, network device) at a defined security level, covering things like authentication, logging, and resource availability under attack. This is a product certification. It tells you what the sausage actually contains.
• IEC 62443-3-3 — system-level security requirements, relevant to integrators and asset owners assembling a zone-and-conduit architecture, not something an individual PLC vendor typically claims on its own.

A vendor citing 4-1 in an RFP has told you something real about their engineering discipline. A vendor citing 4-2 for a specific SKU has told you something about that product’s actual security capabilities at a specific security level (SL-1 through SL-4). These are not interchangeable claims, and RFP boilerplate loves to blur them. If a response says “IEC 62443 certified” without specifying which part, that’s your first flag, not your last.

Why this is happening now

The push into secure-by-design attestations coming out of CISA, the growing habit of treating known-exploited-vulnerability catalogs as a baseline for OT risk conversations, and buyer-side demands for software bills of materials have all converged on vendors at roughly the same time. Asset owners increasingly want to know not just “is this patched” but “does this company have a repeatable way of finding and fixing the next one.” 4-1 is the closest thing the industry has to a portable, third-party-audited answer to that question, so it’s become the credential vendors reach for first — partly because it’s genuinely relevant, and partly because it’s a defensible, quotable line for a sales engineer to put in a proposal without disclosing much.

For PLC, HMI, and drive vendors specifically, pursuing 4-1 also makes commercial sense independent of any single customer’s ask: it’s a one-time (if substantial) investment that lets them answer the same question across dozens of RFPs instead of filling out a bespoke security questionnaire every time. Expect the badge to keep spreading through 2026 regardless of what any individual plant does about it.

A practitioner’s checklist for reading the claim

When “IEC 62443-4-1 certified” lands in a vendor response, don’t take the logo at face value. Work through this:

• Ask which product line the certificate actually covers. 4-1 certificates are often scoped to a specific business unit or product family. A certificate covering the vendor’s DCS platform doesn’t automatically extend to a drive line they acquired two years ago.
• Ask for the certificate number and issuing body, and verify it independently rather than trusting a PDF badge image. Accredited certification bodies maintain registries; a vendor confident in the claim will hand this over without friction.
• Check the certificate date and renewal status. 4-1 certification isn’t permanent — it requires surveillance audits and recertification. A certificate from several cycles ago with no recent audit activity tells you less than a current one.
• Ask what maturity level was assessed. The standard defines practices with graduated maturity expectations; “certified” can mean baseline compliance or a more mature, consistently demonstrated process. Vendors rarely volunteer which.
• Separate the 4-1 claim from any product-specific 4-2 claim. If you need assurance about a specific PLC’s authentication or logging behavior, ask for 4-2 evidence at a stated security level, not just a lifecycle certificate.
• Ask how vulnerability disclosure actually works in practice. Request their published security advisory history or a PSIRT contact. A mature 4-1 process should produce a visible, dated trail of disclosures and patches — if there’s nothing to point to, be skeptical of how rigorously the process is really being run.
• Ask about SBOM delivery mechanics</strong, not just whether SBOMs exist. Format, update cadence, and how it's delivered for a given firmware version all matter more than a yes/no answer.