Cyber Resilience Act (CRA) consulting: compliance for software and hardware manufacturers and suppliers

Regulation (EU) 2024/2847, the Cyber Resilience Act, entered into force on December 10, 2024, has required exploited vulnerabilities to be reported to ENISA since September 11, 2026, and will be fully applicable on December 11, 2027. It affects every manufacturer and distributor of products with digital elements sold in the EU: from desktop applications to IoT devices, routers and enterprise software. Fines reach €15 million or 2.5% of global annual turnover.

Scope your project · Assess my CRA compliance

Rather talk it through? Call us at +34 960 730 013

11-09-2026 — ENISA reporting is already mandatory, for the whole catalog
24 h · 72 h · 14 days — early warning, notification and final report
11-12-2027 — full application: Annex I, conformity and CE marking
€15M or 2.5% — maximum fine, including for failing Article 14

Does your company manufacture or distribute digital products in the EU?

If you develop software that includes client-side installable components, manufacture devices with network connectivity —IP cameras, routers, IoT devices, wearables, industrial systems—, distribute in the EU digital products manufactured outside it, or your components are integrated into other manufacturers' products, the CRA affects you directly. The regulation applies across the whole chain: manufacturer, importer and distributor. Many companies wrongly assume it only applies to hardware manufacturers, but the CRA also covers software developers with networked components, desktop applications with remote connectivity and embedded systems.

The deadline for full compliance is December 2027, but part of it already applies: since September 11, 2026, actively exploited vulnerabilities and severe incidents must be reported to ENISA. Under Article 69(3) that obligation covers the whole catalog, including products that have been on the market for years. What almost nobody has taken on board is the other side: today no CRA harmonised standards have been cited in the Official Journal and no notified bodies have been designated, so many Class I products still have no self-assessment route open.

An exploited vulnerability in your product, under Article 14

Since September 11, 2026 this is the clock that starts when someone exploits a flaw in something you sell. What decides whether you make it is not the patch: it is having agreed in advance who reports, with which account and with what data.

You become aware (Hour 0): A researcher, a customer or a threat feed tells you a vulnerability in your firmware is being exploited. The deadline runs from when you know, not from when you have fully confirmed it. Without a reporting channel or an owner, the warning gets lost in a generic inbox
Early warning (≤ 24 h): Through ENISA's single reporting platform, which forwards it at the same time to the coordinating CSIRT —INCIBE in Spain— and to ENISA. The platform is browser-only with no API: EU Login accounts with two-factor authentication must exist beforehand. The first deadline missed when nobody knows who reports
Vulnerability notification (≤ 72 h): General information about the affected product, the nature of the exploit and of the vulnerability, and the corrective or mitigating measures available, including those users can apply.
Fix and user information (Annex I · Part II): A free security update, distributed securely, and information to affected users about the vulnerability and how to mitigate it, in a structured format. With an up-to-date SBOM you know in minutes which versions and customers are affected
Final report (≤ 14 days after the fix): Description of the vulnerability and its severity, impact, information about the malicious actor where known, and details of the published update.

Why it matters: Failing Article 14 sits in the regulation's highest penalty tier: up to €15 million or 2.5% of worldwide turnover, the same as breaching the essential requirements.

Illustrative example. The deadlines are those of Article 14 of Regulation (EU) 2024/2847; for a severe incident, the final report is due within one month.

What our CRA consulting includes

Applicability analysis: we determine whether your products fall within the scope of the CRA and in which category (default, important Class I, important Class II or critical), based on their core functionality
Making Article 14 operational: reporting owner, accounts on ENISA's single reporting platform, 24 h, 72 h and 14-day templates, and a drill
Technical gap analysis: we assess the product and its secure development lifecycle (SDLC) against the essential requirements of Annex I, Part I
Vulnerability handling gap analysis (Annex I, Part II): SBOM, coordinated disclosure, free updates and support period
Technical product testing: hardware, firmware and application pentesting, and source code review, to show there are no known exploitable vulnerabilities
Prioritized compliance plan: what to cover now and what to prepare for December 2027, with the conformity assessment route open to you today
Technical documentation: technical file, EU declaration of conformity, CE marking and security instructions for users
Coordinated vulnerability disclosure (CVD) policy, reporting channel and security.txt

CRA compliance process

Product classification: We determine each product's level —default, important Class I, important Class II or critical— from its core functionality and the closed lists in Annexes III and IV. The level does not change the requirements: it decides who may sign off that they are met.
Article 14 in place: First, what is already enforceable: who detects, who decides and who reports, with the accounts on ENISA's single reporting platform created and a 24-hour early warning drill on a real product from your catalog.
Technical gap analysis and testing: We assess the product against the essential requirements of Annex I: secure by default, minimal attack surface, no shared credentials, encryption, secure updates and event logging. We check it with tests, not questionnaires.
Process gap analysis: We analyze vulnerability handling: SBOM, dependency monitoring, disclosure channel, declared support period and the ability to publish free patches securely.
Compliance plan: An action plan with two horizons —what is enforceable today and full application in December 2027— with owners, effort estimates and the conformity route your category allows given the current state of standards and bodies.
Implementation and documentation: We support implementing controls in the SDLC and draft the mandatory documentation: technical file, EU declaration of conformity, user instructions and vulnerability history.

Deliverables

Product classification report with justification based on the CRA and its Annexes III and IV
Article 14 reporting procedure, with templates and drill minutes
Technical gap analysis against the essential requirements of Annex I (Parts I and II)
Technical product test report with reproducible findings and retest
Prioritized compliance plan with two milestones: ENISA reporting, already in force, and full application in December 2027
Draft EU declaration of conformity and technical security documentation
Coordinated vulnerability disclosure (CVD) policy and security.txt

Who does the CRA affect?

Software manufacturers with installable components and network connectivity (SaaS with desktop agents, enterprise applications, firmware)
Hardware manufacturers with connectivity: IoT devices, IP cameras, home and professional routers, wearables, connected toys
Software component suppliers whose products are integrated into other manufacturers' products (libraries, SDKs, modules), which are products with their own declaration
EU importers and distributors of digital products manufactured outside the European Union
Industrial automation companies and control system manufacturers (OT/ICS/SCADA) with networked components
Radio equipment manufacturers who already went through the RED and EN 18031: that regime is repealed on December 11, 2027 and replaced by the CRA

CRA and NIS2: two regulations that get mixed up

Both talk about cybersecurity and reporting within 24 hours, but they regulate different things. A manufacturer that also provides an essential service has to comply with both.

	Cyber Resilience Act	NIS2
What it regulates	The security of the product with digital elements throughout its lifecycle	The organization's cybersecurity risk management
Who it binds	Manufacturers, importers and distributors of products sold in the EU	Essential and important entities in the sectors it lists
What is reported	Exploited vulnerabilities and severe incidents affecting the product	Significant incidents affecting the entity's services
Deadlines	24 h warning · 72 h notification · 14-day final report after the fix	24 h warning · 72 h notification · 1-month final report
To whom	ENISA's single reporting platform (coordinating CSIRT: INCIBE)	National CSIRT or competent authority
Since when	Article 14: 11-09-2026 · everything else: 11-12-2027	Directive applicable since 2024; in Spain, transposition still pending
How it is shown	Conformity assessment, EU declaration and CE marking	Risk management measures, supervision and audits
Maximum fine	€15M or 2.5% of worldwide turnover	€10M or 2% (essential) · €7M or 1.4% (important)

Compare with

What we find most often when reviewing products against Annex I

The same password on every unit

Default admin credentials, identical across the fleet and written into the firmware. One of the first things any Annex I review looks at, and one of the easiest to exploit at scale.

Nobody knows what is in the product

No SBOM, or one generated once and never updated. When a CVE appears in a library, the manufacturer takes days to know whether it is affected, and Article 14 gives 24 hours.

Updates that are not verified

Firmware downloaded unsigned or over an unencrypted channel. Anyone on the network can swap the patch for something else.

Nowhere to report

No disclosure policy, no security.txt, no monitored inbox. The researcher who finds the flaw has nobody to tell, and the clock starts anyway.

Debug ports open in production

UART or JTAG consoles reachable on production units, giving a root shell with an adapter that costs a few euros.

A support period nobody has decided

The CRA requires declaring how long free patches will be provided, at least five years unless the expected use is shorter. At many manufacturers it is a decision nobody has taken.

Frequently asked questions about the CRA

When does the Cyber Resilience Act enter into force?

The CRA entered into force on December 10, 2024. The technical and conformity requirements apply in full from December 11, 2027. There are two intermediate milestones: since June 11, 2026, Member States can designate notified bodies for third-party assessment, and since September 11, 2026, actively exploited vulnerabilities and severe incidents must be reported to ENISA.

Does the reporting obligation cover products already on the market?

Yes. Under Article 69(3), Article 14 applies to all products with digital elements, including those placed on the market before December 11, 2027. There is no exemption for age or for discontinued products: if someone exploits a vulnerability in a model you sold years ago, the 24-hour deadline runs just the same.

Do the Annex I requirements also apply to what I already sell?

No, with an important nuance. Under Article 69(2), products placed on the market before December 11, 2027 are only subject to the CRA requirements if they later undergo a substantial modification. The cut-off is the date each unit is placed on the market, so it is worth documenting it precisely.

Does the CRA apply to all software or only to connected hardware?

The CRA applies to all "products with digital elements": hardware and software with direct or indirect network connectivity. Excluded are open-source software released without a commercial purpose, pure SaaS without client-side installable components, medical devices regulated under the MDR, civil aviation products and defense equipment. If your SaaS includes a desktop agent or an installable plugin, that component does fall within the scope of the CRA.

What is the difference between default, Class I, Class II and critical products?

Default products are the majority and can use self-assessment. Important Class I products (identity managers, browsers, password managers, anti-malware software, VPNs, home routers…) need a third party unless a harmonised standard is fully applied. Class II products (hypervisors, firewalls, intrusion detection systems, tamper-resistant microprocessors…) always require a notified body or European certification, and the critical products in Annex IV, certification when the Commission requires it. The level does not change the requirements, only who may sign off that they are met.

Can I self-assess a Class I product today?

It is hard today. At the last review of our guide (September 2026) no CRA harmonised standard had been cited in the Official Journal and no notified bodies had been designated under the regulation. Without a harmonised standard applied in full, Class I needs a third party, and without designated bodies that route is not open yet either. The sensible course is to prepare the technical file as if for an external audit and track the standardization milestones.

Who do I report to in Spain?

Everything goes through ENISA's single reporting platform, which forwards it at the same time to ENISA and to the coordinating CSIRT of the Member State where the manufacturer has its main establishment. In Spain, that coordinating CSIRT is INCIBE. The platform is browser-based, so the EU Login accounts with two-factor authentication of whoever will report must be created before the first warning.

Is an SBOM mandatory?

Yes. Annex I, Part II, requires identifying and documenting the product's components by drawing up a software bill of materials (SBOM) in a commonly used, machine-readable format covering at least the top-level dependencies. It is part of the technical documentation; publishing it is not mandatory. Without an up-to-date SBOM it is almost impossible to know within 24 hours whether a new vulnerability affects you.

I already have CE marking under the Radio Equipment Directive and EN 18031. Does it count?

It counts as groundwork, not as CRA compliance. CE marking is granted per legislative act and there is no cross-recognition. In addition, Delegated Regulation (EU) 2026/339 repeals 2022/30, the RED cybersecurity act, with effect from December 11, 2027: from that day, the cybersecurity of that equipment is governed by the CRA.

What are the penalties for CRA non-compliance?

The CRA sets three levels of penalty: up to €15 million or 2.5% of global annual turnover for breaching the essential cybersecurity requirements or the obligations of Articles 13 and 14, including reporting; up to €10 million or 2% for breaching other obligations; and up to €5 million or 1% for providing incorrect information to the authorities.

Does the CRA overlap with NIS2 or other regulations?

Yes. NIS2 regulates the cybersecurity of entities that provide essential and important services, while the CRA regulates the security of digital products placed on the market. If you are a software manufacturer and also provide an essential service, both apply to you. There are also overlaps with the MDR for connected medical devices (the MDR prevails) and with the Radio Equipment Directive until December 2027.

How long does it take to comply with the CRA?

It depends on your starting point and product category. Article 14 can be made operational in weeks. For the rest, companies with a secure SDLC and mature vulnerability management can complete the process in 6–9 months; those starting from scratch will need 12–24 months to reach December 2027.

Understand the regulation

What is already mandatory

Tools

Technical testing to prove it

Sources

Ready to protect your business?

Answer the scoping form at your own pace and we'll use it to prepare your proposal. If you'd rather talk first, book a free 30-minute call.

Scope your project · Assess my CRA compliance