CRA and IEC 62443-4-1
IEC 62443-4-1 and the Cyber Resilience Act: from secure development lifecycle to CRA evidence
Already developing to IEC 62443-4-1, or planning a secure development lifecycle? We map Annex I of the Cyber Resilience Act onto the practices of your process and assess only what is still missing for the CRA. Without a 62443 process, we build with you the elements the CRA requires.
What IEC 62443-4-1 covers and what the CRA adds
IEC 62443-4-1 sets requirements for the development process of products used in industrial automation: security requirements, design, implementation, testing, handling vulnerabilities and updates, security guidance for users. The standard groups this into eight practices, from security management (SM) to security guidelines (SG).
The Cyber Resilience Act works at the level of the individual product: the manufacturer assesses its cybersecurity risks, takes the outcome into account from planning to maintenance and includes the assessment in the technical documentation (Art. 13(2) to (4)). A certified 62443-4-1 process shows a method and, through SR-2, calls for a threat model per product. It does not by itself produce the assessment in the form Article 13(3) and (4) and Annex VII(3) require: for each requirement in Annex I Part I(2), whether it applies, how it is implemented and, where it does not apply, the justification. On top of that come obligations a 2018 standard cannot anticipate, such as notifications under Article 14 via the single reporting platform, which have applied since 11 September 2026.
Service modules
You commission what is missing. We keep using your existing processes, templates and tools.
Delta assessment against your 62443-4-1 process
We map Annex I Parts I and II onto the practices of your existing process and assess only what the process does not yet produce for the CRA. What works is not rebuilt.
More on the gap analysisRisk assessment per product
We derive architecture, data flows and trust boundaries from source code, deployment configuration and documentation, and keep the threat model as code in your repository. From it we work out the risk assessment for the technical documentation with your developers; the model can be re-run on a changed release.
Threat modelingCRA building blocks without a 62443 process
Without a 62443 process we start with the elements the CRA requires for each product: the risk assessment per product, an SBOM chain from the build pipeline, a process for handling vulnerabilities and the Article 14 reporting process.
Article: security by designWhat you end up with
Results that go into the technical documentation and that your team carries forward.
01
Mapping of Annex I to IEC 62443-4-1
Per requirement: which practice covers it, what evidence exists, what is missing.
02
Gap report per product
Rated findings and a prioritised action plan.
03
Risk assessment per product
For Annex VII(3), with a model that can be re-run on a changed release.
04
Description of the specifications applied
Text for Annex VII(5) for as long as no harmonised standard is applied.
Example extract: Annex I and the practices of IEC 62443-4-1
This is what the mapping in the delta assessment looks like. It is our own simplified reading: neither the CRA nor IEC 62443-4-1 contains an official mapping. In an engagement it is built per product from your process.
| CRA requirement | IEC 62443-4-1 practice | What we check for the CRA |
|---|---|---|
| Risk assessment per product (Art. 13(3) and (4), Annex VII(3)) | SR (incl. SR-2 threat model) | A document per product, with reasons for requirements that do not apply. |
| Security updates, secure distribution (Annex I Part I(2)(c), Part II(2), (7), (8)) | SUM | Separate security updates where feasible; automatic with opt-out where applicable. |
| Software bill of materials (Annex I Part II(1)) | SM (third-party components) | SBOM per release, machine-readable, at least top-level dependencies. |
| Handling and disclosing vulnerabilities (Annex I Part II(2), (4) to (6)) | DM | Coordinated vulnerability disclosure policy, contact address, publication of fixed vulnerabilities. |
| Information and instructions to the user (Annex II) | SG | Single point of contact for vulnerabilities, end date of the support period. |
Mapping by Blackfort Technology. Requirements from Regulation (EU) 2024/2847; practices and abbreviations from the table of contents of IEC 62443-4-1:2018.
How we work
From your existing process to evidence per product.
1
Free initial call
Products, development process, existing certificates and your customers’ requirements. You then receive a proposal with a clearly defined scope.
2
Delta assessment
Map Annex I to the practices of your process, review the evidence, gap report per product.
3
Closing the gaps
Risk assessment per product, SBOM chain, reporting process, depending on the findings.
4
Documentation
Material for the technical documentation and for the information and instructions to the user under Annex II.
Is IEC 62443 a harmonised standard under the CRA?
A standard gives rise to a presumption of conformity only if it is a harmonised standard whose reference has been published in the Official Journal of the EU, and only for the requirements it covers (Art. 27(1)). Common specifications and European cybersecurity certification can also give rise to a presumption (Art. 27(5) and (8)). On 3 February 2025 the Commission asked CEN, CENELEC and ETSI to draft European standards in support of the CRA (standardisation request M/606, Implementing Decision C(2025) 618). When we checked on 9 October 2026, no such reference under the CRA had been published in the Official Journal. IEC 62443-4-1 therefore does not give rise to a presumption of conformity under the CRA today.
The standard is still useful: without harmonised standards, the technical documentation describes the solutions adopted and lists the other relevant technical specifications applied (Annex VII(5)). That is where an established 62443-4-1 process belongs. For important products in class I, however, a notified body then has to be involved unless common specifications or a European cybersecurity certification scheme at assurance level at least ‘substantial’ are applied in full (Art. 32(2)).
What we do not do
So that expectations are right:
- We are neither a certification body nor a notified body. We do not issue IEC 62443 certificates or certificates in the conformity assessment procedure.
- Penetration tests are not part of our services, including for the SVV practice.
- No legal services: we assess role and product class technically and flag questions that need a legal decision for review by your legal department or counsel.
The CRA obligations remain with your company. We help you meet them and document the evidence.
Frequently asked questions
Is IEC 62443-4-1 certification enough for the Cyber Resilience Act?+
No. It evidences a development process with a method. The CRA additionally requires, per product, a risk assessment, technical documentation, information and instructions to the user and a conformity assessment, plus the Article 14 reporting channels. The delta assessment shows which of these your process already delivers. Certificates to IEC 62443-4-1 are issued by accredited certification bodies; Blackfort Technology does not certify.
Is IEC 62443-4-1 a harmonised standard under the CRA?+
When we checked on 9 October 2026, no reference of a harmonised standard under the CRA had been published in the Official Journal. A presumption of conformity based on a harmonised standard (Art. 27(1)) only arises with that publication.
Which practices does IEC 62443-4-1 contain?+
Eight: security management (SM), specification of security requirements (SR), secure by design (SD), secure implementation (SI), security verification and validation testing (SVV), management of security-related issues (DM), security update management (SUM) and security guidelines (SG).
We have no secure development lifecycle. Where do we start?+
With the risk assessment per product, because under Article 13 it determines how you implement Annex I. The SBOM chain, vulnerability handling and the reporting process follow.
Further reading
- Implementing security by design under the CRA
- Risk assessment and threat modeling
- Technical documentation and conformity
- SBOM consulting
- Building the reporting process and PSIRT
- CRA workshop for your team
This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).
Last updated: 2026-10-09
Kontakt aufnehmen
Request a delta assessment
Tell us about your products and the state of your development process. The initial call is free and without obligation; we usually reply within one to two working days.