Artifact GuideEU

Cyber Resilience Act Requirements

A practical map of the CRA requirements that decide whether a product with digital elements can be placed on the EU market.

Use it to connect Annex I controls, vulnerability handling, Article 13 manufacturer duties, user information, and conformity evidence.

Back to main artifact Review sources

Author

Sorena AI

Published

Mar 4, 2026

Updated

Jul 31, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published Mar 4, 2026

Updated Jul 31, 2026

Overview

The CRA combines technical controls with lifecycle and market-access duties. Annex I sets product-security properties and vulnerability handling requirements. Article 13 turns those requirements into manufacturer obligations across risk assessment, component due diligence, support periods, technical documentation, conformity assessment, user information, corrective action, and . Articles 18 to 23 add checks for authorised representatives, importers, distributors, and actors that rebrand a product or make a . Article 24 sets a separate obligation set for open-source software stewards.

Section 1

Apply the requirements on the correct date

The CRA is already in force, but its obligations apply in stages. Chapter IV on notified bodies has applied since 11 June 2026. Article 14 reporting applies from 11 September 2026. The remaining requirements generally apply from 11 December 2027.

Article 69 generally subjects a product placed on the market before 11 December 2027 to the remaining CRA requirements only if it undergoes a from that date. Article 14 is an express exception: its reporting duties apply to all earlier products that fall within CRA scope. A requirements register should therefore distinguish product scope, placement date, support status, reporting applicability, and later substantial modification.

Prepare Article 14 reporting for earlier in-scope products before 11 September 2026.
Use the full Annex I, Article 13, documentation, conformity, declaration, and set for products first placed on the market from 11 December 2027.
For earlier products changed from 11 December 2027, document whether the change is substantial before deciding which requirements apply.
Treat Commission FAQs as non-binding implementation assistance and the March 2026 guidance as a draft, not as additional legal requirements.
Reassess the requirements register when intended purpose, product functions, architecture, remote processing, components, support assumptions, standards, classification, operator role, or the conformity route changes.

Section 2

Annex I Part I: Product security properties

Annex I Part I is the starting point for engineering teams. Products with digital elements must be designed, developed, and produced to provide an appropriate level of cybersecurity based on risk. The detailed properties apply on the basis of the manufacturer cybersecurity risk assessment and where applicable, so the record should show both implemented requirements and justified non-applicability.

Useful evidence is not a generic security statement. It is a requirement-by-requirement mapping from product architecture, intended purpose, reasonably foreseeable use, and operating environment to the controls, tests, and user instructions that make the requirement true for this product.

Known exploitable vulnerabilities: show release gates, vulnerability triage, component checks, and launch decisions that support placing the product on the market without known exploitable vulnerabilities.
Secure by default and updateability: document default configuration, reset capability, security-update mechanism, automatic update behavior where applicable, opt-out or postponement controls, and user notifications.
Access, confidentiality, integrity, availability, and data minimisation: map authentication or access controls, encryption or other protection measures, corruption reporting, resilience measures, and data minimisation choices to product risks.
Attack surface, incident impact, activity logging, and data removal: show external interface review, exploitation mitigation, relevant security logging with user opt-out where required, and secure removal or transfer of user data and settings.

Section 3

Annex I Part II: Vulnerability handling requirements

Annex I Part II covers the manufacturer's vulnerability handling process. These requirements run through the and cover the product as a whole, including integrated components. They are separate from Article 14 reporting, but they feed the same operational evidence base.

The Commission FAQ clarifies that the CRA does not require a patch for every discovered vulnerability in every circumstance. The manufacturer must assess relevance and risk, then put remedies in place without delay in relation to the risk. Remedies can include patches, security updates, mitigations, advisories, configuration guidance, documentation updates, or component replacement where needed.

Identify and document vulnerabilities and components, including an in a commonly used and machine-readable format covering at least top-level dependencies.
Address and remediate vulnerabilities without delay in relation to the risk, and provide new security updates separately from functionality updates where technically feasible.
Run effective and regular security tests and reviews, update the cybersecurity risk assessment where relevant, and keep the vulnerability history aligned with technical documentation.
Maintain and enforce a coordinated vulnerability disclosure policy, provide a contact address for vulnerability reports, securely distribute updates, and disclose fixed-vulnerability information once an update is available unless a justified delay is needed.
Disseminate available security updates without delay and, unless a tailor-made business-user arrangement says otherwise, free of charge with advisory messages explaining relevant user action.

Recommended next step

Convert CRA requirements into product evidence

Use Assessment Autopilot to turn the CRA requirements map into owned product-security controls, vulnerability handling evidence, support-period rationale, documentation tasks, and conformity review checkpoints.

Assessment workflow

Open Assessment Autopilot

Create a CRA requirements assessment with owners, evidence requests, and review checkpoints for a product with digital elements.

Explore next step

Talk to Sorena

Discuss CRA implementation

Review product scope, Annex I mapping, vulnerability handling, and conformity evidence gaps.

Explore next step

Section 4

Article 13: Manufacturer obligations that connect the requirements

Article 13 is the operating model for manufacturers. Before market placement, the manufacturer must ensure the product is designed, developed, and produced in accordance with Annex I Part I and that its processes meet Annex I Part II. The cybersecurity risk assessment must be used during planning, design, development, production, delivery, and maintenance.

The risk assessment must cover intended purpose, reasonably foreseeable use, conditions of use such as operational environment and assets to be protected, and the length of time the product is expected to be in use. If a product-specific Annex I requirement is not applicable, the technical documentation must contain a clear justification rather than silently omitting it.

Keep a risk assessment that explains applicable Annex I Part I requirements, non-applicable requirements, residual risks, testing, and assurance.
Exercise due diligence for third-party and open-source components so they do not compromise product cybersecurity; useful checks include update history, vulnerability databases, security testing, and conformity evidence where available.
Determine the so that it reflects expected use, taking into account in particular reasonable user expectations, product nature and intended purpose, and relevant Union law. The manufacturer may also consider comparable products, the availability of the operating environment, and core component support periods. Record the basis in technical documentation.
Set the at no less than five years unless the product is expected to be used for less than five years, in which case it must match that shorter expected use time.
Prepare user information under Annex II, including manufacturer contact details, vulnerability reporting point, intended purpose, security environment, significant risk circumstances, support end date, update instructions, decommissioning guidance, and declaration of conformity access where applicable.
When the product or the manufacturer's processes are not in conformity, take corrective measures immediately, or withdraw or recall the product as appropriate.

Section 5

Article 14 reporting is related, but not the same requirement

Article 14 creates mandatory reporting duties for manufacturers when they become aware of an actively exploited vulnerability in the product or a severe incident affecting the product's security. Those notifications go through the ENISA single reporting platform to the relevant CSIRT coordinator and ENISA.

For requirements work, the important point is that reporting readiness depends on the same evidence system as vulnerability handling: product identifiers, affected versions, severity and impact, exploit evidence, mitigations, security update status, user communications, and component origin.

Actively exploited vulnerabilities require an early warning within 24 hours, a vulnerability notification within 72 hours unless already covered, and a final report no later than 14 days after a corrective or mitigating measure is available.
Severe incidents affecting product security require an early warning within 24 hours, an incident notification within 72 hours unless already covered, and a final report within one month after the incident notification.
Impacted users, and where appropriate all users, must be informed of the vulnerability or incident and any risk mitigation or corrective measures users can deploy.

Section 6

Economic operator and open-source steward duties

The CRA requirements page should not treat the manufacturer as the only relevant actor. Importers and distributors have verification, due-care, corrective-action, vulnerability escalation, authority cooperation, and document-retention duties. An importer or distributor can also become subject to manufacturer obligations if it places a product on the market under its own name or trademark or carries out a .

Open-source software stewards have a lighter and separate regime. They do not become manufacturers merely because they support an open-source project, but Article 24 still requires a documented cybersecurity policy and cooperation with market surveillance authorities.

Authorised representatives act within a written mandate, which must at least allow them to keep the EU declaration of conformity and technical documentation available for market surveillance authorities.
Importers must check that the conformity assessment has been carried out, technical documentation exists, and declaration are present, Annex II information is supplied, and manufacturer contact obligations are met before placing the product on the market.
Distributors must act with due care, verify and required documents before making the product available, and avoid making products available where they know or have reason to believe the product or manufacturer processes are not compliant.
Open-source software stewards must document a cybersecurity policy that supports secure development, effective vulnerability handling, voluntary reporting, and sharing of vulnerability information in the open-source community.

Section 7

Documentation, conformity assessment, declaration, and CE marking

The CRA requirements become market evidence through technical documentation, conformity assessment, the EU declaration of conformity, and . Article 31 requires technical documentation before placing the product on the market and continuous updates where appropriate at least during the .

Article 32 provides conformity routes: internal control based on module A, EU-type examination based on module B followed by module C, full quality assurance based on module H, or an applicable European cybersecurity certification scheme where available. Which route is available depends on the product category, use of harmonised standards, common specifications, or applicable certification, and whether the product is important or critical under the CRA.

Technical documentation must include product description, software versions affecting compliance, user information, architecture and design information, production and monitoring processes, vulnerability handling specifications, and CVD evidence, risk assessment, support-period rationale, standards or specifications used, test reports, and the declaration of conformity, as applicable to the product.
The EU declaration of conformity states that the applicable Annex I requirements have been demonstrated and, where multiple EU harmonisation laws apply, must be a single declaration covering the relevant Union acts.
cannot be treated as a design asset. It is affixed before placing the product on the market after a positive conformity assessment, visibly and legibly to the product where possible, or for software to the declaration of conformity or an easily accessible accompanying website section.
Keep declaration and technical documentation available to authorities for at least 10 years after placement on the market or for the , whichever is longer, where the relevant CRA provision applies.

Primary sources

References and citations

European Commission CRA reporting obligations

digital-strategy.ec.europa.eu

Referenced sections

Current Commission implementation page for the 11 September 2026 Article 14 start, report stages and Single Reporting Platform.

European Commission Cyber Resilience Act policy page

digital-strategy.ec.europa.eu

Referenced sections

Official Commission overview for CRA policy context and the role of horizontal cybersecurity requirements for products with digital elements.

"Cyber Resilience Act"

European Commission FAQ on the Cyber Resilience Act, version 1.3, July 2026

ec.europa.eu

Referenced sections

Clarifies risk-based application of Annex I, vulnerability remediation expectations, component handling, support-period criteria, technical documentation, conformity assessment routes, declaration of conformity, and CE marking.

"The CRA does not require manufacturers to ensure that a product is free from all vulnerabilities."

Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal

eur-lex.europa.eu

Referenced sections

Primary legal text for Annex I product-security and vulnerability handling requirements, Article 13 manufacturer obligations, Article 14 reporting, Articles 18 to 24 economic-operator and open-source steward duties, Article 31 technical documentation, Article 32 conformity assessment, and CE marking rules.