Meeting IEC 62443 on Real Hardware
IEC 62443 is the dominant standard for industrial automation and control system security, and increasingly a procurement and regulatory requirement. The standard is comprehensive, which is its strength and its challenge: applying it to a specific piece of embedded hardware takes interpretation. Here is how I approach meeting 62443 on real devices rather than treating it as a document to wave at auditors.
What 62443 Is and Is Not
IEC 62443 is a family of standards covering the security of industrial automation and control systems, addressing the whole ecosystem: the asset owners who operate the systems, the integrators who build them, and the product suppliers who make the components. It is process and requirements heavy, deliberately broad, and meant to be tailored to a context rather than applied verbatim.
For someone building an embedded industrial product, the relevant parts are mainly the component requirements, what a secure device must do, and the secure-development lifecycle, how it must be built. Understanding which parts of the sprawling standard apply to your role is the first step, because trying to satisfy all of it without that focus is how teams drown in a standard meant to be scoped.
Security Levels
A central concept is the Security Level, a target from SL 1 to SL 4 describing the strength of attacker the system should resist, from casual or accidental at SL 1 to a well-resourced, motivated, ICS-specialized attacker at SL 4. The level drives how rigorous the controls must be, so choosing the right one is the foundational decision.
SECURITY LEVELS (resistance target) SL 1 protection against casual or accidental violation SL 2 intentional violation, simple means, low resources SL 3 intentional, sophisticated means, moderate resources (ICS-specific) SL 4 intentional, sophisticated means, extended resources (ICS-specific)
Matching the target level to the device’s real risk keeps the effort proportional. A simple sensor in a benign location may warrant SL 1 or 2; a controller for critical infrastructure facing capable adversaries warrants SL 3 or higher. Setting the level too high wastes effort on threats outside the device’s reality; too low leaves real risk unaddressed. This judgment, made early, shapes everything after.
The Foundational Requirements
62443 organizes its technical requirements into seven foundational requirements: identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely response to events, and resource availability. Every specific requirement maps to one of these, and they make a useful checklist for thinking about a device’s security comprehensively.
Walking a device against the seven is a good way to find gaps. Does it authenticate who connects and control what they can do, protect its own integrity and the confidentiality of sensitive data, restrict data flows appropriately, support detecting and responding to events, and remain available under stress. A device weak in one of these has a concrete area to improve, named in the standard’s own terms.
Translating Requirements to Hardware
The work of meeting 62443 on real hardware is translating its requirements into specific design features. Identification and authentication becomes a real auth mechanism on the device’s interfaces. System integrity becomes verified boot and signed firmware. Restricted data flow becomes the segmentation the device supports. The standard says what; the engineering decides how.
This translation is where interpretation lives, and where experience matters. A requirement like the component shall verify the integrity of its firmware maps to verified boot anchored in hardware, with the specifics, which root of trust, which signature scheme, left to the designer. Meeting the standard well means choosing implementations that genuinely satisfy the intent, not box-checking with token measures that pass an audit but not an attacker.
The Secure Development Lifecycle
62443-4-1 specifies a secure development lifecycle for product suppliers: threat modeling, secure design, security requirements, secure implementation, security testing, and a defined process for handling vulnerabilities after release. Certification against it is increasingly expected, and it shapes how the whole product is built, not just what features it has.
Adopting this lifecycle is often the larger lift, because it changes process rather than adding a feature. It means threat modeling in design, writing and tracing security requirements, testing against them, and committing to handle field vulnerabilities responsibly. For a team, building this process is what makes 62443 compliance sustainable rather than a one-time scramble, and it improves the product regardless of the certificate.
Component Requirements Versus System
62443 distinguishes what a component must do from what the integrated system must do, and a device supplier is responsible for the component part while relying on the integrator and asset owner for the rest. A device need not implement every system-level control itself, but it must provide the capabilities the system relies on, and document them.
Being clear about this boundary keeps a supplier from either over-building, trying to solve system problems in a component, or under-delivering, assuming the integrator will cover a gap the device should have closed. The device’s job is to offer the security capabilities the standard expects of a component at its target level, and to document them so the integrator can build a compliant system on top.
Documentation and Evidence
62443 is evidence-driven. Meeting it means not only building secure features but documenting the threat model, the requirements, the testing, and the security capabilities the product provides. Much of the effort in a certification is producing the artifacts that demonstrate the requirements are met, which is why building them as you go beats reconstructing them later.
This documentation overlaps heavily with good security engineering, a threat model, a requirements document, a test plan and results, so a team that does the engineering well is most of the way to the evidence. Framing the security work to also produce the 62443 artifacts, from the start, turns compliance from a separate burden into a byproduct of building the product properly.
Avoiding Box-Checking
The risk with any standard is meeting the letter while missing the intent, implementing a weak version of each requirement that passes an audit but not an attacker. 62443’s breadth makes this tempting, because there is a lot to satisfy. The antidote is to treat the requirements as prompts to genuinely secure the device, with real testing to confirm the controls work.
Pairing 62443 compliance with actual penetration testing is the check that keeps it honest. The standard ensures breadth of coverage; the testing confirms depth, that the authentication cannot be bypassed, the verified boot actually holds, the segmentation is real. A device that is both 62443-compliant and survives a serious test has met the intent, not just the checklist.
A Practical Path
For a team facing 62443, the practical path is to scope which parts apply to your role, choose a target security level matched to your device’s real risk, walk the foundational requirements to find gaps, translate the relevant requirements into concrete hardware and firmware features, adopt the secure development lifecycle, and produce the evidence as you go.
Done this way, 62443 becomes a structured way to build a genuinely secure industrial product, with the certificate as a result rather than the goal. The standard is large, but applied with judgment and paired with real testing, it organizes the work of securing embedded industrial hardware into something achievable and worthwhile, which is what a good standard should do.
A Worked Requirement Translation
The abstract requirements become tractable when you translate a few concretely. Take the component requirement for software integrity: 62443 says the component shall verify the integrity of firmware and software before execution. On real hardware that becomes a specific design: a hardware root of trust holding a public key, a boot ROM that verifies the next stage’s signature, and a refusal to run anything that fails.
62443 CR (integrity) -> concrete hardware design "verify firmware integrity before execution" -> ROM verifies SPL signature (ECDSA-P256) against fused key hash -> SPL verifies U-Boot; U-Boot verifies kernel (chain of trust) -> any failure halts boot; no unsigned stage runs VERIFY: flash a tampered stage -> device refuses to boot it
Doing this translation for each applicable requirement is the real work of meeting 62443, and it is where engineering judgment lives. The standard states the property; you choose the root of trust, the signature scheme, and the failure behavior, then prove the choice satisfies the intent. A requirement met this way is genuinely secure, not merely documented, which is the difference between compliance that helps and compliance that only passes an audit.
Mapping Effort to Security Level
Because the rigor scales with the target security level, it helps to see how the same requirement deepens as the level rises. At SL 1 an authentication requirement might be satisfied by a simple shared credential; at SL 3 it demands individual, cryptographically strong authentication resistant to a sophisticated attacker. The requirement is the same sentence; the bar it sets climbs with the level.
This is why choosing the level honestly matters so much, and why I tie it to the device’s real threat model rather than to ambition or marketing. A device aimed at SL 3 has to back every foundational requirement with controls that withstand a resourced, ICS-specialized attacker, which is a large commitment. Setting the level where the threats actually are keeps the 62443 effort proportional and the resulting certificate meaningful rather than aspirational.
Where This Fits
Helping teams interpret and meet IEC 62443 on real embedded hardware, and confirming the controls with testing, is part of the secure-development and assessment work I do for industrial products. If you are targeting 62443 and want it applied to your device in practice, not just on paper, that is the kind of work we do at Berkner Tech.