What is the Cyber Resilience Act?

Key takeaways

• The Cyber Resilience Act turns product security into a condition of selling in Europe. Manufacturers must build security in, fix vulnerabilities across a defined support period, and report actively exploited flaws within 24 hours.
• The CRA applies to any product that connects to a device or network, in any sector, which covers most hardware and software sold today.
• Obligations continue for years after launch. A declared support period fixes how long free security updates are owed, and that commitment is published at the point of sale.
• Vulnerability reporting starts first, more than a year ahead of every other obligation, and reaches products sold long before the law existed.
• Companies that fail to comply may face fines, and authorities can also stop their product from being sold in the EU.

The EU has introduced the Cyber Resilience Act, a regulation that sets mandatory cybersecurity requirements for hardware and software sold in Europe. It makes manufacturers responsible for the security of what they build across the working life of the product.

From December 11, 2027, a product with digital elements can be placed on the EU market only if it meets a defined set of cybersecurity requirements, and the CE mark that already signals electrical and product safety will signal cybersecurity too.

The first obligation, vulnerability reporting, takes effect on September 11, 2026, which makes it an immediate concern for manufacturers.

Understanding the Cyber Resilience Act (CRA)

The CRA sets a single baseline for product cybersecurity across all 27 member states. It replaces a patchwork of national rules and voluntary schemes, each with its own definition of “secure enough.” Regulation (EU) 2024/2847 defines the cybersecurity requirements a product must meet, requires the manufacturer to demonstrate it meets them, and keeps that obligation running for as long as the product is expected to be in use.

Three terms determine how far the regulation reaches:

• Product with digital elements. Any hardware or software (and its remote data processing solutions) whose intended or reasonably foreseeable use includes a direct or indirect data connection to a device or network. Components placed on the market separately count as products in their own right.
• Placing on the market. The first time that product is made available in the EU, and the moment obligations attach.
• Substantial modification. A change that alters the intended purpose or affects compliance with the essential requirements. It matters because a product placed on the market before 11 December 2027 falls under the full requirements only if it is substantially modified after that date. Reporting obligations apply either way.

Who the CRA applies to

Anything that sends or receives data is likely covered by the CRA, from a smart thermostat to a mobile app to a network switch. Manufacturers carry most of the obligations, and importers and distributors have checks of their own to run.

Products with digital elements

These products include connected consumer devices, industrial and business hardware, operating systems, mobile and desktop applications, software libraries, and hardware or software components sold separately. Remote data processing solutions are in scope where they are integral to the product. For example, a cloud backend that a device cannot function without is treated as part of that product, while standalone SaaS generally is not.

The exclusions to this rule are narrow, and most of them cover products already governed by other Union legislation, including medical devices, motor vehicles, and marine equipment. Products developed exclusively for national security or defense purposes, or for processing classified information, sit outside scope as well. Free and open-source software sits outside scope unless it is supplied in the course of commercial activity.

Manufacturers carry the primary obligations, including the cybersecurity risk assessment, the essential requirements, technical documentation, conformity assessment, and vulnerability handling.

Importers may place a product on the market only after verifying the manufacturer has met those obligations. Distributors check that the CE marking, contact details, user instructions, and the declared support period are present before making a product available.

An importer or distributor that markets a product under its own name, or substantially modifies it, becomes the manufacturer under the CRA and takes on every obligation that role carries.

The CRA’s global reach

Availability on the EU market triggers the CRA, so a US software vendor selling into Europe carries the same obligations as a manufacturer in Frankfurt. Companies outside the Union may also need an authorized representative established there to work with market surveillance authorities.

The reach extends past the companies directly in scope. Organizations that never ship to the EU still buy from vendors that do, and CRA evidence, such as support period end dates, software bills of materials, and vulnerability disclosure policies, moves down the supply chain through procurement and renewal cycles.

What the CRA requires

Annex I is the section of the regulation that lists the actual cybersecurity requirements. It has two parts, and they apply at different points in a product’s life.

Annex I	Part I	Part II
Focus	Product properties	Vulnerability handling
When it applies	At and before placing on the market	Throughout the support period
What it covers	Secure design and defaults, access control, encryption, logging	Software bill of materials, remediation, disclosure policy, free security updates

Essential cybersecurity requirements

Products must be delivered without known exploitable vulnerabilities and in a secure default configuration that users can reset. Which further requirements apply depends on the manufacturer’s own risk assessment, and anything ruled out has to be justified in the technical documentation.

The rest of Annex I covers access control, protection of data confidentiality and integrity, data minimization, resilience to denial of service, limited attack surfaces, exploitation mitigation, security logging, and secure deletion of data. Confidentiality and integrity are expected to be protected using state-of-the-art encryption where appropriate. For products that rely on certificates and cryptographic keys, this creates an ongoing need to know where those assets are deployed, when they expire, and how they can be replaced, making certificate lifecycle management an important part of CRA readiness.

Vulnerability handling and the SBOM

Part II runs for the entire support period. Manufacturers must identify and document components, remediate vulnerabilities without delay, test regularly, operate a coordinated vulnerability disclosure policy, and distribute security updates free of charge.

The software bill of materials anchors all of it. It has to cover at least the top-level dependencies in a commonly used, machine-readable format, and it has to stay current as the product changes.

Reporting obligations from September 2026

Reporting is the first CRA obligation to take effect, and it applies to products already on the EU market. Two types of events require reporting. The first is a vulnerability in the product that is being actively exploited, and the second is a severe incident affecting the product’s security. Routine bugs and scheduled patches do not qualify.

Once either occurs, reporting happens in three stages:

• An early warning goes out within 24 hours of becoming aware.
• A fuller notification follows within 72 hours.
• A final report is due within 14 days of a corrective or mitigating measure becoming available for an actively exploited vulnerability, or within one month of the 72-hour notification for a severe incident.

Notifications go to the Computer Security Incident Response Team (CSIRT) of the member state where the manufacturer has its main establishment and to the European Union Agency for Cybersecurity (ENISA), submitted through the CRA Single Reporting Platform.

The deadline runs from the moment a manufacturer learns of the exploit, which means the first notification usually goes out while the investigation is still running and no fix exists yet. Microenterprises and small enterprises cannot be fined for missing that deadline, though the duty to report still applies in full.

CRA timeline, conformity, and penalties

The CRA came into force in December 2024, but its obligations arrive in stages across three years. Two dates matter most for manufacturers, and the earlier one is already close.

Date	What applies	Who it affects
10 December 2024	Entry into force	Everyone in scope, clock starts
11 June 2026	Notification of conformity assessment bodies	Member states and notified bodies
11 September 2026	Article 14 reporting obligations	Manufacturers, including for products already on the market
11 December 2027	Full application, CE marking, conformity assessment	Manufacturers, importers, and distributors

Most products reach the CE mark through self-assessment. Manufacturers run the conformity assessment procedure under the internal control module, draw up the EU declaration of conformity, and affix the marking. Important products in class I may self-assess only where harmonized standards or a European cybersecurity certification scheme have been applied, while class II and critical products require a notified body or certification.

Penalties are tiered. Breaching the Annex I essential requirements or the manufacturer obligations in Articles 13 and 14 carries fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher. Other obligations reach €10 million or 2%, and supplying incorrect or misleading information to authorities reaches €5 million or 1%. Market surveillance authorities can also restrict a product, order its withdrawal, or require a recall.

What the CRA means for certificates and keys

Several Annex I requirements come down to cryptography. Certificates protect data in transit and at rest, signing keys prove that a software update is genuine, and machine identities determine which systems a product will trust, which means each of them has to be issued, rotated, and revoked correctly.

Those obligations do not end at launch. A support period running five years or longer means the certificates, keys, and algorithms chosen at design time have to hold up across the whole window, and the technical documentation has to show they still do whenever a market surveillance authority asks.

Once 47-day certificate validity takes full effect in 2029, every public TLS certificate in a product will need replacing roughly eight times a year, which runs to several hundred renewals across a single support period.

Manual tracking does not remain viable at that scale. Certificate lifecycle management becomes part of the evidence a manufacturer produces, covering which certificates and keys a product depends on, whether they meet policy, and how quickly they can be replaced when an algorithm or a certificate authority changes.

How to prepare for the CRA

Preparation splits along the two deadlines. September 2026 calls for a reporting process that works under pressure, while December 2027 calls for documented proof that a product meets the requirements.

1. Confirm scope per product. Establish whether each product has a data connection, whether it falls under an exclusion, and whether it sits in an important or critical category.
2. Stand up the reporting path. Put in place a coordinated vulnerability disclosure policy, a named security contact, a live inventory of the machine identities and components each product relies on, and a route from first awareness to filed notification inside 24 hours. This is the September 2026 obligation.
3. Build the SBOM and keep it current. It feeds both the reporting path and the Part II requirements, so treat it as build output.
4. Work Annex I clause by clause. Record the risk assessment, how each requirement is met, and a justification wherever one does not apply. This is the longest stage and produces most of the technical file.
5. Set the support period deliberately. Declare at least five years unless the product is expected to be in use for less, publish the end date at the point of sale, and keep every issued update available for 10 years after release. A product sold in 2027 on those terms commits its cryptography into the 2030s, which is inside the window where the post-quantum standards NIST finalized in 2024 take hold.

How AppViewX supports CRA readiness

Most of the preparation above is process work that sits with engineering and compliance teams. Certificates and keys are the exception, because they need managing continuously for the length of the support period, at a volume that grows as certificate lifetimes shrink. The AppViewX platform is built for that part of the problem, helping enterprise IT and security teams with:

• Discovery and inventory. Certificate discovery across hybrid and multi-cloud estates tracks where cryptography is deployed, when it expires, and which algorithms it uses.
• Signing key protection. Code signing keys stay in FIPS-certified HSMs under one policy across the CI/CD pipeline, so every update a product ships can be authenticated.
• Evidence on demand. Market surveillance authorities can request the technical documentation at any point, and the cryptographic portion of that file is far easier to produce from a live inventory than assembled retrospectively.
• Support period commitments. Crypto-agility becomes an obligation once a support period runs into the 2030s, which is why post-quantum readiness belongs in CRA planning now.