Cyber Resilience Act Obligations
The Cyber Resilience Act is no longer a distant policy file. It is now a dated compliance programme with fixed milestones, and the first operational obligation lands before the wider regime fully applies.
The regulation, formally Regulation (EU) 2024/2847, sets cybersecurity requirements for many connected hardware and software products placed on the EU market. For manufacturers, importers and distributors, the most urgent work is not only product design. It is also the ability to detect, assess and report serious security issues quickly.
This article is for information only and is not legal advice.
The three dates that set the CRA timetable
The Cyber Resilience Act became law in stages. The reporting duties start before the full product compliance regime applies, so the timetable matters.
Date | What changes | Practical meaning |
10 December 2024 | The Cyber Resilience Act entered into force | The legal clock started. Manufacturers should treat this as the start of their preparation period. |
11 September 2026 | Reporting obligations begin | Manufacturers must be ready to report actively exploited vulnerabilities and certain serious incidents through the required process. |
11 December 2027 | Full application of the regime | The main product requirements, conformity assessment duties and market access expectations apply in full. |
The gap between 2026 and 2027 is easy to underestimate. A product may not yet need to meet every full application requirement, but teams still need evidence that they can detect, evaluate and report relevant security issues on time.
That makes the reporting date a core Cyber Resilience Act compliance milestone, not a side issue.
Which products are in scope
The Act applies to products with digital elements made available on the EU market. In plain terms, this means hardware or software that can connect, directly or indirectly, to a device or network.
Examples include:
Internet-connected cameras, routers, sensors and smart appliances
Industrial control devices with network features
Software applications sold or supplied for commercial use
Embedded software in connected hardware
Remote data processing solutions that are necessary for a product to function
The scope is broad because the regulation focuses on cyber risk across the product lifecycle. A vulnerability in a mobile app, firmware package or cloud-linked component can affect the security of the whole product.
Some categories sit outside or under sector-specific rules. These can include certain medical devices, vehicles, aviation products and products developed only for national security or defence purposes. Free and open-source software that is developed or supplied outside commercial activity is treated differently, although commercial use around open-source components can still create duties.
A useful internal test is simple. If the product is digital, connects to something, and is placed on the EU market as part of a commercial activity, it needs a CRA scope review.
Why 24-hour reporting matters
From 11 September 2026, manufacturers must report certain serious security matters. The headline duty is the 24-hour notification for actively exploited vulnerabilities.
An actively exploited vulnerability is not a theoretical weakness found in a lab. It is a security flaw that someone is using, or has used, in real conditions. For example, if attackers exploit a flaw in router firmware to gain access to customer networks, the 24-hour clock becomes critical once the manufacturer becomes aware.
The purpose is speed. Early reporting helps national authorities and the European Union Agency for Cybersecurity, known as ENISA, understand wider risk across the EU market. It also helps reduce fragmented reporting to many separate bodies.
The first report will not always contain every detail. At the 24-hour point, a manufacturer may only know the affected product, the suspected versions, the type of exploitation and any immediate containment steps. That is still valuable.
A good reporting process should answer these questions fast:
Is the issue a vulnerability, an incident, or both?
Is there evidence of active exploitation?
Which product versions and regions are affected?
What temporary mitigation can customers use?
Who approves the report before submission?
What evidence must be preserved for later updates?
This is where CRA reporting obligations, products with digital elements, vulnerability handling, SBOM requirements come together. The reporting duty cannot work if the product team cannot identify affected components or confirm exposure quickly.
What vulnerability handling should look like before 2026
Vulnerability handling is the structured process for receiving, assessing, fixing and communicating security weaknesses. Under the CRA, it becomes a product governance requirement, not just an engineering preference.
A practical process should include:
A clear intake route
Researchers, customers and partners need a way to report a suspected weakness. This can be a security contact, web form or coordinated disclosure channel.
Triage and severity assessment
The team should classify the issue, check whether it affects supported versions and decide whether exploitation is active.
Ownership across product, security and legal teams
Someone must own the technical fix. Someone must manage customer communication. Someone must decide whether legal reporting thresholds are met.
Patch and mitigation planning
Not every fix ships instantly. There may be temporary configuration changes, firewall rules or feature restrictions that reduce risk while a permanent update is prepared.
Disclosure records
Keep records of when the issue was received, when awareness was confirmed, what decisions were made and when reports were submitted. These records may become important evidence during market surveillance.
The key is rehearsal. If the first test of the process is a real exploited vulnerability in September 2026, the organisation is already late.
SBOM readiness before full application
A Software Bill of Materials, or SBOM, is an inventory of software components used in a product. It usually covers direct and indirect components, such as libraries, packages and open-source dependencies.
The CRA expects manufacturers to understand and document product cybersecurity risks. In practice, an SBOM helps answer one urgent question: “Are we affected by this newly disclosed vulnerability?”
Before 11 December 2027, manufacturers should build a repeatable SBOM process for each product line. That means:
generating an SBOM during development and release
updating it when components change
linking components to product versions
checking known vulnerability sources against the inventory
keeping records available for compliance and response work
The SBOM does not need to become a public full recipe for the product. Some information may be sensitive. Still, internal accuracy matters. A stale SBOM can create false confidence and slow down reporting.
Verify the ENISA single reporting platform
The Cyber Resilience Act provides for a single reporting platform operated by ENISA for relevant notifications. This is central to the 2026 reporting model.
Because platform delivery, access methods and submission formats can change through implementation work, manufacturers should verify the current status directly with official sources before building final procedures. Check ENISA’s Cyber Resilience Act pages, European Commission guidance and national authority notices for:
whether the platform is live
account and authentication requirements
supported report formats
links with national computer security incident response teams
test or onboarding options before the reporting date
Do not rely on informal summaries for this point. The reporting channel is part of the evidence trail, so procedures should cite official sources and record the date of verification.
The running order for readiness
The strongest preparation plan starts with scope, then builds response capability.
Map the products first. Identify which products, versions and services fall within the CRA. Then test whether each product team can answer a vulnerability question within hours, not weeks.
Next, run a simulated active exploitation case. Pick a realistic flaw in a software component, trace affected versions through the SBOM, draft the 24-hour report and review who signs it off. This will expose gaps in ownership, records and technical data.
The important date is 11 September 2026. By then, reporting needs to work in practice. The full regime follows on 11 December 2027, but the evidence of mature product security should already be forming.
To prepare with less guesswork, explore a compliance gap review focused on CRA scope, 24-hour reporting, vulnerability handling and SBOM readiness. The earlier the gaps are found, the easier they are to fix before the reporting clock starts.
