- 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"
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.
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.
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.
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.
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.
Assessment Autopilot can convert CRA Annex I product-security and vulnerability-handling requirements into assigned controls, evidence requests, and review checkpoints in Sorena.
Create an Annex I requirements register with owners, applicability decisions, control evidence, and documentation gaps.
Review your current product-security process, technical-documentation gaps, and vulnerability-handling evidence.
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.
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.
A standard or guidance document can help design and test a control, but it creates a CRA presumption of conformity only when the legal conditions for that effect are met and only for the requirements it covers. Keep the product-specific risk assessment and any uncovered Annex I requirement in the file.
Use a crosswalk with four columns: CRA outcome, product-specific control, implementation source, and evidence. Record whether the source is a harmonised standard cited in the Official Journal, a common specification, a certification scheme with recognised effect, or supporting technical guidance.
Sources (7)
Primary source for presumption of conformity, common specifications, and essential cybersecurity requirements.
Supporting consumer IoT security baseline; use its provisions only for the controls and product types they address.
Supporting assessment methodology for the consumer IoT baseline.
Supporting process reference for vulnerability intake and disclosure.
Supporting process reference for vulnerability investigation and remediation.
Supporting organisational information-security management reference.
Supporting organisational information-security risk-management reference.
"Coordinated Vulnerability Disclosure is crucial"
"Manufacturers need to comply with all essential cybersecurity requirements related to vulnerability handling"
"planning, design, development and maintenance"
"ESSENTIAL CYBERSECURITY REQUIREMENTS"
Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning.
Article 14 guide to CRA reports for actively exploited vulnerabilities and severe product-security incidents, including deadlines, CSIRT routing, users, and evidence.
How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking.
Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates.
Article 64 of the EU Cyber Resilience Act sets administrative fine ceilings for Annex I, manufacturer, reporting, economic-operator, notified-body, and information-request breaches.
Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles.
Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence.
Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields.
Compare the EU Cyber Resilience Act with the RED cybersecurity delegated act for connected and radio equipment, including scope, timing, evidence, and transition treatment.
How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records.
Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance.
Compare EU Cyber Resilience Act and UK PSTI product-security scope, duties, evidence, dates, actors, and enforcement for connected products.
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.
Direct CRA FAQ answers on scope, economic-operator roles, essential requirements, vulnerability reporting, conformity assessment, CE marking, support periods, and market surveillance.
Build a CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, updates, and retention.
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.
Practical CRA CE marking answers for products with digital elements: conformity assessment, EU declaration, technical documentation, standards, software placement, and launch evidence.
Cyber Resilience Act FAQ on manufacturer due diligence for integrated components, third-party software, FOSS dependencies, SBOMs, vulnerability handling, and evidence records.
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 FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence.
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 FAQ on economic-operator roles: manufacturers, importers, distributors, authorised representatives, substantial modification, traceability, and evidence controls.
CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information.
FAQ on Cyber Resilience Act hardware and software boundaries: combined products, standalone software, source code, components, remote data processing, SaaS and market-placement changes.
Cyber Resilience Act FAQ on how harmonised standards, common specifications, certification schemes, and OJ publication affect CRA conformity evidence.
FAQ on CRA important and critical products, Annex III and Annex IV classification, core functionality, and conformity assessment consequences.
Cyber Resilience Act FAQ on integrated components, third-party software, remote data processing, SBOM-style evidence, upstream fixes, FOSS dependencies, and manufacturer responsibility.
Official source CRA FAQ on overlap with the Radio Equipment Directive, Machinery Regulation, GPSR, Data Act, exclusions, declarations, documentation, and existing certificates.
FAQ for Cyber Resilience Act launch decisions: known exploitable vulnerabilities, CVEs, component flaws, secure-by-default settings, release gates, Article 14 reporting, and evidence.
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.
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.
Cyber Resilience Act FAQ on market-surveillance authorities, investigations, corrective action, withdrawal, recall, safeguards, sweeps, documentation access, and penalties.
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 explaining the full-quality-assurance route, notified-body assessment, quality-system scope, technical documentation, CE marking, declarations, and records.
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.
Cyber Resilience Act FAQ for free and open-source software: commercial activity, steward duties, manufacturer due diligence, vulnerability handling, public documentation, and user obligations.
Cyber Resilience Act FAQ on OTA updates, automatic security updates, secure update distribution, support-period evidence, and offline update paths.
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 FAQ on product families, variant grouping, shared technical documentation, conformity evidence, and when cybersecurity-relevant differences need separate assessment.
EU Cyber Resilience Act FAQ on products with digital elements, software, firmware, remote data processing, components, exclusions, market placement, and CRA operator 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.
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.
Cyber Resilience Act FAQ on secure-by-default configuration, automatic security updates, attack surface reduction, authentication, data minimisation, user information, and tailor-made products.
Cyber Resilience Act FAQ on classifying security updates, functionality updates, support-period duties, automatic updates, user notices, and substantial-modification review.
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.
Practical CRA FAQ on how manufacturers determine support periods, disclose support end dates, keep security updates available, and document support-period 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 FAQ explaining Annex VII technical documentation, risk assessment evidence, conformity assessment files, vulnerability handling records, product families, RDPS, language, and authority access.
CRA FAQ on the transition period covering entry into force, 2026 reporting, 2027 application, legacy products, stock, customs timing, and software versions.
FAQ on CRA security-update availability, support-period notices, optional public software archives, historical versions, and Article 13(10) software-version limits.
Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information.
Practical CRA FAQ on vulnerability handling: SBOMs, remediation, coordinated disclosure, component issues, security updates, support periods, Article 14 reporting, and user notices.
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.
CRA FAQ on core functionality, product boundaries, remote data processing, integrated components, ancillary functions, and software changes that affect product classification.
CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.