For years, IEC 62443-4-1 and 4-2 certification lived mostly in vendor whitepapers and RFP boilerplate. That’s changing. Major PLC, HMI, and industrial networking vendors have been pushing certified product lines through their catalogs, certification bodies have built out accredited labs to keep pace, and procurement teams are now writing “62443-4-2 certified” into purchase specs as a hard requirement rather than a nice-to-have. That’s genuinely good news. It’s also creating a new failure mode: plant teams treating the certification badge as proof that a device is secure, full stop, when it certifies something narrower and more specific than that.
If you’re specifying, buying, or integrating certified components this year, the badge is a useful signal. It is not a substitute for your own risk analysis. Here’s how to read it correctly.
What 4-1 and 4-2 actually certify
IEC 62443-4-1 certifies a process, not a product. It audits the vendor’s secure development lifecycle: threat modeling during design, secure coding practices, security testing (fuzzing, vulnerability scanning, penetration testing), patch management processes, and a defined vulnerability disclosure and response process. A vendor can hold a 4-1 certification at the organizational level that covers how they build things in general, independent of any specific product passing 4-2.
IEC 62443-4-2 certifies a component against technical requirements mapped to security levels (SL-1 through SL-4) 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. A PLC or HMI certified to, say, SL 2 has demonstrated it meets specific technical controls at that level: things like role-based access control, session lock, audit logging capacity, and resistance to certain classes of denial-of-service behavior.
Both certifications matter, and they answer different questions. 4-1 tells you the vendor has a credible process for finding and fixing vulnerabilities in what they ship you over its life. 4-2 tells you the specific component you’re buying meets a defined set of technical security capabilities today, as tested, in the configuration it was tested in.
What the badge does not tell you
This is where the confusion on the floor actually causes problems.
- It doesn’t certify your configuration. A 4-2 certified HMI shipped with all security features enabled and default credentials changed is a different risk posture than the same HMI deployed with vendor defaults intact because commissioning ran out of hours. The certification tested a defined configuration profile — not however your integrator actually racked and configured it.
- It doesn’t certify the system it’s dropped into. IEC 62443-3-2 and 3-3 govern system-level security, zones, conduits, and system security levels — and those are your responsibility, not the component vendor’s. A certified PLC sitting on a flat network with no segmentation gets none of the benefit its certification implies.
- It doesn’t guarantee the security level maps to your target security level. A component certified at SL 2 does not automatically deliver an SL 2 zone. Zone-level security level depends on every asset in that zone, the conduits connecting it to others, and compensating controls layered around it.
- It has a shelf life. Certifications are tied to specific firmware/software versions. A patch, a feature update, or a hardware revision can move a product out of scope of its original certificate until it’s recertified. Ask when the cert was issued and against which version.
- It says nothing about legacy assets. The controller you installed a decade ago, still running fine on the floor, was never going to be retrofitted into a certification program. Certified new purchases don’t retroactively secure the rest of your architecture.
A procurement checklist that actually interrogates the claim
Don’t accept “IEC 62443-4-2 certified” as a line item. Ask for specifics:
- Which security level was achieved — SL-1, SL-2, SL-3? Vendors will sometimes let “certified” do the work that “certified to SL-1” should be doing.
- Which firmware/software version and hardware revision does the certificate cover, and is that the version you’re actually receiving?
- What configuration was the certified test conducted against? Ask for the capability security level documentation and the recommended hardening configuration, not just the certificate PDF.
- Is the 4-1 process certification held by the specific business unit and product line, or claimed at a corporate level that may not reflect this product’s development history?
- What’s the vendor’s committed patch cadence and end-of-support date for this product, and does that align with your asset lifecycle?
- Which accredited certification body issued it (ISASecure, TÜV, exida, and similar bodies operate accredited 62443 schemes)? Confirm the certificate is current and hasn’t lapsed.
Mapping certified components into your zone/conduit model
The real engineering work starts after the badge is verified. A certified component’s SL-C (capability) rating is a ceiling, not a floor for your zone. Your job is to determine the target security level (SL-T) for the zone that component lives in — based on consequence of compromise, not on what’s convenient to buy — and then check whether the achieved level (SL-A) of the whole zone, given everything else connected to it, actually reaches that target.
In practice that means documenting, per zone: which assets are certified and to what level, which conduits cross zone boundaries and what’s mediating them (firewalls, data diodes, protocol breaks), and where the zone’s weakest asset sets the practical ceiling regardless of what the newest PLC can do.
Where compensating controls still carry the load
Most plants have brownfield floors: a mix of certified new equipment next to controllers that will run until end of life with no realistic path to 4-2 compliance. That’s not a failure of the standard — 62443 was written with exactly this in mind. Zones can still reach a reasonable security level through compensating controls: network segmentation and conduit enforcement via industrial firewalls, application allowlisting on HMI and engineering workstations, unidirectional gateways for historian and reporting traffic out of sensitive zones, jump hosts and MFA for remote access into the OT environment, and strict change management around anything touching PLC logic.
The honest way to run this is to treat legacy assets as permanently un-certifiable and design the zone architecture around that fact, rather than waiting for a certified replacement that may be years off in the capital plan.
The actual payoff of certification, used correctly
Used as one input among several, 4-1/4-2 certification is a real improvement over the alternative, which was vendors making unverifiable security claims in a datasheet. It gives you an accredited third party’s word that a development process exists and that specific technical controls were tested against a defined profile. That’s worth something in vendor selection and worth documenting for audit and insurance purposes.
What it isn’t is a substitute for your own zone/conduit analysis, your own hardening verification at commissioning, and your own compensating controls program for the legacy assets that certification will never reach. Treat the badge as a strong data point in a risk conversation you’re still required to have — not as the conversation’s conclusion.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
