The CRA's 24-Hour Clock Starts on 11 September 2026: Make Sure Someone Answers

From 11 September 2026 the EU Cyber Resilience Act gives manufacturers 24 hours to file an early warning — in a browser, with no reporting API. Here is how to turn that trigger into a phone call with Echobell, and what a louder alert still cannot fix.

Table of Contents

On 11 September 2026, the reporting obligations of the EU Cyber Resilience Act start applying. From that date, a manufacturer that becomes aware of an actively exploited vulnerability in a product with digital elements — or of a severe incident affecting one — has 24 hours to send an early warning to its coordinating CSIRT and to ENISA (European Commission, Regulation (EU) 2024/2847).

That deadline has a property most compliance deadlines do not: it runs on wall-clock hours. There is no business-day carve-out, no weekend pause, and no grace period while your reporting owner is on a flight. And the platform you file through, ENISA's Single Reporting Platform, is a web form — "no Application Programming Interfaces will be provided at this stage" (ENISA FAQ). A named human has to log in and submit.

That makes the 24-hour rule an alerting problem before it is a paperwork problem. This guide shows how to route the moment of awareness into a ringing phone using Echobell, and is honest about the large part of CRA readiness that no notification tool touches.

What exactly starts on 11 September 2026?

Manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through one EU platform, on a staged clock that begins the moment they become aware. Everything else in the CRA — CE marking, the essential requirements in Annex I, conformity assessment — applies from 11 December 2027. Reporting arrives fifteen months earlier, and it applies to products already on the market, not only to what you ship after the date (cyberresilienceact.eu).

Article 14 defines two parallel tracks with the same shape:

StageActively exploited vulnerability — Art. 14(2)Severe incident — Art. 14(4)
Early warningWithin 24 hours of becoming awareWithin 24 hours of becoming aware
NotificationWithin 72 hours of becoming awareWithin 72 hours of becoming aware
Final reportNo later than 14 days after a corrective or mitigating measure is availableWithin one month after the 72-hour notification

The wording is "without undue delay and in any event within 24 hours of the manufacturer becoming aware of it" (Article 14). Twenty-four hours is the ceiling, not the target.

Article 14(5) sets the bar for "severe": an incident qualifies where it negatively affects, or is capable of negatively affecting, the product's ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or where it has led or is capable of leading to the introduction or execution of malicious code. "Capable of" matters — you can owe a report before anything has actually gone wrong for a customer.

Article 14(8) adds a second obligation that runs in parallel: you must also inform the impacted users of the product about the vulnerability or incident, and where necessary about corrective measures they can take. That is a separate audience from the CSIRT, on its own path.

Who is actually on the hook?

Manufacturers of products with digital elements, wherever they are established, plus open-source software stewards in a narrower way. A company outside the EU that sells into the Union does not escape the duty; the regulation expects an economic operator in the EU to be responsible for the relevant obligations (cyberresilienceact.eu).

You report to the CSIRT designated as coordinator in the Member State where you have your main establishment in the Union, and to ENISA simultaneously — but you submit once, through the Single Reporting Platform, which routes it to both (European Commission).

Open-source software stewards are in scope for a defined subset: the Article 14(1) obligation applies to the extent they are involved in developing products with digital elements, and Article 14(3) and (8) apply to the extent that severe incidents affect the network and information systems they provide for that development. If you steward a widely used project, read Article 24 alongside Article 14 rather than assuming either extreme.

Article 15 also allows voluntary reporting — of vulnerabilities, cyber threats, incidents, and near misses — by manufacturers and by anyone else. Voluntary reports do not create new obligations, but the same platform, and the same "somebody has to be awake" problem, applies.

Why is a 24-hour deadline an alerting problem?

Because the clock starts when you become aware, and awareness rarely arrives during office hours. The trigger is a fact reaching your organisation, not a decision your organisation makes.

Look at where that fact typically comes from. A security researcher emails security@ at 23:40 on a Saturday. A downstream customer opens a support ticket describing exploitation. A CVE or KEV feed lights up on a component you ship. Your own EDR flags execution in a build system. DLA Piper's readiness note points out the supply-chain version of this specifically: manufacturers are often not the first to know, and information arrives through importers, distributors, researchers or component suppliers (DLA Piper).

Every one of those paths ends in a notification that your current setup probably delivers silently — an email in a shared inbox, a Slack message in a channel nobody watches overnight, a ticket in a queue that gets triaged on Monday. None of them fail. They deliver correctly, to nobody.

Three details make the gap worse than it looks:

  • There is no API. ENISA states plainly that no reporting APIs will be provided at this stage. You cannot have a script file the early warning for you while everyone sleeps.
  • Access is a per-person setup, done in advance. Authorised representatives register with an EU Login account, and the designated CSIRT coordinator validates their authority after first access. There is a primary representative and a secondary backup, and the invitation to the backup expires after seven days (ENISA FAQ, cyberresilienceact.eu). If the one person who can file is unreachable, the deadline does not care.
  • The penalty tier is the high one. Article 64 puts non-compliance with the Article 13 and 14 obligations in the band of administrative fines "up to EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 % of the its total worldwide annual turnover for the preceding financial year, whichever is higher" (Article 64).

One honest qualification on that last point, because it changes the calculus for small teams: Article 64 excludes manufacturers that qualify as microenterprises or small enterprises from administrative fines for failing to meet the deadline in Article 14(2)(a) or 14(4)(a) — that is, the 24-hour early warning specifically. The duty to report still stands, and the exemption does not extend to the 72-hour notification or the rest of Article 14. Read the article, and take advice, rather than taking a blog post's word for where your company falls.

What does the 24-hour early warning actually contain?

Very little — which is the point. ENISA's guidance describes a small mandatory field set at the early-warning stage: notification type (vulnerability or incident), notification level, reporting time, reporter information, manufacturer or steward name, the product, a title, and for incidents whether unlawful or malicious acts are suspected. Optional fields at that stage include a CVE ID or EUVD ID.

The fuller technical picture — the general nature of the vulnerability or exploit, an initial assessment, corrective and mitigating measures — belongs to the 72-hour notification, not the first 24 hours.

So the early warning is not a research project. It is a short form that a prepared person can file in minutes. The binding constraint is not the form. It is whether a person who is registered, authorised, and awake finds out in time. That is a notification-routing problem, and it is solvable today.

How do I put a ringing phone in front of the 24-hour clock?

Echobell turns a webhook call or an email into an alert that rings and vibrates like an incoming call, which is how it gets through iOS Focus Mode and Do Not Disturb (see bypassing iOS Focus Mode). The setup below sits alongside whatever ticketing and PSIRT process you already run — it does not replace them.

Step 1 — Create a Calling channel reserved for CRA candidates

In the app, create a channel and set the notification type to Calling (notification types). Name it for the decision it triggers, not the data source: "CRA — 24h clock may have started" is better than "Security alerts".

This channel must stay quiet. If it rings for every advisory, every failed scan and every dependency bump, people will stop answering it, and you will have spent your one loud channel on noise. Route those elsewhere — the alert fatigue guide covers the split.

Copy the channel's webhook URL from its details; it looks like https://hook.echobell.one/t/<channel-token>. Treat it as a secret, because anyone holding it can ring your team's phones (webhook guide).

Set templates that are readable on a lock screen at 02:00 by someone half awake:

Title: Possible CRA report — {{product}}
Body: {{kind}} — {{summary}} (aware since {{time}} UTC)

{{time}}, {{date}}, {{hour}} and the other system time variables are always injected in UTC, so the notification records a timestamp even if the sender forgot one. That timestamp is not legal evidence of when awareness began, but it is a useful anchor when you later reconstruct the timeline.

Step 2 — Point your detection paths at the channel

Any system that can call a webhook can trigger the channel. Fields you send become template variables:

curl -X POST https://hook.echobell.one/t/<channel-token> \
  -H "Content-Type: application/json" \
  -d '{
    "product": "Acme Gateway 4.x",
    "kind": "actively exploited vulnerability",
    "summary": "researcher report, working exploit attached",
    "craCandidate": true,
    "externalLink": "https://issues.internal.example/PSIRT-4412"
  }'

The externalLink special variable becomes a clickable link in the notification record, so answering the call puts the responder one tap from the ticket that holds the details.

Worth wiring up, in rough order of how often they are the first signal:

  • Your PSIRT or security intake queue — a webhook when an issue is labelled as a CRA candidate.
  • GitHub security advisories and Dependabot alerts on repositories that build shipped products (GitHub integration).
  • Your SIEM, EDR or WAF, for detections against build, release or signing infrastructure — Article 14(5) explicitly reaches incidents that could lead to malicious code being introduced.
  • Vulnerability intelligence feeds you already consume, filtered to components that appear in your own SBOMs.

Step 3 — Use conditions so only plausible candidates ring

This is the step that keeps the channel credible. Echobell conditions evaluate the same variables and HTTP headers your templates use, and a channel only fires when the expression is true:

craCandidate == true && confirmed == true

Or gate on a header if the sending system cannot shape its body:

header["x-cra-severity"] == "reportable"

Set the threshold at "a competent person should look at this within the hour", not at "this is definitely reportable". Deciding whether Article 14 is engaged is a judgement call that needs a human with the facts; the channel's job is to get that human to the facts quickly. Over-filtering here is the expensive mistake, because a report you never started is worse than a call you did not need.

Step 4 — Catch the systems that only send email

Most first contact from outside your company arrives as email — the researcher, the customer, the national CSIRT, the component vendor. Every Echobell channel can have its own address, so one forwarding rule on security@ turns those messages into calls (email triggers).

Email triggers expose from, to, subject, text and html as variables, so you can filter without parsing anything:

subject != "" && (from == "cert@vendor.example" || subject == "[EXPLOITED]")

Ask your regular reporters and key suppliers to use an agreed subject marker, then match on it. It is a small contractual detail that turns an unstructured inbox into a routable signal.

Step 5 — Put every registered representative on the channel

Share the channel with everyone who can actually file: the primary authorised representative, the secondary backup, and the security lead who can make the Article 14 call. Each subscriber picks their own notification type, so the person on duty can sit at Calling while the rest of the group takes Time Sensitive.

This is the point of the exercise. The SRP requires a registered, validated human. If exactly one person in your company is registered, your 24-hour deadline has a single point of failure with a phone battery.

Step 6 — Rehearse before 11 September, not after

Two rehearsals, both worth doing this month:

  1. The alert path. Fire the curl above with Do Not Disturb genuinely enabled, on the phone that will actually be on someone's nightstand. Turn on Retry Failed Call in the app so a call that fails once is attempted again. An untested escalation path is an assumption.
  2. The filing path. Walk through a report on paper, using ENISA's step-by-step registration and submission guides, which were updated through August 2026 (ENISA SRP). Create the EU Login accounts now, confirm which CSIRT is your coordinator, and issue the secondary-representative invitation early — it expires after seven days.

The second rehearsal has a wrinkle worth knowing about: as of ENISA's July guidance the platform's public URL was still listed as "to be provided at launch", so live end-to-end testing was not yet possible (cyberresilienceact.eu). ENISA has committed to the platform being operational by 11 September 2026. Rehearse everything you can control and do not treat platform readiness as a reason to delay your own.

What Echobell does not do

Being specific about this matters more than usual here, because the subject is regulatory:

  • It does not make you compliant. Echobell is a notification channel. Scoping your products, running a vulnerability handling process, deciding whether Article 14 is engaged, registering with the SRP and filing on time are all yours. No alerting tool has ever satisfied a reporting obligation.
  • It does not file anything. There is no API to file through, and Echobell would not be the thing calling it if there were. It rings a phone; a registered human does the rest.
  • It is not a legal timestamp. The {{time}} variable records when the trigger reached Echobell, in UTC. When "becoming aware" started is a factual question about your organisation, and your incident record — not a push notification — is what documents it.
  • It has no escalation policies or acknowledgement. There is no "if nobody answers in ten minutes, call the next person", no rotation, no audit trail of who acknowledged what. For those you need an incident platform — see Opsgenie alternatives.
  • It cannot guarantee delivery. A call depends on push infrastructure, the network, and a charged phone. Treat it as the layer that shortens the gap between a fact arriving and a person knowing, not as a control you can point at in an audit.
  • It does not track local time. Built-in time variables are UTC only and do not follow daylight saving. Conditions that fence a time window need manual adjustment twice a year.

FAQ

Does using Echobell make us CRA compliant?

No. The CRA imposes obligations on manufacturers, and no notification app can discharge them. What Echobell addresses is one specific failure mode: the 24-hour early warning is missed because the person who could file it did not find out until the next working day. That is a real and common failure mode, but it is one part of a much larger compliance programme.

When does the 24-hour clock actually start?

When the manufacturer becomes aware of the actively exploited vulnerability or the severe incident. The regulation does not define an exact moment, and awareness depends on the facts and how quickly they can be established (DLA Piper). In practice this argues for triage that is fast and documented: the longer the gap between a signal arriving and someone assessing it, the harder it is to explain later.

We are a small company. Are we exempt?

Not from reporting. Article 64 excludes microenterprises and small enterprises from administrative fines specifically for missing the 24-hour deadline in Article 14(2)(a) or 14(4)(a). The obligation to report remains, the 72-hour notification and final report are unaffected, and the definitions of microenterprise and small enterprise are not for you to assume. Treat it as a narrow mitigation, not a pass.

Our security inbox is monitored during business hours. Isn't that enough?

Only if you are prepared to lose up to two thirds of the window on a normal weekend. A report arriving at 18:00 on Friday leaves you with a deadline of 18:00 Saturday. Business-hours monitoring is a fine default for everything else; the 24-hour clock is precisely the case it does not cover.

Yes, and they should. Share one channel and every subscriber is notified on the same trigger, each choosing their own urgency. The engineer confirming exploitation and the person who will submit the form need to start at the same minute, not in sequence.

Does this help with the Article 14(8) duty to inform users?

Indirectly. Article 14(8) requires informing impacted users about the vulnerability or incident and, where necessary, corrective measures. That is customer communication, and it needs your own channels. Echobell can wake the people who own that communication at the same time as the people who own the filing, so the two workstreams start together.

We already report under NIS2 or DORA. Is this the same thing?

No, though the shapes rhyme. NIS2 and DORA place duties on entities based on sector and criticality; the CRA places duties on manufacturers based on the products they place on the EU market. One organisation can be subject to all three, with different clocks and different recipients. If those regimes are also in scope for you, see DORA and NIS2 incident reporting alerts — and note that the alerting layer can be shared even when the obligations are not.

Will the call really get through Do Not Disturb?

Calling notifications are delivered as call-style alerts, which is what lets them break through Focus Mode on iOS. It is not magic: it still depends on OS settings, the network and a charged phone. Test it on the actual device, with Focus Mode actually on, before you rely on it — and enable Retry Failed Call.

Is this iOS only?

No. Echobell is on iOS and on Android via Google Play (Android release). Call-style alert behaviour differs between the platforms, so test on the device the responder will actually carry.

What should we put in the webhook payload?

The minimum needed to decide whether to get up: the product, the kind of signal, one line of context, and an externalLink to the ticket holding the detail. Echobell keeps notification content and history on the device and only accounts, channels and subscriptions on the server (privacy model), but the right habit with security-sensitive material is still to send a pointer, not the substance.

Related articles

Overnight Trading Alerts: The Market Stops Closing on 6 December

US equities move to a 23-hour trading day on 6 December 2026, and CME crypto has traded 24/7 since May. Here's how to route overnight price alerts into a phone call with Echobell — and what a louder alert still cannot fix.

Read more

Your AI Agent Is Waiting for You: Turn Approval Gates Into Phone Calls

Autonomous agents pause and wait silently when they need a human. Nothing in the agent stack rings your phone. Here's how to wire agent approval gates and failed runs into a real call with Echobell.

Read more

DORA and NIS2 Incident Reporting: Get a Phone Call Before the Clock Runs Out

DORA gives you 4 hours from classification. NIS2 gives you 24 hours from awareness. Neither clock pauses at night. Here's how to route detection alerts into a ringing phone call with Echobell.

Read more