INSIGHTS · REGULATION

The CRA's first deadline is 11 September. It asks for less than you've been told.

Leighton Wilson, Indura Labs

Reviewed 4 September 2026. Two points in this guide are still unsettled and are flagged as such rather than guessed at.

If you make anything with software in it and sell it in the EU, you have probably been told that you need a vulnerability handling process, an SBOM and a disclosure policy in place by 11 September 2026. That is not what the regulation says. The September date brings in one obligation, reporting, and the systemic requirements that everyone is worried about do not arrive until December 2027. The distinction matters, because preparing for the wrong one wastes the fifteen months you have.

Two dates, routinely conflated

	11 September 2026	11 December 2027
What applies	Article 14 reporting duties	Article 13 obligations and the Annex I essential requirements
Nature	Event-triggered. Nothing happens until something happens.	Systemic. Applies to the product and the process continuously.
Includes	Reporting actively exploited vulnerabilities and severe incidents	Vulnerability handling, security updates, SBOM, technical documentation, conformity assessment, CE marking
If nothing is being exploited	You have nothing to file	You are still non-compliant if the requirements are unmet

The claim that you need full vulnerability handling by September is wrong, and it is being repeated by people selling readiness services. Vulnerability handling sits in Annex I and is not binding until 11 December 2027. What applies from 11 September is the duty to report, and it only triggers if you become aware of an actively exploited vulnerability or a severe incident. If neither happens, Article 14 asks nothing of you.

That is not an argument for doing nothing. A reporting duty you cannot execute is still a reporting duty, and the clock starts from awareness rather than from when your process is ready. But the honest version is that you need a route to file and someone who knows they own it, not a compliance programme.

What actually triggers a report

Two events, and both have a narrower definition than the everyday use of the words.

An actively exploited vulnerability. There has to be reliable evidence that a malicious actor has exploited it in a system without the owner's permission. Real-world exploitation, not proof-of-concept code, not a high CVSS score, not a theoretical path.
A severe incident having an impact on the security of the product: one that significantly affects the security of your users, or significantly disrupts your own operations.

What does not trigger it: a routine vulnerability report arriving through your disclosure inbox with no evidence of exploitation, a low-severity bug, or a vulnerability you found yourself and quietly fixed. The bar is exploitation and severity, not discovery.

The clock

24 hours from becoming aware: an early warning.
72 hours from becoming aware: a fuller notification, including any corrective or mitigating measures taken.
Final report. For a vulnerability, no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, within one month of the 72-hour notification.

"Becoming aware" is the part worth thinking through in advance. If a customer emails your support address on a Friday afternoon with evidence of exploitation, the 24 hours runs from then, not from when the message reaches somebody who understands it. That is a routing problem, and it is solvable this week without any tooling.

Where the report goes

Filing is single-entry. You submit once through ENISA's Single Reporting Platform, and it reaches both ENISA and the CSIRT designated as coordinator for your member state at the same time. That CSIRT then handles onward circulation to other member states where your product is available. You do not file separately with every national authority.

Working out which CSIRT is yours follows the place of main establishment, meaning where decisions about your products' cybersecurity are predominantly taken. If that is genuinely ambiguous, it falls to the member state where you have the most EU employees. Manufacturers outside the EU report where their authorised representative is established.

Two things that are still unsettled, in Sweden specifically

This is the part most international explainers skip, and it is where a Swedish manufacturer is actually exposed.

Sweden has not finished its national implementing legislation. The complementary Swedish provisions for the CRA have been through consultation, with industry bodies including Energiföretagen Sverige raising unresolved questions about scope and about overlap with obligations they already carry under Cybersäkerhetslagen. Market surveillance arrangements follow from that legislation. Finland, by comparison, has already concentrated CRA market surveillance in a single authority. Sweden's position is worth confirming rather than assuming.

The list of designated coordinator CSIRTs was still outstanding as of mid-2026. CERT-SE is Sweden's national CSIRT function, and it now sits with NCSC at FRA following the transfer of cyber functions on 1 July 2026. Whether it is formally designated as Sweden's coordinator for CRA purposes is not something I have been able to confirm from a primary source, and ENISA had indicated the full list would come later.

Practical version: confirm your reporting route before you need it, not during a 24-hour clock. Register on the platform, identify your coordinator CSIRT and complete whatever authorisation check it requires, because that check is manual, varies between CSIRTs, and happens on first access rather than in advance. Finding out who to file with while the clock runs is the failure mode worth designing out.

Are you even a manufacturer?

More organisations are than expect to be, and the CRA's definition does not track the everyday one. You do not have to run a factory.

If you develop software and place it on the EU market, you are a manufacturer of a product with digital elements.
If you put your own name or trademark on someone else's product, you generally take on manufacturer obligations for it. White-labelling is not a way of staying out.
If you substantially modify a product, including by adding functionality or reconfiguring its software, you can become the manufacturer of the modified product.

That third case is a live grey zone in Sweden rather than a settled question. Energiföretagen raised exactly this in consultation, using electricity meters as the example: an energy company that configures the software, adds functionality and applies its own branding may or may not become a manufacturer carrying full CRA responsibility, and they asked for clearer definitions. If your business involves integrating, configuring or rebranding other people's hardware, this question is worth resolving deliberately.

Legacy products are in scope

The reporting duty is not limited to products you launch after September. Article 69(3) extends Article 14 to products with digital elements placed on the EU market before the regulation applies in full, and Commission guidance has confirmed it. A product shipped in 2019 and still in use counts. A product past the end of its support period still counts while it remains in use.

The practical implication is that the portfolio you have to be able to report on is larger than the one you are actively developing, and it is probably larger than the list anybody at your company keeps.

What is actually worth doing before next Friday

Proportionate to the obligation, which is a reporting duty rather than a programme:

Decide who owns it. One named person who knows the 24-hour clock exists and has authority to file.
Fix the routing. Make sure a report of exploitation reaching support, sales or a shared inbox gets to that person the same day, including at a weekend.
List the products. Everything with digital elements you have placed on the EU market, including legacy and end-of-support. This is usually the longest job and the one that cannot be done under time pressure.
Confirm the route. Identify your coordinator CSIRT and get platform access sorted before you need it.

None of that requires an SBOM, a vulnerability handling process, or a conformity assessment. Those matter, and they are due in December 2027, which is a separate piece of work with a separate deadline.

What I am not certain about

Two things in this guide are open rather than settled, and I would rather flag them than write around them. Sweden's national implementing provisions were not finalised at the time of writing, and Sweden's formally designated coordinator CSIRT under the CRA is not something I could confirm from a primary source. Both are worth checking against ENISA and the Swedish government's own publications before you rely on them. If you find a primary source that settles either, send it and this page gets updated with a note.

This is a starting point, not a legal determination. If the useful question for you is whether you count as a manufacturer at all, that is a scope question, and scope questions are the kind of work I do.

Ask a scope question → Reporting clock → Read the NIS2 vs DORA guide →