The CRA's 24-hour clock is live. It starts in your support inbox.

Picture a ticket that lands in your support queue late on a Friday. A customer's security team says someone has been using a flaw in your product's admin interface to get into their network, and they have the logs to show it. The message is calm, a little technical, and tagged low priority, because nothing is down. It will be read on Monday.

Until recently, that delay was an embarrassment. Since 11 September 2026, for a company that sells software or connected hardware in the European Union, it may also be a missed legal deadline.

What changed in September

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, sets security rules for products with digital elements, meaning software and hardware, across their whole life. Most of it does not bite until 11 December 2027. One part already does. According to the European Commission, since 11 September 2026 manufacturers must report actively exploited vulnerabilities, and severe incidents that affect the security of their products, through a Single Reporting Platform run by ENISA, the EU's cybersecurity agency.

The timetable is short. The Commission's summary asks for an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report no later than 14 days after a fix is available for an exploited vulnerability, or within a month of the 72-hour notification for a severe incident. Affected users must also be told what happened and what they should do about it.

Two details catch people out. Legal commentary on the Commission's final guidance notes that the duty covers products placed on the market before the Act fully applies, and that it continues after a product's support period has ended. The appliance you stopped patching years ago still counts. The same commentary notes that you do not have to report, after the fact, exploitation you already knew about before 11 September.

First, check whether this is your problem at all

Not every software company is a manufacturer under the Act. The CRA is aimed at products: installable software, firmware, mobile and desktop apps, connected devices and the components that go into them. Software delivered purely as a service is broadly outside it, unless that service is the remote data processing a product needs in order to work, such as the cloud backend a smart device cannot function without. If customers only ever reach your application through a browser, much of this article may describe your suppliers rather than you, though other rules may still apply.

The edges are genuinely blurry: a desktop agent that ships alongside a web product, an SDK you hand to customers, an on-premises edition sold to two banks. The Commission published practical guidance on 27 July 2026, and that is the place to start, followed by your own counsel. Scope is a legal question. Everything below is an engineering one.

The real requirement is noticing

Read Article 14 as an engineer and it is hardly a paperwork rule at all. Filling in an early warning takes minutes. The hard part is everything that has to happen before anyone knows there is something to file. Exactly when a company counts as aware is for lawyers and regulators to settle. The practical question is simpler: how long does a credible signal sit somewhere before a person who can judge it sees it?

In many companies the honest answer is unflattering, because the signal almost never arrives at the security team. It arrives as a support ticket, an email to a salesperson, a comment on a public issue tracker, a researcher's note to a general contact address, or a remark in a customer's quarterly review. Each of those places has its own queue, its own priorities and its own idea of what counts as urgent.

Trace a single report through a typical company and the time rarely vanishes in one place. It leaks away at each handoff.

• The signal lands in the wrong queue. Support triages by customer impact, not by exploitability. A calm message about an attack can sit behind a noisy one about a password reset.
• Nobody knows which products contain the flaw. If the weakness is in a third-party library, you need a software bill of materials (SBOM), a list of every component in every version you shipped, to know what is affected. Building that list during an incident takes days.
• Nobody can tell exploitation from theory. Without logs or telemetry from the product, the team argues about whether the attack is real. The rule turns on active exploitation, so that argument is the decision.
• Nobody owns the call. Engineering assumes legal files reports, legal assumes security does, and security is waiting for engineering to confirm the facts.
• Nobody can reach the users. Telling affected users means knowing who runs which version, and having a way to reach them that is not the marketing newsletter.

Will a penetration test create reports you have to file?

Buyers now ask this before commissioning a test, and the honest answer is: mostly no. The trigger is a vulnerability that a malicious actor is actually exploiting. A flaw found by testers you hired, working with your permission, is a vulnerability, not an exploited one. It belongs in your normal vulnerability handling: fix it, ship the update, disclose it as your policy says.

The exception matters. A good tester sometimes finds traces of someone who got there first: an unfamiliar account with administrator rights, a web shell left on a server, logs showing the same weakness being used months ago. That is no longer a test finding. It may be evidence of an incident or of active exploitation, and the clock may now be running. Write this into the rules of engagement before the test starts: what counts as a sign of earlier compromise, whom the tester calls, how evidence is preserved, and who decides whether it is reportable.

There is a quieter argument for testing, too. Every flaw found by someone you hired is one fewer that can be found first by someone you did not. Under the CRA, that is the difference between a ticket in your backlog and a filing with a national authority.

Run the drill before a real report runs you

You can measure your readiness in an afternoon, and it is better done with a fake report than with a slide deck.

• Plant a realistic signal. Ask someone outside the security team to submit a mock report through an ordinary channel, such as the support form, at an ordinary time. Tell as few people as possible.
• Time the first handoff. Record how long it takes to reach a person who can judge whether the report is credible. This is usually the biggest surprise.
• Ask what shipped. Name a real third-party component and see how long it takes to list every product and version that contains it, including the ones out of support.
• Ask whether it is exploited. Check whether your product produces the logs that could show an attack in progress, and whether anyone can read them quickly.
• Draft, do not file. Have the named owner write the early warning and the user notice, then compare the total elapsed time with 24 hours.

Then fix the slowest step and run the drill again next quarter. Most of the fixes are unglamorous: a rule that escalates support tickets mentioning exploits or attacks, a security contact address someone actually reads at weekends, a component list generated by the build pipeline instead of by hand, a one-page runbook with a named owner and a deputy.

What you can hand to someone else, and what you cannot

The decision to report, and the report itself, stay with you. No vendor can be accountable for your regulatory filings, and you should be wary of one who offers to be. If you already have a product security function with a working intake process, a component inventory and a rehearsed runbook, you probably need nothing more than the drill above.

Outside help earns its place in the engineering underneath: generating a bill of materials on every build, adding the telemetry that separates an attack from a theory, building a reliable update path for devices already in the field, and testing the product the way an attacker would, so that fewer flaws are discovered by anyone else. That work sits across development and security, which is exactly why it so often falls between two teams that each own half of it.

The regulation counts in hours, but readiness is counted in handoffs. A company that can get a stranger's message to the right person in twenty minutes will find 24 hours generous. One that cannot will find a week too short.