The Cyber Resilience Act: What Security Teams Must Document

The EU Cyber Resilience Act (Regulation 2024/2847) does something no previous EU cyber law did: it puts security obligations on the product, not just the operator. It entered force on 10 December 2024, its main obligations apply from 11 December 2027, and non-compliance carries penalties up to €15 million or 2.5% of worldwide annual turnover. For security and network teams used to NIS2 and DORA, the CRA is a different axis of the same regulatory push — and this guide explains where it overlaps with the network controls you already run, and where it does not.

What the CRA Actually Regulates

The CRA applies to “products with digital elements” — hardware and software placed on the EU market — regardless of whether they connect to the internet. That spans routers, smart devices, industrial systems, and software components as ordinary as a library. Manufacturers, importers, and distributors share responsibility, and products require CE marking demonstrating conformity. The European Commission’s Cyber Resilience Act overview sets out the product categories and timeline.

Which Products Are in Scope

The CRA sorts products with digital elements into risk tiers, and the tier sets the conformity route. The default class— the large majority of products — can self-assess against the essential requirements. Important products(Class I and II) — including password managers, network-management systems, VPNs, routers, firewalls, and microcontrollers — face stricter expectations, with Class II requiring third-party assessment. Critical products— hardware security modules, smartcard secure elements, smart-meter gateways — may require European cybersecurity certification.

Note where network equipment lands: routers, firewalls, and network-management systems are named explicitly as important products. If your organisation manufactures or white-labels any network appliance for the EU market, the CRA reaches your own product line — not only your suppliers’.

CRA vs NIS2 vs DORA: Different Axes

The most common confusion is treating these as competing frameworks. They are complementary, and they regulate different subjects:

An organisation can be obligated under all three: a manufacturer of a networked device that is also an essential entity under NIS2 and, if it is a financial-sector ICT supplier, in scope of DORA. The controls overlap heavily even though the legal subjects differ.

The Core Obligations

Secure by design and default. Products must ship in a secure configuration requiring no hardening, with protection against unauthorised access built into the architecture and essential functions maintained under attack.

Vulnerability handling. Manufacturers must operate a coordinated vulnerability-disclosure process, maintain a software bill of materials (SBOM), and track and remediate vulnerabilities across the support period — with actively exploited vulnerabilities reportable to ENISA within 24 hours of awareness.

Security updates.Security patches must be delivered for a defined support period, with that period communicated to buyers before purchase — ending the practice of silently abandoned firmware.

Data protection and access control. Data minimisation, encryption in transit and at rest, strong authentication, and access logging — obligations that align closely with GDPR Article 32 and with the technical measures already familiar to network teams.

Where the CRA Meets the Network Team

The CRA is a product regulation, so much of it lands on product and development teams rather than network operations. But three threads connect directly to firewall and network practice. First, the vulnerability-handling obligation requires you to knowwhat is exposed — the same continuous automated vulnerability scanning that underpins other frameworks feeds CRA evidence. Second, where a product cannot be patched immediately, network segmentation and egress control act as compensating controls that limit exposure — an operational decision the network team owns. Third, for organisations deploying self-hosted or on-premise components to meet data-sovereignty obligations, the self-hosted deployment patterns for regulated industries apply equally to CRA-scoped software.

Conformity Assessment and CE Marking

CE marking demonstrates conformity. For most products, manufacturer self-assessment against the essential requirements suffices; critical and important product categories require third-party conformity assessment. Technical documentation must prove conformity, and a declaration of conformity accompanies the product to market. Market-surveillance authorities can order non-compliant products withdrawn.

The Timeline

Frequently Asked Questions

Does the CRA apply to internal or air-gapped software?

It applies to products with digital elements placed on the EU market, including software that never accesses the internet. The trigger is placing the product on the market, not connectivity. Purely internal, bespoke software you do not place on the market is generally out of scope, but verify against the final guidance for your product category.

How is the CRA different from NIS2?

NIS2 governs how an operator manages cyber risk; the CRA governs the security of the product itself across its lifecycle. A device manufacturer that is also an essential entity is obligated under both — CRA for what it ships, NIS2 for how it runs.

What happens if a product is non-compliant?

Penalties reach €15 million or 2.5% of worldwide annual turnover, whichever is higher, and market-surveillance authorities can require withdrawal from the EU market. The commercial risk of market exclusion typically outweighs the fine.

Conclusion

The CRA closes the gap NIS2 and DORA left open: the security of the products themselves. December 2027 is closer than the 36-month window suggests once conformity assessment and SBOM tooling are factored in. For network teams, the practical contributions are vulnerability visibility and segmentation as a compensating control — both measurable with the free firewall readiness check and structured in the FwChange methodology.