Two instincts are leading small software vendors astray on the EU's Cyber Resilience Act (CRA).

The first instinct: "The deadline is late 2027 — I have time." The second: "This is only for Microsoft and Siemens."

Both are wrong, and the calendar is the reason. The CRA was adopted on 10 October 2024 and entered into force on 10 December 2024. But it doesn't switch on all at once. The notification duties under Article 14 apply from 11 September 2026 — already in the past. The remaining product requirements — conformity assessments, CE marking, the full documentation package — follow on 11 December 2027.

That split timeline is the whole story. The part of the CRA that can hurt you first isn't the paperwork in 2027. It's the reporting duty that's live right now.

What "already live" actually means

Article 14 requires manufacturers of products with digital elements to notify authorities when they become aware of an actively exploited vulnerability in their product — or a severe incident affecting its security. The timeline is brutal by normal support-desk standards:

An early notification within 24 hours of becoming aware. A fuller notification within 72 hours. A final report within one month.

And this applies to any product with digital elements sold commercially in the EU — your SaaS, your WordPress plugin, your desktop app, your dev tool. Not just the giants.

The penalties underline the point: up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Three things worth doing now

Almost everything the CRA asks of you early is operational, not legal. You don't need a law firm; you need a release process that produces evidence.

1. Build the SBOM into your release pipeline. For every release, generate a machine-readable inventory of what you shipped — every dependency, every version. CycloneDX is the pragmatic format. Do it in CI so it happens whether or not anyone remembers.

2. Keep evidence of what you ship and how long you support it. Archive each release's SBOM, record your stated support period, and keep incident records. When a regulator — or an enterprise customer — asks what was in version 4.8.0 and whether it was still supported, the answer should be a file, not a memory.

3. Set up a vulnerability intake and response process. Publish a security contact point, define who triages reports, and set internal deadlines that beat the regulatory ones. The 24-hour clock starts when you become aware — so "becoming aware" needs to be a defined process, not an accident.

The bottom line

The CRA rewards vendors who can show their work. Start with the release pipeline: if every release produces an SBOM and an archive entry, you're most of the way to the evidence trail the regulation assumes you have.

If you sell software in the EU, what does your current evidence trail look like? Send me a line or two about how you track releases today — no call, I'm just collecting patterns across small vendors. And if you'd rather automate the whole thing, the founding beta is open: https://getwaybill.io/founding-beta.

Sources