The CRA Timeline: What Applies from September 2026
The Cyber Resilience Act has been in force since 10 December 2024, but its obligations take effect in stages. Most requirements - secure development, conformity assessment, CE marking - apply only from 11 December 2027 (European Commission). The reporting obligation, however, is brought forward: the provisions of Article 14 apply from 11 September 2026, and the rules on notifying conformity assessment bodies under Chapter IV from 11 June 2026 (European Commission). For manufacturers this means the duty to report vulnerabilities and incidents arrives more than a year before the main date of full application.
Affected are manufacturers of products with digital elements - which covers software, connected hardware and their remote data processing solutions very broadly. According to Germany's Federal Office for Information Security, the staggered reporting deadlines apply to all products with digital elements on the EU market, including legacy products already placed on the market (BSI). This is an important distinction too: it is not only about new developments but about the entire supported installed base.
| Deadline from awareness | What must be reported | Recipient |
|---|---|---|
| 24 hours | Early warning: affected product, affected member states, initial assessment of active exploitation | Relevant CSIRT and ENISA (European Commission) |
| 72 hours | Full notification: type of vulnerability, impact on the product, corrective measures taken and planned | Relevant CSIRT and ENISA (European Commission) |
| 14 days | Final report for an actively exploited vulnerability, once a corrective measure is available | Single Reporting Platform (European Commission) |
| 1 month | Final report for a severe security incident | Single Reporting Platform (European Commission) |
Reporting will run centrally through a single Single Reporting Platform (SRP), operated by the EU cybersecurity agency ENISA and intended to be operational by 11 September 2026 (European Commission). Manufacturers report there once; the platform forwards to the relevant national CSIRT - in Germany the BSI. This lowers the bureaucratic hurdle but changes nothing about the actual difficulty: the clock starts with awareness, and anyone who notices an exploitation late has already used up part of their 24 hours.
Actively Exploited Vulnerability and Severe Incident - the Trigger
Not every discovered vulnerability starts the 24-hour clock. The CRA ties the early-warning duty to two types of event: an actively exploited vulnerability and a severe security incident affecting the security of the product with digital elements (European Commission). The crucial word is actively exploited: it concerns vulnerabilities for which there are signs of actual exploitation - not every theoretically conceivable gap. This very distinction makes the early warning so demanding, because the manufacturer must recognise that something is being exploited, not merely that it could be.
The 24-hour deadline begins as soon as the manufacturer becomes aware of the active exploitation or the incident. In practice that is often the most dangerous point: anyone without continuous observation of their own attack surface frequently learns of an exploitation only through third parties - and the clock has long been ticking by then. Whoever sees a new, unknown certificate for their own domain or a changed third-party script early gains exactly the hours that are missing later.
On top of this comes a substantial threat of sanctions: infringements of the CRA's core obligations can be penalised with fines of up to 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher (European Commission, Art. 64 CRA). Lower tiers provide for up to 10 million euros or 2 percent and up to 5 million euros or 1 percent (European Commission). Beyond fines, market surveillance authorities can also order recalls or the withdrawal of a product from the market - a consequence that for many manufacturers weighs more heavily than any fine.
CRA Reporting Is Not security.txt - but They Belong Together
A common confusion: the CRA reporting obligation and a security.txt file sound related but concern two different directions. The security.txt is a standardised procedure (RFC 9116) by which a manufacturer tells security researchers where to report a discovered vulnerability - so it governs the inbound flow of reports. The CRA reporting obligation governs the outbound flow: the manufacturer's notification to the authorities once a vulnerability is being actively exploited.
The two interlock, because the CRA in Article 13 requires a coordinated vulnerability disclosure policy and a single point of contact for vulnerability reports anyway (European Commission, Art. 13 CRA). A reachable, correctly deposited security.txt is the technical means of locating this contact point - which is exactly why its reachability should be monitored. What a clean disclosure setup looks like and how it is checked continuously is explored in the article on monitoring security.txt and vulnerability disclosure.
Inbound channel: tells finders the contact point. A missing or unreachable file delays external reports - the very ones that could trigger an early warning.
Outbound duty: 24-h early warning, 72-h full notification, 14-day final report to CSIRT and ENISA once a vulnerability is being actively exploited.
Organisational framework: documented processes to receive and remediate reported vulnerabilities, plus a single point of contact.
Inventory of software components, at least the top-level dependencies - the basis for knowing which own or third-party component a reported gap affects.
Why the 24-Hour Deadline Is Hard to Meet Without Monitoring
A 24-hour deadline from awareness is organisationally hard - but the real problem is awareness itself. A manufacturer can only report what it notices. If it notices the exploitation only when customers complain or a security researcher goes public, a significant share of the response time has already elapsed. The industry's response speed is sobering here: the mean time to detect an attack was recently 181 days, and the average overall duration of a data breach from detection to containment 241 days (IBM Cost of a Data Breach Report 2025). Anyone working with such timescales structurally cannot meet a 24-hour deadline.
At the same time the pace of exploitation is rising. In the Verizon Data Breach Investigations Report 2025, the share of breaches in which exploitation of vulnerabilities was the initial access vector grew by 34 percent year over year and accounted for around 20 percent of all analysed incidents (Verizon DBIR 2025). The number of known, actively exploited vulnerabilities keeps growing: the KEV catalogue of the US agency CISA now lists over 1,300 entries (CISA Known Exploited Vulnerabilities Catalog). Every new entry affecting a component used in your own product can start the CRA clock.
It is also notable that the reporting obligation is not tied to your own code. A significant share of modern products consists of open-source and third-party components, and that is exactly where many actively exploited vulnerabilities arise. If such a component is attacked, it can start the CRA clock even though the code comes from an external source. Anyone who maintains an up-to-date component inventory and continuously reconciles it against public catalogues recognises faster whether a reported gap affects their own product - and can approach the tight deadline with solid information rather than guesswork. The same inventory later also underpins the software-component evidence required under Annex VII.
The 24-hour deadline begins with awareness. Continuous monitoring shortens the time to awareness - and that is precisely the lever. Whoever is notified within minutes of a new phishing certificate for their brand, a quietly altered third-party script or a dropped security header has the maximum span to verify, contain and report in time - instead of having eaten into the deadline at the very start.
Related reporting obligations add to the pressure: the NIS2 Directive has a very similar 24-hour early warning for essential and important entities. How these obligations specifically affect website and service providers is described in the article on NIS2 reporting obligations for website operators. For many organisations CRA and NIS2 overlap - and both require that incidents are detected quickly in the first place.
What XICTRAQ Monitors Continuously
XICTRAQ renders the registered websites and endpoints in a real browser, checks them regularly from multiple locations and compares the current state with an approved baseline. If something security-relevant changes, a signal arises - and with it the awareness that makes the CRA clock meaningfully startable in the first place. The following building blocks pay directly into early-warning capability.
New certificates for your own brand or lookalike domains from the public CT logs are checked against brand and typo patterns - an early warning for phishing and domain abuse. Details in the article on Certificate Transparency monitoring.
The SHA-256 fingerprint of embedded third-party scripts is monitored. If a script changes unnoticed - the classic Magecart pattern - drift detection fires. More in the article on monitoring Subresource Integrity.
Dropped HSTS, CSP or X-Content-Type-Options headers and weak TLS configurations are detected - often the first visible sign of a misconfiguration after a deploy.
Whether the file foreseen in RFC 9116 remains reachable at the expected location is checked continuously - so that the contact point required by Article 13 does not silently disappear.
On top of this comes the CRA component cockpit: it tracks the components used in the product along with their version status and heuristically warns of outdated building blocks as well as of approaching CRA deadlines. If a deployed library is listed in a public catalogue of actively exploited vulnerabilities, that is exactly the signal that triggers a check and, where appropriate, an early warning. This turns the abstract obligation into a concrete, traceable workflow.
- Real rendering - pages and scripts are loaded in a real browser, not just fetched as HTML, so that dynamically loaded changes become visible
- Baseline diff - the current state is compared against the last approved state, so only genuine deviations raise an alert
- Multiple locations - checks run from several nodes to avoid local distortions
- Central inventory - certificates, scripts and components are inventoried, so a reported gap can be quickly mapped to your own attack surface
The Alerting Workflow as Deadline Insurance
A signal is only useful if it reaches the right people in time. That is why the alerting workflow is the heart of CRA preparation. If XICTRAQ detects a security-relevant deviation, it triggers a notification across multiple channels - via email, Slack, Discord or Telegram. That way the internal check begins in minutes, not days, and the 24-hour deadline starts with the largest possible buffer.
What matters is escalation: if an alert remains unacknowledged, the next responsible person is notified. Precisely with a 24-hour deadline that may also run on a Friday evening or during a holiday, an escalation chain prevents a critical signal from being left lying around. The dedupe logic groups similar messages so that one real incident does not become hundreds of individual alerts that dull the team.
When you deliberately renew a certificate, update a third-party script as planned, or adjust headers, the target state changes. Re-approve the new baseline after each planned release - then the monitoring only alerts on genuine, unintended deviations rather than on every planned change. That keeps the signal-to-noise ratio high and the team reacting to what counts.
How much time is left in the end is a question of error budget and reaction thresholds. Anyone who aligns their alerting to clear thresholds, instead of reacting to every bit of noise, keeps the team able to act. The same principle from the SLO world - alert early but not excessively - is described in the article on error budget and burn-rate alerts. For the CRA deadline it means: better one verifiable signal in minutes than a flood that no one takes seriously any more.
Be Prepared by September 2026
The CRA reporting obligation is no reason for panic but a clear occasion to review your own detection capability. The deadline of 11 September 2026 is fixed, and the 24-hour deadline forgives no blind spots. Three steps help you be prepared: first, set up a documented, coordinated disclosure process including a reachable security.txt; second, continuously monitor your own attack surface - certificates, embedded scripts, security headers, deployed components; third, establish an escalating alerting workflow that reliably brings a signal to a human.
The common denominator of these three steps is time. Every hour that passes between exploitation and awareness is an hour missing for verification, containment and reporting. Continuous monitoring cannot prevent a vulnerability - but it brings the moment of awareness forward and makes the tight CRA deadlines technically reachable in the first place. That is exactly where the practical value of a monitoring and alerting setup lies: it turns an invisible process into a visible, reportable signal. And it incidentally provides documented evidence that deviations were detected and handled - a paper trail that, in the event of an authority inquiry, is typically as valuable as the timely report itself.
This article is based on data and documents from: European Commission - 'Cyber Resilience Act: Reporting obligations' and 'Cyber Resilience Act' (digital-strategy.ec.europa.eu, deadlines 24 h / 72 h / 14 days, Single Reporting Platform, start of application of Art. 14 on 11 Sep 2026 and full application on 11 Dec 2027, sanction framework Art. 64), CRA regulation text Art. 13 and Art. 14 (coordinated disclosure, reporting obligations), Annex VII (SBOM), Germany's Federal Office for Information Security (BSI, Cyber Resilience Act, framing of the staggered reporting deadlines and legacy products), IBM Cost of a Data Breach Report 2025 (mean time to detect and contain), Verizon Data Breach Investigations Report 2025 (share of exploit-based initial access), CISA Known Exploited Vulnerabilities Catalog (scope of actively exploited vulnerabilities), RFC 9116 (security.txt). Legal assessments are not legal advice.