IEC 62443-4-2
The technical bar a component has to clear
IEC 62443-4-1 asks whether your development process is capable. IEC 62443-4-2 asks a different question: what can the component itself actually do? It defines the technical security capabilities a component brings to an industrial system, rated on four capability security levels an evaluator works to.
Why it matters
A secure process does not prove a capable product
You can run an exemplary secure development lifecycle and still ship a component that cannot authenticate a user, encrypt a connection, or survive a burst of traffic. 4-1 measures how you build; 4-2 measures what you built. Certification schemes normally expect both, because an auditor who trusts your process still has to see the capabilities in the product.
The value of 4-2 is that it is concrete. Each requirement is a capability an evaluator can look for, an integrator can switch on, and an attacker can exploit if it is missing. That makes it the standard your customers — the system integrators and asset owners building with your component — actually read when they decide whether your product can go into their system.
This assessment scores the component requirements every component shares. The type-specific requirements for your component sit on top and need separate review — the result says so plainly.
The seven foundational requirements
What a component is measured on
IEC 62443-4-2 groups its component requirements under the same seven foundational requirements the whole 62443 series shares. Each reaches the level of its weakest requirement — a component cannot claim a level for a foundational requirement while one requirement it depends on is absent.
- FR 1
Identification and authentication control
Whether the component can tell who or what it is talking to — human users, and other software and devices — before it grants access.
- FR 2
Use control
Once something is identified, whether the component enforces what that identity is allowed to do, and records what it did.
- FR 3
System integrity
Whether the component can protect itself and its data from unauthorised change, in transit and at rest.
- FR 4
Data confidentiality
Whether the component keeps sensitive information from being read by those who should not see it, and the cryptography it uses to do so.
- FR 5
Restricted data flow
Whether the component can sit in a segmented network and control what is allowed to cross the boundary around it.
- FR 6
Timely response to events
Whether the component makes its security events available so someone — or another system — can notice and respond.
- FR 7
Resource availability
Whether the component keeps working under stress and can be backed up and recovered — the priority that sets industrial systems apart from IT.
- How to read them
A component is not rated once overall — it earns a capability security level against each of the seven requirements separately. That per-FR profile is exactly what a system integrator carries into an IEC 62443-3-3 assessment, so the same seven headings follow the product from the component bench to the installed system.
Capability security levels
SL-C 1 to 4: the attacker each level withstands
A capability security level (SL-C) is defined by the kind of adversary the component can resist, not by a score. The right target is not universal — it comes from the risk assessment of the system the component goes into (IEC 62443-3-2), set by the integrator or asset owner.
- SL-C 1Casual or coincidentalProtection against mistakes and incidental misuse, not a deliberate attacker.
- SL-C 2Simple, intentionalProtection against intentional misuse using simple means: low resources, generic skills, low motivation. The level most components are expected to reach.Most common target
- SL-C 3Sophisticated, ICS-specificProtection against intentional misuse using sophisticated means: moderate resources, ICS-specific skills, moderate motivation.
- SL-C 4Sophisticated, well-resourcedProtection against sophisticated means with extended resources, ICS-specific skills, and high motivation. Rare outside the highest-consequence systems.
Component types
One shared set, four type-specific sets on top
IEC 62443-4-2 defines the shared component requirements plus a second set for each component type. This assessment scores the shared set — which applies to every component — and points you at the type-specific set your component also has to meet.
- SAR
Software application
Software running on a host — a SCADA client, engineering tool, or historian.
- EDR
Embedded device
A purpose-built device with firmware — a PLC, RTU, IED, or sensor.
- HDR
Host device
A general-purpose computer running your software — an operator workstation or server.
- NDR
Network device
A device that moves or filters traffic — a switch, router, firewall, or gateway.
How the series fits together
Process, product, and system
4-1 and 4-2 are companions: 4-1 certifies the development process behind the component, 4-2 certifies the technical capability of the component itself. A certification scheme normally expects both — a capable product built through a secure process.
Above the component sits the system. IEC 62443-3-3 assesses what a whole system achieves in the field (SL-achieved), using the same seven foundational requirements. Your component profile is a building block the integrator combines, hardens at the zone boundary, and demonstrates at system level.
Why SL-C is a ceiling, not a guarantee
A component capable of SL-C 3 only contributes SL-3 to a system if the integrator deploys it that way, and capabilities that ship switched off contribute nothing until someone enables them. A gap at component level is a gap the integrator inherits — which is why closing it here is usually cheaper than compensating for it later.
Assessments for this framework
Structured questionnaires scored entirely in your browser — no account, nothing transmitted. Each maps its result back to the requirement it measures.
Get in touch
Pin down which IEC 62443-4-2 requirements your components must meet
Tell us what the component is and the security level you are targeting or being asked for. We will come back with the requirements that apply at that level, and where your current design is likely to fall short of them.
We reply within two working days.
Full contact detailsOpens our scheduling page in a new tab — pick a slot that suits you.
Useful in a first message
- What the component is — embedded device, host, network, or software application.
- The security level (SL 1–4) you are targeting, or that a customer or integrator is asking for.
- Whether this sits alongside an IEC 62443-4-1 process or CRA obligation you are also working on.
Please keep a first message free of confidential technical detail and trade secrets. Once we reply we can agree an encrypted channel for anything sensitive.