Another Brussels deadline is about to become an American scramble.
Europe’s next compliance headache for U.S. technology companies has a date: Sept. 11.
That’s when the EU Cyber Resilience Act (CRA) starts a 24-hour reporting clock for manufacturers that become aware of an actively exploited vulnerability in a product they sell in Europe or a severe security incident affecting it.
If your company sells software, devices, embedded systems or other digital products there, Sept. 11 should have your attention.
That’s 24 hours. Not 24 hours after legal finishes its review. Not after engineering figures out exactly which versions are affected. Not after somebody finds the product owner who is vacationing in Maui. The clock starts ticking when your security team becomes aware of the bug.
“On Sept. 11, the companies most likely to get into trouble will be the ones that discover their reporting process for the first time after the clock has already started,” said Devashri Datta, OpenChain CRA Compliance Chairman.
Why Europe Put a Clock on Software Security
The CRA was years in the making. Brussels announced it in 2021 after WannaCry, Pegasus and other attacks exposed a larger problem: too many digital products shipped vulnerable, with too little responsibility for securing them afterward. The European Commission proposed the law in 2022; it took effect in 2024.
The idea is simple: make manufacturers responsible for securing digital products throughout their lifecycles, instead of leaving customers to absorb the risk.
Sept. 11 is when the first big requirement goes live: manufacturers must report actively exploited vulnerabilities and severe product-security incidents, with an early warning due within 24 hours of awareness.
One wrinkle: the regulatory obligation arrives before the punishment. Reporting becomes mandatory Sept. 11, but the CRA’s fine regime — up to €15 million or 2.5% of worldwide turnover — applies beginning Dec. 11, 2027. Miss a report this fall and you are out of compliance; by December 2027, CRA violations can also put products at risk of restriction, withdrawal or recall from the EU market.
See the sidebar to the right, “What Is the Cyber Resilience Act, and Why Should U.S. Companies Care?” for the full timeline, scope and penalty breakdown.
The more immediate question is whether companies are remotely ready to meet that first deadline.
There is plenty of reason to think some aren’t.
A 2026 Linux Foundation/OpenSSF survey found 72% of U.S. and Canadian respondents were unfamiliar with the CRA. Among manufacturers, only 41% expect to be fully compliant by December 2027; 39% don’t know when they will be.
“At the moment I think we are seeing a lot of ‘wait and see’ reactions,” said Josh Bressers, vice president of security at Anchore, speaking to Security Point Break.
Wendenburg sees companies taking the deadline seriously moving the other way.
“The shift is from interpreting the CRA to operationalizing it,” he told SPB. Companies are assigning incident-response ownership, expanding SBOM coverage, adding continuous vulnerability monitoring and rehearsing the 24- and 72-hour reporting workflow.
For U.S. companies tempted to regard this as Europe’s problem, there is another unpleasant detail.
It isn’t.
The CRA follows the product, not the passport. Software, hardware and separately sold components subject to the law face the same rules on the EU market whether their maker is in Düsseldorf or Dallas.
Wendenburg said ONEKEY is already seeing more CRA interest from U.S. makers of industrial equipment, network products and embedded systems.
“The biggest blind spot is among companies that still see themselves primarily as hardware manufacturers, despite shipping products containing large amounts of third-party software.”
If GDPR taught U.S. companies anything, it is that Brussels has reach. CRA isn’t GDPR on steroids. Think GDPR’s long arm. But CRA, Wendenburg said, is “much more engineering- and operations-driven.”
It lands across product security, engineering, incident response and legal — ideally at once.
Another EU Rule for U.S. Companies
CRA is hardly the first European digital rule to reach U.S. companies. GDPR already regulates how many handle Europeans’ personal data. Depending on their operations and sector, companies may also face NIS2 or DORA cybersecurity reporting requirements. At home, U.S. public companies face the SEC’s cyber-disclosure rules.
So 24 hours is not the novelty. The trigger is.
CRA can start the clock when a manufacturer becomes aware that a vulnerability in its product is being actively exploited — potentially before there is a breach, a materiality decision or certainty about how exposed the product is.
Andrea Hall, principal security program manager for Red Hat Product Security Governance, Risk and Compliance, calls the problem “the timer trap.” She describes CRA’s trigger as the most aggressive of the EU’s major cyber-reporting clocks.
Her concern is what happens before the facts are settled: who decides an alert is real, who determines product impact, and who has authority to report while triage is still underway?
Manufacturers do not report every vulnerability they discover.
“From September 11, 2026, manufacturers must report only actively exploited vulnerabilities and severe security incidents, not every vulnerability they discover,” Wendenburg said.
ENISA, the EU’s cybersecurity agency, defines an actively exploited vulnerability as one with reliable evidence of malicious exploitation.
An early warning is due within 24 hours of awareness, with more detail within 72 hours. For exploited vulnerabilities, a final report follows within 14 days of a patch or other corrective measure becoming available.
Then the incident trail matters: when the alert arrived, what suppliers knew, what engineering found and when the issue was escalated.
Open-source cybersecurity researcher Devashri Datta sees the ambiguity there.
“The ambiguity is the gap between hearing that a component is being exploited somewhere and knowing that the vulnerability is contained in your product and relevant to your implementation,” she said.
Her point: You know Component X is under attack and somewhere in your software. Now prove Product Y in Germany is actually exposed — while the clock is running.
Bressers told SPB that proving actual product exposure remains surprisingly difficult.
“The reachability problem with vulnerabilities is still a significant challenge,” he said. “It’s usually very easy to prove something IS used, but proving something isn’t used is a lot harder, maybe impossible.”
You Have 22 Days. Use Them
Companies that may be in scope have three weeks to test the machinery.
- Know your EU products. Article 14 applies even to in-scope products already on the EU market before the broader CRA takes effect in 2027.
- Name who owns the clock. Datta recommends PSIRT handle triage, legal/compliance make the regulatory call and a named executive authorize filing.
- Map vulnerability → component → product → version. ONEKEY found only 12% of surveyed industrial organizations had a complete view of software across their products.
- Know what your SBOM can’t prove. Bressers says identifying a component is easier than proving the product isn’t exposed.
- Learn the reporting system now. ENISA’s Single Reporting Platform goes live Sept. 11 and already has registration and submission guidance.
- Test the workflow. Wendenburg said companies are already “rehearsing the 24-hour and 72-hour reporting workflow.” A tabletop can expose the gaps without touching production.
Many aren’t there yet. ONEKEY found just 14% had launched extensive CRA measures; 37% called the 24-hour mandate their biggest challenge.
The SBOM Is Not Your Get-Out-of-CRA-Free Card
SBOMs matter because you cannot assess an exploited dependency if you don’t know what’s in the product.
“By definition you have to know what’s in your software to understand if your code or a dependency has a vulnerability,” Bressers said. “SBOM is a tool that can certainly help with that.”
But an SBOM match is only the start. ONEKEY found 44% had begun creating SBOMs; just 12% had completed them across their product portfolios.
Datta has seen what happens next. One company could identify the dependency, but not quickly determine which versions were affected, who was authorized to notify regulators or what evidence legal needed. “The bottleneck was not the SBOM itself; it was the decision process around it,” she said.
Tools can map the software, but they cannot make an organization act under a 24-hour clock.
“A checklist cannot create organizational authority,” Datta said. “It can tell you what evidence and processes you need, but it cannot make your SBOM current, resolve product ownership, decide risk tolerance, or make legal, security, and engineering move together under a 24-hour clock.”
Before Everyone Reaches for the Excedrin
Not everybody thinks CRA deserves the panic. Bressers thinks the Sept. 11 requirement is more manageable than the full CRA regime.
“The ability to meet the reporting deadline is much more simple than the complete CRA requirements,” he said.
Linux kernel maintainer Greg Kroah-Hartman goes further.
“This is nothing out of the ordinary that good software engineering firms shouldn’t be doing,” he said during an OpenSSF podcast in June.
If basic software hygiene is standard engineering, the readiness numbers are damning: only 41% of surveyed manufacturers expect to be CRA-compliant by the end of 2027; 39% don’t know when they’ll get there.
Maybe Brussels isn’t the whole problem.
Datta expects CRA-built inventories, SBOM/VEX workflows and escalation paths to become global.
“The reporting destination may be regional,” she said, “but the underlying vulnerability-response discipline is likely to become global.”
First comes Sept. 11. U.S. manufacturers have less than three weeks to find the products, name the owners and test the process. After that, the clock starts for real.
