The Cyber Resilience Act, formally Regulation (EU) 2024/2847, is the European Union’s framework for the cybersecurity of products with digital elements. Its objective is clear: to ensure that software and hardware products placed on the EU market are designed, developed, documented, supported, and maintained in line with cybersecurity requirements throughout their lifecycle.

While the regulation entered into force in late 2024, its application is progressive, with three key dates now approaching: 11 June 2026, 11 September 2026, and 11 December 2027.

To prepare properly, manufacturers need to understand who is in scope, which obligations matter most, how conformity assessment works, and what needs to be in place before enforcement fully begins.

Who the CRA applies to

The CRA applies to products with digital elements placed on the EU market. In practice, that means software, hardware, and some related remote services that are necessary for a product to function.

The regulation primarily targets manufacturers, but importers and distributors also have obligations as part of the chain bringing those products to market.

Not all products are treated the same way under the CRA. The regulation distinguishes between several categories, with different levels of requirements and conformity assessment:

• Default products: the standard category for most software and hardware products with digital elements.

• Important products — Class I: products such as operating systems, browsers, password managers, VPNs, routers, SIEMs, smart home security products, and connected toys.

• Important products — Class II: higher-risk categories such as hypervisors, firewalls, IDS/IPS, and tamper-resistant microcontrollers.

• Critical products: the most sensitive categories, including hardware security devices such as HSM-like products, smartcards, and smart meter gateways.

These categories matter because the CRA does not apply in exactly the same way to every product: the level of scrutiny and the conformity assessment route depend on where a product falls.

What you actually have to do

The CRA is not just about building more secure products. It also creates concrete obligations around vulnerability handling, reporting, user communication, and documentation.

1. Build and maintain secure products

Products placed on the EU market must meet baseline cybersecurity requirements by design: secure-by-default configurations, access controls, data protection, resilience, logging, and security updates.

The regulation also requires manufacturers to assess cybersecurity risks, document that assessment, and keep it updated during the product’s support period.

2. Put vulnerability handling on formal rails

The CRA treats vulnerability handling as a continuous process. Companies placing product on the EU market must identify components, track vulnerabilities, remediate them without delay, test security regularly, and distribute updates securely.

It also requires a coordinated vulnerability disclosure policy, as well as measures to facilitate vulnerability reporting, including a contact address and a clear single point of contact.

3. Report actively exploited vulnerabilities and severe incidents

From 11 September 2026, manufacturers will have to report actively exploited vulnerabilities and severe incidents having an impact on the security of the product through ENISA’s Single Reporting Platform (SRP).

The reporting timeline is staged:

• within 24 hours: early warning

• within 72 hours: notification with initial details

• later: a final report, depending on whether the event is a vulnerability or an incident

This reporting goes from the SRP to the designated national CSIRT coordinator and to ENISA.

4. Inform users, not only authorities

The CRA does not stop at regulatory reporting. Under Article 14(8), once a manufacturer becomes aware of an actively exploited vulnerability or a severe incident, it must also inform impacted users, and where appropriate all users, of the issue and of any mitigation or corrective measures they can take.

That matters because CRA compliance is not only about sending a report to authorities. It is also about being able to communicate clearly, quickly, and in a usable format to the people affected.

How CRA assessment actually works

1. The same legal base, different levels of scrutiny

All in-scope products are subject to the CRA’s essential cybersecurity requirements. In practice, that means two things:

• product requirements: the product itself must be designed, developed, and maintained securely

• process requirements: the manufacturer must have formal vulnerability handling processes in place

Those requirements come from Annex I of the CRA:

• Part I covers the product itself: secure-by-default settings, access control, data protection, resilience, logging, updates, and reduced attack surface

• Part II covers vulnerability handling: identifying components, tracking vulnerabilities, issuing security updates, coordinated vulnerability disclosure, secure update delivery, and related processes

So the question is not whether Annex I applies. It does.

The real difference between categories is how conformity is assessed.

2. The CRA uses three main assessment routes

The CRA relies on three main conformity assessment routes, called modules:

• Module A: the manufacturer assesses conformity itself

• Modules B + C: a notified body examines the product design, then the manufacturer ensures production remains aligned with that approved design

• Module H: a notified body assesses the manufacturer’s quality system as a whole

a. Default products: mostly self-assessed

As defined earlier in this article, this is the broad default category for most products with digital elements, including many software and hardware products that are neither listed as important nor critical.

These products must still comply with Annex I. But in most cases, the conformity route is Module A.

That means the manufacturer assesses compliance internally, prepares the technical documentation, draws up the EU declaration of conformity, and affixes the CE marking.

No notified body is required by default.

b. Important products: the higher the risk, the less self-assessment is enough

For important products, the logic becomes stricter.

• For Class I important products (see list in part 1)

  • self-assessment may still be possible under Module A, but only if the manufacturer relies on a recognised route for presumption of conformity, such as harmonised standards, common specifications, or an applicable European cybersecurity certification scheme.

  • If that is not the case, the product must go through a third-party conformity route.

• For Class II important products (see list in part 1)

  • self-assessment is no longer the normal route. These products require a stricter assessment path involving a notified body, or an applicable certification route.

  • In practice, conformity must go through Modules B + C or Module H, unless a relevant certification route applies where the regulation allows it.

That is the practical takeaway:

the more sensitive the category, the less the CRA lets you rely on internal assessment alone.

c. Critical products: the highest level of scrutiny

For critical products, the CRA applies the highest level of scrutiny.

These products do not follow Module A. They must go through a stricter route: either Modules B + C, Module H, or, where the Commission makes it applicable through delegated acts, a European cybersecurity certification scheme at the required assurance level.

So critical products are not limited to Module H. The key point is that they require a third-party or certification-based route, with possible mandatory certification depending on future delegated acts.

d. In short

The hierarchy is:

• Default products → often Module A

• Important Class I → Module A possible, but not always

• Important Class II → Modules B + C, Module H, or certification

• Critical products → Modules B + C, Module H, or certification, with possible mandatory certification depending on delegated acts

Getting ready before enforcement bites

The CRA does not switch on all at once. But the sequence now matters.

1. Three dates to keep straight

• 11 June 2026: the CRA’s conformity assessment provisions start applying

• 11 September 2026: Article 14 reporting obligations start applying

• 11 December 2027: the regulation applies in full

These dates do not mean the same thing. June is about the assessment framework starting to operate. September is about mandatory reporting for actively exploited vulnerabilities and severe incidents. December 2027 is when the broader CRA regime fully applies.

2. What companies should have ready before each step

Before June 2026, the priority is to know where each product sits: default, important Class I, important Class II, or critical. That determines the conformity route and whether self-assessment is enough or whether a notified body may be needed.

Before September 2026, manufacturers need to be operationally ready for Article 14 reporting: identifying what must be reported, meeting the 24-hour and 72-hour deadlines, and knowing which national CSIRT coordinator they report to through ENISA’s Single Reporting Platform.

Before December 2027, the broader picture has to be in place: secure product design, vulnerability handling processes, documentation, support period logic, user information, single point of contact, and the ability to communicate clearly when something goes wrong.

3. What happens if you do not

The CRA is backed by real enforcement powers.

Non-compliance can lead to corrective measures, restrictions on placing products on the EU market, product withdrawal or recall, and administrative fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher.

Where Tacit fits

Tacit helps software vendors implement some of the most concrete communication and disclosure requirements introduced by the CRA.

It helps teams:

• inform customers and users clearly when vulnerabilities affect their products, especially when mitigation steps or corrective measures need to be shared quickly;

• provide a clear and identifiable point of contact for vulnerability-related communication, directly from the publisher page;

• receive CVD-related communications on the platform, then assess, track, and update them in a structured way over time;

• keep vulnerability statements, remediation status, and affected versions structured, traceable, and easy to update.

• host their coordinated vulnerability disclosure policy in a visible and accessible place;

Tacit is built for the operational side of CRA compliance: turning vulnerability communication into something clear, structured, and usable for both internal teams and external audiences.