Europe’s 24-hour vulnerability clock reports to regulators first and customers second

The week

In the second week of September 2026, Europe began to answer in law part of an old question for security teams. When a criminal group finds a hole in the firewall that guards a company’s network and starts using it, who finds out first, and how quickly does the news reach the company?

The EU Cyber Resilience Act, usually shortened to the CRA, is a European law that sets security requirements for “products with digital elements”: essentially anything sold in the EU that contains software or connects to a network, from operating systems and routers to business applications and smart devices. It entered into force in December 2024, and most of its obligations apply from December 11, 2027.

Its reporting duty came first. From September 11, 2026, manufacturers of products with digital elements sold in the EU must report actively exploited vulnerabilities and severe incidents affecting their products. A vulnerability is a flaw in software that an attacker could use to get in or cause harm. “Actively exploited” means someone is already using it in the real world; a flaw that a researcher has spotted but nobody has used does not count. A severe incident is a security event that seriously affects the product, its users or its security.

The timetable is tight. The sequence is an early warning within 24 hours of becoming aware, a fuller notification within 72 hours and a final report later.

Reports go through ENISA’s Single Reporting Platform to the national CSIRT acting as coordinator, with ENISA informed at the same time. ENISA is the EU’s cybersecurity agency. A CSIRT, or computer security incident response team, is a national body that coordinates the response to cyber threats. ENISA launched an initial version of the platform on September 11 and said it would add functions over the following months.

Two details widened the reach. The duty covers products already on the market as well as new ones, so years of installed equipment came into scope on day one. And medical devices regulated under the EU device regulations are outside the Act, because they already have their own rulebook.

A buyer’s question: how will the news reach us?

Most commentary on the Cyber Resilience Act addresses manufacturers. Banks, health systems and public agencies mostly sit on the other side, as buyers of the operating systems, network equipment, security tools, applications and connected devices the Act covers. For them, the useful question is how news of an exploited flaw in something they run will now reach them.

That question matters because time is what decides the damage. When attackers are using a flaw, every hour between the vendor knowing and the customer acting is an hour in which the customer is exposed without knowing it. A bank whose firewall has a known hole, or a hospital whose network switches are being targeted, needs to hear quickly and clearly what is affected and what to do.

The answer runs through three separate channels: the regulator channel the Act built, the customer channel it requires but does not time, and the buyer’s own channel for everything the Act leaves out. Each needs a different response.

A quick note on roles. The Act places duties on “manufacturers,” meaning those who develop or have a product developed and sell it under their own name. Whether any of an organization’s own activities make it a manufacturer under the Act is a question for its lawyers. A bank that sells a branded app, or a health system that markets software it built, may want to ask.

Channel one: the regulator channel

The 24-hour clock runs from the manufacturer to the authorities. An early warning goes to the coordinating CSIRT in the member state of the manufacturer’s main establishment, and ENISA sees it at the same time. A fuller notification follows within 72 hours. For a vulnerability, the final report is due within 14 days of a fix or mitigation becoming available. A mitigation is a step that reduces the risk without fully fixing the flaw, such as switching off a vulnerable feature. For a severe incident, the final report is due within a month of the notification. The Act lets information arrive in stages, so an early warning can be thin, perhaps little more than “we have a problem in this product line and are investigating.”

What it changes for buyers

For buyers, this channel matters indirectly. Authorities can now see which manufacturers report quickly and which report late, and they can share information with CSIRTs in other member states where the product is sold. Over time that should push vendors toward faster triage. Triage, borrowed from emergency medicine, means quickly sorting problems by how serious they are.

Buyers do not, however, receive these reports. A bank’s security team cannot log in to the ENISA platform and read what its firewall vendor filed. What the regulator channel changes is vendor incentive, and buyers should not mistake it for an alert feed. It works like a restaurant hygiene inspection, which makes kitchens cleaner over time but does not tell you whether tonight’s fish is fresh.

What it demands of vendors

It also changes the internal maturity a vendor needs. Meeting a 24-hour clock requires knowing which products and versions contain an exploited component. Modern software is assembled from many parts, much of it written by others. When a flaw turns up in one widely used part, the manufacturer has to know quickly every product it is in.

That means a current component inventory, which the Act will require more formally, through a software bill of materials, from December 2027. A software bill of materials, or SBOM, is exactly what it sounds like: an ingredients list for a piece of software, naming each component and its version. Vendors without that inventory face the reporting clock first and the documentation duty later. For buyers, how quickly a vendor can say which of its products are affected is a good early sign of whether it has its house in order.

Channel two: the customer channel

The Act also requires manufacturers to inform impacted users of an actively exploited vulnerability or a severe incident, and where appropriate all users. Where relevant, they must describe mitigation or corrective measures users can take. The duty is real, and it covers products placed on the market before the main obligations apply. It does not carry the same hour-by-hour deadline as the report to authorities.

So the law guarantees that customers will be told, and tells regulators within a day, but leaves the customer’s timing open. Closing that gap falls to the buyer.

Closing the gap with contracts

Contracts are the obvious tool. A buyer can ask that customer notice follow the regulator notice within a short, defined period, and that it name affected products and versions. It can also specify that notice go to a monitored security mailbox rather than a sales contact. An urgent security warning that lands in the inbox of an account manager who left last year is as good as no warning.

Making notices machine-readable

The Act also encourages notice in a structured, machine-readable format where appropriate. Machine-readable means a computer can read it directly, rather than a person having to read an email and retype the details. A buyer that can ingest such advisories into its vulnerability management tool will act faster than one that reads emails. A vulnerability management tool is the software a security team uses to track which flaws affect which of its systems and which have been fixed. CSAF, the common advisory format many large vendors already publish, is the obvious target. CSAF stands for Common Security Advisory Framework, a standard layout for security warnings that lets any compatible system read where the problem is and what to do.

Matching notices to what you run

Notices are only useful if they can be matched to assets. A simple test: when a vendor names an affected version, the security team should be able to list every place it runs within an hour. For many organizations the honest answer depends on whether the configuration management database is current for network appliances and on-premises software. A configuration management database, or CMDB, is the organization’s master list of its technology: what it has, where it is, what version it runs and who owns it. Network appliances are physical boxes such as firewalls and routers; on-premises software is software the organization runs on its own computers rather than renting from the cloud. These are the categories most often missing or out of date. Fixing that is cheaper than any contract clause.

Channel three: the buyer’s own channel

The Act leaves large parts of a regulated organization’s estate untouched. Estate here means everything the organization runs.

• Software as a service. Software delivered purely as a service is generally addressed by other EU law, notably NIS2, unless it is remote processing integral to a product. Software as a service, or SaaS, is software you use over the internet and never install, such as many email, HR and customer-management tools. NIS2 is a separate EU directive on the security of important organizations and services.
• Medical devices. Medical devices sit under their own regulations.
• In-house software. Software an organization builds for its own use is not placed on the market.
• Open source. Open-source components pulled directly into in-house code carry lighter or no obligations, depending on who stewards them. Open-source software is code published freely for anyone to use; a steward is an organization that looks after a project over time.

For these, nothing changed on September 11. A hospital still learns of a flaw in an infusion pump through the device maker and health-sector channels. A bank still relies on its SaaS providers’ contractual incident terms. An agency still tracks exploited vulnerabilities in its own code through its own scanning and through public sources such as CISA’s Known Exploited Vulnerabilities catalog. CISA, the US Cybersecurity and Infrastructure Security Agency, keeps that catalog as a public list of flaws known to be used by attackers.

Label every critical asset by channel

The practical step is to label every critical technology asset by channel. Assets covered by the Act can be held to its customer notice duty. Assets outside it need equivalent terms written into contracts or monitored through other feeds. The labeling also exposes a common blind spot: products bought through resellers or bundled into managed services, where the buyer may not know which manufacturer owes it notice. If a managed service provider installed a set of network devices, the buyer may not know who made them, and the manufacturer may not know the buyer exists.

US buyers gain, without a guarantee

US organizations are part of this picture whether or not they operate in Europe. Most large technology vendors sell into the EU and will run one global process rather than a European one. Their disclosure habits will shift for every customer, even if only European users have the legal right to notice. A US bank may therefore benefit from faster vendor triage without being covered by the law, but it cannot rely on that benefit being guaranteed to it.

What a late warning costs

Vulnerability notices can sound like a matter for the security team alone, but they bear directly on what boards and regulators ask about.

Risk and loss. An actively exploited flaw is, by definition, one that criminals are already using. Many of the most damaging attacks on banks, hospitals and agencies, including ransomware attacks that lock up systems until a ransom is paid, begin with a known flaw in a firewall, remote-access gateway or other piece of network equipment that was not fixed in time. The gap between a vendor learning of a flaw and the customer acting on it is the window attackers rely on.

Operations. Emergency fixes are disruptive. A team that hears early, knows exactly which devices are affected and receives a clear mitigation can plan the work. A team that hears late and has to hunt for affected systems ends up taking things offline in a hurry, often at the expense of customers or patients.

Regulators. Banks, health systems and public agencies have their own reporting and resilience obligations. Supervisors increasingly ask how an organization learns about threats in the technology it depends on, and how quickly it responds. “We were waiting for the vendor to email us” is not a strong answer.

Third-party risk. Most organizations now depend on technology they did not build and do not fully control. The CRA strengthens one part of that dependency, the relationship with product manufacturers, but only if the buyer turns the law’s general duty into specific contract terms and working processes.

Cost. Almost everything recommended here is inexpensive compared with the cost of an incident: a clause in the next contract renewal, a change of notification address, a setting in a tool the security team already owns and an honest clean-up of the inventory. The expensive part is discovering the gaps during a live attack.

One flaw, three channels: a bank’s Tuesday

Suppose a mid-sized bank with operations in Europe and the US. One Tuesday morning, the maker of its firewalls learns that attackers are exploiting a flaw in one software version.

Within 24 hours the manufacturer files an early warning through ENISA’s platform. The bank sees none of that. What it receives depends on what it arranged in advance.

If the bank had negotiated a defined customer-notice period, a machine-readable advisory arrives at its monitored security mailbox shortly afterward, naming the affected version. Its vulnerability management tool reads the advisory automatically. The security team checks its CMDB and within the hour has a list of every firewall running that version, including two in a branch office installed by a managed service provider. The team applies the vendor’s recommended mitigation that afternoon and schedules the fix.

If the bank had not arranged any of this, the advisory eventually arrives as a general email to a sales contact. Someone forwards it to security a day later. The team has to search manually for affected devices and misses the two branch-office firewalls, because the managed service provider’s equipment was never added to the inventory. Those devices stay exposed for weeks.

The same week, the bank’s cloud-based HR system has its own security incident. The CRA plays no part; what matters is the bank’s SaaS contract. And a flaw in code the bank wrote itself turns up in CISA’s catalog, which the bank’s own scanning should catch. Each of the three warnings reached the bank through a different channel, and only one of them was governed by the CRA.

The prepared bank and the unprepared one

The bank that comes out of that Tuesday well has four things in place: contracts with critical vendors that set a short customer-notice period after any CRA report, name affected versions and send notice to a monitored security address; advisories received in a machine-readable format and fed straight into the vulnerability management tool; an inventory accurate enough to show within an hour where an affected version runs; and every critical asset labeled by channel, with contracts or feeds covering anything the Act does not.

The failures tend to run the other way. Teams assume that because vendors now report to regulators within 24 hours, customers will hear within 24 hours too. Security notices stay routed to sales or account contacts, or arrive only as emails that someone has to read and retype. The inventory covers laptops and servers well but network appliances and on-premises software poorly, and it forgets devices installed through resellers or managed service providers. And some organizations assume the CRA covers SaaS, medical devices or in-house code, when it does not.

Where the warning could go missing

• Do our contracts with key vendors set a defined period for telling us after they report an exploited flaw to authorities?
• Where do vendor security notices go today, and is that mailbox monitored around the clock?
• If a vendor names an affected version this afternoon, could we list every place it runs before the end of the day?
• Which products did we buy through resellers or managed service providers, and do we know who made them?
• How do we hear about flaws in our SaaS tools, medical devices and in-house code?

With hindsight

ENISA’s platform went live on schedule, in an initial version that the agency says it will extend over the coming months, with user manuals, a glossary and a help desk alongside. For a new pan-European reporting system, launching on the legal start date was no small thing.

By October 2026 the regime had run for about a month, too short to judge its effect. A month of reports cannot show whether vendors are triaging faster, whether customers are hearing sooner, or whether the early warnings are useful.

The channel split described here has held. Buyers see the customer notices, not the regulator filings. Nothing in the first month changed the basic point that the 24-hour clock serves authorities, and that a customer’s own speed depends on its contracts, its intake and its inventory.

No public data yet show how many reports have been filed or how quickly. When such figures appear, they will be worth reading closely, especially any indication of how often early warnings are followed by fuller notifications on time.

The December 2027 obligations, including component documentation, will raise the bar further. Once vendors must keep a formal software bill of materials, buyers will have a stronger basis for asking which products contain a newly exploited component, and vendors will have less excuse for slow answers. Buyers who build the habit of asking now will be ready to use that information when it arrives. Those who do not may find that the ingredients list exists but nobody on their side knows how to read it.

A regulation aimed at manufacturers still asks something of buyers. The law improves vendor behavior; it does not deliver warnings to your door. Organizations should follow Commission and ENISA guidance as it develops, and ask their lawyers how the Act applies to any products they sell themselves.