Article
Card image cap for article

Navigating the EU Cyber Resilience Act: A Curated Guide to the Best Supporting Documents

Cybersecurity

2/13/2026

A Curated Guide to the Best Supporting Documents

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024 and will be fully applicable by 11 December 2027, with reporting obligations already starting from 11 September 2026. For anyone responsible for products with digital elements - whether hardware, software, or integrated systems - this list of supporting documents might be useful.

Rather than walking you through every article and annex of this regulation, I want to point you to a curated set of high-quality supplementary documents that help you understand and implement the CRA's requirements. Each covers a specific dimension of the regulation and can serve as a practical starting point for your compliance journey.

Note: Article 71 of Regulation (EU) 2024/2847 also brings Chapter IV (Articles 35-51) forward to 11 June 2026.

What the CRA Requires in a Nutshell

The CRA establishes the first EU-wide horizontal cybersecurity framework for all products with digital elements placed on the EU market. Manufacturers must ensure their products meet essential cybersecurity requirements (Annex I) throughout the entire lifecycle, from design and development to post-market support for regularly at least five years, and aligned to the expected product lifetime. The regulation also mandates vulnerability handling processes, coordinated vulnerability disclosure, incident reporting to ENISA and national CSIRTs, a Software Bill of Materials (SBOM), and CE marking to demonstrate conformity. Non-compliance can lead to fines of up to 15 million € or 2.5% of global annual turnover.

ENISA/JRC: CRA Requirements Standards Mapping

One of the most valuable resources available is the joint report by the European Commission's Joint Research Centre (JRC) and ENISA [1]: Cyber Resilience Act Requirements Standards Mapping (EUR 31892 EN, JRC137340).

This study maps every essential requirement from CRA Annex I against existing cybersecurity standards from CEN, CENELEC, ETSI, ISO, IEC, and ITU. For each CRA requirement, the report identifies the most relevant standards, assesses the degree of coverage, highlights gaps, and indicates which product lifecycle stage (design, implementation, validation, commissioning, surveillance, maintenance, end of life) the requirement applies to.

Key takeaways
  • No single standard comprehensively covers all CRA requirements.
  • ETSI EN 303 645 maps to the highest number of security requirements, but is specific to consumer IoT and expressed at a high level.
  • The IEC 62443 series provides detailed requirements but is limited to Industrial Automation and Control Systems (IACS).
  • Significant gaps exist for SBOM requirements, secure update distribution mechanisms, user notification, and the obligation to provide security updates free of charge.

This document is indispensable for anyone trying to understand which standards already cover your CRA obligations and where additional work is needed.

ATHENE White Paper Series

The National Research Center for Applied Cybersecurity (ATHENE), operated via the Fraunhofer Institute for Secure Information Technology (SIT) in Darmstadt, has published an excellent series of three white papers [2] that address the CRA from complementary angles.

White Paper 1: Legal Requirements ("Recht")

This white paper provides a structured analysis of the CRA's legal framework. It answers foundational questions: Who qualifies as a manufacturer, importer, or distributor? What is the scope of products covered? How do legacy products and open-source software fit in? It clearly explains the obligations for each actor along the supply chain, the conformity assessment procedures, the tiered product classification (default, important Class I/II, critical), and the penalty framework - fines up to €15 million for violations of core requirements. The annex includes a detailed tabular overview of all obligations for manufacturers, authorized representatives, importers, distributors, and open-source software stewards. This is the right starting point if you need to understand the regulatory structure before diving into technical implementation.

White Paper 2: Technical Requirements ("Technische Anforderungen")

This white paper targets those who shape the technical development framework in manufacturing companies. It covers:

  • Cybersecurity risk assessment as the foundation for CRA compliance, including practical guidance on adapting existing frameworks like ISO 27005 or BSI IT-Grundschutz.
  • Products without known exploitable vulnerabilities: what this means in practice and how to verify it.
  • Software Bill of Materials (SBOM): purpose, CRA requirements, and implementation recommendations including CycloneDX and SPDX formats.
  • Security and vulnerability testing: integration of automated testing (SAST, DAST, fuzzing) into development pipelines, with a recommendation to rotate external penetration testers every two to three years.
  • Coordinated Vulnerability Disclosure (CVD): process requirements and practical options ranging from a simple PGP-enabled email address to full bug bounty programs.
  • CE marking: the conformity assessment process and practical considerations (e.g., where to place the CE mark on download-only software).
  • Manufacturer reporting obligations: the three-stage reporting process (24h / 72h / final report) for actively exploited vulnerabilities and severe incidents.

White Paper 3: Risk Management ("Risikomanagement")

Published in July 2025, this is the newest addition to the series and zooms in specifically on risk management under the CRA. Its central insight is that the CRA introduces a product-centric concept of cybersecurity risk, fundamentally different from the organization-centric approach of ISO/IEC 27001 or NIS-2.

Key contributions include:

  • A clear comparison of how cybersecurity risk is defined in the CRA versus established standards (ISO 27001, NIS-2, BSI IT-Grundschutz).
  • A practical mapping of CRA requirements to SecDevOps phases (plan, design, build, test, deploy, operate), with specific tool recommendations for each phase.
  • A comparative analysis of requirements engineering methodologies (INCOSE, NIST SP 800-160, ISO/IEC 62443, OWASP SAMM, MITRE ATT&CK, STPA-Sec, SAFe) and their alignment with CRA obligations.

This white paper is especially useful if your organization already has risk management processes in place and needs to understand how to adapt them for CRA product-level compliance.

BSI Technical Guideline TR-03183

The German Federal Office for Information Security (BSI) has developed a comprehensive three-part Technical Guideline - BSI TR-03183 - specifically designed to help manufacturers prepare for the CRA [3].

Part 1: General Requirements (v0.9.0)

This part translates the CRA's essential requirements into testable, product-agnostic requirements with corresponding assessment criteria. It covers 14 essential security requirements related to product properties (security by design, no known vulnerabilities, secure default configuration, security updates, access control, confidentiality protection, integrity protection, data minimization, availability, attack surface limitation, incident mitigation, recording and monitoring, and data deletion) plus seven vulnerability handling requirements. Each requirement follows a structured format: the CRA source text, a condition indicating when it applies, and detailed assessment criteria for evaluators. The guideline explicitly warns that it does not replace legal obligations but provides a valuable initial interpretation and testable framework.

Part 2: Software Bill of Materials (v2.1.0)

This part defines BSI's requirements for SBOMs, which the CRA mandates as part of vulnerability management. It specifies:

  • Supported formats: CycloneDX (v1.6+) and SPDX (v3.0.1+) in JSON or XML.
  • Required, additional, and optional data fields for the SBOM itself and for each component - including creator, name, version, filename, dependencies, distribution licenses, hash values, and executable/archive/structured properties.
  • Detailed rules for license identification using SPDX identifiers.
  • Different levels of SBOM detail (top-level, n-level, transitive, delivery item, complete) with clear diagrams.
  • A complete field-by-field mapping to both CycloneDX and SPDX format specifications.

This is an essential reference if you need to produce SBOMs that are compliant and interoperable.

Note: SBOM should be in a commonly used, machine-readable format (per the essential requirements framing), but practice details vary by product and implementing standards.

Part 3: Vulnerability Reports and Notifications (v1.0.0)

This part specifies the technical requirements for establishing a Coordinated Vulnerability Disclosure (CVD) process. The level of detail is impressive and very practical. It covers:

  • The mandatory security.txt file per RFC 9116, including canonical URI, contact information, OpenPGP keys, CVD policy link, and digital signature requirements.
  • Organizational roles: manufacturers must establish at least a Product Security Incident Response Team (PSIRT) and a CSIRT with dedicated functional mailboxes (e.g., csirt@example.com, psirt@example.com).
  • A web form for (anonymous) vulnerability reports, a dedicated public web page for incoming reports, and detailed requirements for a CVD policy.
  • Guaranteed response times: simple response within 5 working days, detailed feedback within 10 working days.
  • Vulnerability disclosure: validated and verified vulnerabilities must be publicly disclosed within 90 days, extendable once by 90 days in consultation with the national CSIRT (extension possible in exceptional cases).

Medical Devices: Where Does the MDR End and the CRA Begin?

For those working with medical devices and digital health products, a particularly insightful article by Miriam Schuh and Christina Ziegler-Kiefer [4] was published in Medizinprodukte Journal (Vol. 32, No. 6, 2025): "Der Cyber Resilience Act und Medizinprodukte – Welche Cybersicherheitsanforderungen gelten für Medizinprodukte?".

The article examines the interplay between the CRA and the Medical Device Regulation (MDR, EU 2017/745). Under Art. 2(2)(a) CRA, products that fall under the MDR are explicitly excluded from CRA scope. However, the boundary is not always obvious:

  • Medical devices and their accessories are excluded from CRA, as both are covered by the MDR.
  • Wearables are only excluded from CRA if they have a diagnostic or therapeutic purpose under the MDR. Health-tracking wearables without medical purpose fall under the CRA (Annex III, No. 19).
  • Software is only excluded from CRA if it is specifically intended for medical purposes (e.g., diagnostic support, therapy management). General administration software, lifestyle apps, or fitness apps without medical purpose fall under the CRA.
  • Supplier components (e.g., Bluetooth or WLAN modules): If a supplier places a non-medical Bluetooth/WLAN communication module on the market as a standalone product with digital elements, the CRA may apply to that module, even when it is intended to be integrated into a medical device.
  • Spare parts are exempt from the CRA if they replace identical components with the same specifications (Art. 2(6) CRA).

The decisive factor in every case is the intended purpose (Zweckbestimmung) determined by the manufacturer. The article includes two practical decision trees, one for classifying products as medical devices under MDR, and one specifically for software.

Final Thought

The CRA is not just another compliance checkbox. It represents a paradigm shift toward product-level cybersecurity accountability across the entire EU market. The documents I've highlighted here provide an excellent foundation, whether you need legal orientation, technical implementation guidance, or sector-specific analysis for medical devices.

References

Go back