Cyber Resilience Act: Where the Gaps Actually Are

The Cyber Resilience Act enters into full application on 11 December 2027, but the decisive groundwork is being laid well before that date. A recent survey reported by heise online shows that many companies are still not sufficiently familiar with the requirements on reporting obligations and software bills of materials. For governance, risk and compliance functions, the question is no longer whether the CRA is relevant, but which evidence must actually be in place by the next deadlines, and who is responsible for providing it.

How far has industry actually progressed with CRA implementation?

According to a survey by cybersecurity provider ONEKEY cited by heise online, 45 percent of the companies surveyed are barely or not at all familiar with the CRA requirements.

A second finding carries more weight further down the supply chain: according to the same survey, only 18 percent of suppliers provide the necessary CRA information, even though manufacturers remain liable for supplied components as well. The real risk therefore lies less in a company’s own development department than in the chain of upstream suppliers.

Nevertheless, a third of companies state that they intend to meet all requirements by the December 2027 deadline, according to heise online. In many cases, a gap remains between this ambition and documented preparation. Similar uncertainty about the actual scope of application also shows up under other EU legislation, as the article “NIS2-Registrierungslücke: Was sie über Scope-Unsicherheit zeigt” illustrates.

Which deadlines lie between now and full application?

The Cyber Resilience Act entered into force on 10 December 2024, the reporting obligation for vulnerabilities and incidents applies from 11 September 2026, and the regulation applies in full from 11 December 2027.

The real preparation time falls between these dates. Companies that want to meet the reporting obligation from September 2026 need a working detection and escalation chain in place by that date, not a draft of one. Full compliance, including the SBOM obligation, follows just over a year later, but the processes required for it cannot be built in the final weeks before the deadline.

The German Federal Office for Information Security (BSI) accompanies this transition period with a technical guideline that specifies requirements for SBOM and reporting, but this guideline does not replace a company’s own risk assessment.

What does the reporting obligation under Article 14 CRA actually require?

Manufacturers must report actively exploited vulnerabilities and severe security incidents to the competent coordinating authority and to ENISA, with an early warning within 24 hours and a follow-up notification within 72 hours.

Both notifications go through the single reporting platform provided for under the CRA, which forwards them simultaneously to the coordinating CSIRT and to ENISA. The clock starts when the manufacturer becomes aware of the issue, not when a specialist department or an external reporter confirms it.

For a GRC function, this means the escalation paths within the 24-hour deadline must be documented in writing and rehearsed before the September 2026 deadline is reached. How strongly such a reporting chain depends on rehearsed processes rather than on technology alone is described in the article “ISMS: Menschen, Prozesse und Technologie sind entscheidend”.

Which evidence for the software bill of materials is most often still missing?

The SBOM is part of the technical documentation and must cover at least the direct software dependencies, yet many companies are missing precisely this information for supplied components.

The CRA does not mandate a single technical format; in practice, CycloneDX and SPDX have become established. What matters is less the format than currency: an SBOM created once loses relevance with every software update and should be tightly coupled to build and release processes.

The finding on suppliers applies directly here: without reliable information from the supply chain, a company’s own SBOM remains incomplete, regardless of how well internal documentation is organised. How such dependencies on third parties can be captured systematically is described in the article “Was das Third-Party Cyber Risk Management von etablierten Sicherheitsfunktionen lernen kann”.

Which first step can be scheduled concretely right now?

The next verifiable step is a complete product inventory that records, for each product, whether a machine-readable SBOM exists and which suppliers still need to provide missing information.

Security or compliance officers should have a documented escalation process for actively exploited vulnerabilities in place by the 11 September 2026 deadline, including access to the reporting platform and a named owner for the 24-hour deadline. In parallel, it is worth taking stock of which products and suppliers currently have machine-readable SBOM data at all.

Because CRA notifications are product-related while other regimes such as NIS2 report at the organisational level, it is also worth looking at the interfaces between the two obligations, as the article “Cyber Resilienz neu denken im Kontext von NIS2” sets out. Companies that begin this stock-take now still have time before the September 2026 deadline for a test run of the reporting chain.