---
title: "CRA Requirements"
canonical_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/requirements"
source_url: "https://www.sorena.io/artifacts/eu/cyber-resilience-act/requirements"
author: "Sorena AI"
description: "Map Cyber Resilience Act requirements from Annex I to manufacturer duties, vulnerability handling, user information, technical documentation, declaration of conformity, and CE marking evidence."
published_at: "2026-03-04"
updated_at: "2026-07-16"
keywords:
  - "Cyber Resilience Act requirements"
  - "CRA Annex I"
  - "CRA manufacturer obligations"
  - "CRA vulnerability handling"
  - "CRA technical documentation"
  - "CRA declaration of conformity"
  - "CRA CE marking"
  - "EU compliance"
  - "Cyber Resilience Act"
  - "CRA requirements"
  - "Annex I"
  - "Products with digital elements"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# CRA Requirements

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

*Artifact Guide* *EU*

## 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.

The CRA requirements are not just a checklist of technical controls. 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 CE marking. Articles 18 to 23 add checks for authorised representatives, importers, distributors, and actors that rebrand or substantially modify products. Article 24 sets a separate obligation set for open-source software stewards.

## 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.

## Annex I Part II: Vulnerability handling requirements

Annex I Part II covers the manufacturer's vulnerability handling process. These requirements run through the support period 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 SBOM 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*

*Placement: after the requirement breakdown*

## 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.

- [Open Assessment Autopilot](/solutions/assessment.md): Create a CRA requirements assessment with owners, evidence requests, and review checkpoints for a product with digital elements.
- [Discuss CRA implementation](/contact.md): Review product scope, Annex I mapping, vulnerability handling, and conformity evidence gaps.

## 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 should 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 should 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 support period using expected use, reasonable user expectations, product nature and intended purpose, relevant Union law, comparable products, operating environment, and core component support periods; record the basis in technical documentation.
- 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.

## 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.

## 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 substantial modification.

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 and must at least be able to keep the EU declaration of conformity and technical documentation available for authorities where that task is assigned.
- Importers must check that the conformity assessment has been carried out, technical documentation exists, CE marking 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 CE marking 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 fosters secure development, effective vulnerability handling, voluntary reporting, and sharing of vulnerability information in the open-source community.

## Documentation, conformity assessment, declaration, and CE marking

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

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 should include product description, software versions affecting compliance, user information, architecture and design information, production and monitoring processes, vulnerability handling specifications, SBOM and CVD evidence, risk assessment, support-period rationale, standards or specifications used, test reports, and the declaration of conformity.
- The EU declaration of conformity states that the applicable Annex I requirements have been demonstrated and, where multiple EU harmonisation laws apply, should be a single declaration covering the relevant Union acts.
- CE marking 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 support period, whichever is longer, where the relevant CRA provision applies.

## Primary sources

- [Regulation (EU) 2024/2847, Cyber Resilience Act, Official Journal](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng?ref=sorena.io) - 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.
  - Quote: "essential cybersecurity requirements"
- [European Commission FAQ on the Cyber Resilience Act, version 1.2, January 2026](https://ec.europa.eu/newsroom/dae/redirection/document/122331?ref=sorena.io) - 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.
  - Quote: "The CRA does not require manufacturers to ensure that a product is free from all vulnerabilities."
- [European Commission Cyber Resilience Act policy page](https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act?ref=sorena.io) - Official Commission overview for CRA policy context and the role of horizontal cybersecurity requirements for products with digital elements.
  - Quote: "Cyber Resilience Act"

## Related Topic Guides

- [CRA Applicability Test for Products With Digital Elements](/artifacts/eu/cyber-resilience-act/applicability-test.md): Check whether the EU Cyber Resilience Act applies to a hardware, software, firmware, open-source, or connected product before conformity planning.
- [CRA Article 14 Reporting Obligations for Vulnerabilities and Incidents](/artifacts/eu/cyber-resilience-act/reporting-obligations.md): Article 14 guide to CRA reports for actively exploited vulnerabilities and severe product-security incidents, including deadlines, CSIRT routing, users, and evidence.
- [CRA Blue Guide Concepts FAQ | Placing on the Market, Making Available, Distance Sales](/artifacts/eu/cyber-resilience-act/faq/blue-guide-concepts.md): 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](/artifacts/eu/cyber-resilience-act/faq/ce-marking.md): 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](/artifacts/eu/cyber-resilience-act/faq/component-due-diligence.md): 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 and CE Marking](/artifacts/eu/cyber-resilience-act/conformity-assessment-and-ce-marking.md): How to choose a Cyber Resilience Act conformity route, prepare technical documentation, issue the EU declaration of conformity, and affix CE marking.
- [CRA Conformity Assessment Routes FAQ | Module A, Module B+C, Module H, Important and Critical Products](/artifacts/eu/cyber-resilience-act/faq/conformity-assessment-routes.md): 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](/artifacts/eu/cyber-resilience-act/faq/cybersecurity-risk-assessment.md): CRA FAQ on Article 13 cybersecurity risk assessments, Annex I applicability, intended purpose, foreseeable use, technical documentation, and update evidence.
- [CRA deadlines and compliance calendar | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/deadlines-and-compliance-calendar.md): Track the Cyber Resilience Act entry into force, staged application dates, Article 14 reporting deadlines, transitional rules, and review dates.
- [CRA Declaration of Conformity FAQ | Annex V, Simplified Declaration, CE Marking](/artifacts/eu/cyber-resilience-act/faq/declaration-of-conformity.md): 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](/artifacts/eu/cyber-resilience-act/faq/economic-operators.md): 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](/artifacts/eu/cyber-resilience-act/faq/essential-cybersecurity-requirements.md): CRA FAQ on Annex I product cybersecurity requirements, vulnerability handling, secure-by-default design, risk assessment, documentation, lifecycle duties, and user information.
- [CRA Essential Cybersecurity Requirements in Annex I](/artifacts/eu/cyber-resilience-act/essential-cybersecurity-requirements.md): An official source guide to the Cyber Resilience Act Annex I requirements for product security, vulnerability handling, secure-by-design controls, documentation, and evidence.
- [CRA Hardware and Software Boundaries FAQ | Product Scope, Components, RDPS](/artifacts/eu/cyber-resilience-act/faq/hardware-software-boundaries.md): 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](/artifacts/eu/cyber-resilience-act/faq/harmonised-standards-and-common-specifications.md): 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](/artifacts/eu/cyber-resilience-act/faq/important-and-critical-products.md): 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](/artifacts/eu/cyber-resilience-act/faq/integrated-components-and-dependencies.md): 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](/artifacts/eu/cyber-resilience-act/faq/interplay-with-other-eu-laws.md): 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](/artifacts/eu/cyber-resilience-act/faq/known-exploitable-vulnerabilities-at-launch.md): 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](/artifacts/eu/cyber-resilience-act/faq/legacy-products.md): 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](/artifacts/eu/cyber-resilience-act/faq/manufacturer-obligations.md): 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](/artifacts/eu/cyber-resilience-act/faq/market-surveillance-and-enforcement.md): 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](/artifacts/eu/cyber-resilience-act/faq/module-b-c.md): 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](/artifacts/eu/cyber-resilience-act/faq/module-h.md): 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](/artifacts/eu/cyber-resilience-act/faq/notified-bodies.md): 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](/artifacts/eu/cyber-resilience-act/faq/open-source-software.md): 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](/artifacts/eu/cyber-resilience-act/faq/over-the-air-updates.md): 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](/artifacts/eu/cyber-resilience-act/faq/penalties-and-fines.md): 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 Penalties and Fines: Article 64 Caps and Enforcement Context](/artifacts/eu/cyber-resilience-act/penalties-and-fines.md): 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.
- [CRA Product Families FAQ | Variants, Shared Assessments, Family Reuse, Conformity Scope](/artifacts/eu/cyber-resilience-act/faq/product-families.md): 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 | EU Cyber Resilience Act](/artifacts/eu/cyber-resilience-act/products-with-digital-elements-scope.md): Apply the EU Cyber Resilience Act scope test for software, hardware, remote data processing, components, open-source software, exclusions, and economic-operator roles.
- [CRA Products With Digital Elements Scope FAQ](/artifacts/eu/cyber-resilience-act/faq/scope-and-products-with-digital-elements.md): 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](/artifacts/eu/cyber-resilience-act/faq/remote-data-processing-solutions.md): 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](/artifacts/eu/cyber-resilience-act/faq/reporting-obligations.md): 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 SBOM and Vulnerability Management Template](/artifacts/eu/cyber-resilience-act/sbom-and-vulnerability-management-template.md): Build a CRA-ready SBOM and vulnerability handling record with component inventory, triage, remediation, disclosure, reporting, update, and technical documentation fields.
- [CRA Secure-by-Default FAQ | Default Configuration and Annex I Controls](/artifacts/eu/cyber-resilience-act/faq/secure-by-default.md): 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](/artifacts/eu/cyber-resilience-act/faq/security-updates-vs-functionality-updates.md): 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](/artifacts/eu/cyber-resilience-act/faq/substantial-modification.md): 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](/artifacts/eu/cyber-resilience-act/faq/support-period.md): 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](/artifacts/eu/cyber-resilience-act/faq/tailor-made-products.md): 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](/artifacts/eu/cyber-resilience-act/faq/technical-documentation.md): 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](/artifacts/eu/cyber-resilience-act/faq/transition-period.md): 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](/artifacts/eu/cyber-resilience-act/faq/update-availability-and-archives.md): 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](/artifacts/eu/cyber-resilience-act/faq/user-information-and-transparency.md): Practical CRA FAQ on Annex II user instructions, support-period disclosure, vulnerability contacts, update notices, importer and distributor information.
- [CRA vs RED Cybersecurity Delegated Act](/artifacts/eu/cyber-resilience-act/cra-vs-red-cybersecurity-delegated-act.md): 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 vs UK PSTI Act | Cyber Resilience Act Comparison](/artifacts/eu/cyber-resilience-act/cra-vs-uk-psti-act.md): Compare cited EU Cyber Resilience Act duties with UK PSTI planning points, with UK legal details clearly marked for separate source review.
- [CRA Vulnerability Handling and Disclosure | Article 14 Reporting and Security Updates](/artifacts/eu/cyber-resilience-act/vulnerability-handling-and-disclosure.md): How EU Cyber Resilience Act manufacturers should run vulnerability intake, remediation, coordinated disclosure, Article 14 reporting, secure updates, and evidence records.
- [CRA Vulnerability Handling FAQ | Support Periods, Components, Reporting](/artifacts/eu/cyber-resilience-act/faq/vulnerability-handling.md): 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](/artifacts/eu/cyber-resilience-act/faq/module-a.md): 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 CRA Compliance Program for Manufacturers and Economic Operators](/artifacts/eu/cyber-resilience-act/compliance.md): Build a Cyber Resilience Act compliance program around product scope, Annex I security requirements, conformity assessment, technical documentation, vulnerability reporting, and market surveillance.
- [EU Cyber Resilience Act Checklist for Product Security and CE Marking](/artifacts/eu/cyber-resilience-act/checklist.md): 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 Core Functionality FAQ | CRA Product Classification](/artifacts/eu/cyber-resilience-act/faq/core-functionality.md): 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 FAQ](/artifacts/eu/cyber-resilience-act/faq.md): 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 Repairs and Spare Parts FAQ](/artifacts/eu/cyber-resilience-act/faq/repairs-and-spare-parts.md): CRA FAQ for repairs, spare parts, legacy products, security updates, substantial modification, and responsibility after product changes.
- [EU Cyber Resilience Act Technical Documentation and Audit File](/artifacts/eu/cyber-resilience-act/technical-documentation-and-audit-file.md): Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention.


---

[Privacy Policy](https://www.sorena.io/privacy.md) | [Terms of Use](https://www.sorena.io/terms-of-use.md) | [DMCA](https://www.sorena.io/dmca.md) | [About Us](https://www.sorena.io/about-us.md)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/eu/cyber-resilience-act/requirements.md