We are certified to IEC 62443-4-1. Does that make us CRA-ready?

It covers a large part of the process side of Annex I: secure development lifecycle, defence in depth, security testing, update management. What 62443 does not give you is the product-level regulatory record the CRA asks for: an SBOM bound to each shipped version, exploitation-aware triage with recorded decisions, an awareness rule that starts a 24-hour clock, staged Article 14 notifications, a support period per product and Annex VII documentation kept for ten years. Harmonised standards for the CRA are still being developed; until they are cited, 62443 evidence supports but does not presume conformity.

Our controllers are in service for twenty years. Is the support period twenty years?

The support period must reflect the time users can reasonably expect to use the product and be at least five years unless the product is expected to be in use for less. For industrial equipment that expectation is often far longer than five years, and Article 13(8) asks you to take the expected lifetime into account. You can set the period, justify it and communicate it; what you cannot do is set five years for a product everyone expects to run for two decades without a rationale. Your legal advisers decide the position; Vellaci records it with reasoning and approver.

The vulnerable component is in a supplier’s firmware blob. Is it our problem?

If the blob ships inside your product, its vulnerabilities are in your product. Annex I Part II asks you to identify and document components, including third-party ones, and to address vulnerabilities without delay. Contractually you will lean on the supplier for the fix; operationally you still own the triage, the customer communication and, if it is actively exploited, the Article 14 reporting. Put the blob in the SBOM with its version so the exposure is visible the day an advisory appears.

Our customers are NIS2 operators. Who reports what?

Both may report the same event under different regimes. The operator reports a significant incident affecting its services under NIS2; you, as the manufacturer, report an actively exploited vulnerability or severe incident affecting the product under CRA Article 14. The deadlines are similar but not identical and the recipients differ. Coordinate the wording, keep separate records, and do not assume one notification discharges the other. The CRA versus NIS2 guide sets the two side by side.

Can we keep vulnerability details confidential during coordinated disclosure with OT customers?

Yes, and the CRA expects a coordinated vulnerability disclosure policy. Reporting to the CSIRT and ENISA is separate from public disclosure; you may indicate sensitivity in the notification. Annex I Part II requires you to publicly disclose information about fixed vulnerabilities once a security update is available, which for OT customers usually means an advisory with affected versions, the fix and mitigations, timed with the patch window your customers can realistically use.

Who it is for

CRA readiness for industrial and embedded product manufacturers.

Controllers, drives, sensors, gateways, machinery with digital elements, embedded modules and the long-lived firmware inside them. What the Cyber Resilience Act adds on top of the IEC 62443 work you have probably already done, and how to run it for products that stay in service for decades.

Direct answer. Industrial and embedded products with software and a data connection are products with digital elements, and the company that places them on the EU market under its own name is generally the manufacturer under Regulation (EU) 2024/2847. Since 11 September 2026 every manufacturer must report actively exploited vulnerabilities and severe incidents within 24 and 72 hours of awareness; from 11 December 2027 the essential requirements, conformity assessment and CE marking apply, with several industrial and security-hardware categories classified as important or critical products.

Most industrial manufacturers arrive with more security process than a typical software company: a 62443 programme, a PSIRT, an obsolescence policy. What is usually missing is the product-level record the regulation is built around, and the arithmetic of very long service lives against a support period you have to declare and defend. Start with whether each product line is in scope, then take the free readiness assessment to see which of the gaps below apply to you.

Existing work

How much of our IEC 62443 programme counts?

A lot of it, on the process side. Annex I Part I (product properties) and the secure-development expectations behind it overlap heavily with 62443-4-1 and the component requirements of 62443-4-2. The gap is not in how you build; it is in what you can show, per product and per version, and in the reporting machinery.

Area	What a 62443 programme usually has	What the CRA additionally needs	In Vellaci
Secure development lifecycle	IEC 62443-4-1 practices: threat modelling, secure coding, testing, defect management	Evidence linked to the specific product and version an authority asks about	Evidence vault tied to products, requirements and versions; readiness framework with weighted requirements
Component inventory	Bill of materials for hardware; sometimes a build manifest	A software BOM per firmware version covering RTOS, BSP, libraries and third-party blobs	CycloneDX / SPDX ingestion per version; deduplicated component catalogue; immutable historical SBOMs
Vulnerability handling	PSIRT process, advisories, customer notifications	Continuous matching of the inventory against advisories and exploitation signals; recorded decisions	Matching against OSV, GitHub advisories, CISA KEV and EPSS; triage with mandatory reasons; VEX statements
Regulatory reporting	Customer and sector notification habits	Awareness rule, 24 h / 72 h clocks, staged content, submission record	CRA Reporting Command Center with server-side deadlines, prefilled forms, alerts, recorded ENISA SRP submissions
Support period	Product lifecycle policy; obsolescence management	A published, justified security-support period per product with end-of-support communication	Support period per product with rationale, approver and end-of-support alerts
Technical documentation	Design files, test reports, certificates	Annex VII structure kept current for ten years or the support period	Documentation workspace with version history and evidence links; hash-chained audit log

Harmonised standards under the CRA are still being developed and will be cited in the Official Journal when adopted. Until then, 62443 evidence is strong supporting material for the technical documentation but does not create a presumption of conformity on its own. Keep it, link it to the products it covers, and treat the product-level records as the work to do now.

Classification

Which of our products are important or critical?

Annex III and Annex IV list several categories that appear in industrial and embedded portfolios. The listing applies where the function is the product’s core functionality; a PLC that happens to contain a secure element is not a secure element. Classification changes the conformity route from 11 December 2027, not the reporting or vulnerability-handling duties.

Important products (Annex III)

Microprocessors and microcontrollers with security-related functionalities (Class I)
ASICs and FPGAs with security-related functionalities (Class I)
Tamper-resistant microprocessors and tamper-resistant microcontrollers (Class II, third-party conformity assessment)
Industrial firewalls, intrusion detection and network equipment sold as products: see the network and security products page

Critical products (Annex IV)

Hardware devices with security boxes
Smart meter gateways and other devices for advanced security purposes, including secure cryptoprocessing

Critical products may become subject to mandatory European cybersecurity certification by delegated act. Nothing on this page asserts that such an act has been adopted for a category; check the category pages and the Official Journal.

Most industrial products, from drives and I/O modules to HMIs and machine controllers, are default products: full Annex I obligations, self-assessment under Module A, no notified body. Record the reasoning either way. Vellaci's onboarding walks through the Annex III and IV functions, stores the classification with rationale and approver, and versions the rule set that produced it.

Reporting

What must be in place now that Article 14 reporting is in force?

Article 14 has applied since 11 September 2026 to every manufacturer, including for products placed on the market years ago. For industrial manufacturers the hard parts are awareness across a large installed base and the mismatch between a 24-hour clock and OT patch windows measured in months.

Awareness is an organisational rule, not a feeling

An advisory for a third-party RTOS, a customer SOC reporting exploitation on a plant network, a CISA KEV entry naming your product family: decide which of these makes the organisation aware, who confirms it and where the timestamp is written. The early warning is due 24 hours later, whether or not the fix exists.

Reporting is separate from patching

The 72-hour notification asks for an initial assessment and the corrective or mitigating measures taken or available to users. For OT products that is often a mitigation (network isolation, configuration change) long before a firmware update reaches a plant. Reporting on time with a mitigation is expected; waiting for the patch is not.

The final report has two triggers

Actively exploited vulnerability: no later than 14 days after a corrective or mitigating measure is available. Severe incident, such as a compromised build or update infrastructure: within one month after the 72-hour notification. Long OT patch cycles do not extend either; they make the mitigation wording in the earlier notifications more important.

Coordinate with operators, do not merge

Your customers under NIS2 have their own incident obligations. Agree in your coordinated vulnerability disclosure policy how you will inform them, when the public advisory follows, and who says what to which authority. Keep the records apart so each notification can be evidenced on its own.

The CRA Reporting Command Center runs those clocks from the confirmed awareness time, stages the three notifications with the facts you already recorded, and keeps a drill mode so the team can rehearse a 24-hour early warning without touching live metrics. Submission itself is done by your representative on the ENISA single reporting platform; Vellaci records it with time, reference and receipt.

Support period

How do we handle products that outlive any reasonable support period?

Article 13(8) requires a support period that reflects expected use and lasts at least five years unless the product is expected to be used for less. Industrial products routinely run for fifteen to thirty years. The regulation does not resolve that tension for you; it requires you to decide, justify, publish and then actually deliver security updates for the period you declare.

Declare per product line, with reasons

Component supply commitments, the base OS or RTOS vendor’s support, the realistic upgrade path for the installed base. Record the rationale and the approver on the product; an authority can ask why the period is what it is.

Plan supplier cliffs

Your period cannot silently outrun the security support of the SoC SDK, the wireless module firmware or the embedded Linux distribution. Keep those in the SBOM as components with versions, and reassess the period when a supplier announces end of support.

Communicate end of support early

The end date must be communicated to users. For OT customers that means enough notice to plan a migration in a maintenance window, a final security update, and clarity about what the product still does afterwards. Keep the published statements as evidence.

Operations

How does this map to Vellaci workflows?

The regulation is easier to run than to describe once each obligation is a record with an owner. This is the shape of the operation for an embedded product line.

Embedded SBOMs without a package manager

Yocto, Buildroot, Zephyr and most silicon-vendor SDKs can emit CycloneDX or SPDX for the image they build; binary-analysis tools reconstruct the rest for vendor blobs and pre-built libraries. Push the document to the exact firmware version from CI with the SBOM ingestion API or CLI. Components are deduplicated across the portfolio, so one advisory for a shared RTOS shows every affected product and version in one view, and the historical SBOM of a version shipped in 2019 remains what it was.

From advisory to auditable decision

New matches are enriched with CISA KEV and EPSS and queued for triage. A reviewer records a state with a mandatory reason, a VEX statement where the code path is not reachable, a remediation owner and the CRA reportability review. Rejecting reportability is a recorded decision too. The product registry holds the classification, support period and coordinated disclosure policy, and the hash-chained audit log shows who changed which decision and when.

Vellaci does not certify conformity, is not a notified body and does not make legal determinations. It gives an industrial manufacturer one system in which products, firmware versions, components, vulnerabilities, incidents, reporting cases and evidence are connected, so that the question “which shipped products contain this component and what did we decide” has an answer with names and timestamps.

Last reviewed 13 September 2026 · Operational guidance, not legal advice.

FAQ

Industrial and embedded questions, answered plainly.

We are certified to IEC 62443-4-1. Does that make us CRA-ready?: It covers a large part of the process side of Annex I: secure development lifecycle, defence in depth, security testing, update management. What 62443 does not give you is the product-level regulatory record the CRA asks for: an SBOM bound to each shipped version, exploitation-aware triage with recorded decisions, an awareness rule that starts a 24-hour clock, staged Article 14 notifications, a support period per product and Annex VII documentation kept for ten years. Harmonised standards for the CRA are still being developed; until they are cited, 62443 evidence supports but does not presume conformity.
Our controllers are in service for twenty years. Is the support period twenty years?: The support period must reflect the time users can reasonably expect to use the product and be at least five years unless the product is expected to be in use for less. For industrial equipment that expectation is often far longer than five years, and Article 13(8) asks you to take the expected lifetime into account. You can set the period, justify it and communicate it; what you cannot do is set five years for a product everyone expects to run for two decades without a rationale. Your legal advisers decide the position; Vellaci records it with reasoning and approver.
The vulnerable component is in a supplier’s firmware blob. Is it our problem?: If the blob ships inside your product, its vulnerabilities are in your product. Annex I Part II asks you to identify and document components, including third-party ones, and to address vulnerabilities without delay. Contractually you will lean on the supplier for the fix; operationally you still own the triage, the customer communication and, if it is actively exploited, the Article 14 reporting. Put the blob in the SBOM with its version so the exposure is visible the day an advisory appears.
Our customers are NIS2 operators. Who reports what?: Both may report the same event under different regimes. The operator reports a significant incident affecting its services under NIS2; you, as the manufacturer, report an actively exploited vulnerability or severe incident affecting the product under CRA Article 14. The deadlines are similar but not identical and the recipients differ. Coordinate the wording, keep separate records, and do not assume one notification discharges the other. The CRA versus NIS2 guide sets the two side by side.
Can we keep vulnerability details confidential during coordinated disclosure with OT customers?: Yes, and the CRA expects a coordinated vulnerability disclosure policy. Reporting to the CSIRT and ENISA is separate from public disclosure; you may indicate sensitivity in the notification. Annex I Part II requires you to publicly disclose information about fixed vulnerabilities once a security update is available, which for OT customers usually means an advisory with affected versions, the fix and mitigations, timed with the patch window your customers can realistically use.

Guide
The CRA support period: how long, how to decide and what to publish
Article 13(8) requires a support period of at least five years unless the product is used for less, during which vulnerabilities are handled and security updates provided. How to determine it, document the rationale, publish it and manage end of support.
Guide
CRA technical documentation: what Annex VII requires and how to keep it current
The contents of the technical documentation under Article 31 and Annex VII — product description, design and vulnerability-handling processes, risk assessment, support period, standards, test reports, declaration and SBOM — with a structure you can maintain per product for ten years.
Guide
CRA vs NIS2: products versus organisations, and how the reporting duties fit together
The Cyber Resilience Act regulates products with digital elements; NIS2 regulates essential and important entities. Many manufacturers face both. How scope, obligations and the 24-hour / 72-hour / one-month reporting steps compare, and how to run one runbook for both.

See what your 62443 programme does not yet cover.

The free assessment maps your current set-up to the CRA’s product-level records and reporting duties in about eight minutes.

Get my CRA gap map Book a CRA readiness review