Identification and authentication control
Every user, device and process proves who it is before it gets in.
Typical featuresUnique accountsCertificates or strong passwordsMFA for peopleAccount lockout
Product cybersecurity
IEC 62443-4-2 CSA Certification
Find the security features your product is missing, design them in, and certify the component.
Best forMakers of controllers, gateways, sensors, network devices and industrial software that need a certified component. ISASecure CSA, TÜV or exida.
Service overview
The features your product needs, and how to build them in
IEC 62443-4-2 lists the security capabilities a component must have, grouped under seven foundational requirements and graded by security level. It is the standard your customers point to when they ask whether your product can go into their zone at SL 2 or SL 3.
We start by settling the component type and the target security level with you, then check the product feature by feature. For every capability that is missing or partial, we identify the feature you need, show how to integrate it into the product with the least change to the architecture, and help you produce the evidence that it works.
An IEC 62443-4-2 certificate needs an IEC 62443-4-1 process behind it, at maturity level 3 for the practices applied to this product: practiced, with evidence, for the features going into the certified component. If you already have that, we build on it. If you do not, the SDLC track runs with this one and the two audits are planned together.
What we cover
- Component type: embedded device, host device, network device or software application
- Target security level agreed with your customers in mind
- Feature gap assessment against every component requirement, FR 1 to FR 7
- New features identified and designed into the product: authentication, access control, integrity, confidentiality, logging, resource protection
- Common component security constraints, including the IEC 62443-4-1 process requirement
- Verification evidence per requirement: test plans, test results, documentation
- Robustness and vulnerability testing planned before the audit
- Audit preparation and support on the day
IEC 62443-4-2
Seven foundational requirements, feature by feature
The component requirements sit under seven headings. For each one we check what the product has, name the feature that is missing, and show how to build it in with the least change to the architecture. Which features you need depends on the target security level.
Use control
Each identity can do only what its role allows, and the product records who did what.
Typical featuresRole-based accessSession lock and timeoutAuthorised firmware changes
System integrity
Firmware, software and data cannot be changed unnoticed.
Typical featuresSigned firmwareSecure bootInput validationIntegrity checks
Data confidentiality
Data at rest and on the wire stays private.
Typical featuresEncrypted protocolsKey managementProtected secrets
Restricted data flow
Only the traffic the product needs, on the interfaces it needs.
Typical featuresUnused ports and services offAllow-listsSegmentation support
Timely response to events
Security events are recorded and can be read by the people who need them.
Typical featuresAudit logTimestampsLog export to the SOC
Resource availability
The product keeps doing its job under attack and comes back after one.
Typical featuresDoS resistanceResource limitsConfiguration backup and restoreFail-safe behaviour
SL 1Casual or coincidental misuse
SL 2Simple means, low resources, generic skills
SL 3Sophisticated means, moderate resources, IACS skills
SL 4Sophisticated means, extended resources, IACS skills
Gap assessment output
The traffic light report
The feature gap assessment reports every component requirement for your target level in one of three colours.
Green
Keep doing
The capability is there and the evidence exists. It goes into the audit file as it is.
Amber
Tune up
Present in part, or met only by a compensating measure that still needs documenting in the security guidelines.
Red
Start now
Missing. A feature to design into the product before the audit, planned first because it sets the timeline.
Our approach
Engagement methodology
The steps of the engagement, built around how your team already designs, builds and releases the product.
Target definition
Settle the component type, the target security level and the scope of the certificate. The target level comes from where your customers will deploy the product, not from ambition: an SL 2 certificate that ships beats an SL 3 programme that does not.
OutputComponent type, target SL, certificate scope
Feature gap assessment
Check the product against every component requirement for the target level, FR 1 to FR 7, plus the common constraints. Each requirement is marked met, partial or missing in a Traffic Light report, with the evidence that exists today.
OutputTraffic Light feature gap report
New features and how to integrate them
For every partial or missing requirement we identify the feature you need and how to build it into the product with the least change to the architecture: what goes in firmware, what in the application, what can be met by a documented compensating measure. Your engineers keep the design decisions.
OutputFeature list with design options
Verification evidence
A test plan per requirement, run with your team: functional tests, robustness tests, vulnerability scans, and the documentation the auditor will ask for. Evidence is collected as the features land, not at the end.
OutputTest plan and evidence per requirement
Certification audit
We prepare the audit file, join the assessment and close findings with you, whether the scheme is ISASecure CSA, TÜV or exida.
OutputCertificate
Common questions
Frequently asked questions
Talk to RelyBlue
Ready to discuss IEC 62443-4-2 CSA Certification?
An honest conversation about your product and the path to CRA compliance or IEC 62443 certification. No sales pressure, no fear tactics.
- You talk to a senior advisor, never a salesperson