What Is the EU Cyber Resilience Act?
The Cyber Resilience Act is Regulation (EU) 2024/2847, an EU law that sets mandatory cyber security requirements for hardware and software products sold in the European Union. It applies to manufacturers, importers, and distributors of ‘products with digital elements,’ covering everything from smart home devices to enterprise software, and requires them to build in security from the design stage through to end of support.
Unlike earlier EU cyber security instruments, which mostly targeted critical infrastructure operators, the CRA regulates the product itself. A product that does not meet its requirements cannot legally carry the CE marking and be placed on the EU market, regardless of how the company that built it is organised or where it is based.
The regulation was adopted by the Council on 10 October 2024, published in the Official Journal on 20 November 2024, and entered into force on 10 December 2024. It complements, rather than replaces, the NIS2 Directive, which governs how certain organisations run their own cyber security, not how they build the products they sell.
For a business leader, the practical takeaway is simple: if your company designs, manufactures, imports, or distributes anything with a chip, a connection, or a line of code that ends up in the hands of an EU customer, the CRA almost certainly applies to you in some capacity.
Who Must Comply with the CRA?
The CRA assigns different obligations to different roles in the supply chain, and the weight of responsibility is heavily front-loaded onto manufacturers. Understanding which role your business plays, sometimes more than one, is the first step in any compliance plan.
Manufacturers
Manufacturers carry the primary compliance burden under the CRA, accounting for roughly 90% of the obligations set out in the regulation. If your company designs a product with digital elements, develops the software that runs on it, or has a product built under your brand by a third party, you are the manufacturer in the eyes of EU law, regardless of where your engineering team sits.
These obligations include running a cyber security risk assessment before the product ships, building to the Annex I essential requirements, drawing up an EU declaration of conformity, affixing CE marking, maintaining a vulnerability handling policy for the life of the product, and producing a Software Bill of Materials (SBOM).
On top of this, manufacturers also carry the reporting duty for actively exploited vulnerabilities – the obligation that becomes enforceable first in September 2026.
Importers
Importers are companies established in the EU that place a non-EU manufacturer's product on the EU market. Their core duty is non-EU import compliance verification: before bringing a product in, the importer must confirm the manufacturer has carried out the correct conformity assessment, prepared technical documentation, and affixed CE marking correctly.
If an importer has reason to believe a product does not meet CRA requirements, it cannot place that product on the market until the issue is fixed, and it must inform both the manufacturer and the relevant market surveillance authority.
Distributors
Distributors, the retailers, resellers, and marketplaces that make a product available without manufacturing or importing it, have a lighter but still real obligation. Before listing or selling a product, a distributor must verify that CE marking, the EU declaration of conformity, and required documentation are present. If a distributor becomes aware of a non-compliant or vulnerable product already on its shelves or storefront, it must act, including pulling the listing and notifying the manufacturer or importer.
Authorised representatives
A manufacturer based outside the EU that wants to sell into the bloc must appoint an authorised representative, an EU-established legal or natural person who acts as the manufacturer's non-EU proxy for regulatory purposes. The authorised representative holds the technical documentation, cooperates with national market surveillance authorities (in Lithuania, this is coordinated with NKSC), and can be held accountable if the manufacturer cannot be reached directly. For non-EU manufacturers, appointing this representative early is not optional administrative paperwork – it is a condition of legally entering the EU market at all.
CRA Scope: Which Digital Products Are Affected?
The CRA's scope is intentionally broad. It applies to products with digital elements (PDEs): any hardware or software product, along with its remote data processing solutions, with a direct or indirect connection to another device or network. That connection is what pulls a product into scope, whether it's logical or physical, direct or indirect.
In practice, this covers:
- Hardware with digital components, from industrial sensors to consumer electronics.
- On-premises software, including enterprise applications and embedded systems.
- Embedded firmware running inside connected devices.
- Remote data processing solutions that are essential to a covered product's function, even when that processing happens in the cloud.
What's excluded from CRA scope?
Two categories sit outside the CRA by design. Software-as-a-Service (SaaS) that is not essential to the functioning of a separately sold product generally falls under the NIS2 Directive instead, since NIS2 governs how a service is operated rather than how a product is built. The line gets thinner where a SaaS component is integral to a hardware or software product's core function; that remote processing element can pull the whole offering back into CRA scope.
Open-source software developed outside commercial activity is also exempt from manufacturer obligations. Once open-source code gets bundled into a commercial product or paid support offering, the company shipping it inherits full responsibility for that code under the CRA. The regulation does create a lighter, tailored regime for ‘open-source software stewards’, organisations that provide sustained, non-commercial support to a free and open-source project used in commercial products elsewhere.
A small number of sectors already covered by equally strict EU product-safety regimes, including medical devices, motor vehicles, aviation, and military equipment, are also carved out to avoid double regulation.
What Is a ‘Product with Digital Elements’?
A product with digital elements is any hardware or software product whose intended or reasonably foreseeable use includes a direct or indirect logical or physical connection to a device or network. Classification runs on the product's core function, not on every component bundled inside it. A general-purpose laptop that happens to ship with a password manager pre-installed is still assessed as a default-category laptop; the password manager itself, sold as a standalone product, would face the stricter Class I requirements described below.
Core CRA Cyber Security Requirements for Manufacturers
The CRA's essential cyber security requirements sit in Annex I and rest on a single principle: products must be secure by design and secure by default, not secured after the fact. The requirements split into two groups, security properties the product must have when it ships, and a vulnerability handling process the manufacturer must run for as long as the product is supported. The most useful way for a business team to think about Annex I is across the product lifecycle.
Design phase
Security work starts before a line of code is written. Manufacturers are expected to carry out risk-based asset mapping and a documented cyber security risk assessment for the product, identify how vulnerabilities could be isolated to limit blast radius, and apply secure-by-design principles, such as minimising the attack surface, throughout the architecture.
Build phase
During development, the CRA expects secure default settings out of the box: no default or hard-coded passwords, and built-in tamper protection where relevant. Data minimisation also applies here; the product should only process the data it genuinely needs to function, reducing what an attacker could ever expose.
Release phase
Before a product is placed on the market, the manufacturer must generate a Software Bill of Materials – typically in a machine-readable format such as SPDX or CycloneDX – and complete mandatory testing to verify the product meets the essential requirements. This is the documentation gate. A product without a current SBOM and test evidence is not ready to ship into the EU.Support phase
Compliance does not end at launch. Manufacturers must commit to a defined support period – a minimum of five years unless the product is genuinely expected to be in use for a shorter time – during which they provide lifecycle security updates and patch vulnerabilities without unreasonable delay. A published Coordinated Vulnerability Disclosure (CVD) policy is mandatory, giving security researchers a clear, safe channel to report issues rather than disclosing them publicly first.
Product Risk Classification
Not every product faces the same level of scrutiny. The CRA sorts products with digital elements into risk tiers, and the tier determines whether a manufacturer can self-certify or must bring in an independent third party.
Default - unclassified
Most products with digital elements fall into the default category. A manufacturer can self-assess conformity with Annex I and is free to choose a stricter route voluntarily, but nothing forces them to involve an external body. This is the lowest-friction path through the regulation.
Class I (Important - lower tier)
Class I covers products that perform security-relevant functions but present comparatively lower risk if something goes wrong. Browsers, password managers, and PKI infrastructure are the textbook examples. Manufacturers here can still self-certify once the relevant harmonised standards are published, or opt for third-party assessment if those standards are not yet available or are not used.
Class II (Important - higher tier)
Class II products perform functions that are critical to the cyber security of other products or networks, or that could cause significant harm if compromised. Firewalls, hypervisors, tamper-resistant microprocessors sit here. Third-party conformity assessment by a notified body is mandatory for Class II, regardless of which standards the manufacturer applies.
Above Class II sits a third tier of critical products, such as smart cards, secure elements, and smart meter gateways, where a European cyber security certificate or, failing that, the same third-party route as Class II is always required. If your product touches secure cryptographic processing or critical metering infrastructure, assume the strictest assessment path applies from day one.
The Software Bill of Materials (SBOM) Target Architecture
An SBOM is no longer a nice-to-have for security teams. Under the CRA, it is a legal artefact. The regulation requires manufacturers to maintain a Software Bill of Materials in a commonly used, machine-readable format, with SPDX and CycloneDX the two formats the market has converged on, covering at least the top-level dependencies of the product.
The purpose is software supply chain transparency: when a new vulnerability is disclosed anywhere in the open-source or commercial component ecosystem, a manufacturer with an accurate SBOM can run continuous vulnerability correlation and know within minutes whether it is affected, rather than days. That speed is what makes the 24-hour reporting clock described below achievable.
SBOMs must stay current through releases and component changes and be retained alongside the rest of the technical documentation for at least 10 years after the product is placed on the market, or for the full support period if that runs longer. Manufacturers building this now, rather than in 2027, gain a real operational advantage. Automated SBOM generation that plugs into existing CI/CD pipelines turns a compliance burden into a routine build step.
Comparison: CRA vs. NIS2 vs. ISO 27001
Business leaders frequently conflate these three because they all sit under the EU cyber security umbrella, but each answers a different question.
The practical relationship is complementary, not competing. NIS2 governs how a hospital, bank, or energy operator runs its own network and reports incidents at the organisational level. The CRA governs the medical device, payment terminal, or smart meter that the company buys and plugs in. ISO 27001 certification can provide useful supporting evidence of a mature security management process, but it does not substitute for CRA conformity assessment or a CE marking. A company can hold ISO 27001 certification and still be non-compliant with the CRA if its products lack an SBOM or a vulnerability handling process.
EU Cyber Resilience Act Timeline and Implementation Deadlines
The CRA does not switch on all at once. It uses a phased timeline that gives manufacturers a runway, but the runway is shorter than most teams assume.
The September 2026 CRA reporting deadline
The September 2026 milestone deserves more attention than it usually gets – it catches companies off guard. From that date, manufacturers must meet a strict vulnerability reporting timeline for any actively exploited vulnerability:
- Within 24 hours of becoming aware of it – an early warning notification.
- Within 72 hours – a detailed follow-up notification.
- Within 14 days of a fix becoming available – a final report, including root cause analysis and corrective measures.
Reports go through the ENISA-operated Single Reporting Platform to the manufacturer's home CSIRT and to ENISA simultaneously.
This reporting duty is not limited to new products. Under the CRA's transitional provisions, products already on the EU market before full application in December 2027 do not retroactively need CE marking or a full conformity assessment, unless they undergo a substantial modification. But the vulnerability reporting obligation applies to every in-scope product on the market from September 2026 onwards, including products your company shipped years ago. A 2019 device with an actively exploited flaw discovered in 2026 still triggers the 24-hour clock.
CRA compliance in Lithuania
Lithuania's cyber security framework runs through the National Cyber Security Centre (NKSC), operating under the Ministry of National Defence. NKSC already serves as the country's main cyber incident response body under the national Law on Cyber Security and its implementing resolution (both available only in Lithuanian on the official Seimas legal register).
As of the most recent national cyber security status report, the Ministry of National Defence, as the authority responsible for CRA implementation in Lithuania, had begun drafting an implementation action plan. The formal designation of Lithuania's CRA notifying authority and market surveillance authority or authorities was still in progress. Businesses operating in Lithuania should treat NKSC as their practical first point of contact for cyber incident matters today, while watching for the formal national designation, expected ahead of the June 2026 notified-body deadline.
CRA compliance in Latvia
Latvia's national cyber authority is CERT.LV, which operates under the Ministry of Defence and already functions as the country's NIS2 competent authority and incident response centre. As with the other Baltic states, formal designation of the specific bodies responsible for CRA market surveillance and notified-body oversight in Latvia is expected to build on this existing structure as the 2026 deadlines approach.
CRA compliance in Estonia
Estonia's Information System Authority (RIA), through its Cyber Security Centre (NCSC-EE), is the country's established cyber security authority and the natural anchor point for CRA-related coordination, mirroring the role RIA already plays under Estonia's Cyber Security Act and the NIS2 framework.
How to Achieve CRA Compliance
Compliance is not a single certificate; it is a sequence of decisions, each of which narrows down what the next one requires. Most manufacturers move through three stages.
How do you classify product risk under the CRA?
Start with product asset mapping: a full inventory of every product with digital elements your company places on the EU market, including white-labelled and OEM products built under your brand. Each product is then checked against the CRA's risk categories: default, Class I, Class II, or critical, based on its core function rather than every feature bundled inside it. This step alone often surprises leadership teams, who discover a ‘simple’ device actually performs a Class II function because of an embedded component.
How do you choose a CRA conformity assessment pathway?
Once a product's risk class is set, the available conformity assessment pathways narrow accordingly. Default-category products can self-assess and issue an EU declaration of conformity directly. Critical products require engaging a notified body, applying harmonised European standards as they become available, or both. Pathway selection should happen early. Notified-body capacity is expected to be tight as the December 2027 deadline approaches, and a six-month assessment queue is not a risk worth discovering in late 2027.
How do you build CRA compliance into engineering workflows?
Companies that handle the CRA well stop treating it as a paperwork exercise and build it into the engineering workflow. That means CI/CD pipeline compliance tracking, automated SBOM extraction on every build rather than a manual exercise before release, secure-by-design development frameworks baked into the SDLC, and continuous vulnerability scanning tied directly to the SBOM so a new CVE against a dependency is flagged automatically. Teams with this tooling in place by mid-2026 will meet the September reporting deadline comfortably. Whereas teams without it will be building the process under the pressure of a live 24-hour clock.
What This Means for Your Business Before 2027
The Cyber Resilience Act turns product cyber security from an engineering preference into a market access requirement. The September 2026 reporting deadline is the one most businesses underestimate. It applies to products already shipped, not just future releases, and it requires a detection-to-disclosure process that most companies do not yet have running end-to-end.
The December 2027 deadline is the bigger structural shift: CE marking without CRA conformity will no longer be possible for in-scope products, and the conformity assessment route a product needs depends entirely on how it gets classified. Getting that classification right now, while there is still time to redesign rather than scramble, is the highest-leverage decision most manufacturers will make this year.
Whether your organisation builds the product, imports it, or distributes it across the Baltic market, the practical next step is the same: map your product portfolio against the CRA's scope and risk tiers, confirm who in your supply chain owns each obligation, and put a vulnerability reporting process in place well before September 2026 arrives. Rather than navigating this alone, businesses can turn to Baltic Amadeus's CRA compliance services to run this assessment and build a clear, prioritised roadmap toward full compliance.
