Artifact GuideEU Cyber Resilience Act

CRA Annex I Essential Cybersecurity Requirements

Translate the Cyber Resilience Act's product-security and vulnerability-handling requirements into controls that engineering, product, and compliance teams can evidence.

This page helps separate risk-based product properties from lifecycle duties, then connect both to technical documentation and release evidence.

Author
Sorena AI
Published
Mar 4, 2026
Updated
Oct 15, 2026
Overview

Annex I contains the Cyber Resilience Act's . Part I point (1) requires an appropriate level of cybersecurity based on risk, while the detailed Part I point (2) product properties apply where relevant on the basis of the cybersecurity risk assessment. Part II defines the manufacturer's vulnerability-handling processes, which apply when the product is placed on the market and throughout the support period.

Section 1

What Article 6 makes Annex I do

Article 6 ties market access to Annex I. A product with digital elements may be made available on the market only if the product meets the applicable Part I requirements and the manufacturer's processes comply with Part II.

That means Annex I should be treated as a conformity argument, not as a generic security wishlist. The useful working file is a requirement register that shows the requirement, the product boundary, the risk assessment outcome, the implemented control, the test or review evidence, and the documentation location.

  • Start with the product as placed on the market, including software versions, intended purpose, reasonably foreseeable use, and relevant remote or integrated components.
  • Use the cybersecurity risk assessment to decide which Part I point (2) requirements apply and how they are implemented.
  • Keep Part II separate as the operating model for vulnerability identification, remediation, testing, disclosure, reporting contact, and secure updates.
  • Where a Part I requirement is not applicable, record the specific product reason and the related risk treatment in the technical documentation.
Section 2

When Annex I becomes a market-access requirement

Annex I applies to all in-scope product categories, not only important or critical products. Classification changes the conformity route; it does not remove the .

Most Annex I obligations apply from 11 December 2027. For products placed on the market before that date, Article 69 generally makes the remaining CRA requirements applicable only if the product undergoes a substantial modification from 11 December 2027. Article 14 reporting starts earlier, on 11 September 2026, and applies to all in-scope products placed on the market before 11 December 2027.

  • Use Annex I now as the design and evidence baseline for products intended for placement on the market from 11 December 2027.
  • For earlier products, keep the placement date and post-2027 modification record with the product file.
  • Do not confuse the Article 69 transition with an exemption from Article 14 reporting.
Section 3

Annex I Part I: product-security outcomes

Part I starts with an overall requirement for an appropriate level of cybersecurity based on the risks, then lists product properties that apply where relevant. The Commission FAQ explains that manufacturers must determine relevance through the cybersecurity risk assessment, and that non-applicability needs a clear justification.

A practical Annex I Part I assessment should therefore avoid yes-or-no labels without evidence. Each answer should point to design choices and tests that show how the product meets the relevant outcome.

  • Known exploitable vulnerabilities: show the vulnerability status and release gate used when the product is placed on the market.
  • Secure by default: document default accounts, exposed services, cryptographic defaults, certificate validation, reset behaviour, and any tailor-made business-user deviation.
  • Security updates: explain how vulnerabilities can be addressed, when automatic security updates are applicable, and how users can opt out or postpone where the CRA requires that choice.
  • Protection controls: map requirements for access control, confidentiality, integrity, data minimisation, availability, attack-surface reduction, exploitation mitigation, logging, and secure removal or transfer of data and settings.
Recommended next step

Turn CRA Annex I requirements into an evidence-backed assessment

Assessment Autopilot can convert CRA Annex I product-security and vulnerability-handling requirements into assigned controls, evidence requests, and review checkpoints in Sorena.

Section 4

Annex I Part II: vulnerability handling during the support period

Part II is not limited to launch readiness. It sets the manufacturer's vulnerability-handling process for the product, including integrated components, throughout the support period.

The CRA does not require the same patch response for every vulnerability, but it does require the manufacturer to assess relevance and risk, then put appropriate remedies in place without delay. A remedy may be a patch, mitigation, configuration guidance, advisory, documentation change, or another suitable measure, depending on the risk.

  • Maintain a vulnerability and component record, including an in a commonly used, machine-readable format covering at least top-level dependencies.
  • Process internal findings, external reports, component vulnerabilities, and third-party information through one triage and remediation workflow.
  • Run effective and regular security tests and reviews, and update the cybersecurity risk assessment where those activities reveal relevant information.
  • Publish information about fixed vulnerabilities once an update is available, including affected products, impact, severity, and clear remediation information, unless a justified short delay is needed so users can apply the fix.
  • Maintain a coordinated vulnerability disclosure policy, a reporting contact, secure update-distribution mechanisms, and free security updates unless the CRA's tailor-made business-user exception applies.
Section 5

Secure-by-design work products to keep

The CRA covers planning, design, development, production, delivery, and maintenance. For Annex I, secure-by-design work is strongest when it produces records that are usable at release review and later by a notified body or market surveillance authority.

The goal is not to publish every internal engineering record. It is to maintain enough traceability to show how the product and the manufacturer's processes meet the applicable Annex I requirements.

  • Product boundary file: product model or version, software affecting compliance, intended purpose, foreseeable use, remote data processing, integrated components, and user-facing security assumptions.
  • Risk and requirement matrix: Annex I point, applicability decision, reason, control design, test method, evidence link, owner, and residual issue handling.
  • Release gate evidence: vulnerability search results, open vulnerability disposition, default-configuration checks, update-channel checks, and user-information review.
  • Lifecycle evidence: vulnerability intake records, triage decisions, remediation plans, security update records, advisory publication records, CVD policy location, and support-period rationale.
  • Reassessment record: product or intended-purpose changes, new interfaces or remote processing, component or support-status changes, vulnerability findings, changed standards, and the resulting risk-assessment, test, documentation, or conformity action.
Section 7

Technical documentation and authority evidence

Article 31 requires technical documentation to contain the data or details used to show that the product and the manufacturer's processes comply with Annex I. Annex VII then specifies the minimum documentation elements, including the cybersecurity risk assessment, vulnerability-handling process information, test reports, standards or alternative solutions, support-period information, and where applicable the .

The Commission FAQ emphasises that technical documentation may be requested by market surveillance authorities and should be comprehensive and clear. It also explains that the risk assessment and documentation should be updated where relevant information emerges after placement on the market.

  • Keep the cybersecurity risk assessment in the technical documentation and link it to the Annex I Part I applicability record.
  • Describe vulnerability-handling processes, including the , CVD policy, reporting contact, and secure update-distribution solution.
  • List harmonised standards, common specifications, certification schemes, or other technical specifications used; where they are not used, describe the alternative solution adopted.
  • Keep test reports, review outputs, EU declaration of conformity records, user-information evidence, and support-period rationale aligned to the product version placed on the market.
  • Treat unsupported assertions such as 'low risk' or 'not applicable' as incomplete unless the file shows the product-specific basis and the control or mitigation chosen.
Primary sources

References and citations

enisa.europa.eu
Referenced sections
  • Background source for coordinated vulnerability disclosure as the process context behind Annex I Part II vulnerability reporting and disclosure controls.
"Coordinated Vulnerability Disclosure is crucial"
ec.europa.eu
Referenced sections
  • Clarifies how Part I applicability is risk-based, how Part II vulnerability handling applies during the support period, and what technical documentation should demonstrate.
"Manufacturers need to comply with all essential cybersecurity requirements related to vulnerability handling"
digital-strategy.ec.europa.eu
Referenced sections
  • Commission overview confirming the CRA's focus on mandatory cybersecurity requirements for product planning, design, development, maintenance, and lifecycle vulnerability handling.
"planning, design, development and maintenance"
data.europa.eu
Referenced sections
  • Primary legal source for Article 6, Article 13, Article 31, Annex I essential cybersecurity requirements, Annex II user information, and Annex VII technical documentation.
"ESSENTIAL CYBERSECURITY REQUIREMENTS"
Show all related guides (55)

CRA Requirements | Annex I, Manufacturer Duties and CE Evidence

Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence.

CRA SBOM and Vulnerability Management Template

Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields.

CRA vs RED Cybersecurity Delegated Act

Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment.

CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates

How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records.

EU CRA Compliance Program for Manufacturers and Economic Operators

Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance.

EU CRA vs UK PSTI Product Security Regime

Compare EU Cyber Resilience Act and UK PSTI product-security scope, duties, evidence, dates, actors, and enforcement for connected products.

EU Cyber Resilience Act Checklist for Product Security and CE Marking

A CRA checklist for products with digital elements: scope, Annex I security controls, vulnerability handling, Article 14 reporting, technical documentation, conformity assessment, CE marking, and support-period evidence.

EU Cyber Resilience Act FAQ

Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance.

EU Cyber Resilience Act Technical Documentation and Audit File

Build a CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, updates, and retention.

CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales

CRA FAQ explaining Blue Guide market-access concepts for products with digital elements: placing on the market, making available, imports, CE marking, operator roles, online sales, stock, and testing exceptions.

CRA CE Marking FAQ | Conformity Assessment, EU Declaration, Evidence

Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence.

CRA Component Due Diligence FAQ | Third-Party Software, FOSS, SBOMs

Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records.

CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products

Cyber Resilience Act FAQ on when manufacturers can use module A, when module B+C or module H is required, and how important and critical products affect the route.

CRA Cybersecurity Risk Assessment FAQ | Article 13, Annex I, Updates

CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence.

CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking

FAQ on the Cyber Resilience Act EU Declaration of Conformity: Annex V contents, simplified Annex VI wording, CE marking link, technical documentation, retention, updates, and operator duties.

CRA Economic Operators FAQ | Manufacturers, Importers, Distributors, Authorised Representatives

CRA FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls.

CRA Essential Cybersecurity Requirements FAQ | Annex I Part I and Part II

CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information.

CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS

FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes.

CRA Harmonised Standards FAQ | Presumption of Conformity, Common Specifications

Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence.

CRA Important and Critical Products FAQ | Annex III, Annex IV, Conformity Assessment

FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences.

CRA Integrated Components and Dependencies FAQ | Third-Party Software and SBOM Evidence

Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility.

CRA Interplay With EU Product Laws FAQ | RED, Machinery, Data Act

Official source CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates.

CRA Known Exploitable Vulnerabilities at Launch FAQ

FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence.

CRA Legacy Products FAQ | Pre-11 December 2027 Products

Cyber Resilience Act FAQ on products placed on the market before 11 December 2027, Article 14 reporting, substantial modification, distributor stock, spare parts, and records.

CRA Manufacturer Obligations FAQ | Article 13, Annex I, CE Marking

FAQ for Cyber Resilience Act manufacturers covering Article 13 duties, risk assessment, Annex I, vulnerability handling, support periods, documentation, conformity assessment, reporting, CE marking, and evidence controls.

CRA Market Surveillance and Enforcement FAQ | Authorities, Corrective Action, Safeguards

Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties.

CRA Module B+C FAQ | EU-Type Examination, Conformity to Type, Notified Bodies

CRA Module B+C FAQ explaining EU-type examination, conformity to type, notified-body evidence, production control, CE marking, declarations, and certificate changes.

CRA Module H FAQ | Full Quality Assurance, Notified Body Surveillance, CE Marking

CRA Module H FAQ explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records.

CRA Notified Bodies FAQ | Scope, Modules B+C and H, Certificates

Practical CRA FAQ on when notified bodies are needed, how CRA bodies are designated, what their notified scope means, and how Module B+C and Module H assessments work.

CRA Open-Source Software FAQ | FOSS Scope, Stewards, Manufacturers

Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations.

CRA Over-the-Air Updates FAQ

Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths.

CRA penalties and fines FAQ | Article 64 fine caps

FAQ on EU Cyber Resilience Act Article 64 penalties: maximum fine tiers, turnover caps, national enforcement, economic operators, reporting duties, and open-source steward carve-outs.

CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope

CRA FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment.

CRA Products With Digital Elements Scope FAQ

EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator boundaries.

CRA Remote Data Processing Solutions FAQ | Product Scope, Cloud and Backend Boundaries

FAQ on how the EU Cyber Resilience Act treats remote data processing solutions, manufacturer-controlled backends, third-party cloud services, SaaS, risk assessment, documentation, and user information.

CRA Reporting Obligations FAQ | Article 14, CSIRTs, ENISA, User Notices

Cyber Resilience Act FAQ on Article 14 reporting for actively exploited vulnerabilities and severe incidents, including timing, CSIRT routing, ENISA access, user notices, and evidence.

CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls

Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products.

CRA Security Updates vs Functionality Updates FAQ

Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review.

CRA Substantial Modification FAQ | Updates, Repairs, Manufacturer Duties

Cyber Resilience Act FAQ on when software updates, repairs, spare parts, and post-market changes become substantial modifications and trigger CRA manufacturer, evidence, and conformity duties.

CRA Support Period FAQ | Expected Product Lifetime, Security Updates, User Information

Practical CRA FAQ on how manufacturers determine support periods, disclose support end dates, keep security updates available, and document support-period evidence.

CRA Tailor-Made Products FAQ | Bespoke Products, Market Placement, Evidence

FAQ on when a bespoke product may be treated as tailor-made under the EU Cyber Resilience Act, what the carve-out changes, and what manufacturers still need to document.

CRA Technical Documentation FAQ | Annex VII Evidence and Technical File

CRA FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access.

CRA Transition Period FAQ | Entry Into Force, Application Dates, Reporting, Legacy Products

CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions.

CRA Update Availability and Software Archives FAQ

FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits.

CRA User Information and Transparency FAQ | Annex II Instructions

Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information.

CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting

Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices.

Cyber Resilience Act Module A FAQ | Internal Production Control

FAQ on when CRA Module A internal production control is available, when it is blocked, and what documentation, testing, standards, and evidence it still requires.

EU Cyber Resilience Act Core Functionality FAQ | CRA Product Classification

CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification.

EU Cyber Resilience Act Repairs and Spare Parts FAQ

CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.