The EU Cyber Resilience Act (EU CRA) is a regulation that makes cybersecurity requirements legally mandatory for virtually every product with digital elements sold in the European Union, with full enforcement beginning in December 2027. If your company makes IoT devices, industrial control systems, routers, smart home products, medical devices, or any connected hardware, the CRA applies to you.
This is not a voluntary framework. Non-compliance carries penalties of up to EUR 15 million or 2.5% of global annual turnover. The December 2027 deadline is firm. And unlike some previous EU tech regulations, the CRA has real teeth in terms of enforcement mechanism: products that don’t meet requirements cannot legally be sold in the EU market.
The good news is that the requirements are concrete and achievable. Here is what the EU CRA actually requires for firmware and hardware manufacturers, and what you need to start doing now.
What Is the EU Cyber Resilience Act?
The EU Cyber Resilience Act is an EU regulation that establishes mandatory cybersecurity requirements for products with digital elements sold in the EU. It was adopted in 2024 and the main requirements become enforceable from December 2027. The CRA covers hardware with embedded software, standalone software products, and connected devices.
The core premise of the CRA is simple: manufacturers bear responsibility for the cybersecurity of their products throughout the product lifecycle, not just at the point of sale. This means vulnerability disclosure, SBOM generation, security update commitments, and ongoing monitoring are all required activities.
Who Does the EU CRA Apply To?
The CRA applies to any manufacturer, importer, or distributor placing a “product with digital elements” on the EU market. A product with digital elements is any product that can connect to other devices or networks, either directly or indirectly.
This covers:
- IoT devices (smart home, industrial, medical, automotive)
- Networking equipment (routers, switches, firewalls)
- Industrial control systems and operational technology
- Consumer electronics with connectivity
- Software products sold as a product (not as a service)
- Operating systems, firmware, and middleware when sold as part of a product
The CRA also applies to non-EU companies. If you are an Indian, US, or Chinese manufacturer and you sell connected hardware into the EU market, the CRA applies to you.
There are two categories of products. Default essential products (a broad catch-all) and critical products (higher-risk categories like industrial control systems, network devices, and smart meters). Critical products face additional requirements and often require third-party conformity assessment rather than self-assessment.
Key Firmware Requirements Under the EU CRA
The CRA’s Annex I lists essential cybersecurity requirements. The following are the ones that directly affect firmware development and release.
Article 13: SBOM Requirement
Manufacturers must produce and maintain a Software Bill of Materials (SBOM) for each product. The SBOM must list all software components, their versions, and their identifiers (such as CPE or PURL). This is a direct requirement for firmware: you cannot satisfy Article 13 without knowing exactly what is in your firmware image.
The CRA does not mandate a specific SBOM format, but the industry standard options are CycloneDX (JSON or XML) and SPDX. Both are machine-readable and supported by the major vulnerability management tools.
Article 14: Active Vulnerability Reporting
Article 14 requires manufacturers to report actively exploited vulnerabilities in their products to ENISA (the EU Agency for Cybersecurity) within 24 hours of becoming aware of them. This is arguably the most operationally demanding requirement in the CRA.
For firmware teams, this means you need a process to monitor your products for exploitation activity, correlate CVEs against your firmware components, and have a reporting pathway to ENISA ready before you need it. You cannot improvise this in 24 hours during an active incident.
Conformity Assessment
Manufacturers must complete a conformity assessment to demonstrate compliance with the CRA’s essential requirements before placing a product on the EU market. For default essential products, manufacturers can self-assess using internal documentation. For critical products (Class I and Class II as defined in Annex III), third-party assessment by a notified body is required.
The conformity assessment requires documented evidence that your product meets each essential requirement. A compliance grade from your firmware security analysis platform, tied to the CRA’s Annex I requirements, is exactly this kind of evidence.
Essential Requirements in Annex I
Annex I lists 14 essential requirements. The firmware-relevant ones include:
- No known exploitable vulnerabilities in the product at time of release
- Secure default configuration
- Protection against unauthorized access
- Protection of data at rest and in transit
- Minimized attack surface
- Availability of security updates
- Secure update mechanisms with verification
- Disclosure of known vulnerabilities and security updates
| CRA Requirement | Where It Shows Up in Firmware | FDIE Coverage |
|---|---|---|
| No known exploitable vulnerabilities | CVE scan at release | CVE detection + CISA KEV flagging |
| Secure default configuration | Default credentials, open ports | Credential detection + attack surface analysis |
| Secure update mechanisms | Update signing, rollback protection | Firmware update category in 40+-point test suite |
| Minimize attack surface | Unnecessary services, debug interfaces | Attack surface analysis |
| Data protection | Encryption in use | Cryptography analysis |
| SBOM generation | Component inventory | CycloneDX + SPDX SBOM export |
| Active exploitation reporting | Article 14 alerts | CISA KEV + EPSS correlation |
The December 2027 Deadline: What It Actually Means
The CRA’s main requirements become mandatory on December 11, 2027. After that date, any product with digital elements placed on the EU market must meet all CRA requirements.
“Placed on the market” means the first time a product is made available in the EU. If you sell a product line continuously, every new unit you ship after December 2027 must comply.
Products already on the market before December 2027 are not automatically exempt. If you continue to sell the same product after December 2027, it needs to comply.
The reporting obligations under Article 14 apply earlier: manufacturers must be ready to report actively exploited vulnerabilities from September 2026.
There is no transition period announced as of this writing. Plan for December 2027 as a hard deadline.
Penalties for Non-Compliance
The CRA enforcement follows EU model with tiered penalties:
- Infringement of the essential requirements: up to EUR 15 million or 2.5% of global annual turnover (whichever is higher)
- Infringement of Article 14 reporting obligations: up to EUR 10 million or 2% of global annual turnover
- Providing false or misleading information to market surveillance authorities: up to EUR 5 million or 1% of global annual turnover
Market surveillance authorities in each EU member state are responsible for enforcement. Products found non-compliant can be prohibited from sale, recalled from the market, or removed from circulation.
How to Start Preparing Today
You have until December 2027, which sounds like a long time but isn’t once you account for product development cycles, regulatory review, and organizational change. Here is a practical starting sequence:
Inventory your products. List every product your company ships that connects to anything. Identify which ones are sold or will be sold in the EU. This is your CRA scope.
Generate SBOMs for each product. You cannot assess CRA compliance without knowing what components are in your firmware. Automate SBOM generation as part of your firmware build pipeline. Don’t do this manually.
Run a CVE scan against your current firmware. You need to know what vulnerabilities exist in your products today, before you can address them.
Review your update mechanisms. Do your firmware updates have signature verification? Can devices roll back to a known-good version? These are Annex I requirements.
Assess your default configuration. Remove default credentials, close unnecessary ports, disable debug interfaces in production builds.
Set up Article 14 monitoring. You need a way to know when a CVE in your product components becomes actively exploited. CISA KEV is the most reliable public source for this.
Write your conformity assessment documentation. Start documenting how each essential requirement is met. This documentation is what you present to a notified body or market surveillance authority if asked.
Map your findings to a compliance grade. A systematic mapping from your security analysis to CRA Annex I requirements is what turns a security scan into audit evidence.
How FDIE Helps with EU CRA Compliance
FDIE automates most of the firmware-level CRA preparation:
FDIE generates CycloneDX and SPDX SBOMs automatically from every firmware upload, satisfying Article 13’s component inventory requirement. It runs a 40+-point test suite mapped to CRA essential requirements and produces an A-F compliance grade per framework, with the specific test results that constitute conformity assessment evidence.
For Article 14, FDIE correlates every CVE finding against the CISA Known Exploited Vulnerabilities (KEV) catalog and EPSS (Exploit Prediction Scoring System), so actively exploited vulnerabilities are flagged immediately rather than buried in a list of hundreds.
CVSS severity, EPSS exploit probability, and CISA KEV status on every finding - the evidence Article 14’s conformity assessment asks for.
FDIE’s compliance page at /platform/compliance/ shows the full mapping between the 40+ test cases and each of the 6 supported frameworks, including EU CRA.
If you’re starting your CRA compliance program, the Pro plan includes full EU CRA framework mapping, SBOM and VEX generation, CISA KEV integration, and Delta Intelligence for tracking compliance changes across firmware versions.
Frequently Asked Questions
Q: Does the EU CRA apply to software? Yes. The EU CRA applies to standalone software products sold as a product (not as a service). Software-as-a-Service (SaaS) is explicitly excluded from the CRA, as are cloud services and open source software developed outside a commercial context. If you sell embedded software, operating systems, or firmware as part of a hardware product, you are covered.
Q: What is Article 14 of the EU CRA? Article 14 requires manufacturers to report actively exploited vulnerabilities in their products to ENISA (the EU Agency for Cybersecurity) within 24 hours of becoming aware of exploitation activity. Manufacturers must also notify the users of affected products. This obligation applies from September 2026, before the main CRA requirements come into force in December 2027.
Q: When does the EU CRA become mandatory? The main requirements of the EU Cyber Resilience Act become mandatory on December 11, 2027. The reporting obligations under Article 14 apply earlier, from September 2026. Products placed on the EU market after December 11, 2027 must comply with all CRA requirements.