TL;DR: The EU Cyber Resilience Act shifts compliance from proving past controls to reporting actively exploited vulnerabilities within 24 hours, forcing companies selling digital products into the EU to tighten vulnerability identification, SBOM visibility, ownership, and remediation processes, according to Seemplicity. Manual coordination and fragmented toolchains now create compliance risk as much as technical exposure.
NHIMG editorial — based on content published by Seemplicity: The CRA Deadline You Can’t Ignore: What Every Company Needs to Fix Before September 2026
By the numbers:
- The CRA introduces a 24-hour reporting requirement for actively exploited vulnerabilities from September 11, 2026.
- Manufacturers, importers, and distributors face 72-hour fuller notifications and 14-day final reports for actively exploited vulnerabilities.
- Non-compliance can result in fines up to the greater of €15 million or 2.5% of global annual turnover.
Questions worth separating out
Q: What breaks when CRA reporting depends on manual coordination?
A: Manual coordination breaks the CRA model because the regulation compresses discovery, escalation, and notification into a 24-hour window.
Q: Why do SBOM gaps create compliance risk under the CRA?
A: SBOM gaps create compliance risk because you cannot report an actively exploited vulnerability confidently if you cannot identify which component, build, or shipped product contains it.
Q: How do security teams know whether CRA response is actually working?
A: They know it is working when they can identify an affected product, name an accountable owner, draft the notification, and prove corrective action inside a realistic tabletop window.
Practitioner guidance
- Map every in-scope product and distribution path Identify every product, service, importer, distributor, and EU market route that could trigger CRA obligations.
- Define reporting authority in writing Assign a named owner who can declare an actively exploited vulnerability, start the 24-hour clock, and coordinate ENISA and CSIRT notification without waiting for informal approval chains.
- Validate SBOM accuracy against shipped builds Trace one known vulnerable component from source repository to build artefact to customer-deployed product.
What's in the full article
Seemplicity's full blog covers the operational detail this post intentionally leaves for the source:
- The article expands on the 24-hour, 72-hour, and 14-day reporting sequence and how each window changes response sequencing.
- It breaks down the CRA product classification timeline, including where different product types face earlier or later obligations.
- It outlines a 90-day readiness checklist that links exposure mapping, SBOM validation, and supplier contract updates.
- It explains how Seemplicity positions its workflow around exposure management and autonomous response across identity, cloud, and IT ecosystems.
👉 Read Seemplicity's analysis of the EU Cyber Resilience Act reporting deadline →
EU Cyber Resilience Act reporting: are your response controls ready?
Explore further
CRA readiness is a governance problem before it is a compliance problem. The article is right to focus on speed, but the real issue is whether an organisation can make a reporting decision under pressure without waiting for manual coordination. That requires explicit authority, tested escalation, and product-level ownership. In practice, the companies most likely to miss the CRA clock are those that still treat vulnerability response as a ticket queue.
A question worth separating out:
Q: Who is accountable when a vulnerable product misses the CRA deadline?
A: Accountability sits with the organisation that sells, imports, or distributes the in-scope digital product into the EU, but internal ownership must be assigned before an incident occurs. Without named reporting authority and evidence ownership, compliance becomes everybody’s job and therefore nobody’s job.
👉 Read our full editorial: EU Cyber Resilience Act reporting turns vulnerability response into a 24-hour test