The 21 Cyber Resilience Act requirements manufacturers must meet

What does the Cyber Resilience Act require?

The CRA's ultimate objective is to make products with digital elements in the EU market safer and more resilient against malicious use.

How product manufacturers should achieve that is described in the regulation's annexes. The most important is Annex I, which describes the regulation's 21 essential cybersecurity requirements, split into two parts: Part I lists out 13 product security requirements, and Part II describes 8 vulnerability handling requirements.

What counts as a product with digital elements?

The CRA defines a product with digital elements as a software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately. Here are some examples:

• Hardware: a smart thermostat or an industrial router
• Standalone software: a password manager or an accounting app
• Firmware: the embedded code in a microcontroller sold to device makers
• Borderline case: remote processing, such as a cloud backend, is in scope when the product cannot perform one of its functions without it. Standalone SaaS is out of scope

Article 2 carves out products already covered by sectoral rules: medical devices (Regulations (EU) 2017/745 and 2017/746), motor vehicles, civil aviation (Regulation (EU) 2018/1139), and marine equipment, which are not in scope of this new law.

Where do the CRA requirements sit in the regulation?

Annex I explains the necessary security requirements. The articles around it set the process: Article 13 covers manufacturer duties, Article 14 describes reporting, Article 28 explains the EU declaration of conformity, and Article 30 talks about the CE marking.

Who has to meet the CRA requirements?

• Manufacturers are held accountable to implement the requirements in Annex I in full.
• Importers (according to Article 19) and distributors (mentioned in Article 20) carry verification duties, not the responsibilities listed in Annex I. For example, a distributor does not have to build the technical documentation that a manufacturer is responsible for.
• Open-source software stewards follow a light-touch regime under Article 24. Individual contributors to free and open-source software that is not under their responsibility are out of scope entirely.
• Non-EU manufacturers may appoint an authorized representative in the EU under Article 18. This is optional; importers carry the EU verification duties either way.

What are the 13 product security requirements in Annex I Part I?

These 13 points sit under an umbrella duty: an appropriate level of cybersecurity based on the product's risks. Another way to look at them is by grouping them into different categories like "design and build requirements," "data protection requirements," "access and monitoring requirements," and "availability and update requirements."

Design and build requirements

Security starts before launch: a product must ship with no known exploitable vulnerabilities when it is made available on the market.

It must also be secure by default, with a way to reset it to its original state. The only exception is a tailor-made product where the manufacturer and business user agree on a different setup.

Design must limit the attack surface, including external interfaces. Finally, manufacturers need to include exploitation mitigation, such as sandboxing, so a successful attack does less damage.

Data protection requirements

Data must stay confidential whether it is stored, transmitted, or processed, so use state-of-the-art encryption at rest and in transit. Data, commands, programs, and configurations also need protection against unauthorized changes, and the product must report corruption.

Collect only what is adequate, relevant, and limited to the intended purpose. Users must be able to delete all data and settings permanently and securely, and to transfer data securely where it can move to another product.

Access and monitoring requirements

Protect the product from unauthorized access with authentication and identity and access management, and report possible unauthorized access. The product must also record and monitor relevant internal activity, such as access to or changes in data, services, or functions, and users must be able to opt out.

The opt-out detail can catch teams by surprise. You cannot force logging on users, so detection must still work when they switch it off.

Availability and update requirements

A product's essential and basic functions must stay available, including after an incident, so build in resilience against denial-of-service attacks. Your product must also avoid degrading the services that other devices or networks provide.

Vulnerabilities must be fixable through security updates. Where applicable, automatic security updates should install within an appropriate timeframe and be on by default, with a clear opt-out and the option to postpone.

How the Article 13(2) risk assessment changes what applies to you

The Annex I Part I requirements apply "where applicable," based on your own cybersecurity risk assessment under Article 13(2).

A defensible risk assessment covers the product's intended purpose, foreseeable use, operating environment, assets, and threats. It shows how each requirement is met or why it does not apply, and it belongs in the Annex VII technical documentation.

What are the 8 vulnerability handling requirements in Annex I Part II?

1. Identify and document vulnerabilities and components, including a Software Bill of Materials
2. Address and remediate vulnerabilities without delay, including through security updates
3. Apply effective and regular security tests and reviews
4. Publicly disclose fixed vulnerabilities once an update is available
5. Put in place and enforce a coordinated vulnerability disclosure policy
6. Facilitate information sharing and provide a contact address for vulnerability reports
7. Provide mechanisms to distribute updates securely
8. Disseminate security updates without delay and free of charge

Identifying and documenting vulnerabilities

You must identify and document vulnerabilities and components, including by drawing up a Software Bill of Materials (SBOM). We cover the SBOM rules in more detail later in this guide.

Remediation and security update duties

Once you know about a vulnerability, fix it without delay, usually through a security update.

Where technically feasible, ship security fixes separately from feature updates so users can patch without taking on new functionality.

Keep testing and reviewing the product's security regularly, and distribute every security update without delay and free of charge.

Disclosure duties after a fix ships

Once a security update is available, publicly disclose the fixed vulnerability. Include a description, information to identify the affected product, the impact, the severity, and clear remediation guidance.

You may delay publication where the security risk of disclosure outweighs the benefit, until users have had the chance to patch. That is a judgment call, so record why you made it.

Coordinated vulnerability disclosure policy and security contact

Your coordinated vulnerability disclosure (CVD) policy must be enforced, not just published. You also need a contact address for vulnerability reports and a way to share information about vulnerabilities in your product and its third-party components.

What a practical setup could look like: a security.txt file, a dedicated disclosure page, and a monitored inbox with a response SLA.

Secure update distribution

Distribute updates securely, and security updates automatically where applicable. An insecure update mechanism is a breach even if the patch is effective against a vulnerability.

What does the CRA require in a Software Bill of Materials (SBOM)?

Annex I Part II makes a software bill of materials (SBOM) mandatory. Here's what the CRA requires on format, depth, sharing, and storage.

Which SBOM format does the CRA mandate?

It doesn't mandate a specific format. Instead, it mentions "a commonly used and machine-readable format." For example, SPDX and CycloneDX are market practice.

How deep does the SBOM have to go?

The SBOM must cover "at the very least the top-level dependencies." However, it shouldn't stop there. Transitive dependencies are where exploited vulnerabilities usually live, and your reporting duty applies whatever depth your SBOM reaches.

Do you have to publish your SBOM?

No. The CRA creates no general duty to share your SBOM with customers or third parties. It sits in your technical documentation, available to market surveillance authorities on request.

Where does the SBOM live?

An SBOM lives in the Annex VII technical documentation, kept for at least 10 years or the product's support period, whichever is longer. Keep one SBOM per shipped version of the product, not one static file per product line.

How long is the CRA support period?

The five-year minimum and when a shorter period applies

The product's support period must be at least five years. If expected use is shorter, the support period must match it, but you would need to document your reasoning as to why it would be shorter. The Commission may set longer minimums for specific product categories by delegated act in the future.

How to justify and document the support period?

Article 13(8) names the factors to weigh:

• Reasonable user expectations
• The nature and intended purpose of the product
• Union law on product lifetime
• Support periods of comparable products
• Availability of the operating environment
• Support periods of third-party components that provide core functions
• Guidance from ADCO and the Commission

Record the information you used in the Annex VII technical documentation.

What the support period means for your release roadmap?

A product shipped in 2028 with a five-year support period commits your team to security updates into 2033.

What are the CRA reporting deadlines?

Article 14 sets three deadlines for actively exploited vulnerabilities: within 24 hours, 72 hours, and 14 days.

The 24-hour early warning

Send an early warning without undue delay within 24 hours of becoming aware of an actively exploited vulnerability.

Submit it through ENISA's Single Reporting Platform under Article 16, which notifies the designated CSIRT (Computer Security Incident Response Team)—the national team that coordinates vulnerability handling—and ENISA at the same time. Where applicable, name the Member States where the product has been made available.

The 24-hour deadline still applies to micro and small enterprises, but they can't be fined for missing it. All other reporting deadlines apply in full.

The 72-hour vulnerability notification

Within 72 hours of becoming aware of the exploit, submit a follow-up notification with general information about the product, the general nature of the exploit and vulnerability, corrective or mitigating measures taken, measures users can take, and your own assessment of how sensitive the information is.

The 14-day final report

Submit a final report no later than 14 days after a corrective or mitigating measure becomes available. It must describe the vulnerability, its severity and impact, and, where available, any malicious actor that exploited it.

Severe incidents that affect the security of your product run on a different clock. The 24-hour early warning and 72-hour notification still apply, but the final report is due within one month after you submit the 72-hour incident notification. It must include a detailed description of the incident, its severity and impact, the type of threat or root cause, and the mitigation measures applied or ongoing.

Who you report to and how?

You report simultaneously to the CSIRT designated as coordinator and to ENISA, through the Single Reporting Platform under Article 16. This is not the NIS2 incident reporting route and not a national regulator filing.

What changed on September 11 2026?

Article 14, which lists out these reporting obligations, became enforceable on September 11 2026, ahead of the rest of the regulation. It covers products already on the market and ones you'll be launching in the future.

What documentation does the CRA require?

Technical documentation under Annex VII

The technical documentation covers the product description, design and development information, the cybersecurity risk assessment, vulnerability handling processes, applied standards, and test results. Draw it up before placing the product on the market and keep it current.

EU declaration of conformity under Annex V

It includes product identification, the manufacturer's name and address, a sole-responsibility statement, the object of the declaration, the standards applied, and any notified body involved. Annex VI allows a simplified declaration that links to the full text.

Information and instructions to the user under Annex II

Users must receive the manufacturer's contact point, product identification, intended use, known or foreseeable circumstances leading to significant cybersecurity risk, the vulnerability reporting address, and the support period end date.

The support period end date must reach the user. Documenting it internally is not enough.

How long must CRA documentation be kept?

At least 10 years after the product is placed on the market, or for the support period, whichever is longer.

How do CRA requirements change by product class?

The CRA sorts products into classes by how much damage a compromise could cause: Default, Important Class I, Important Class II, and Critical.

Every class must meet the same 21 requirements. What changes is how you prove conformity: the higher the risk, the more likely it is you need an independent assessment of your product security.

Default products and self-assessment

Most products fit into the "default" category. For these, you check compliance yourself (known as the "module A" internal control procedure), write the technical documentation, and sign the declaration of conformity. No outside assessor is involved. Default products are those not listed in Annex III or Annex IV.

Important products, Annex III Class I

Examples for this class include identity and access management software, browsers, password managers, antimalware, VPNs, network management systems, SIEM, boot managers, PKI software, network interfaces, operating systems, routers and modems, security-related microprocessors and microcontrollers, smart home assistants, smart locks and cameras, connected toys with social or tracking features, and wearables with health tracking or intended for children.

You can self-assess only if you fully apply harmonized standards, common specifications, or a European cybersecurity certification. Otherwise, you'll need a third-party assessment.

Important products, Annex III Class II

This class covers hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, and tamper-resistant microprocessors and microcontrollers. Class II generally needs a higher-assurance, third-party assessment.

Critical products under Annex IV

Critical products are hardware devices with security boxes, smart meter gateways, and smartcards and secure elements. They may be subject to mandatory European cybersecurity certification.