On September 11, 2026, a new clock starts for manufacturers of products with digital elements on the EU market.
When an actively exploited vulnerability affects one of your products, you have 24 hours to file an early warning and 72 hours for a full notification, filed once through a single reporting platform to the CSIRT where your main establishment sits, with ENISA notified at the same time. A final report follows no later than 14 days after a corrective measure is available.
The question is not whether you'll report. It's whether you can answer "which of our products contain this component, and which versions?" before the clock runs out.
What the CRA Actually Requires Now
Most of the Cyber Resilience Act: secure-by-design, conformity assessment, the CE marking, mandatory SBOMs, applies in full from December 11, 2027. But the vulnerability and incident reporting obligations arrive earlier, on September 11, 2026, and they reach products placed on the EU market before the CRA applies in full. Your installed product line is on the clock, not just what you ship next.
That timing matters. The full compliance regime is a 2027 engineering program. The reporting clock is a 2026 operational problem, and it arrives first.
The penalties are not symbolic: up to €15 million or 2.5% of global annual turnover, whichever is higher.
The Reporting Clock Is a Visibility Test
Here is what a 24-hour reporting obligation really measures: how fast you can determine exposure.
When a vulnerability in a widely used component is reported as actively exploited, every manufacturer with that component in a shipped product is on the clock. The ones who can answer "we ship that component in these three products, at these versions" in minutes will file an accurate early warning and move on. The ones who cannot will spend the first 24 hours doing inventory instead of response, and an inaccurate or late filing is its own exposure.
This is not a development problem. It's a data problem. The component data exists; it lives in your SBOMs. The question is whether it's searchable when you need it.
Turning SBOMs Into a Reporting-Ready Inventory
SCIP, the Supply Chain and AI Threat Intelligence Platform, ingests your CycloneDX and SPDX SBOMs into Splunk and maintains a continuously searchable component inventory across every product you ship.
When a vulnerability is reported, you search the component by name. SCIP returns every product that includes it, the exact version in each, the associated CVEs, and whether any of those CVEs appear on CISA's Known Exploited Vulnerabilities catalog, the closest open signal to the CRA's "actively exploited" trigger.
That gives you the two facts the early warning requires: what's affected, and how severe. In minutes, not in a day of manual hunting.
SCIP does not detect exploitation in your running systems, SBOMs are declarative, and that's a different layer. What it does is collapse the exposure-scoping step, which is the part of the 24-hour window that usually consumes it.
One more precision point, since searchable and current are two different claims: the search is only as accurate as the most recently ingested SBOM for that specific unit or product line. SCIP's drift monitor flags changes between successive SBOM submissions, new components, removed components, version changes, but that comparison still depends on a fresh SBOM coming in. A field unit that's been patched, reconfigured, or rolled back since its last SBOM submission won't show that change until the next one lands. Keeping field SBOMs current is the operational discipline that makes the 24-hour speed argument actually hold.
After the warning, the 14-day final-report clock is a remediation-tracking problem. SCIP's risk scoring lets you prioritize the affected products by exposure and follow remediation to closure, so the final report is a record you already have rather than one you reconstruct.
One More Clock, Running in Parallel
One scoping note on everything above: this covers the 24-hour authority-facing reporting clock specifically, the CSIRT and ENISA path. Article 14 also carries a separate obligation, informing affected users about the vulnerability and mitigation steps, which runs alongside that path, not folded into it. Different clock, different audience, and it's easy to build the authority-facing process and discover the user-notification duty exists mid-incident.
Start Before the Clock Does
Component Search is in SCIP. Install from Splunkbase, ingest your SBOMs, and confirm today that you can answer the exposure question in minutes: splunkbase.splunk.com/app/8814
September 11 is a date. The product that gets confirmed exploited is not, and shared components don't put your whole portfolio on the same clock, only the product where exploitation is confirmed does. The question isn't whether you have this component somewhere. It's whether, once that one product is confirmed, you can name its exact affected version fast enough to file.
If you ship into the EU, where does your reporting readiness stand right now, minutes, hours, or "we'd find out the hard way"? I'd like to know where most teams are.