CRA · Regulation (EU) 2024/2847
Cyber Resilience Act compliance: what manufacturers must do, from reporting to CE marking
Since 11 September 2026, manufacturers must report actively exploited vulnerabilities and severe incidents, including for products already on the market. Products placed on the EU market from 11 December 2027 must meet the CRA's essential requirements. We set up your reporting path, SBOM, vulnerability handling and route to CE marking.
// In short
Who the Cyber Resilience Act applies to
The Cyber Resilience Act, Regulation (EU) 2024/2847, applies to manufacturers, importers and distributors of products with digital elements that connect, directly or indirectly, to a device or network: hardware with software and software sold on its own in the EU. The manufacturer is responsible for the product's security throughout its support period, reports vulnerabilities and incidents, and completes a conformity assessment before affixing the CE mark. We prepare manufacturers for that assessment; we are not a notified body.
As of 24 September 2026. Source: Regulation (EU) 2024/2847.
// Deadlines
Two dates have passed, the third sets your plan
CRA
Rules on notified bodies
Chapter IV (Articles 35-51): notification of the bodies that will assess important and critical products.
CRA
Reporting of vulnerabilities and severe incidents
Article 14 also covers products placed on the market before 11 December 2027 (Article 69(3)). Reports go through ENISA's platform.
ENISA (opens in a new tab)CRA
The CRA applies in full
Essential requirements in Annex I, conformity assessment, EU declaration of conformity and CE marking for products placed on the market.
Regulation 2024/2847 (opens in a new tab)
As of . Sources: Regulation (EU) 2024/2847 (Articles 14, 69 and 71), ENISA, European Commission.
// What we do
From product classification to the declaration of conformity
We work with your product, engineering and support teams, because the CRA touches all three. The paperwork comes out of your build pipeline and your vulnerability intake, not next to them.
01Classification
Whether and how the CRA covers your product
Default product, important class I or II, or critical. The class decides whether internal control is enough or a notified body has to be involved.
02Reporting (Art. 14)
A reporting path rehearsed before the real thing
Who spots an actively exploited vulnerability, who decides, and which data goes into the 24-hour early warning, the 72-hour notification and the final report.
03SBOM
An SBOM generated with every build
Machine-readable, covering at least the top-level dependencies (Annex I, Part II, point 1), and tied to the version your customers actually run.
04Vulnerability handling
From a researcher's report to a fix in the field
Coordinated vulnerability disclosure policy, a contact address for reports, triage, fix, secure distribution of updates and notice to users. An owner and a deadline at every stage.
05Risk and requirements
Risk assessment and gaps against Annex I
A documented cybersecurity risk assessment for the product (Article 13) and a gap list against the essential requirements. For industrial products we also structure development along IEC 62443-4-1.
06Conformity assessment
Technical documentation and the route to CE
Choice of conformity assessment procedure, technical documentation and a draft EU declaration of conformity. We are not a notified body: we prepare you for the assessment, we don't carry it out. Some important products and all critical ones go through a notified body or a European cybersecurity certification scheme (Article 32).
First step: one product line in 5 weeks
Product classification
Whether the product is in scope, which category it falls into and which conformity assessment procedure follows from that.
Reporting path, rehearsed on one scenario
A tabletop run of an actively exploited vulnerability: who detects it, who decides, and what goes into the early warning within 24 hours.
SBOM from the build
An SBOM for one product line, generated in your CI pipeline and attached to the released version.
Gap list against Annex I
Gaps in the requirements and in vulnerability handling, each with a priority, an owner and a date before 11 December 2027.
The result: one product line classified, with a rehearsed reporting path and an SBOM
Fixed scope and date, agreed in writing before we start. Request the first step
// Scope
What we do and what we don't
We do
- Product classification and choice of the conformity assessment procedure
- A reporting path for vulnerabilities and incidents, including a rehearsal
- SBOM generation in CI and a vulnerability handling process
- Cybersecurity risk assessment and a gap analysis against Annex I
- Security testing of the product's applications and interfaces
We don't
- Conformity assessment as a notified body: we are not one
- CE marking: the manufacturer signs the EU declaration of conformity
- Reports to the CSIRT and ENISA on the manufacturer's behalf
- Guarantees of CRA compliance
We test product software against OWASP standards, as described on our OWASP application testing page.
// Read more
Related topics and services
More on software and process security on our blog:
// FAQ
Questions about the Cyber Resilience Act
Does the CRA apply to products we already sell?
For reporting, yes: since 11 September 2026 the Article 14 obligations also cover products placed on the market earlier (Article 69(3)). The other requirements apply to products placed on the market from 11 December 2027, and to older ones only if they undergo a substantial modification after that date (Article 69(2)). As of 24 September 2026.
What must be reported, and how fast?
An actively exploited vulnerability: early warning within 24 hours, notification within 72 hours and a final report no later than 14 days after a fix or mitigation is available. A severe incident affecting the product's security: 24 hours, 72 hours and a final report within one month of the notification. Reports go to the CSIRT designated as coordinator and to ENISA at the same time.
What are the CRA's SBOM requirements?
An SBOM in a commonly used, machine-readable format that covers at least the product's top-level dependencies. The Commission may specify the format and elements in an implementing act. The simplest approach is to generate the SBOM with every build and store it with the released version.
Do we need a notified body?
For most products, no: a default product can use internal control (module A), which the manufacturer carries out itself. Important class I products can only use it when they fully apply harmonized standards, common specifications or a European certification scheme. Class II and critical products need a notified body (modules B and C, or H) or European cybersecurity certification (Article 32). We are not a notified body: we prepare the technical documentation and evidence for the assessment. As of 24 September 2026.
How long do we have to support a product?
For the support period the manufacturer sets, based on how long the product is expected to be in use. As a rule it is at least five years, unless the expected use time is shorter (Article 13(8)). During that time the manufacturer handles vulnerabilities as set out in Annex I, Part II.
What are the penalties?
Breaches of the essential requirements and of Articles 13 and 14 can cost up to EUR 15 million or up to 2.5% of total worldwide annual turnover, whichever is higher (Article 64(2)). Member States set the detailed penalty rules.
Let's start with one product line
Tell us which product you sell in the EU. We reply within one business day, with questions about the architecture, the build pipeline and how you handle reports today.
Request the first stepPrefer to talk first?
30 minutes on whether and how the CRA covers your product, no sales pitch.
Book a 30-minute call (opens in a new tab)