The CRA Deadline You Can’t Ignore: What Every Company Needs to Fix Before September 2026

Security teams have spent the last few years getting used to regulations that ask them to prove something after the fact: show us your patch history, show us your audit trail, show us what happened during the incident. The Cyber Resilience Act changes that rhythm entirely. It doesn’t just ask you to keep records. It asks you to report an actively exploited vulnerability within 24 hours of discovering it.

That’s not a compliance checkbox. That’s an operational demand, and most organizations aren’t built to meet it yet.

This Isn’t a Regional Problem, It’s a Market Access Problem

The first instinct for a lot of security and compliance teams is to assume the CRA is someone else’s problem. It’s EU legislation, so it must be an EU company’s headache, right?

Not quite. The CRA applies based on where your product ends up, not where your company is headquartered. If you manufacture, import, or distribute a product with digital elements, hardware, software, SaaS, IoT, connected devices, and that product lands on the EU market, the CRA applies to you. It doesn’t matter if your engineering team sits in Austin, Manchester, or Munich.

If you’ve been through GDPR, this pattern will feel familiar. The EU doesn’t regulate where you’re from. It regulates where your product goes.

The clock on the CRA’s first major obligation starts ticking on September 11, 2026. From that date forward, manufacturers, importers, and distributors of in-scope products must notify ENISA and their national CSIRT whenever they discover an actively exploited vulnerability or a severe security incident. That date is closer than most compliance calendars reflect.

The Reporting Clock That Catches Everyone Off Guard

Here’s where the CRA stops being a policy document and starts being an operational problem.

Once the reporting obligation kicks in, the timeline looks like this:

• 24 hours to file an early warning with ENISA and your national CSIRT, starting the moment you become aware of an actively exploited vulnerability or severe incident.
• 72 hours to submit a fuller notification, including the corrective or mitigating measures you’ve taken so far.
• 14 days to submit a final report once a remediation is available, for actively exploited vulnerabilities. Severe incidents get a slightly longer window: a final report within one month of the 72-hour notification.

Read that first number again. Twenty-four hours. That’s not a lot of runway if your process for identifying, triaging, and escalating a vulnerability still involves a spreadsheet, an email chain, and someone waiting for a ticket to get picked up. The regulation doesn’t care what timezone your security team works in or how many tools are feeding it alerts. The clock starts the moment you know, and it doesn’t pause for the weekend.

What Actually Triggers the Clock, And Why Most Teams Aren’t Ready

“Actively exploited vulnerability” and “severe incident” sound like straightforward terms until you try to operationalize them. Who decides when a vulnerability crosses from theoretical to actively exploited? What does your team do in the first hour after that determination gets made? If the answer is “we’d figure it out,” that’s a gap worth closing well before September.

There’s also a quieter dependency hiding underneath all of this: you can’t report on a vulnerable component you can’t see. The CRA’s formal SBOM mandate doesn’t land until December 2027, but in practice, you need component-level visibility long before that. Accurate SBOMs are what make it possible to identify an exploited component and report on it within 24 hours in the first place. Waiting until the 2027 deadline to build that visibility means walking into the September 2026 reporting requirement blind.

This is exactly the kind of gap that breaks manual remediation processes. When findings live in five different tools, ownership is unclear, and someone has to manually chase down which team owns which asset, a 24-hour SLA isn’t a stretch goal. It’s not achievable.

The Classification Maze

Not every product hits the same deadline, and the classification system is worth understanding before you assume you have more runway than you actually do.

Horizontal (type A) products face a compliance deadline of August 30, 2026. Vertical (type C) and horizontal (type B) products have until October 30, 2026. That second date creates an odd sequencing problem: the majority of the harmonized standards that translate the CRA’s requirements into specific, actionable practices aren’t expected to be published until that same October 30, 2026 date. In other words, some organizations will be expected to comply with technical requirements before the technical guidance clarifying those requirements is even public.

That’s not a reason to wait. It’s a reason to start building the foundational pieces now, the vulnerability monitoring, the SBOM visibility, the internal escalation process, so you’re not scrambling to interpret new standards and hit a compliance deadline in the same quarter.

What Non-Compliance Actually Costs

The penalties attached to the CRA are steep enough to get a board’s attention. Non-compliance can result in fines up to the greater of €15 million or 2.5% of global annual turnover. For a mid-market software or hardware company, that’s not a line item. That’s the kind of number that turns a security team’s roadmap into a boardroom conversation.

A 90-Day Readiness Checklist

If September 2026 is on your radar now, here’s where to start:

• Map your exposure. Identify every product or service that touches the EU market, whether directly or through a partner or distributor.
• Stand up vulnerability monitoring aligned to Article 14, so you have a defined process for identifying and escalating actively exploited vulnerabilities.
• Define your internal triggers. Decide, in writing, what separates an actively exploited vulnerability from a severe incident, and who has the authority to make that call.
• Build and validate your SBOMs now. Don’t wait for the 2027 mandate. You need this visibility to meet the 2026 reporting requirement.
• Update supplier and distributor contracts so CRA obligations are reflected through your supply chain, not just inside your own walls.
• Stress-test your tooling. Could your team actually produce a compliant report within 24 hours today? If the honest answer is no, that’s your starting point.

Findings Aren’t the Hard Part. Action Is.

The CRA isn’t really a detection problem. Most organizations already have the scanners, the alerts, and the vulnerability data. What the CRA exposes is the gap between finding a problem and actually doing something about it, on a clock that doesn’t leave room for manual coordination.

That’s the gap Seemplicity is built to close. Seemplicity fuses exposure management and autonomous response to help security teams get ahead of AI-era attacks, not just react to them. Seemplicity’s Agentic Exposure Action Platform™ closes the gap between finding an exposure and actually fixing it, moving beyond static rules to investigate, guide fixes, and initiate remediation response across identity, cloud, and IT ecosystems. Instead of a security analyst manually chasing ticket status across five tools while a 24-hour reporting clock runs out, Seemplicity gives teams the context to act at the pace regulations like the CRA now demand.

A 24-hour SLA isn’t survivable with spreadsheets and email threads. It’s survivable with a system that closes the gap between finding an exposure and resolving it, with accountability built in from the start. That’s what regulations like the CRA are really asking organizations to prove: not just that you found the problem, but that you can act on it fast enough to matter.