The Cyber Resilience Act is now in force: what your team needs running since September 11

There’s a date on the European regulatory calendar that turns a technical problem into a legal one: September 11, 2026. From that day on, any manufacturer placing products with digital elements on the European Union market is required to report actively exploited vulnerabilities and severe incidents affecting the security of their products — with an early warning within the first 24 hours of becoming aware.

If your company sells software in the EU — a SaaS with a product component, an application, a device with firmware, a commercial library — this applies to you. And the uncomfortable part isn’t the notification form: it’s everything that has to already exist in your organization for that form to be fillable in 24 hours.

What exactly the CRA requires since September

The Cyber Resilience Act entered into force in December 2024 with a staggered timeline. The main obligations — essential cybersecurity requirements, CE marking, conformity assessment — apply from December 11, 2027. But the reporting obligations arrived more than a year earlier, on September 11, 2026, and work like this:

24 hours to submit an early warning from the moment the manufacturer becomes aware of an actively exploited vulnerability or a severe incident.
72 hours for the full notification, including the risk assessment and any corrective or mitigating measures taken or planned.
Final report no later than 14 days after a corrective measure is available (vulnerabilities) or one month after the notification (severe incidents).

Reports are submitted once, through the Single Reporting Platform (SRP) operated by ENISA, and reach both the CSIRT of the member state where the manufacturer has its main establishment and ENISA itself simultaneously. The platform has been operational since September 11; throughout June 2026 ENISA published registration instructions, training materials and dry-run support, and on March 3, 2026 the Commission published its first substantive interpretative guidance on the regulation.

Two nuances that surprise many teams. First: the obligations are not limited to new products — they also cover products already placed on the EU market before the regulation fully applies. Second: non-compliance with the essential requirements and the obligations in Articles 13 and 14 can be sanctioned with fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher (Article 64).

For the open source ecosystem there’s a relevant exemption: open-source software stewards — foundations and entities supporting free software development without commercializing it — sit outside the fine regime. If you monetize the software, however, you’re a manufacturer in every respect. An Open Core model like ours falls on the commercial side of that line, and we accept that plainly: the obligations apply.

The real problem isn’t the form — it’s the clock

Read it again: 24 hours from becoming aware. This is what the calendar of a real case looks like:

# Timeline of a CRA notification — actively exploited vulnerability

T+0h    Word breaks that a CVE in your authentication dependency
        is being exploited in the wild
T+2h    Your continuous scanning flags the finding on `main`
        → from this point on, you are "aware"
T+24h   ━━ Deadline: early warning to the SRP ━━
T+72h   ━━ Deadline: full notification (assessment + measures) ━━
T+14d   ━━ Deadline: final report after the corrective measure ━━

The regulation doesn’t require you to know everything instantly — the clock starts when you become aware of the problem. But that wording cuts both ways: your detection tooling determines when you “know”, and an organization that scans once a quarter isn’t protected by its own blindness — due diligence includes having a reasonable capability to find out. In practice, the deadline pushes the pressure upstream, to the prior question: how long does it take you to find out that a vulnerability in your product is being exploited?

Answering that within a useful timeframe requires having at least four capabilities solved in advance:

A continuous vulnerability inventory. When word breaks that a CVE is being actively exploited, the first question is “does it affect us?” — and the answer requires knowing which dependencies, at which versions, live in which products and on which branches. If getting that answer means cloning repositories and launching ad hoc scans, the 24 hours evaporate in the fact-finding phase. Continuous SCA scanning (OSV-Scanner, in Gerion’s pipeline) turns that question into a query against data that already exists.

Distinguishing production from development. The notification concerns the marketed product — the code your customers actually run. You need to filter findings by branch and separate what’s on main or release branches from what lives on a half-finished feature branch. That distinction — the same one that drives Gerion’s 10× financial multiplier — is exactly what delimits the scope of a CRA notification.

An auditable history. The final report asks for a chronology: when it was detected, what was assessed, what corrective measure was applied and when. A findings register with states and dates — detected, in remediation, mitigated, closed — is the difference between writing the report by querying data and reconstructing it by interviewing people. Documented diligence is also your best defense if the market surveillance authority comes asking.

Control over sensitive data. Few things are more delicate than the list of unpatched vulnerabilities in your product: it is, quite literally, an attack map. Under the CRA that information also acquires legal weight. That’s a strong argument for reducing what travels: with Gerion, your code doesn’t leave your CI, and only findings metadata (severity, type, path, line, rule message, and git context) reaches the platform — a SaaS on European infrastructure — never code. Even so, that list is sensitive information: decide who you share it with and under what conditions.

If you don’t have this running yet

The 24-hour clock is already ticking — but it’s not too late to catch up. A realistic plan:

Determine whether you’re a manufacturer under the CRA. If you place products with digital elements on the EU market in the course of a commercial activity, almost certainly yes. The Commission’s March guidance is the most authoritative reference for edge cases.
Set up continuous scanning now, not when the first incident hits. The CRA value isn’t the point-in-time scan — it’s the accumulated history that lets you answer “since when has this affected us?” with data.
Define the notification runbook. Who decides a finding is reportable, who writes, who submits to the SRP. With a 24-hour deadline, the process can’t be improvised mid-incident.
Register with the SRP and join the dry runs. ENISA has published instructions and materials. One internal dry run as soon as possible is worth more than any process document.

September is the dress rehearsal for December 2027

The reporting obligations are only the first phase. On December 11, 2027 the rest of the regulation enters into application: verifiable essential cybersecurity requirements, vulnerability management across the product’s entire lifecycle, technical documentation including a component inventory, and CE marking as a condition of market access.

The relationship between the two dates is not accidental. Everything you build to comply with reporting — continuous scanning, a dependency inventory, a findings register with history — is infrastructure the 2027 phase takes for granted. Teams that treat September as an isolated formality will have to rebuild the same muscle in fifteen months, this time with a conformity assessment in the middle. Teams that treat it as the first piece of the full program arrive at 2027 with half the work already done.

The less cynical reading

It’s easy to read the CRA as bureaucracy with fines attached. The more useful reading is different: everything it demands — continuous vulnerability inventory, prioritization with production context, remediation history, rapid response capability — is what a mature product security program does anyway. The regulation doesn’t ask for anything you wouldn’t want to have; it asks that you have it demonstrably, with a deadline.

Teams that reached September 11 with that infrastructure running aren’t experiencing the CRA as a burden. If yours isn’t there yet, now is the moment to build it — you’ll experience it as the first time your security work translates directly into an obligation the business understands without explanation.