What is the Cyber Resilience Act?
The Cyber Resilience Act (CRA) is an EU regulation that sets mandatory cybersecurity requirements for all products with digital elements sold on the European market. It covers hardware and software throughout their entire lifecycle, from design to end-of-support. Manufacturers must build security in by default, maintain a software bill of materials, handle vulnerabilities actively, and report incidents within strict timelines. The regulation entered into force in December 2024 and becomes fully enforceable on 11 December 2027.
The CRA fills a gap that previous regulation left open. NIS2 tells organisations how to protect themselves. DORA tells financial institutions how to manage operational resilience. The CRA tells manufacturers how to build secure products. If you make anything that connects to a network and sell it in the EU, this regulation applies to you.
For manufacturers in the European mid-market, 2026 is the year when preparation turns into operational reality. Reporting obligations start in September 2026. Notified bodies for conformity assessments need to be in place by June 2026. Waiting until 2027 means scrambling against deadlines that your competitors have already met.
What the CRA requires from manufacturers
The regulation defines 21 requirements grouped into two categories: product security properties and vulnerability handling processes.
Security by design and by default. Products must ship in a secure default configuration. Unnecessary ports, services and features should be disabled out of the box. Authentication and access control must be built in, not bolted on afterwards. Data in transit and at rest needs encryption. Secure update mechanisms must be available from day one.
Vulnerability management throughout the product lifecycle. Manufacturers must define a support period during which they commit to patching vulnerabilities. The general minimum is five years. This includes regular security testing, a coordinated vulnerability disclosure (CVD) process for external researchers, and maintaining a software bill of materials (SBOM) for every product.
Incident and vulnerability reporting. From 11 September 2026, manufacturers must report actively exploited vulnerabilities to ENISA and national CSIRTs. The timelines are tight:
| Report type | Deadline | Content |
|---|---|---|
| Early warning | Within 24 hours | First notification of actively exploited vulnerability or serious incident |
| Formal notification | Within 72 hours | Technical analysis, impact description, remediation steps |
| Final report | Within 14 days | Root cause analysis and confirmation of available fix |
For a mid-market manufacturer with a small IT team and no 24/7 security operations centre, meeting these timelines requires preparation. You need a Product Security Incident Response Team (PSIRT) with clear roles, automated alerting, and pre-drafted notification templates before the September 2026 deadline arrives. Organisations that run their security through a single management console have a structural advantage here. When access logs, network events, and policy changes live in one place, assembling an early warning report within 24 hours becomes a process rather than a scramble. Jimber’s SASE platform, for example, captures these data points centrally, which means your PSIRT spends its time analysing the incident rather than correlating logs from five separate tools.
Conformity assessment. Before placing a product on the market, manufacturers must demonstrate compliance. The assessment route depends on the product’s risk classification.
Which products are covered (and which are not)
The CRA applies to any “product with digital elements” (PDE), defined as hardware or software whose intended use involves a direct or indirect connection to a device or network. That definition is deliberately broad.
The regulation classifies products into four risk tiers:
| Category | Examples | Assessment route |
|---|---|---|
| Default (~90% of products) | Smart home devices, connected toys, office software, Bluetooth speakers | Self-assessment (Module A) |
| Important Class I | VPN software, password managers, routers, network management systems | EU type examination by notified body (Module B+C) |
| Important Class II | Firewalls, hypervisors, industrial robot controllers, tamper-resistant microprocessors | EU type examination (Module B+C) |
| Critical | Smart meter gateways, hardware security modules (HSMs) | Full quality assurance or European certification scheme (Module H) |
Getting the classification right matters. A manufacturer that self-assesses a Class I product risks market access suspension and fines. If you produce anything that touches network security, identity management, or industrial control, check the Annex III and IV lists carefully.
What falls outside the CRA. Products already regulated under sector-specific frameworks are largely excluded: medical devices (MDR/IVDR), vehicles (UNECE R155), aviation, and marine equipment. Open-source software developed outside commercial activity is exempt, though commercial distributions of open-source components are not. Pure SaaS delivered entirely in the cloud is outside scope, but any downloadable component or on-premises element brings the product back in.
How the CRA fits with NIS2 and DORA
The CRA is the third leg of Europe’s cybersecurity regulatory framework. Each regulation addresses a different dimension:
| CRA | NIS2 | DORA | |
|---|---|---|---|
| Focus | Product security | Organisation security | Financial sector resilience |
| Who it targets | Manufacturers, importers, distributors of digital products | Essential and important entities across 18 sectors | Banks, insurers, investment firms, crypto providers |
| What it governs | How products are designed, maintained and disclosed | How organisations manage risk, access, incidents | How financial entities manage ICT third-party risk |
| Key deadline | 11 Sep 2026 (reporting), 11 Dec 2027 (full) | Active in Belgium since Oct 2024 | Active since Jan 2025 |
| Penalties | Up to EUR 15M or 2.5% of global turnover | Up to EUR 10M or 2% of global turnover | Up to EUR 5M or 10% of turnover for providers |
A manufacturer of industrial controllers might face all three. The CRA governs the product itself. NIS2 applies if the manufacturer is classified as an important entity. And DORA applies indirectly: financial institutions using those controllers will demand CRA-compliant products as part of their own DORA register of information.
For organisations already working on NIS2 compliance for mid-market, the overlap is an advantage. Risk assessment methodologies, asset inventories, and incident response processes developed for NIS2 translate directly to CRA requirements. Platforms like Jimber that consolidate security controls into a single auditable system help organisations navigate both frameworks without duplicating work.
Why CRA compliance starts on the factory floor
Here is the part most compliance guides miss. The CRA requires that your product is secure. But a product built in a compromised production environment is not secure, regardless of how well you designed it.
If an attacker gains access to your build pipeline, firmware compilation server, or software distribution infrastructure, they can inject malicious code into your product before it leaves the factory. This is not theoretical. Supply chain attacks on SolarWinds, Kaseya, and 3CX followed exactly this pattern.
For manufacturers of connected products, securing the production environment is a CRA compliance requirement, not just good practice. You need to demonstrate that the integrity of your product was maintained throughout the manufacturing process.
This is where production network security becomes directly relevant. Jimber’s SASE platform addresses the specific challenges manufacturers face:
Network segmentation between IT and OT. The corporate network where email and ERP run must be strictly separated from the production environment where firmware is compiled and flashed. Jimber’s SD-WAN and FWaaS enforce this separation with identity-based policies managed from a single console. A ransomware outbreak in the office should never reach the build servers.
Zero Trust access to production systems. Only authorised engineers should be able to modify product firmware or software builds. Jimber’s Zero Trust Network Access grants per-application access based on user identity and device posture, not network location. Every access decision is logged with a full audit trail.
Inline isolation for agentless production equipment. PLCs, HMIs, and flashing stations cannot run security agents. Jimber’s NIAC hardware sits inline between these devices and the network, enforcing per-device communication policies without touching the device itself. A compromised laptop on the IT network hits a wall before it reaches production equipment. The SASE for manufacturing guide covers the technical implementation in detail.
Centralised logging for audit evidence. CRA conformity assessments will ask how you ensure production integrity. A single management console that logs every access decision, policy change, and device communication flow provides the evidence trail that auditors expect.
Five steps to prepare for CRA compliance
Step 1: run a gap assessment against Annex I
List every product in your portfolio that contains digital elements. Classify each one according to the CRA’s risk tiers. Then map your current security practices against the 21 requirements in Annex I.
Jimber’s CRACy compliance tool was developed as part of an EU-backed initiative specifically for this purpose. It translates the abstract Annex I requirements into concrete technical controls, identifies gaps, and helps prioritise remediation. For SMEs without a dedicated compliance team, this structured approach replaces months of manual interpretation.
Step 2: build and maintain your SBOM
A software bill of materials documents every component in your product: libraries, frameworks, open-source dependencies, and their versions. Use standardised formats like CycloneDX or SPDX. Update the SBOM with every release.
The SBOM is not just a compliance document. It is your early warning system. When a new vulnerability appears in a widely used library (as with Log4j in 2021), an up-to-date SBOM tells you within hours whether your products are affected.
Step 3: establish vulnerability disclosure and incident response
Set up a coordinated vulnerability disclosure process before September 2026. External researchers need a clear, documented way to report vulnerabilities. Internally, define your PSIRT with named roles, escalation paths, and pre-drafted notification templates that meet the 24/72/14-day reporting requirements.
The quality of your incident response depends on how quickly you can determine what happened. If your security architecture logs access decisions, device posture evaluations, and network flows in a single timeline, root cause analysis accelerates significantly. This is one of the practical reasons manufacturers consolidating onto a unified SASE platform, such as Jimber, find incident response preparation easier to operationalise.
Step 4: implement security testing
Regular penetration testing and automated vulnerability scanning should cover both the product and its production environment. Test update mechanisms to confirm they cannot be tampered with. Validate that default configurations are actually secure.
Step 5: prepare your conformity documentation
For default-category products, internal documentation following Module A is sufficient. For Important Class I and II products, you need a notified body. These bodies are being designated throughout 2026, and capacity will be limited. Book early to avoid delays that could block your market access in 2027.
Your technical dossier should include the risk assessment, test results, SBOM, vulnerability handling procedures, and evidence of security-by-design processes. The effort required to compile this evidence varies enormously depending on your security architecture. A manufacturer running five separate tools needs to extract, correlate, and cross-reference logs from each one. Jimber’s single management console generates a unified audit trail that covers access control, network segmentation, and device communication flows in one exportable dataset. That difference can reduce documentation preparation from months to weeks.
Belgian and Benelux context
Belgium’s Centre for Cybersecurity Belgium (CCB) plays a central role in CRA implementation. As the national CSIRT, the CCB receives incident reports and oversees certification processes.
The SECURE project. The EU has launched funding specifically to help SMEs with CRA compliance. Belgian companies can apply for subsidies up to EUR 30,000, covering 50% of costs for risk assessments, SBOM development, and security testing. The first application window ran until March 2026, but additional calls are expected.
CyberFundamentals (CyFun) overlap. Belgian manufacturers already working towards CyFun self-assessment will find significant overlap with CRA requirements. CyFun covers many of the same technical controls, particularly around access management, incident handling, and asset inventory. CyFun certification does not equal CRA conformity, but it provides a strong foundation. Organisations running their CyFun evidence collection through a consolidated platform like Jimber’s can reuse much of that documentation for CRA purposes. The access logs, segmentation policies, and device inventories that satisfy CyFun’s Protect function map directly to the production environment controls the CRA expects. The NIS2 compliance checklist maps specific controls that apply across all three frameworks.
Penalties. Non-compliance with Annex I requirements can result in fines up to EUR 15 million or 2.5% of global annual turnover. Failure to meet reporting obligations carries the same ceiling. Regulators can also order product recalls or market withdrawal, which for most manufacturers is more damaging than any fine.
FAQ
When does the Cyber Resilience Act come into force?
The CRA entered into force on 10 December 2024. Reporting obligations for actively exploited vulnerabilities begin on 11 September 2026. Full enforcement, including conformity assessments and CE marking requirements, starts on 11 December 2027.
Does the CRA apply to software?
Yes. The CRA covers both hardware and software products with digital elements, including standalone software distributed for use on end-user devices. Pure SaaS delivered entirely in the cloud is excluded, but any downloadable component or client-side element brings the product into scope.
What is an SBOM and why does the CRA require one?
A software bill of materials (SBOM) is a machine-readable inventory of every component in your product, including open-source libraries, third-party modules, and their versions. The CRA requires an SBOM because modern software typically consists of 75% or more external components. A vulnerability in any one of them affects your product. The SBOM makes that supply chain transparent.
How do CRA and NIS2 overlap?
The CRA governs the security of products you manufacture. NIS2 governs the security of your organisation. A manufacturer classified as an important entity under NIS2 must comply with both. The practical overlap is significant: risk assessment, incident response, access control, and supply chain management appear in both frameworks. Completing CyFun or ISO 27001 for NIS2 gives you a head start on CRA’s organisational requirements.
Does the CRA affect my production environment?
Yes. The CRA requires manufacturers to ensure product integrity throughout the lifecycle, including during manufacturing. A compromised production environment can inject vulnerabilities into otherwise well-designed products. Securing build pipelines, firmware servers, and production networks with Zero Trust controls and network segmentation is part of demonstrating CRA compliance. For production equipment that cannot run security agents, inline isolation hardware like Jimber’s NIAC enforces per-device communication policies without disrupting operations.
Can I get financial support for CRA compliance in Belgium?
The EU-funded SECURE project offers Belgian SMEs subsidies up to EUR 30,000, covering 50% of eligible costs for CRA compliance activities. Additional national and regional programmes, including the KMO-portefeuille, may cover advisory costs related to cybersecurity certification and compliance.
The Cyber Resilience Act changes the baseline for every manufacturer selling connected products in Europe. Compliance is not optional, and the timelines are closer than they appear. Manufacturers that invest now in secure development practices, production environment security, and structured compliance documentation will meet the 2027 deadline without scrambling. Those that wait risk market access delays, fines, and the reputational damage that comes with being caught unprepared. Ready to secure your production environment for CRA compliance? Book a demo and see how Jimber’s SASE platform protects the infrastructure where your products are built.
