The CRA Deadline Nobody Talks About: What September 11 Means If You Ship or Bundle Any Software

Ask most IT people what regulation they're worried about and you'll hear the same two acronyms: NIS2 and DORA. Fair enough. Both have swallowed a lot of column inches over the past year. But there's a third date that has slipped under the radar, and for anyone who writes, bundles, customises or resells software, it matters more than you might think.

The date is 11 September 2026. On that day, the vulnerability-reporting obligations of the EU's Cyber Resilience Act (CRA) become enforceable. Not the full weight of the Act — that lands later, on 11 December 2027 — but the reporting duties specifically. And those duties come with 24-hour and 72-hour clocks that assume you already have processes in place. If you're starting from zero in August 2026, you're already too late.

The reason this deadline has been so quiet is partly Brexit. Plenty of UK businesses assume EU rules don't apply to them any more. For a lot of software, that assumption is wrong.

Wait — why does an EU law apply to a Nottingham SME?

The CRA governs "products with digital elements" placed on the EU market. It doesn't care where the company is based. It cares whether your product ends up in the hands of an EU customer.

So if you sell a piece of software, a connected device, or a cloud-connected tool to a customer in Dublin, Amsterdam or Berlin, you're potentially in scope. Even if that customer found you through a reseller. Even if the EU sale is a small slice of your revenue.

The law also stretches the word "manufacturer" much further than most people expect. You don't need to have built something from scratch to count as one. And that's where a lot of UK SMEs and IT providers are about to get a surprise.

The scoping test: are you a "manufacturer" under the CRA?

Here's a plain-English version. Work through it honestly.

1. Do you develop software or a connected product and sell it commercially? Obvious yes. A SaaS product, a mobile app, an IoT device — all in scope. If you charge for it and it has digital elements, assume the CRA applies.

2. Do you take someone else's software, change it, and put your name on it? This is the big one. If you take an open-source tool, a white-label platform or a third-party product, customise it, and sell or supply it under your own brand, the CRA treats you as the manufacturer of that modified product. The obligations shift to you.

3. Do you bundle multiple products together and sell them as one package? A managed IT provider that assembles a security bundle, a monitoring dashboard and a backup tool into a single branded offering may be creating a new product in the eyes of the regulation. Bundling isn't a free pass.

4. Do you "substantially modify" a product you resell? Straight resale of an unmodified product generally keeps you out of manufacturer status — you'd more likely be an importer or distributor, which carries lighter duties. But the moment you make a substantial change to how the product works, you can become the manufacturer.

5. Does any of the above reach an EU customer? If yes to any of 1–4 and yes to this, you're likely in scope.

A quick real-world illustration. Say you run a small dev shop in Beeston. You take an open-source booking engine, rebrand it, add a payment integration and a custom admin panel, and sell it to a chain of clinics — some of which have branches in the Republic of Ireland. Under the old way of thinking, you're "just using open source". Under the CRA, you're the manufacturer of a product with digital elements that's on the EU market. The vulnerability-reporting clock applies to you.

What actually happens on 11 September 2026

From that date, if you're a manufacturer under the CRA, you must report:

• Actively exploited vulnerabilities in your product — an early warning within 24 hours of becoming aware, then a fuller notification within 72 hours.
• Severe incidents affecting the security of your product, on similar timescales.

Reports go to a central platform coordinated through ENISA and the relevant national CSIRT. There's also a final report due within 14 days of a corrective measure being available.

The key word in all of this is "aware". The clock starts when you find out, not when it's convenient. That's impossible to meet if you have no way of receiving vulnerability reports in the first place, no triage process, and no idea what components sit inside the products you ship.

The two things most SMEs are missing

When we look at how ready smaller businesses are, two gaps show up again and again.

No SBOM. A Software Bill of Materials is a list of every component, library and dependency inside your product — the ingredients label, essentially. The CRA doesn't force you to publish your SBOM, but you're expected to maintain one and be able to produce it. Without it, you can't answer the basic question a vulnerability report raises: "Are we affected?" When Log4Shell hit in late 2021, the companies that coped were the ones who could search their SBOMs and get an answer in minutes. Everyone else spent a fortnight guessing.

No vulnerability-disclosure process. Most SMEs have no published way for a security researcher — or a customer, or a passer-by — to tell them about a flaw. No security.txt file, no dedicated inbox, no owner. If someone finds a hole in your product and can't reach you, that's not just embarrassing. Under the CRA it undermines your entire compliance position, because your reporting obligation depends on you being able to become aware in an orderly way.

A pre-deadline checklist

You have time, but not a lot of it. Here's a sensible order of work.

1. Run the scoping test above for every product you ship. Write down the answer for each. Don't rely on "we're probably fine".
2. Confirm your EU exposure. Check your customer list and reseller arrangements. One EU customer is enough to matter.
3. Build an SBOM for each in-scope product. Tools like Syft, CycloneDX and SPDX generators can produce one automatically from most codebases. Get it into your build pipeline so it stays current.
4. Set up a vulnerability-disclosure channel. At minimum: a monitored security@ email address, a published security.txt file, and a named person responsible for triage.
5. Write a simple intake-and-triage runbook. Who receives a report, who assesses severity, who decides whether it's an actively exploited vulnerability, and who files the notification. Practise it once before you need it.
6. Map the 24/72-hour clock into your process. Make sure someone can act within those windows, including out of hours.
7. Review your open-source and third-party components. If you're re-shipping other people's code, you inherit their vulnerabilities. Know what you're carrying.
8. Document everything. The CRA rewards demonstrable process. A lightweight but written approach beats a sophisticated one that lives in someone's head.

Don't let the loud acronyms drown this one out

NIS2 and DORA are important, but they hit fairly defined groups — essential services and financial entities. The CRA's reach is wider and quieter, precisely because it catches ordinary businesses that never thought of themselves as software manufacturers.

If you bundle, customise or resell anything with digital elements, and any of it touches the EU market, spend an afternoon on the scoping test now. Getting an SBOM and a disclosure process in place is a few weeks of work, not a few days. September 2026 will arrive faster than it looks, and it's not a date you can negotiate.

If you're not sure which side of the line you fall on, that's exactly the kind of question worth answering before the clock starts, not after. We're happy to walk through it with you.