Artifact GuideEU

EU Cyber Resilience Act Compliance Program

A product-by-product compliance architecture for manufacturers, importers, distributors, and other economic operators.

Use the CRA to connect secure design, conformity assessment, technical documentation, vulnerability handling, reporting, and market surveillance response.

Author
Sorena AI
Published
Mar 4, 2026
Updated
May 25, 2026
Sections
6

Structured answer sets in this page tree.

Primary sources
3

Cited legal and guidance references.

Publication metadata
Sorena AI
Published Mar 4, 2026
Updated May 25, 2026
Overview

A CRA compliance program should be built around each product with digital elements and the processes used to design, develop, produce, maintain, and support it. The practical output is not a standalone policy: it is a product compliance file that proves how Annex I requirements, CE marking, vulnerability handling, reporting, and economic-operator duties are controlled across the product lifecycle.

Section 1

Start with product scope and operator roles

The CRA applies to products with digital elements made available on the Union market when their intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network. The compliance program should therefore begin with a product inventory that records the product, software versions that affect cybersecurity compliance, remote data processing dependencies, intended purpose, reasonably foreseeable use, market channel, and support period.

Role assignment matters because the CRA places different obligations on manufacturers, authorised representatives, importers, distributors, open-source software stewards, and other operators. Importers and distributors also become subject to manufacturer obligations when they place a product on the market under their own name or trademark or substantially modify a product already placed on the market.

  • Create a CRA product file for each product family, with the exact product boundary and any remote data processing solution needed for product functions.
  • Record the manufacturer, authorised representative where used, Union importer, distributors, and any operator that may become the manufacturer because of branding or substantial modification.
  • Classify whether the product is ordinary, important class I, important class II, or critical, because that classification drives the conformity assessment route.
  • Capture exclusions or overlaps with sectoral Union law only when the product file explains the legal basis and the requirement coverage.
Section 2

Turn Annex I into engineering release controls

Article 13 requires manufacturers to design, develop, and produce products in line with the essential cybersecurity requirements in Annex I Part I, and to operate vulnerability handling processes in line with Annex I Part II. The risk assessment must be documented, updated during the support period, and used during planning, design, development, production, delivery, and maintenance.

For engineering teams, Annex I should be translated into release gates, not left as legal text. Each gate should produce evidence that can be reused in the technical documentation and in market surveillance responses.

  • Risk assessment: intended purpose, foreseeable use, operating environment, assets to protect, threat assumptions, applicable Annex I requirements, and justified non-applicability decisions.
  • Secure product controls: no known exploitable vulnerabilities at market placement, secure-by-default configuration, access control, confidentiality, integrity, availability, attack-surface reduction, incident-impact reduction, security logging where applicable, and secure data removal.
  • Component controls: software bill of materials covering at least top-level dependencies, third-party component due diligence, vulnerability database checks, component support-period review, and escalation to component maintainers when vulnerabilities are identified.
  • Update controls: secure update distribution, security updates without delay, separation of security updates from functionality updates where technically feasible, user advisories, and automatic security updates where applicable with a clear opt-out.
Section 3

Choose the conformity assessment route before release

The CRA requires the manufacturer to assess both the product and the manufacturer's processes against Annex I. Article 32 gives four routes: internal control based on module A, EU-type examination based on module B followed by conformity to type based on module C, full quality assurance based on module H, or an applicable European cybersecurity certification scheme.

The route depends on product classification and the availability or use of harmonised standards, common specifications, or certification schemes. Ordinary products may use the Article 32(1) routes. Important class I products need module B plus C or module H when the relevant standards, specifications, or certification schemes are not applied or do not exist. Important class II products use module B plus C, module H, or an applicable certification scheme. Critical products follow the certification route when required, otherwise the class II routes.

  • For module A, keep proof that the manufacturer itself controlled design, development, production, and vulnerability handling and declared conformity on its own responsibility.
  • For module B plus C, prepare a notified-body package covering technical design, development, vulnerability handling processes, risk analysis, test evidence, and production conformity to the approved type.
  • For module H, treat the quality system as a cybersecurity and vulnerability-handling system, with documented responsibilities, design controls, testing, monitoring, and surveillance readiness.
  • Where standards or certifications are used for presumption of conformity, document exactly which requirements they cover and how uncovered Annex I requirements are met.
Section 4

Build technical documentation as the compliance file

Article 31 and Annex VII make the technical documentation the core evidence set. It must be drawn up before the product is placed on the market and continuously updated where appropriate during the support period. Manufacturers must keep the technical documentation and EU declaration of conformity available for market surveillance authorities for at least 10 years after placement on the market or for the support period, whichever is longer.

The documentation should be structured so an authority can understand the product, assess the cybersecurity risk analysis, see the Annex I mapping, and trace test results and vulnerability-handling procedures without reconstructing the product history from scattered tools.

  • Product description: intended purpose, relevant software versions, hardware illustrations where applicable, user information, instructions, markings, and secure installation guidance.
  • Architecture and lifecycle: design, development, production, monitoring, system architecture, software-component relationships, validation controls, and vulnerability-handling process specifications.
  • Vulnerability evidence: SBOM, coordinated vulnerability disclosure policy, vulnerability contact address, secure update distribution design, test and review records, and fixed-vulnerability disclosure process.
  • Conformity evidence: risk assessment, applied harmonised standards or specifications, alternative technical solutions where standards are not used, test reports, EU declaration of conformity, and support-period rationale.
Section 5

Operate the support-period and reporting system

The CRA support period is the period during which the manufacturer must handle vulnerabilities effectively. Article 13 requires the manufacturer to set that period based on expected use, reasonable user expectations, product nature and intended purpose, relevant Union law, comparable products, operating-environment availability, and support periods for core third-party components. It is at least five years unless the product is expected to be used for less than five years.

Article 14 reporting is a separate operating process. Manufacturers must notify actively exploited vulnerabilities and severe incidents affecting product security through the single reporting platform to the CSIRT designated as coordinator and ENISA. The program needs a triage path that can identify reportable events, route them to the correct notification endpoint, inform impacted users, and preserve final-report evidence.

  • Publish and retain the support-period end date, at least month and year, at purchase and in user-facing information where applicable.
  • Keep security updates available for at least 10 years after issue or for the remainder of the support period, whichever is longer.
  • For actively exploited vulnerabilities, prepare the 24-hour early warning, 72-hour vulnerability notification, and final report after a corrective or mitigating measure is available.
  • For severe incidents affecting product security, prepare the 24-hour early warning, 72-hour incident notification, final report, user communications, and mitigation records.
Section 6

Prepare importers, distributors, and market surveillance response

Importers must check before placing a product on the Union market that the manufacturer has carried out the appropriate conformity assessment, drawn up technical documentation, applied the CE marking, provided the EU declaration of conformity, and supplied required user information. Distributors must act with due care and verify CE marking, manufacturer and importer identification, support-period information, user instructions, and necessary documents before making products available.

Market surveillance authorities can request data and documentation needed to assess design, development, production, and vulnerability handling. Where a product or its vulnerability handling presents a significant cybersecurity risk, authorities can evaluate the product, require corrective action, withdrawal, or recall, and coordinate with CSIRTs, ENISA, other market surveillance authorities, and data-protection authorities where relevant.

  • Give importers a pre-market evidence pack: CE marking evidence, EU declaration of conformity, manufacturer identification, support-period disclosure, user instructions, and access path to technical documentation.
  • Give distributors a due-care checklist that covers CE marking, documents received, vulnerability escalation, and stop-ship triggers for suspected non-conformity or significant cybersecurity risk.
  • Maintain an authority-response index with product identification, version history, conformity route, Annex I mapping, risk assessment, SBOM access, test reports, vulnerability records, and corrective-action logs.
  • Define who can approve corrective action, withdrawal, recall, public communication, and notified-body interaction when market surveillance authorities identify non-compliance.
Recommended next step

Turn the CRA compliance architecture into product files

Assessment Autopilot can convert this CRA program structure into product-level scope records, Annex I mappings, evidence requests, and reporting readiness checks for products with digital elements.

Primary sources

References and citations

digital-strategy.ec.europa.eu
Referenced sections
  • Official Commission overview used for high-level CRA purpose, manufacturer lifecycle obligations, CE marking context, and application timing.
"mandatory cybersecurity requirements for manufacturers"
eur-lex.europa.eu
Referenced sections
  • Primary source for CRA scope, economic-operator duties, Annex I requirements, conformity assessment routes, technical documentation, reporting, support-period duties, and market surveillance powers.
"essential cybersecurity requirements"
Related guides

Explore more topics

CRA Applicability Test for Products With Digital Elements
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
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
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 and CE Marking
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
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 deadlines and compliance calendar | EU Cyber Resilience Act
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
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 Essential Cybersecurity Requirements in Annex I
A grounded 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
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
Grounded 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 Penalties and Fines: Article 64 Caps and Enforcement Context
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
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
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
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 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 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 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 vs UK PSTI Act | Cyber Resilience Act Comparison
Compare grounded 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
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
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 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 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 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 Repairs and Spare Parts FAQ
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
Build an audit-ready CRA technical file around Article 31 and Annex VII: product scope, risk assessment, vulnerability handling, conformity evidence, testing, and retention.