In the last few months, a specific two questions have started showing up in nearly every conversation I have with customers in the EU: 

• if a vulnerability in your stack were exploited tonight, could your team file a 24-hour early warning with a regulator, and 
• do they know it's their job? 

Most of the time, the answer is "probably" or "we'd figure it out." 

Under the EU Cyber Resilience Act, that answer is no longer good enough. September 11, 2026, is when the first hard enforcement date arrives, and it applies to products already on the market, not just new releases.

That's not a scanner problem. It's a governance problem, and it's the one I want to walk through here.

Key Takeaways

• The EU CRA's Article 14 mandatory reporting requirement takes effect September 11, 2026, requiring a 24-hour early warning for actively exploited vulnerabilities.
• Full CRA compliance, including CE marking, conformity assessment, and SBOM requirements, is enforced beginning December 11, 2027.
• A scanner tells you what's vulnerable. It doesn't tell you when you knew, what you did, or how long it took, which is exactly what CRA requires you to document.
• Non-compliance exposure isn't only the fine. A market surveillance authority can restrict EU product sales while an investigation is open, with no fixed timeline.
• This is not legal advice. Scope, applicability, and compliance determinations for your specific products are questions you should bring to your legal team.

The question changed, and most programs haven't caught up.

Every customer I talk to has at least one scanner in place. What CRA asks for isn't a longer vulnerability list. It's answers to: what was in your product, when did you become aware of a problem, what did you do about it, and how long did remediation take. That's a documented, auditable process with a named owner at each stage.

I've discussed these issues with security leaders who are confident right up until I asked the questions: if ENISA asked you to reconstruct your dependency inventory for a product version from six months ago, how long would that take, and how sure are you of what it would show? The pause that follows is the gap. It's not a knowledge gap. It's a documentation gap, and it's the one CRA is determined to close.

Scanning is not governance, and CRA makes that distinction load-bearing.

This has been ActiveState's position for a while now: scanning is reactive, and it happens after a package is already in your environment. A well-run scanner, doing exactly what it's supposed to do, generates a documented record of every vulnerability found and not remediated in a defensible window. Under CRA, that record isn't just a to-do list anymore. It's evidence.

The distinction that matters here is Curate and Govern versus Scan and Pray. Scan and Pray finds problems after they've already entered your environment. Curate and Govern keeps them out at the point of origin, so there are fewer findings to explain in the first place. Sixty percent of breaches exploit a known, already-patched vulnerability. CRA doesn't just require you to patch. It requires you to prove when you knew and how fast you moved.

Transitive dependencies are where the CRA gap actually lives

Most dependency inventories I see stop at direct dependencies: the packages a team explicitly chose. But 64% of open source components in production are transitive, meaning they were pulled in by something else your team selected, not chosen directly. CRA requires a machine-readable SBOM covering at least top-level dependencies. For security teams, extending that inventory to transitive dependencies makes it more useful: you need to understand which components could affect your shipped products, including those your team didn’t select directly. 

I've watched this catch teams off guard more than once. A security leader will tell me their SBOM is solid. Then I ask three questions: 

• Is it machine-readable, in a commonly used format such as SPDX or CycloneDX? 
• Does it include transitive dependencies? 
• Can you connect those components to the product versions your customers actually received? 

That second question is usually where the confidence drops. That last question turns an inventory discussion into a response-readiness discussion.

The 24-hour clock doesn't wait for your triage backlog

Seventy-five percent of security teams already spend more than 20% of their time on manual alert triage. CRA's 24-hour early warning window doesn't add headcount to fix that. It adds a deadline on top of it. The teams I've seen handle this well aren't the ones with the biggest security budgets. They're the ones who moved the governance decision upstream, before a package ever reaches a build, so there's less to triage when a CVE drops.

That’s where the ActiveState Curated Catalog can help. It provides vetted open source components built from source, with provenance records and remediation support. When those records are connected to shipped product versions, teams have a stronger starting point for answering “are we affected? without an afternoon of archaeology through CI logs.

ActiveState publishes a five-business-day remediation SLA for critical CVEs once an upstream fix is available. Your team still needs to integrate, test, and deliver the updated component, while meeting its reporting obligations.

What the enforcement sequence actually looks like

The fine gets the headline. Up to €15 million or 2.5% of worldwide annual turnover, whichever is higher, for the most serious violations. But the number that matters more in the boardroom is the sequence: a market surveillance authority can restrict EU product sales while an investigation is still open, and that restriction isn't tied to a fine being issued first. That's a revenue conversation with no predictable end date, not a line item on a compliance budget.

I want to be direct about one thing here: none of this is legal advice, and I'm not a lawyer. Whether CRA applies to your specific products, what tier of obligation you fall into, and how your organization should respond are determinations for your legal team to make. What I can speak to is what I'm consistently hearing from security leaders preparing for September, and where the operational gaps tend to sit.

Where to start if you haven't

Start with one shipped product and a response exercise:

• Assign an owner and backup. Confirm who assesses reportability, approves the notification, and submits it including outside business hours.
• Trace the components. Check whether your inventory identifies direct and transitive dependencies and connects them to shipped product versions.
• Rehearse the response. Use a hypothetical active-exploitation report to test how quickly the team identifies affected releases and assembles an initial notification.
• Record the gaps. Give each unresolved issue an owner and a due date.

Use the exercise to establish what works today and what needs attention next.

Talk to an ActiveState expert about where your organization stands.