ActiveState

Under the EU CRA, one question decides whether you keep access to the EU market:

Can you prove what's inside your product?

The majority of modern products are open source code your team didn't write. Under the EU CRA, security teams must prove exactly what's inside them and that every package is accounted for, on demand.

EU CRA's Article 14 reporting obligations have been in force since September 11, 2026. They require manufacturers to report actively exploited vulnerabilities and severe incidents on every product already on the market, not just new releases. If your reporting pipeline isn't operational today, you're already inside a live enforcement window.

The reporting is time-boxed: a 24-hour early warning, a 72-hour full notification, and a 14-day final report once a corrective measure is available, filed to your national CSIRT through the ENISA Single Reporting Platform.

The next deadline is December 11, 2027, and requires full CRA compliance. It means you'll need a technical documentation file, a defined security update support period, and secure-by-design product architecture.

This reflects our current understanding of EU CRA and is not legal advice. Confirm scope and applicability for your products with your legal team.

Under the EU CRA, a critical vulnerability in your product creates four obligations that are active today, and scanner tooling alone can't cover them.

EU CRA Incident Console / Incidents / INC-4410
Critical vulnerability CVE-2026-3391 Report readiness: 0 of 4 fields complete
EU CRA required field
Product and component affected
No match
System of record SBOM manager

No confirmed match for this component in current inventory.

EU CRA required field
Date identified
Not logged
System of record SIEM · Monitoring

First detection timestamp not logged in ticket.

EU CRA required field
Action taken
Unsigned
System of record Change mgmt · CM-4410

Signed off by: — unsigned —

EU CRA required field
Time to resolution
Still open
System of record SLA tracker

9 of 14 remediation days used. Still open.

Day 9 of 14

The 24-hour clock is already running. It starts the moment you become aware of a vulnerability in your product

Miss it, and you risk EU CRA enforcement action.

Most teams don't maintain a record of every component in their product. Since September 11, 2026, that gap is a 24-hour deadline, not a future one. Miss the window on an actively exploited vulnerability, and a market surveillance authority can restrict EU sales of the product for the duration of an investigation, on a timeline you don't set and can't shorten.

EU CRA is enforced by national market surveillance authorities, who can require products to be brought into compliance, restrict their availability, or order withdrawal or recall from the EU market. Financial penalties alone can reach a ceiling of €15M or 2.5% of worldwide annual turnover, whichever is higher, though actual outcomes depend on the nature and duration of the infringement and regulatory discretion.

For most organizations, the market access exposure (sales restricted while an investigation runs) is the more immediate consequence than the fine, because the timeline sits with the regulator and is unknown. The EU CRA also raises the bar on product liability: a product that was non-compliant at the time of a breach and used as an attack vector is materially harder to defend.

The €15M figure is a legal maximum. This is not legal advice. Confirm your exposure with legal counsel.

Where would your team actually stand?

September 11 was the first test.

December 11, 2027, is the one that decides market access permanently.

Organizations that stood up a reporting pipeline for September 11 have a foundation. What most still don't have is the rest of the file a conformity assessor will actually ask for. The EU CRA asks for four things your program must have:

A technical documentation file that accumulates evidence continuously. Risk assessments, test records, SBOM data, and vulnerability handling history, built throughout the product lifecycle, not assembled after the fact when an assessor asks for it.

A machine-readable SBOM that goes beyond the legal minimum. The legal minimum covers direct dependencies, what your team chose by name. But 64% of open source in production sits one layer deeper, in transitive dependencies nobody chose directly, and that's usually where an exploited vulnerability turns up. Meeting the minimum and covering your actual risk are two different bars.

A defined security update support period, budgeted and committed before a vulnerability forces the decision, including components whose maintainers stop patching before your product reaches end of life.

Secure-by-design product architecture. Minimal attack surface, secure defaults, built-in access control. These are design requirements. They can't be retrofitted at audit time.

The EU CRA is sector-neutral and applies based on market access, not headquarters location: if your connected software products reach EU users, you are likely in scope regardless of where your company is based.

Legal Disclaimer: The information provided is for general informational purposes only and is not intended as legal, financial, or professional advice. You should not act upon any information without seeking professional counsel. We make no representations or warranties of any kind, express or implied, about the completeness, accuracy, reliability, or availability of the information.

'Scan and pray' programs can't meet this bar.
A governed source of open source can.

The ActiveState Curated Catalog is what makes that possible

Talk to an expert

Software inventory

Every open source component is built from source with cryptographic attestation. Provenance is producible on demand.

Inventory · SBOM manager09:12
No confirmed match in current inventory.
Product / componentNo match
Confirmed match — 12+ languages covered.
Product / componentVerified

Continuous monitoring

Disclosures are monitored for and announced as soon as they’re public.

Monitoring · SIEM09:12
First detection timestamp not logged.
Date identifiedNot logged
Detected and timestamped — 09:12.
Date identifiedLogged

Change control

Every fix contains an auditable record of what was done and when.

Change managementCM-4410
No signed remediation record on file.
Action takenUnsigned
Remediation signed and on file.
Action takenSigned

Remediation SLA

Remediation runs on a 5 business-day SLA for Critical CVEs, against 54-day industry average. A timeline you can plan on.

SLA tracker · CRA reportingSLA · Critical
9 of 14 remediation days used. Still open.
Day 9 of 14Still open
Resolved — Day 3 of 5.
Day 3 of 5Resolved

Only vetted, policy-aligned components enter your product in the first place, through the tools your team already uses, including their AI coding agents. The open source software in your product is accounted for before a question ever arrives.

Connect with our team to see how the ActiveState Curated Catalog fits your setup and closes the gap between September 11 obligations and December 11, 2027 requirements.

Talk to an expert Take the EU CRA Security Readiness Assessment

Frequently asked questions

Actively exploited vulnerabilities and severe incidents affecting products already on the EU market, filed to your national CSIRT through the ENISA Single Reporting Platform. The reporting is time-boxed: a 24 hour early warning, a 72 hour full notification, and a 14 day final report once a corrective measure is available.

The moment your organization becomes aware, not the moment a fix ships. If you don't already have a live, current inventory of every component in a product, documentation and course of action is difficult to establish.

The EU CRA distinguishes actively exploited vulnerabilities from incidents with a significant impact on a product's security, and both can trigger reporting. Where exactly that line sits for a given product is a judgment call your organization needs to be able to defend, so this is worth confirming directly with legal counsel rather than relying on a general rule.

A market surveillance authority can require the product to be brought into compliance, restrict its availability, or order withdrawal from the EU market, and financial penalties can reach €15M or 2.5% of global annual turnover, whichever is higher. For most organizations, the market access consequence, sitting on a timeline the regulator controls, is the harder one to plan around.

Not on its own. A scanner flags a vulnerability and opens a ticket; it doesn't give you an auditable record of what was in the product, when you knew, what you did, and how long it took, which is what the EU CRA actually asks for. That takes a documented workflow and a current component inventory behind it.

No, and we wouldn't claim that. What the Curated Catalog does is keep the "what's running in this product" question already answered, through continuously maintained provenance and current SBOM data, before a disclosure ever happens, which is the part of the 24-hour window most teams currently lose time to.

Take the 5-question EU CRA Security Readiness Assessment, or talk to our team directly about where the gaps are likely to be.

This reflects our current understanding of EU CRA and is not legal advice. Confirm scope and applicability for your products with your legal team.