When placing a product with digital elements on the market, manufacturers shall ensure that it has been designed, developed and produced in accordance with the essential cybersecurity requirements set out in Part I of Annex I.

What This Obligation Means

This paragraph establishes the foundation of cybersecurity in product manufacturing. It requires that every product placed on the EU market is secure by design, by default, and throughout its lifecycle. This includes secure coding practices, vulnerability management, data protection, and attack surface reduction — aligning technical execution with compliance obligations.

How to Comply in Practice

Organizational Actions

• Establish a secure development governance model, assigning clear roles for engineering, security, and compliance.

• Integrate cybersecurity requirements into product development planning and release gates.

• Conduct regular cybersecurity risk assessments aligned with product lifecycle phases.

Policy / Process Updates

• Define and document a Secure Development Lifecycle (SDL) policy that aligns with Annex I requirements.

• Incorporate security checkpoints in design and code review processes.

• Establish a security assurance plan for production and post-market phases.

Technical Implementations

• Apply secure coding standards (e.g., OWASP, SEI CERT).

• Implement vulnerability scanning and penetration testing during development.

• Use configuration management and version control to ensure traceability.

• Employ security automation tools in CI/CD pipelines (e.g., SAST, DAST, SCA).

Documentation Requirements

Maintain technical documentation as per Article 31 and Annex VII, including:

• Architecture diagrams

• Threat models

• Vulnerability management processes

• Evidence of testing and risk treatment decisions

• Maintain an SBOM (Software Bill of Materials) in a machine-readable format (CycloneDX, SPDX).

Common Pitfalls and Readiness Gaps

• Treating security as an afterthought or post-release checklist rather than part of design.

• Incomplete documentation of security testing or architectural decisions.

• Lack of traceability between identified risks and implemented controls.

• Failing to align development processes with formal cybersecurity risk assessments.

Tools and Frameworks to Help

• NIST Secure Software Development Framework (SSDF) – practical implementation guidance for secure design and coding.

• OWASP SAMM – for assessing and improving software security maturity.

• ISO/IEC 27034 – framework for integrating security into application lifecycle.

• ENISA Good Practices for Secure Development and Maintenance of Software and Hardware.

• Snyk, SonarQube, Semgrep, Dependency-Track – for automated vulnerability and dependency management.

Paragraph 1 sets the tone for the entire Cyber Resilience Act — emphasizing that security is not optional or reactive. Compliance requires building cybersecurity discipline directly into the engineering DNA of the organization. Manufacturers who embed these practices will not only meet CRA requirements but also reduce long-term risks and enhance customer trust.

For the purpose of complying with paragraph 1, manufacturers shall undertake an assessment of the cybersecurity risks associated with a product with digital elements and take the outcome of that assessment into account during the planning, design, development, production, delivery and maintenance phases of the product with digital elements with a view to minimising cybersecurity risks, preventing incidents and minimising their impact, including in relation to the health and safety of users.

What This Obligation Means

This paragraph builds upon the secure design principle by introducing a mandatory cybersecurity risk assessment for every product with digital elements.

Manufacturers are required to identify, analyze, and evaluate cybersecurity risks throughout the product lifecycle — from planning and design to post-market maintenance.

The aim is twofold:

• Prevent cybersecurity incidents by proactively understanding potential threats and vulnerabilities.

• Minimize their impact — not just in digital terms, but also regarding user health, safety, and societal consequences.

In short, this is where compliance becomes dynamic. It requires organizations to continuously evaluate and integrate risk intelligence into every stage of product development and maintenance.

How to Comply in Practice

Organizational Actions

• Define a formal cybersecurity risk management process integrated into the product lifecycle.

• Assign clear accountability for product risk ownership — typically within engineering, security, and quality assurance functions.

• Establish a risk acceptance framework to define thresholds for acceptable and residual risks.

Policy / Process Updates

• Develop a Cybersecurity Risk Assessment Policy that references recognized methodologies (e.g., ISO 14971 for safety-related, ISO 27005, ENISA guidelines, or NIST 800-30).

• Incorporate risk reviews at key product milestones (e.g., design freeze, pre-release, major updates).

• Update the Secure Development Lifecycle (SDL) documentation to include continuous risk monitoring and re-assessment after major code or dependency changes.

Technical Implementations

• Conduct threat modeling (e.g., STRIDE, PASTA, or LINDDUN) to identify attack vectors early in design.

• Perform vulnerability assessments and penetration testing aligned with the risk severity identified.

• Implement automated security scanning tools (SCA, SAST, DAST) as part of CI/CD to monitor evolving risks.

• Maintain security telemetry and logging mechanisms to detect anomalies post-deployment.

• Integrate safety and cybersecurity risk mapping, ensuring that digital risks with physical safety implications are addressed.

Documentation Requirements

• Maintain a Cybersecurity Risk Assessment Report capturing:

• Threat landscape relevant to the product

• Identified risks and their severity

• Mitigation and control measures

• Residual risk justification and acceptance criteria

• Document evidence of re-assessment after product updates, configuration changes, or emerging threats.

• Link findings with post-market surveillance activities (per Article 14).

Common Pitfalls and Readiness Gaps

• Treating risk assessment as a one-time activity rather than continuous throughout product lifecycle.

• Relying solely on general enterprise risk management instead of product-specific risk analysis.

• Not correlating cybersecurity risk with user safety and regulatory compliance impact.

• Poor documentation of risk decisions or missing traceability between risks and controls.

Tools and Frameworks to Help

• ISO/IEC 27005 – foundational standard for information security risk management.

• ENISA Cybersecurity Risk Management Framework for ICT Products.

• NIST SP 800-30 – Guide for Conducting Risk Assessments.

• Threat modeling tools: OWASP Threat Dragon, Microsoft Threat Modeling Tool.

• Risk tracking and traceability tools: Jira with risk plugins, ThreatPlaybook, or SecureFlag.

Paragraph 2 operationalizes secure design by anchoring it in risk intelligence. It reminds manufacturers that true resilience stems from understanding where their systems can fail — before attackers do. A well-documented, continuously updated risk assessment not only fulfills regulatory obligations but also strengthens product credibility and user trust in the long term.

The cybersecurity risk assessment shall be documented and updated as appropriate during a support period to be determined in accordance with paragraph 8 of this Article. That cybersecurity risk assessment shall comprise at least an analysis of cybersecurity risks based on the intended purpose and reasonably foreseeable use, as well as the conditions of use, of the product with digital elements, such as the operational environment or the assets to be protected, taking into account the length of time the product is expected to be in use. The cybersecurity risk assessment shall indicate whether and, if so in what manner, the security requirements set out in Part I, point (2), of Annex I are applicable to the relevant product with digital elements and how those requirements are implemented as informed by the cybersecurity risk assessment. It shall also indicate how the manufacturer is to apply Part I, point (1), of Annex I and the vulnerability handling requirements set out in Part II of Annex I.

What This Obligation Means

This paragraph reinforces that cybersecurity risk assessment is not static. It must be:

• Documented – formally recorded with clear rationale and traceability,

• Updated – throughout the support period, and

• Comprehensive – covering intended purpose, foreseeable use, operational conditions, and the expected lifespan of the product.

It also introduces an explicit mapping requirement: the manufacturer must clearly show how the security requirements in Annex I (Parts I & II) apply to their product, and how these have been implemented.

In essence, Paragraph 3 ties together risk, compliance, and implementation — making sure that every security requirement and control can be justified and traced back to a specific risk identified.

How to Comply in Practice

Organizational Actions

• Establish a governed process for maintaining risk documentation throughout the product lifecycle and support period.

• Assign a risk documentation owner (typically product security lead or compliance officer).

• Define triggers for risk reassessment, such as software updates, new vulnerabilities, or changes in usage environment.

Policy / Process Updates

• Update your Cybersecurity Risk Assessment Procedure to require periodic review and documentation updates.

• Integrate lifecycle checkpoints (e.g., annually or with every major release) for reviewing and validating risk documentation.

• Define a support-period-aligned update cycle, consistent with the product’s declared maintenance and patching duration.

Technical Implementations

• Implement version-controlled risk documentation repositories (e.g., Git-based systems or GRC platforms).

• Use asset inventories and threat models to align operational environment assumptions with real-world conditions.

• Automate risk traceability by linking vulnerability findings (from scanners or SBOM tools) back to risk records.

• Ensure the implementation of security requirements from Annex I:

  • Annex I, Part I (1) – Secure design, development, and production principles.

  • Annex I, Part I (2) – Secure by default configuration, protection of data and functions, and access control mechanisms.

  • Annex I, Part II – Vulnerability handling and patch management processes.

Documentation Requirements

Maintain a Cybersecurity Risk Assessment Document that includes:

• Product purpose and intended use scenarios.

• Foreseeable misuse conditions.

• Operating environments (e.g., cloud, on-prem, IoT, industrial).

• Asset protection scope (data, credentials, firmware, user safety).

• Mapped security requirements from Annex I — showing which apply, how they apply, and how compliance is achieved.

• Reference to vulnerability handling procedures and update mechanisms.

• Include version history and change logs to demonstrate updates during the support period.

• Maintain cross-references to test reports and conformity assessments for each applied requirement.

Common Pitfalls and Readiness Gaps

• Treating documentation as a compliance checkbox rather than a living artifact.

• Failing to maintain traceability between risk findings and implemented controls.

• Inconsistencies between the declared support period and the actual maintenance of risk documentation.

• Not clearly linking Annex I requirements to tangible security measures.

• Neglecting foreseeable misuse or environmental factors (e.g., insecure network configurations, untrusted supply chain components).

• Tools and Frameworks to Help

• GRC and documentation platforms: Jira Align, Drata, Tugboat Logic, or Confluence (with version control).

• Threat modeling and traceability: IriusRisk, ThreatModeler, Microsoft TMT.

• SBOM and vulnerability tracking: Snyk, CycloneDX, Dependency-Track, Anchore.

• ISO/IEC 27005 and NIST 800-30 for structured risk documentation templates.

• Annex I compliance mapping using ENISA’s Cybersecurity by Design for ICT Products guidance.

Paragraph 3 transforms risk assessment into a traceable compliance narrative. It ensures manufacturers can answer the fundamental CRA question:

“How do your cybersecurity controls align with your risk understanding — and how has that alignment evolved over time?”

This continuous documentation practice doesn’t just support CRA audits; it strengthens engineering discipline and transparency, both of which are essential for long-term cyber resilience.

When placing a product with digital elements on the market, the manufacturer shall include the cybersecurity risk assessment referred to in paragraph 3 of this Article in the technical documentation required pursuant to Article 31 and Annex VII. For products with digital elements as referred to in Article 12, which are also subject to other Union legal acts, the cybersecurity risk assessment may be part of the risk assessment required by those Union legal acts. Where certain essential cybersecurity requirements are not applicable to the product with digital elements, the manufacturer shall include a clear justification to that effect in that technical documentation.

What This Obligation Means

This clause formalizes that the cybersecurity risk assessment is a required part of the technical documentation. In practical terms, it means:

• The manufacturer must embed the documented cybersecurity risk assessment (from Paragraph 3) within the technical documentation required by Article 31 and Annex VII.

• For products that fall under other EU laws (e.g., MDR, RED, or automotive regulations), the CRA risk assessment can be integrated into those existing risk documents — avoiding duplication.

• If certain cybersecurity requirements under Annex I are not applicable, the manufacturer must explicitly justify why (e.g., a sensor without network capability may not need encryption mechanisms).

The goal is full transparency: regulators, notified bodies, or market surveillance authorities must be able to see exactly how risks were identified, assessed, and addressed — or why certain requirements don’t apply.

How to Comply in Practice

Organizational Actions

• Define ownership for maintaining and updating the technical documentation, ensuring it always contains the latest risk assessment.

• Integrate cybersecurity documentation management with product compliance and certification workflows.

• Establish a documentation review board (including engineering, compliance, and security) to validate justifications for non-applicable requirements.

Policy / Process Updates

• Update the Technical Documentation Policy to include cybersecurity risk assessment as a mandatory section.

• Create a mapping process linking Annex I requirements to risk assessment outcomes, technical controls, and testing evidence.

• Ensure procedures support multi-framework integration, allowing one consolidated documentation set for multiple EU regulations (e.g., CRA + MDR + RED).

Technical Implementations

• Use structured templates (e.g., XML, JSON, or YAML) that allow the risk assessment to be embedded alongside product design documentation.

• Leverage tools that link risk records to SBOMs, vulnerability management reports, and testing evidence.

• Implement a system of cross-references between CRA risk assessment and other regulatory risk artifacts when applicable.

Documentation Requirements

• The technical documentation (per Article 31 and Annex VII) must now explicitly include:

• The Cybersecurity Risk Assessment document developed in Paragraph 3.

• A cross-reference matrix showing which Annex I requirements apply and how they’re addressed.

• Justifications for non-applicable requirements, including:

  • Technical rationale (e.g., no connectivity, no data storage).

  • Risk-based reasoning (e.g., minimal exposure or containment design).

  • Evidence of integration with other risk assessments (for products covered by other EU acts).

  • Version control and timestamps for traceability.

Common Pitfalls and Readiness Gaps

Treating cybersecurity risk assessment as an annexed document instead of an integrated part of the technical file.

Missing or vague justifications for non-applicable requirements.

Failing to maintain alignment between the risk assessment and the current product version or SBOM.

Fragmented documentation — e.g., one set for CRA and another for MDR — creating confusion during audits.

Using unstructured, non-searchable document formats (e.g., PDFs without metadata).

Tools and Frameworks to Help

• Documentation management platforms: Polarion, Jama Connect, or Confluence + Git integration.

• Risk-to-requirement mapping tools: IriusRisk, ISMS.online, or ServiceNow GRC.

• SBOM-based linkage: Snyk, Anchore, or CycloneDX for embedding security evidence within documentation.

• Template standards:

• ISO/IEC 27005 – for structured risk recording,

• ISO/IEC 30111 – for vulnerability handling,

• ENISA CRA implementation guidelines (for Annex I mapping).

Paragraph 4 is about traceable assurance — it transforms the cybersecurity risk assessment from a working document into formal evidence of due diligence.

By embedding it into technical documentation, organizations not only meet compliance obligations but also create a single source of truth for regulators, auditors, and customers alike.

This integrated approach avoids redundancy, ensures consistency across regulations, and strengthens confidence that security is built in — not bolted on.

For the purpose of complying with paragraph 1, manufacturers shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements, including when integrating components of free and open-source software that have not been made available on the market in the course of a commercial activity.

What This Obligation Means

This paragraph emphasizes that manufacturers are responsible for ensuring that components sourced from third parties do not compromise the cybersecurity of their products with digital elements. In practical terms:

• Manufacturers must exercise due diligence when selecting and integrating third-party components.

• This obligation includes all components, whether commercial, proprietary, or free and open-source software (FOSS), even if they have not been previously marketed commercially.

• The focus is on preventing cybersecurity weaknesses from being introduced through external dependencies, ensuring that the final product maintains the expected level of security.

• Essentially, the manufacturer cannot simply assume that third-party components are secure—they must actively evaluate and mitigate risks associated with these components.

How to Comply in Practice

Organizational Actions

• Assign ownership for evaluating third-party components, including software libraries, firmware, and hardware modules.

• Integrate due diligence checks into procurement and design workflows.

• Establish a review board or security committee to assess the risk profile of critical components, particularly for FOSS with limited documentation or unknown maintenance status.

Policy / Process Updates

• Update vendor management and procurement policies to include cybersecurity evaluation criteria.

• Define a component risk assessment process that covers:

  • Security history (known vulnerabilities)

  • Maintenance and patching practices

  • License and support status

  • Compatibility with the product’s security requirements

• Incorporate FOSS governance policies for tracking, versioning, and patching open-source components.

Technical Implementations

• Use Software Bill of Materials (SBOM) to track all third-party components and their versions.

• Run vulnerability scans and static code analysis on third-party software before integration.

• Apply sandboxing or isolation techniques for high-risk components when full verification is not immediately possible.

• Maintain cross-references between third-party component evaluations and the main cybersecurity risk assessment to show traceability.

Documentation Requirements

Include in the technical documentation:

• List of all third-party components and their sources.

• Evidence of due diligence (risk assessment, security testing results).

• Justification for any components deemed low-risk despite known vulnerabilities (risk-based rationale).

• Notes on FOSS components, including version control, license information, and patch management plan.

Common Pitfalls and Readiness Gaps

• Blindly integrating third-party components without security checks.

• Using outdated or unpatched libraries or firmware.

• Lack of documentation linking third-party evaluations to the product’s overall risk assessment.

• Treating FOSS components differently than commercial components in terms of risk management.

Tools and Frameworks to Help

• SBOM & component tracking: CycloneDX, SPDX, Snyk, WhiteSource.

• Vulnerability scanning: OWASP Dependency-Check, Snyk, Black Duck.

• FOSS governance: FOSSA, Evident.io, Black Duck Open Source Management.

• Risk assessment frameworks: ISO/IEC 27005 for risk management, ENISA CRA guidelines for third-party component evaluation.

Paragraph 5 ensures that cybersecurity is holistic, covering not only the manufacturer’s own development but also all integrated external components. By exercising due diligence, organizations prevent third-party components from becoming weak points, creating a more resilient, secure product. Proper documentation of these evaluations demonstrates compliance and provides traceable evidence to regulators and auditors.

Manufacturers shall, upon identifying a vulnerability in a component, including in an open source-component, which is integrated in the product with digital elements report the vulnerability to the person or entity manufacturing or maintaining the component, and address and remediate the vulnerability in accordance with the vulnerability handling requirements set out in Part II of Annex I. Where manufacturers have developed a software or hardware modification to address the vulnerability in that component, they shall share the relevant code or documentation with the person or entity manufacturing or maintaining the component, where appropriate in a machine-readable format.

What This Obligation Means

This paragraph focuses on the responsibility of manufacturers to act when vulnerabilities are discovered in components—including open-source components—used in their products with digital elements. In practical terms:

• Manufacturers must report vulnerabilities to the original creator, maintainer, or vendor of the component.

• Vulnerabilities must be addressed and remediated according to the vulnerability handling requirements in Part II of Annex I of the CRA.

• If the manufacturer develops a fix or mitigation, they should share relevant code or documentation with the component’s maintainer.

• Whenever possible, sharing should be in a machine-readable format, supporting automation and better traceability.

• The goal is to close security gaps quickly, maintain ecosystem security, and promote coordinated vulnerability management.

How to Comply in Practice

Organizational Actions

• Define ownership for vulnerability management in the organization, including detection, reporting, remediation, and follow-up.

• Establish a communication channel with third-party vendors and open-source communities for reporting vulnerabilities.

• Maintain a vulnerability register linking each component to discovered vulnerabilities, remediation actions, and reporting status.

Policy / Process Updates

• Update the Vulnerability Management Policy to include third-party and FOSS components.

• Define escalation procedures for critical vulnerabilities that pose immediate risk to the product or end-users.

• Include timelines for reporting, remediating, and documenting fixes in accordance with CRA Annex I.

• Ensure a process exists to validate the effectiveness of fixes before deployment.

Technical Implementations

• Use vulnerability scanning tools to detect known issues in components (commercial and open-source).

• Track component versions via SBOMs to identify affected products quickly.

• Develop patches or mitigations in a controlled environment, ensuring they do not introduce new vulnerabilities.

• Provide machine-readable reports (e.g., JSON, XML) when sharing vulnerability information with component maintainers.

Documentation Requirements

Include in the technical documentation:

• List of identified vulnerabilities per component.

• Evidence of reporting to the component manufacturer or maintainer.

• Remediation actions taken, including software or hardware fixes.

• Links to shared code or documentation, specifying format and version.

• Cross-reference to the main cybersecurity risk assessment for traceability.

Common Pitfalls and Readiness Gaps

• Failing to report vulnerabilities promptly to component maintainers.

• Incomplete documentation of remediations or patches applied.

• Ignoring open-source components under the assumption that “someone else will fix it.”

• Not using machine-readable formats, leading to inefficient collaboration and traceability.

• Missing alignment between vulnerability handling and the CRA’s Annex I requirements.

Tools and Frameworks to Help

• Vulnerability scanning: Snyk, Black Duck, WhiteSource, OWASP Dependency-Check.

• Vulnerability tracking & management: Jira, ServiceNow, ISMS.online, Kenna Security.

• SBOM tracking: CycloneDX, SPDX.

• Patch sharing / machine-readable formats: Git repositories, automated vulnerability feed formats (JSON/XML).

• Reference frameworks: ISO/IEC 30111 for vulnerability handling, ENISA CRA guidance.

Paragraph 6 ensures responsible disclosure and remediation of vulnerabilities in all components, fostering collaboration across the software and hardware ecosystem. By reporting vulnerabilities to the component maintainers and sharing fixes, manufacturers help secure not only their own products but the broader digital ecosystem. Proper documentation and machine-readable sharing also demonstrate compliance and provide traceable evidence for audits.

The manufacturers shall systematically document, in a manner that is proportionate to the nature and the cybersecurity risks, relevant cybersecurity aspects concerning the products with digital elements, including vulnerabilities of which they become aware and any relevant information provided by third parties, and shall, where applicable, update the cybersecurity risk assessment of the products.

What This Obligation Means

This paragraph emphasizes that manufacturers must systematically document all relevant cybersecurity aspects of products with digital elements, proportionate to the product’s nature and associated risks. In practical terms:

• Manufacturers are required to maintain ongoing records of cybersecurity-related information, including:

• Vulnerabilities discovered internally or reported by third parties.

• Information from third-party sources that could impact product security (e.g., supplier advisories, CVE notices).

• The documentation must be proportionate to the product’s risk profile; higher-risk products require more detailed and frequent documentation.

• When new information is collected, manufacturers must update the cybersecurity risk assessment to reflect the current risk posture.

• The goal is continuous monitoring and traceable evidence of security management throughout the product lifecycle.

How to Comply in Practice

Organizational Actions

• Assign responsibility for continuous cybersecurity documentation to a product security or compliance team.

• Define a process for collecting, reviewing, and validating third-party vulnerability information and advisories.

• Schedule regular reviews of documentation to ensure it reflects current risks and vulnerabilities.

Policy / Process Updates

• Update cybersecurity policies to require systematic logging and traceable documentation of all relevant cybersecurity aspects.

• Include procedures for:

  • Recording vulnerabilities and threat intelligence.

  • Linking updates to the centralized risk assessment.

  • Incorporating third-party input from suppliers, FOSS communities, or security researchers.

• Define criteria for proportionality, ensuring documentation effort aligns with the product’s impact and threat exposure.

Technical Implementations

• Use centralized tracking systems for vulnerabilities, security incidents, and risk assessment updates (e.g., Jira, ServiceNow, ISMS platforms).

• Link SBOMs, patch records, and third-party advisories directly to the product’s risk assessment.

• Automate alerts and triggers to update the risk assessment when new vulnerabilities or relevant information are detected.

Documentation Requirements

Maintain a living record of cybersecurity aspects, including:

• Newly discovered or reported vulnerabilities.

• Third-party security information impacting components or the product.

• Updates to risk assessment reflecting new findings.

• Ensure traceability, version control, and date stamps for all entries.

• Proportion documentation detail to risk level: critical systems may require full technical details; lower-risk products may use summary-level documentation.

Common Pitfalls and Readiness Gaps

• Treating documentation as static rather than dynamic, failing to update with new vulnerabilities or third-party reports.

• Failing to link updated information to the main cybersecurity risk assessment.

• Over-documenting low-risk items while neglecting high-risk areas.

• Lack of version control or traceability, making audits difficult.

Tools and Frameworks to Help

• Vulnerability tracking & documentation: Jira, ServiceNow, Kenna Security, ISMS.online.

• SBOM and component monitoring: CycloneDX, SPDX, Snyk.

• Risk assessment tools: IriusRisk, ISO/IEC 27005-based platforms.

• Automation and alerts: CI/CD integration for FOSS updates, vulnerability feeds, and patch monitoring.

• ENISA CRA guidelines for documentation best practices.

Paragraph 7 ensures that cybersecurity management is continuous and evidence-based. By systematically documenting vulnerabilities, third-party inputs, and other relevant information, and updating the risk assessment accordingly, manufacturers maintain an accurate and current view of product security. This ongoing diligence supports compliance, proactive risk mitigation, and accountability throughout the product lifecycle.

Manufacturers shall ensure, when placing a product with digital elements on the market, and for the support period, that vulnerabilities of that product, including its components, are handled effectively and in accordance with the essential cybersecurity requirements set out in Part II of Annex I.

Manufacturers shall determine the support period so that it reflects the length of time during which the product is expected to be in use, taking into account, in particular, reasonable user expectations, the nature of the product, including its intended purpose, as well as relevant Union law determining the lifetime of products with digital elements. When determining the support period, manufacturers may also take into account the support periods of products with digital elements offering a similar functionality placed on the market by other manufacturers, the availability of the operating environment, the support periods of integrated components that provide core functions and are sourced from third parties as well as relevant guidance provided by the dedicated administrative cooperation group (ADCO) established pursuant to Article 52(15) and the Commission. The matters to be taken into account in order to determine the support period shall be considered in a manner that ensures proportionality.

Without prejudice to the second subparagraph, the support period shall be at least five years. Where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time.

Taking into account ADCO recommendations as referred to in Article 52(16), the Commission may adopt delegated acts in accordance with Article 61 to supplement this Regulation by specifying the minimum support period for specific product categories where the market surveillance data suggests inadequate support periods.

Manufacturers shall include the information that was taken into account to determine the support period of a product with digital elements in the technical documentation as set out in Annex VII.

Manufacturers shall have appropriate policies and procedures, including coordinated vulnerability disclosure policies, referred to in Part II, point (5), of Annex I to process and remediate potential vulnerabilities in the product with digital elements reported from internal or external sources.

What This Obligation Means

This paragraph focuses on ensuring that products with digital elements are supported throughout their lifecycle, with effective management of vulnerabilities. In practical terms:

• Manufacturers must handle vulnerabilities effectively for the entire support period of the product, including vulnerabilities in third-party components.

• The support period is the timeframe during which the product is expected to be in active use and adequately maintained for cybersecurity.

• When determining the support period, manufacturers must consider:

  • Reasonable user expectations (how long users expect the product to be secure and functional).

  • Product nature and intended purpose (e.g., consumer device vs. industrial control system).

  • Relevant EU laws regarding product lifetimes.

  • Support periods of similar products in the market.

  • Availability of the operating environment and core third-party components.

  • Guidance from ADCO and the European Commission.

• The support period must be proportionate to the risks and product type, with a minimum of five years unless the expected use is shorter.

• All considerations used to determine the support period must be documented in the technical file (Annex VII).

• Manufacturers must maintain policies and procedures for vulnerability management, including coordinated vulnerability disclosure, to address potential issues reported internally or externally.

How to Comply in Practice

Organizational Actions

• Define product support ownership, including teams responsible for patching, monitoring vulnerabilities, and coordinating disclosure.

• Establish a vulnerability response team capable of processing reports, performing impact assessments, and rolling out mitigations.

• Ensure that the support period aligns with the product’s expected use, and plan resources to maintain support throughout this period.

Policy / Process Updates

• Update Product Lifecycle Policies to specify minimum support periods (≥5 years or as per expected use).

• Implement Vulnerability Management Policy covering:

  • Detection and reporting of vulnerabilities (internal and external sources).

  • Prioritization, assessment, and remediation procedures.

  • Coordinated Vulnerability Disclosure (CVD) processes.

• Include guidelines for third-party components, ensuring their updates align with the product’s support period.

• Incorporate ADCO recommendations and Commission guidance when determining or adjusting support periods.

Technical Implementations

Track vulnerabilities and patches over the full support period using a centralized system (e.g., Jira, ServiceNow, or ISMS platforms).

Maintain SBOMs and component versioning to ensure all third-party and FOSS components are supported.

Implement automated alerting for new vulnerabilities in integrated components.

Ensure updates and fixes are documented and linked to the product’s cybersecurity risk assessment.

Documentation Requirements

Include in technical documentation (Annex VII):

• Rationale for the support period determination.

• Evidence of policies and procedures for ongoing vulnerability management.

• Records of vulnerabilities reported, assessed, and remediated.

• Coordinated vulnerability disclosure mechanisms and records of communications with internal/external reporters.

Common Pitfalls and Readiness Gaps

• Failing to provide a minimum five-year support period without justification.

• Inadequate tracking of third-party or open-source component vulnerabilities over the support period.

• Lack of evidence linking policies, procedures, and remediation actions to the product’s risk assessment.

• Incomplete documentation of considerations used to define the support period.

• Not implementing coordinated vulnerability disclosure mechanisms.

Tools and Frameworks to Help

• Vulnerability tracking & lifecycle management: Jira, ServiceNow, Kenna Security, ISMS.online.

• SBOM and component monitoring: CycloneDX, SPDX, Snyk.

• Patch management & release automation: GitOps, CI/CD pipelines, update distribution tools.

• CVD platforms: HackerOne, Bugcrowd, OpenSSF Best Practices.

• Reference frameworks: ISO/IEC 30111 for vulnerability handling, ENISA CRA guidance for support periods.

Paragraph 8 ensures that manufacturers maintain product security throughout its expected use, addressing vulnerabilities in their own code and in third-party components. By defining a clear support period, implementing vulnerability management policies, and documenting all considerations, manufacturers provide predictable, traceable security assurance to users, regulators, and auditors. This approach strengthens trust and ensures compliance with CRA requirements.

Manufacturers shall ensure that each security update, as referred to in Part II, point (8), of Annex I, which has been made available to users during the support period, remains available after it has been issued for a minimum of 10 years or for the remainder of the support period, whichever is longer.

What This Obligation Means

This paragraph emphasizes that manufacturers must ensure long-term availability of security updates for products with digital elements. In practical terms:

• Every security update made available to users during the product’s support period must remain accessible for a defined minimum period.

• The minimum availability period is 10 years, or the remainder of the support period if it is longer.

• This ensures that users and organizations can apply past security updates even after newer updates are released, supporting ongoing protection and regulatory compliance.

• The obligation applies to all updates covered under Part II, point (8) of Annex I, which generally includes patches addressing vulnerabilities, performance issues, and security hardening.

How to Comply in Practice

Organizational Actions

• Assign responsibility for long-term storage and distribution of security updates.

• Define internal policies for versioning, retention, and archival of updates.

• Include audit mechanisms to verify that all past security updates remain available for the required period.

Policy / Process Updates

• Update the Software Maintenance and Update Policy to include:

  • Minimum 10-year retention of security updates or longer if the support period exceeds 10 years.

  • Procedures for making updates accessible to end users, distributors, and system integrators.

  • Coordination with third-party components to ensure compatible updates are retained.

• Define end-of-life (EOL) policies that align update availability with the support period and CRA requirements.

Technical Implementations

• Maintain a centralized update repository with version control, audit logs, and machine-readable formats.

• Ensure updates are backward-compatible and can be applied to systems still in use.

• Provide multiple distribution channels (download portals, package managers, automated update systems) to ensure accessibility over the long term.

• Implement integrity verification mechanisms (digital signatures, checksums) to guarantee update authenticity.

Documentation Requirements

Record in technical documentation (Annex VII):

• List of all security updates released.

• Dates of release and retention plans.

• Evidence that updates remain accessible and can be retrieved by users.

• Processes for long-term maintenance and archival of updates.

Common Pitfalls and Readiness Gaps

• Failing to retain old security updates for the required minimum period.

• Not documenting update availability or retention plans.

• Relying on external distribution channels without guarantees for long-term access.

• Updates that cannot be applied independently (e.g., requiring intermediate versions that are no longer available).

Tools and Frameworks to Help

• Update management systems: WSUS, SCCM, Red Hat Satellite, Git-based repositories.

• SBOM and version tracking: CycloneDX, SPDX, Snyk.

• Archival and content delivery: Object storage with long-term retention policies (S3 Glacier, Azure Blob Archive).

• Integrity verification: OpenPGP, SHA checksums, digital signing tools.

• Reference frameworks: ENISA CRA guidelines for update availability, ISO/IEC 30111 for secure patch management.

Paragraph 9 ensures long-term security assurance for users by guaranteeing that security updates remain accessible throughout and beyond the support period. Maintaining a repository of updates and proper documentation strengthens trust, regulatory compliance, and the overall resilience of the product ecosystem.

Where a manufacturer has placed subsequent substantially modified versions of a software product on the market, that manufacturer may ensure compliance with the essential cybersecurity requirement set out in Part II, point (2), of Annex I only for the version that it has last placed on the market, provided that the users of the versions that were previously placed on the market have access to the version last placed on the market free of charge and do not incur additional costs to adjust the hardware and software environment in which they use the original version of that product.

What This Obligation Means

This paragraph addresses how manufacturers can manage compliance when they release substantially modified versions of software products. In practical terms:

• Manufacturers may focus cybersecurity compliance efforts on the most recent version of a software product rather than maintaining full compliance for all older versions.

• Users of previously released versions must have free access to the latest version.

• Users should not incur additional costs to adjust their hardware or software environment to use the latest version.

• The aim is to simplify compliance for manufacturers while ensuring that users are not disadvantaged and continue to benefit from security improvements.

How to Comply in Practice

Organizational Actions

• Define a version management and upgrade policy for software products, covering:

• Identification of substantially modified versions.

• Compliance focus on the latest version.

• Ensuring free and smooth access for users of older versions.

• Establish a communication plan to notify users about updates and provide clear upgrade instructions.

Policy / Process Updates

• Update Software Lifecycle and Compliance Policies to include:

  • Definition of “substantially modified version.”

  • Mechanisms to provide users of older versions with free access to the latest version.

  • Procedures to minimize additional costs or hardware/software changes for users.

• Include provisions for tracking user adoption of the latest version and support for legacy environments where upgrades are not immediately feasible.

Technical Implementations

• Use version control and deployment tools to manage release histories and update distribution.

• Ensure backward compatibility where possible to reduce hardware/software adjustments for users.

• Provide automated update or upgrade mechanisms to deliver the latest version to existing users.

• Maintain documentation linking older versions to the latest version and the cybersecurity improvements included.

Documentation Requirements

Include in technical documentation (Annex VII):

• Records of software versions released, highlighting substantial modifications.

• Evidence that the latest version is freely accessible to users of older versions.

• Notes on measures to avoid additional costs for users when upgrading.

• Traceability between compliance of the latest version and prior versions.

Common Pitfalls and Readiness Gaps

• Charging users for access to the latest version or requiring costly environment changes.

• Failing to clearly define which versions are “substantially modified.”

• Not providing clear guidance or automated mechanisms for users to upgrade.

• Incomplete documentation linking older versions to compliance of the latest version.

Tools and Frameworks to Help

• Version control systems: Git, SVN, Mercurial.

• Software distribution platforms: Package managers, CI/CD pipelines, enterprise update services.

• Upgrade automation: Patch management tools, auto-update modules, containerized deployments.

• Tracking and analytics: User adoption metrics, feedback systems.

• Reference frameworks: ENISA CRA guidance, ISO/IEC 30111 for patching and vulnerability handling.

Paragraph 10 balances regulatory compliance with user experience. By focusing compliance on the most recent version while ensuring free and cost-free access for users of older versions, manufacturers can streamline security efforts and maintain product security across all users. Proper documentation and upgrade mechanisms are critical to demonstrating compliance and protecting users.

Manufacturers may maintain public software archives enhancing user access to historical versions. In those cases, users shall be clearly informed in an easily accessible manner about risks associated with using unsupported software.

What This Obligation Means

This paragraph focuses on maintaining historical software versions and informing users of associated risks. In practical terms:

• Manufacturers may keep public archives of older software versions, allowing users access to legacy versions if needed.

• Users must be clearly informed about the security risks of using unsupported or outdated versions.

• Information about risks must be easily accessible and understandable, enabling users to make informed decisions.

• The objective is to balance user flexibility with cybersecurity awareness, ensuring users are aware that older versions may no longer receive updates or patches.

How to Comply in Practice

Organizational Actions

• Define policies for public archival of historical software versions, specifying which versions may be retained.

• Assign responsibility for risk communication, ensuring users are adequately informed about unsupported software.

• Maintain a repository or archive platform for historical versions that includes documentation and warnings.

Policy / Process Updates

• Update Software Lifecycle Policy to include management of historical versions and risk disclosure.

• Define user notification processes, such as:

  • On download pages or repositories.

  • During installation or upgrade prompts.

  • Through release notes or documentation.

• Include standardized risk messaging highlighting that unsupported versions:

  • May contain unpatched vulnerabilities.

  • Could be incompatible with current environments.

  • Are outside the manufacturer’s support and compliance scope.

Technical Implementations

• Use a centralized archive or repository with version control for historical software.

• Ensure download links include visible warnings about unsupported status.

• Implement metadata tagging to indicate support status, last update date, and known vulnerabilities.

• Optionally, provide migration guidance to encourage upgrading to supported versions.

Documentation Requirements

Record in technical documentation (Annex VII):

• List of archived versions available publicly.

• Evidence of user-facing risk communication.

• Notes on procedures for managing and updating archives.

• Metadata linking archived versions to vulnerabilities or known risks.

Common Pitfalls and Readiness Gaps

• Archiving historical versions without clear warnings about risks.

• Making unsupported versions easily accessible without accompanying guidance.

• Lack of documentation showing risk communication measures.

• Archiving versions that could pose regulatory or security liability without mitigation.

Tools and Frameworks to Help

• Software repositories and archives: GitHub, GitLab, Artifactory, Nexus Repository.

• User notification and messaging tools: Web banners, release notes, installer warnings.

• Metadata and version tracking: SPDX, CycloneDX, automated tagging.

• Reference frameworks: ENISA CRA guidance on software archives and risk communication, ISO/IEC 27005 for risk awareness.

Paragraph 11 allows manufacturers to offer users access to legacy software while ensuring they are informed of security risks. By maintaining clear and accessible risk communication, manufacturers provide user transparency and promote informed decision-making, reducing the potential for security incidents associated with unsupported software.

Before placing a product with digital elements on the market, manufacturers shall draw up the technical documentation referred to in Article 31.

They shall carry out the chosen conformity assessment procedures as referred to in Article 32 or have them carried out. Where compliance of the product with digital elements with the essential cybersecurity requirements set out in Part I of Annex I and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Part II of Annex I has been demonstrated by that conformity assessment procedure, manufacturers shall draw up the EU declaration of conformity in accordance with Article 28 and affix the CE marking in accordance with Article 30.

What This Obligation Means

This paragraph outlines the final compliance and certification steps manufacturers must complete before placing a product with digital elements on the market. In practical terms:

• Manufacturers must prepare complete technical documentation (as per Article 31) before market placement.

• The manufacturer must perform, or have performed, the appropriate conformity assessment procedure (Article 32) to demonstrate compliance.

• Compliance must cover:

  • Product-level cybersecurity requirements (Part I of Annex I).

  • Process-level cybersecurity requirements (Part II of Annex I).

• Once compliance is confirmed, manufacturers must:

  • Draw up the EU Declaration of Conformity (Article 28).

  • Affix the CE marking to the product (Article 30).

• This ensures that the product legally meets EU cybersecurity standards and is ready for market entry.

How to Comply in Practice

Organizational Actions

• Assign responsibility for preparing technical documentation and coordinating the conformity assessment.

• Ensure cross-functional review of both product and process compliance evidence, including security, engineering, and legal teams.

• Maintain a compliance register linking the technical file, assessment results, and CE marking evidence.

Policy / Process Updates

• Update Product Compliance Policy to reflect:

  • Step-by-step process for conducting conformity assessment.

  • Internal approval workflows before issuing the EU Declaration of Conformity.

  • CE marking procedures and requirements for cybersecurity compliance.

• Include policies for process and product validation, ensuring alignment with Annex I requirements.

Technical Implementations

• Prepare structured technical documentation with embedded cybersecurity risk assessment, SBOM, vulnerability records, and mitigation evidence.

• Conduct conformity assessment procedures, either internally (if self-assessment is allowed) or via a notified body.

• Maintain traceability between Annex I requirements and evidence, ensuring auditors can validate compliance efficiently.

Documentation Requirements

Technical documentation must include:

• Complete product specifications and cybersecurity risk assessment.

• Evidence of vulnerability management and component due diligence.

• Records of conformity assessment results for both Part I and Part II of Annex I.

• The EU Declaration of Conformity signed and dated.

• Proof of CE marking application on the product.

Common Pitfalls and Readiness Gaps

• Incomplete technical documentation missing risk assessment, SBOM, or vulnerability records.

• Failure to align conformity assessment with both product and process requirements.

• Delays in drawing up the EU Declaration of Conformity.

• Incorrect or missing CE marking on the product.

Tools and Frameworks to Help

• Documentation management: Polarion, Jama Connect, Confluence + Git integration.

• Conformity assessment support: ISO/IEC 27001-based checklists, internal audit templates, notified body guidance.

• Traceability tools: IriusRisk, ServiceNow GRC, Jira for linking requirements to evidence.

• Reference frameworks: ENISA CRA guidance, ISO/IEC 30111 for vulnerability handling, SBOM standards (CycloneDX, SPDX).

Paragraph 12 ensures that the manufacturer demonstrates full compliance with CRA cybersecurity requirements before market placement. By preparing comprehensive technical documentation, completing the conformity assessment, issuing the EU Declaration of Conformity, and affixing the CE marking, manufacturers provide legally recognized evidence that their product meets EU cybersecurity standards. This step formalizes compliance and signals regulatory confidence to users and authorities.

Manufacturers shall keep the technical documentation and the EU declaration of conformity at the disposal of the market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer.

What This Obligation Means

This paragraph focuses on the retention and accessibility of compliance documentation for regulatory purposes. In practical terms:

• Manufacturers must retain technical documentation and the EU Declaration of Conformity for each product.

• The minimum retention period is 10 years after the product has been placed on the market, or the support period, whichever is longer.

• Documentation must be readily available to market surveillance authorities upon request, enabling verification of CRA compliance.

• The purpose is to ensure traceability, accountability, and regulatory oversight throughout the product lifecycle.

How to Comply in Practice

Organizational Actions

• Assign responsibility for document retention and management, ensuring records remain accessible for audits.

• Maintain a central repository for technical documentation and EU Declarations of Conformity.

• Implement audit-ready procedures so that documents can be retrieved efficiently for market surveillance authorities.

Policy / Process Updates

Update Documentation Retention Policy to specify:

• Retention period criteria (≥10 years or longer if support period exceeds 10 years).

• Access and retrieval procedures for market surveillance authorities.

• Version control, archival, and backup requirements.

• Include guidance on digital and physical storage, ensuring secure, tamper-proof access.

Technical Implementations

• Use document management systems with version control and audit trails (e.g., Polarion, Confluence + Git, Jama Connect).

• Store EU Declarations of Conformity and technical files in formats that are easily accessible and readable over long periods.

• Implement redundant backup systems to prevent data loss.

• Apply metadata and indexing for efficient retrieval, including product identifiers, version numbers, and dates.

Documentation Requirements

Retained documents must include:

• Complete technical documentation (per Article 31 and Annex VII).

• EU Declaration of Conformity (per Article 28).

• Version history and timestamps for traceability.

• Evidence of updates to risk assessment, vulnerability management, and security measures.

Common Pitfalls and Readiness Gaps

• Retaining documentation for less than 10 years or shorter than the support period.

• Storing documents in formats that become unreadable over time (e.g., obsolete file types).

• Poor indexing or lack of metadata, making retrieval difficult during audits.

• Inadequate security or backup measures, risking loss or tampering of records.

Tools and Frameworks to Help

• Document management systems: Polarion, Jama Connect, Confluence + Git, SharePoint.

• Version control and archival: Git, SVN, enterprise content management systems.

• Secure storage and backup: Cloud archival solutions (S3 Glacier, Azure Blob Archive) with long-term retention policies.

• Reference frameworks: ENISA CRA guidance on documentation retention, ISO/IEC 27001 for secure records management.

Paragraph 13 ensures that manufacturers maintain long-term traceability and accountability for products with digital elements. By retaining technical documentation and EU Declarations of Conformity for the required period, manufacturers enable market surveillance authorities to verify compliance and support regulatory enforcement. Proper organization, secure storage, and efficient retrieval procedures are key to fulfilling this obligation.

Manufacturers shall ensure that procedures are in place for products with digital elements that are part of a series of production to remain in conformity with this Regulation. Manufacturers shall adequately take into account changes in the development and production process or in the design or characteristics of the product with digital elements and changes in the harmonised standards, European cybersecurity certification schemes or common specifications as referred to in Article 27 by reference to which the conformity of the product with digital elements is declared or by application of which its conformity is verified.

What This Obligation Means

This paragraph emphasizes that products in a series of production must continue to comply with CRA requirements. In practical terms:

• Manufacturers must establish procedures to ensure ongoing conformity of each product in series production with the CRA.

• Procedures must account for any changes that could affect compliance, including:

  • Changes in product design, characteristics, or functionality.

  • Modifications in the development or production process.

  • Updates to harmonised standards, European cybersecurity certification schemes, or common specifications referenced for compliance (per Article 27).

• The goal is to ensure that all units produced after the initial certification remain compliant, maintaining regulatory conformity throughout the product lifecycle.

How to Comply in Practice

Organizational Actions

• Assign a compliance owner responsible for ongoing monitoring of production and design changes.

• Establish a cross-functional review process (engineering, quality, security, compliance) to evaluate any changes affecting product conformity.

• Maintain a series production compliance register, tracking conformity verification for each batch or release.

Policy / Process Updates

• Update Change Management and Production Policies to require:

  • Assessment of the impact of design, process, or standard changes on CRA compliance.

  • Documentation of conformity verification for modified products.

  • Procedures to review updates to harmonised standards, certification schemes, and common specifications, applying changes where necessary.

• Implement internal audit mechanisms to ensure procedures are followed consistently for all production batches.

Technical Implementations

• Use version-controlled production records to track changes in design, software, hardware, and manufacturing processes.

• Implement automated checks or quality gates in production workflows to verify conformity with the latest standards.

• Maintain traceability between product units, risk assessments, and compliance documentation to demonstrate ongoing adherence.

Documentation Requirements

Technical documentation (Annex VII) should include:

• Records of conformity checks for series production.

• Evidence of evaluations of changes in product design, process, or standards.

• References to updated harmonised standards, certification schemes, or common specifications applied.

• Version history and timestamps for traceability of production compliance.

Common Pitfalls and Readiness Gaps

• Failing to update procedures to account for design or production changes.

• Lack of monitoring of updates to standards or certification schemes affecting conformity.

• Not maintaining documentation demonstrating ongoing compliance for each batch.

• Fragmented responsibility leading to inconsistent application of procedures across production.

Tools and Frameworks to Help

• Change management and version control: Git, Jira, Polarion, Confluence.

• Quality management systems: ISO 9001-based QMS, ERP-integrated compliance tracking.

• Compliance verification tools: IriusRisk, ServiceNow GRC, automated test suites.

• Reference frameworks: ENISA CRA guidance on ongoing conformity, ISO/IEC 27001 for change management and continuous compliance.

Paragraph 14 ensures that compliance is maintained beyond initial certification, protecting the security of all products produced in a series. By establishing robust procedures to track changes in design, production, and standards, manufacturers can guarantee consistent adherence to CRA requirements, reduce regulatory risk, and ensure that every product delivered to the market is secure and compliant.

Manufacturers shall ensure that their products with digital elements bear a type, batch or serial number or other element allowing their identification, or, where that is not possible, that that information is provided on their packaging or in a document accompanying the product with digital elements.

What This Obligation Means

This paragraph ensures that each product with digital elements can be uniquely identified. In practical terms:

• Manufacturers must provide a unique identifier for each product, which can be:

  • Type number

  • Batch number

  • Serial number

  • Other identification element that allows tracing the product.

• If it is not possible to mark the product itself, the information must be provided on the packaging or in accompanying documentation.

• The goal is to enable traceability, accountability, and efficient recall or vulnerability management if needed.

How to Comply in Practice

Organizational Actions

• Assign responsibility for product identification and labeling within production and compliance teams.

• Maintain a centralized product registry linking identifiers to technical documentation, risk assessments, and production records.

• Ensure identifiers are unique, consistent, and persistent across the product lifecycle.

Policy / Process Updates

• Update Product Identification Policy to define:

  • Format and type of identifiers (serial, batch, type, or equivalent).

  • Placement of identifiers on the product, packaging, or documentation.

  • Procedures to manage exceptions when direct marking is not feasible.

• Integrate identification processes with vulnerability management and traceability workflows, enabling rapid response in case of security incidents.

Technical Implementations

• Implement serialization or batch tracking systems in production lines.

• Use machine-readable codes (e.g., QR codes, barcodes, or RFID tags) where appropriate.

• Maintain digital records linking each identifier to the product’s technical documentation and risk assessment.

• Ensure identifiers are durable and resistant to tampering or wear throughout the product’s support period.

Documentation Requirements

Include in technical documentation (Annex VII):

• List of identification elements used and their format.

• Mapping of identifiers to production batches or units.

• Procedures for handling exceptions where product marking is not feasible.

• Evidence linking identifiers to technical documentation, risk assessments, and EU Declaration of Conformity.

Common Pitfalls and Readiness Gaps

• Failing to assign unique or persistent identifiers.

• Using identifiers that are difficult to read or decode, limiting traceability.

• Omitting identifiers from packaging or accompanying documentation when direct marking is impossible.

• Poor linkage between identifiers and product documentation, complicating audits or recalls.

Tools and Frameworks to Help

• Serialization and tracking systems: ERP modules, MES systems, or dedicated product tracking software.

• Labeling and marking tools: QR/barcode printers, RFID tagging solutions.

• Digital traceability platforms: Product lifecycle management (PLM) tools like Siemens Teamcenter, PTC Windchill.

• Reference frameworks: ENISA CRA guidance on traceability, ISO 9001 for product identification and traceability.

Paragraph 15 ensures that each product can be uniquely identified and traced, which is critical for vulnerability management, regulatory compliance, and market surveillance. By implementing robust identification systems and linking identifiers to technical documentation, manufacturers can maintain accountability, facilitate audits, and quickly respond to security incidents.

Manufacturers shall indicate the name, registered trade name or registered trademark of the manufacturer, and the postal address, email address or other digital contact details, as well as, where applicable, the website where the manufacturer can be contacted, on the product with digital elements, on its packaging or in a document accompanying the product with digital elements. That information shall also be included in the information and instructions to the user set out in Annex II. The contact details shall be in a language which can be easily understood by users and market surveillance authorities.

What This Obligation Means

This paragraph ensures that users and authorities can easily contact the manufacturer of a product with digital elements. In practical terms:

• Manufacturers must provide clear contact information, including:

  • Name, registered trade name, or registered trademark.

  • Postal address, email address, or other digital contact details.

  • Website, if applicable.

• This information must appear:

  • On the product itself, or

  • On its packaging, or

  • In accompanying documentation.

• The information must also be included in the user instructions and information (Annex II).

• Contact details must be in a language easily understood by both users and market surveillance authorities.

• The objective is to facilitate communication for support, vulnerability reporting, or regulatory purposes.

How to Comply in Practice

Organizational Actions

• Assign responsibility for maintaining accurate and up-to-date manufacturer contact information.

• Ensure contact details are reviewed and validated during product documentation preparation.

• Establish internal procedures to promptly update contact details across all communication channels when changes occur.

Policy / Process Updates

• Update Product Labeling and Documentation Policies to specify:

• Required contact information fields.

• Locations where contact information must appear (product, packaging, documentation, user instructions).

• Language requirements to ensure accessibility.

• Integrate contact detail management with support and vulnerability handling procedures to ensure inquiries are properly routed.

Technical Implementations

Include contact details in:

• Product labeling (physically or digitally embedded).

• Packaging print or inserts.

• Electronic user manuals, PDF guides, and embedded product interfaces.

• Maintain a centralized database of contact information for consistency across products and updates.

• Ensure contact details are machine-readable where possible for automated vulnerability reporting or regulatory compliance systems.

Documentation Requirements

Technical documentation (Annex VII) should include:

• Manufacturer name and registered trademark details.

• Postal and digital contact information, including website if applicable.

• Evidence that contact information is included in user instructions (Annex II) and on product/packaging.

• Language used for contact information.

Common Pitfalls and Readiness Gaps

• Providing incomplete contact details (e.g., missing email or postal address).

• Not updating contact information across all relevant documents when company information changes.

• Using a language not understood by users or market authorities, leading to communication issues.

• Failing to include contact details in user instructions, which is legally required.

Tools and Frameworks to Help

• Document and labeling management: Polarion, Confluence, PLM systems.

• Centralized contact database: ERP systems, CRM platforms.

• Version control and audit tracking: Git, SharePoint, or internal QA systems.

• Reference frameworks: ENISA CRA guidance on labeling and user information, Annex II – Information and Instructions for Users.

Paragraph 16 ensures transparency and accessibility for users and authorities. By clearly providing manufacturer contact information in all required locations and languages, manufacturers enable efficient support, vulnerability reporting, and regulatory communication, which strengthens both user trust and regulatory compliance.

For the purposes of this Regulation, manufacturers shall designate a single point of contact to enable users to communicate directly and rapidly with them, including in order to facilitate reporting on vulnerabilities of the product with digital elements.

Manufacturers shall ensure that the single point of contact is easily identifiable by the users. They shall also include the single point of contact in the information and instructions to the user set out in Annex II.

The single point of contact shall allow users to choose their preferred means of communication and shall not limit such means to automated tools.

What This Obligation Means

This paragraph ensures that users have a direct and efficient way to communicate with the manufacturer, particularly regarding cybersecurity vulnerabilities. In practical terms:

• Manufacturers must designate a single point of contact (SPOC) for all communications related to the product with digital elements.

• The SPOC should enable:

  • Rapid user communication for general inquiries or support.

  • Efficient reporting of vulnerabilities, facilitating coordinated vulnerability disclosure.

• The SPOC must be easily identifiable by users.

• The contact must be included in user information and instructions (Annex II).

• Users must be allowed to choose their preferred communication method, which should not be limited to automated tools (e.g., web forms only).

• The overall goal is to ensure flexible, clear, and effective communication between users and the manufacturer, supporting proactive cybersecurity management.

How to Comply in Practice

Organizational Actions

• Assign responsibility to a dedicated individual or team to serve as the SPOC.

• Define roles and responsibilities for the SPOC, including tracking, triaging, and responding to vulnerability reports.

• Ensure that the SPOC is accessible during the product’s support period and can coordinate internally with security, engineering, and compliance teams.

Policy / Process Updates

• Update Vulnerability Management and Incident Response Policies to integrate SPOC responsibilities, including:

• Logging and triaging vulnerability reports.

• Coordinating with third-party component providers where relevant.

• Providing timely feedback or mitigation updates to users.

  • Include guidance in user instructions (Annex II) on how to identify and contact the SPOC.

  • Define communication options: email, phone, web portal, or other methods, ensuring users can select their preferred method.

Technical Implementations

• Establish a dedicated communication channel:

  • Email alias (e.g., security@manufacturer.com)

  • Web-based reporting portal or form

  • Telephone or other direct communication options

• Ticketing system integrated with incident and vulnerability tracking tools

• Maintain tracking and response metrics to ensure timely action on reported vulnerabilities.

• Integrate SPOC workflows with vulnerability management platforms (e.g., Jira, ServiceNow, IriusRisk).

• Ensure user-facing instructions clearly present the SPOC and multiple communication options.

Documentation Requirements

Technical documentation (Annex VII) should include:

• Name and role of the SPOC.

• Contact details for the SPOC (email, web portal, phone if applicable).

• Evidence that the SPOC is responsible for vulnerability reporting and response.

• Links to how users can report vulnerabilities, included in user instructions (Annex II).

• Records of training and processes ensuring SPOC readiness.

Common Pitfalls and Readiness Gaps

• Failing to designate a single point of contact, leading to fragmented vulnerability reporting.

• Not providing clear contact information for the SPOC to users.

• Inadequate processes for tracking, triaging, and responding to reported vulnerabilities.

• SPOC responsibilities not aligned with internal incident response or vulnerability handling procedures.

Tools and Frameworks to Help

• Vulnerability management and ticketing systems: Jira, ServiceNow, IriusRisk, Bugzilla.

• Communication platforms: Dedicated email alias, secure web portal forms.

• Incident tracking: Integration with SIEM or SOC dashboards for actionable follow-up.

• Reference frameworks: ENISA CRA guidance on vulnerability handling and single point of contact, Annex II – Information and Instructions for Users.

Paragraph 17 ensures that users can report vulnerabilities directly and efficiently, supporting proactive cybersecurity management. By establishing a SPOC, manufacturers enable rapid communication, coordinated responses, and regulatory transparency, reducing security risks and building user trust.

Manufacturers shall ensure that products with digital elements are accompanied by the information and instructions to the user set out in Annex II, in paper or electronic form. Such information and instructions shall be provided in a language which can be easily understood by users and market surveillance authorities. They shall be clear, understandable, intelligible and legible. They shall allow for the secure installation, operation and use of products with digital elements. Manufacturers shall keep the information and instructions to the user set out in Annex II at the disposal of users and market surveillance authorities for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer. Where such information and instructions are provided online, manufacturers shall ensure that they are accessible, user-friendly and available online for at least 10 years after the product with digital elements has been placed on the market or for the support period, whichever is longer.

What This Obligation Means

This paragraph ensures that products with digital elements are accompanied by clear, accessible, and durable user instructions. In practical terms:

• Manufacturers must provide information and instructions as set out in Annex II, either in paper or electronic form.

• Instructions must be:

  • Clear, understandable, intelligible, and legible.

  • Written in a language easily understood by users and market surveillance authorities.

  • Designed to enable secure installation, operation, and use of the product.

• Instructions must be retained and accessible for at least 10 years after market placement or for the support period, whichever is longer.

• If provided online, instructions must be user-friendly, accessible, and available for the same retention period.

• The goal is to empower users to safely operate the product and ensure regulatory authorities can review guidance if needed.

How to Comply in Practice

Organizational Actions

• Assign responsibility for creating, reviewing, and updating user instructions.

• Ensure cross-functional review including engineering, security, compliance, and legal teams.

• Establish a document retention system to maintain instructions for the required period.

Policy / Process Updates

• Update User Information and Documentation Policy to include:

  • Clear standards for clarity, legibility, and understandability.

  • Language requirements to cover target users and regulatory authorities.

  • Procedures for secure installation and safe operation instructions.

  • Online availability and retention for at least 10 years or the support period.

• Integrate instructions with vulnerability reporting, updates, and support policies.

Technical Implementations

• Provide instructions in digital formats (PDF, HTML, or interactive manuals) for online access.

• Ensure website accessibility and user-friendliness, including search functionality and responsive design.

• Implement version control and archiving to track updates and retain previous versions.

• Use metadata and indexing for easy retrieval by users and market surveillance authorities.

Documentation Requirements

Technical documentation (Annex VII) should include:

• Copies or references to user instructions.

• Language(s) in which instructions are provided.

• Evidence of secure installation, operation, and use guidance.

• Proof of retention and online availability for the required period.

Common Pitfalls and Readiness Gaps

• Instructions that are unclear, incomplete, or difficult to understand.

• Failing to provide instructions in languages understandable to users or authorities.

• Not maintaining online instructions for the required period.

• Omitting instructions from technical documentation or failing to update versions.

Tools and Frameworks to Help

• Content management and documentation systems: Confluence, SharePoint, Polarion, MadCap Flare.

• Version control and archival: Git, document management platforms with retention policies.

• Accessibility tools: WCAG compliance tools for web-based instructions.

• Reference frameworks: ENISA CRA guidance on user instructions, Annex II – Information and Instructions for Users, ISO/IEC 27001 for secure documentation practices.

Paragraph 18 ensures that users have all necessary guidance to securely use products with digital elements and that regulatory authorities can review instructions when needed. Clear, accessible, and long-term retention of instructions enhances user safety, product security, and compliance readiness.

Manufacturers shall ensure that the end date of the support period referred to in paragraph 8, including at least the month and the year, is clearly and understandably specified at the time of purchase in an easily accessible manner and, where applicable, on the product with digital elements, its packaging or by digital means.

Where technically feasible in light of the nature of the product with digital elements, manufacturers shall display a notification to users informing them that their product with digital elements has reached the end of its support period.

What This Obligation Means

This paragraph ensures that users are fully informed about the duration of support for their product with digital elements. In practical terms:

• Manufacturers must clearly specify the end date of the support period, including at least the month and year, at the time of purchase.

• This information must be presented in an easily accessible and understandable manner, which may include:

  • On the product itself.

  • On the packaging.

  • Via digital means, such as the product website, account portal, or app interface.

• Where technically feasible, manufacturers must notify users when the product has reached the end of its support period.

• The goal is to ensure transparency regarding product support, enabling users to plan updates, replacements, or mitigations for end-of-support products.

How to Comply in Practice

Organizational Actions

• Assign responsibility for tracking support periods for all products with digital elements.

• Maintain a centralized support period registry linking products, batches, and versions to their end-of-support dates.

• Define internal procedures for issuing end-of-support notifications to users.

Policy / Process Updates

• Update Product Support Policy to include:

  • Methods for communicating support end dates at the point of purchase.

  • Requirements for notifications when the support period ends.

  • Procedures for handling products that may reach end-of-support while still in use.

• Integrate with vulnerability management and user communication policies to ensure proactive messaging.

Technical Implementations

• Include support period details in:

  • Product labeling, packaging, or accompanying documentation.

  • Digital interfaces, apps, or portals associated with the product.

• Implement automatic notifications (push notifications, email, or in-product messages) when the support period expires.

• Ensure records of notifications sent are maintained for compliance and audit purposes.

Documentation Requirements

Technical documentation (Annex VII) should include:

• Support period details, including end month and year.

• Evidence of how support period information is communicated at purchase.

• Procedures and systems used to notify users when the support period ends.

• Records showing implementation of end-of-support notifications, if technically feasible.

Common Pitfalls and Readiness Gaps

• Failing to clearly communicate the support period at purchase.

• Omitting support end dates from product, packaging, or digital interfaces.

• Lack of automated or feasible notification systems to inform users when support ends.

• Poor record-keeping of notifications, complicating compliance audits.

Tools and Frameworks to Help

• Product lifecycle management systems: Siemens Teamcenter, PTC Windchill.

• Customer communication platforms: Email automation (SendGrid, Mailchimp), in-product notifications, app messaging systems.

• ERP/CRM systems: Track product batches, versions, and associated support end dates.

• Reference frameworks: ENISA CRA guidance on support periods and end-of-support notifications, Annex VII – Technical Documentation Contents.

Paragraph 19 ensures transparency and user awareness regarding product support periods. By clearly specifying the end date and providing notifications, manufacturers help users plan for updates, replacements, or mitigations, improving both cybersecurity and customer trust.

Manufacturers shall either provide a copy of the EU declaration of conformity or a simplified EU declaration of conformity with the product with digital elements. Where a simplified EU declaration of conformity is provided, it shall contain the exact internet address at which the full EU declaration of conformity can be accessed.

What This Obligation Means

This paragraph ensures that users and authorities have access to the EU Declaration of Conformity (DoC) for products with digital elements. In practical terms:

• Manufacturers must provide either:

  • A full copy of the EU Declaration of Conformity, or

  • A simplified EU Declaration of Conformity with the product.

• If a simplified DoC is provided, it must include the exact internet address where the full DoC can be accessed.

• The objective is to ensure transparency and regulatory compliance, allowing users and authorities to verify conformity with CRA requirements.

How to Comply in Practice

Organizational Actions

• Assign responsibility for preparing and maintaining EU Declarations of Conformity.

• Ensure that simplified versions clearly reference the full DoC online.

• Maintain a central repository for all DoCs and ensure accurate linking for online access.

Policy / Process Updates

• Update Product Compliance and Documentation Policy to include:

• Procedures for providing either full or simplified DoC with products.

• Rules for generating online links to full DoC from simplified versions.

• Regular review to ensure URLs remain accessible and up-to-date.

Technical Implementations

• Include full DoC as a PDF or electronic document in the product package or online portal.

• Provide simplified DoC on product labels, packaging, or inserts, including the exact URL for the full DoC.

• Implement website management systems to ensure DoC pages remain accessible for the required retention period.

Documentation Requirements

• Technical documentation (Annex VII) should include:

• Evidence that the product is accompanied by either full or simplified DoC.

• If simplified, record the exact URL where the full DoC can be accessed.

• Procedures for maintaining DoC availability online.

• Records of updates and version control of DoCs.

Common Pitfalls and Readiness Gaps

• Providing a simplified DoC without a direct link to the full DoC.

• URLs for full DoC becoming inactive or outdated.

• Omitting DoC with the product, violating compliance obligations.

• Lack of tracking and version control for updated DoCs.

Tools and Frameworks to Help

• Document management systems: Confluence, SharePoint, Polarion for maintaining DoCs.

• Website content management: WordPress, Drupal, or corporate portals for DoC accessibility.

• ERP/PLM integration: Ensure that product batches link to the correct DoC.

• Reference frameworks: ENISA CRA guidance on EU Declaration of Conformity, Annex VII – Technical Documentation Contents.

Paragraph 20 ensures that regulatory and user transparency is maintained by making the EU Declaration of Conformity readily available. Providing either the full DoC or a simplified version with a direct link to the full document allows quick verification of product compliance, strengthening trust and regulatory adherence.

From the placing on the market and for the support period, manufacturers who know or have reason to believe that the product with digital elements or the processes put in place by the manufacturer are not in conformity with the essential cybersecurity requirements set out in Annex I shall immediately take the corrective measures necessary to bring that product with digital elements or the manufacturer’s processes into conformity, or to withdraw or recall the product, as appropriate.

What This Obligation Means

This paragraph ensures that manufacturers take immediate action when a product or process is found to be non-compliant with essential cybersecurity requirements. In practical terms:

• From the moment the product is placed on the market and throughout the support period, manufacturers must act if they know or reasonably believe that the product or their processes are not in conformity with Annex I requirements.

• Corrective actions may include:

  • Bringing the product or process into conformity (e.g., software patch, process update).

  • Withdrawing the product from the market.

  • Recalling the product already distributed to users.

• The objective is to prevent security risks due to non-compliant products or processes and protect users and the market.

How to Comply in Practice

Organizational Actions

• Establish a corrective action team responsible for evaluating and addressing non-conformities.

• Maintain a process for monitoring product and process compliance throughout the product lifecycle.

• Define roles and responsibilities for immediate escalation and implementation of corrective measures.

Policy / Process Updates

• Update Non-Conformity and Corrective Action Policies to include:

  • Criteria for identifying non-conformity.

  • Immediate response procedures for corrective actions, withdrawal, or recall.

• Coordination with market surveillance authorities and users when corrective actions are taken.

• Integrate with vulnerability management, risk assessment, and support procedures to ensure timely detection of non-conformities.

Technical Implementations

• Implement monitoring systems for detecting deviations from Annex I cybersecurity requirements.

• Use issue tracking and product lifecycle management tools to record non-conformities and track corrective actions.

• Prepare software updates, patches, or process improvements to quickly bring products into conformity.

Documentation Requirements

Technical documentation (Annex VII) should include:

• Evidence of corrective actions taken for non-conformities.

• Records of decisions to withdraw or recall products.

• Communication logs with users and market authorities.

• Updated risk assessments demonstrating compliance after corrective measures.

Common Pitfalls and Readiness Gaps

• Delayed response to non-conformities, increasing cybersecurity risks.

• Inadequate monitoring of products and processes post-market placement.

• Failure to document corrective actions or notify authorities as required.

• Lack of clear procedures for withdrawal or recall, leading to regulatory or legal issues.

Tools and Frameworks to Help

• Issue tracking and corrective action systems: Jira, ServiceNow, IriusRisk.

• Product lifecycle management tools: Siemens Teamcenter, PTC Windchill.

• Communication and notification systems for recalls or withdrawals.

• Reference frameworks: ENISA CRA guidance on corrective actions, Annex I – Essential Cybersecurity Requirements, Annex VII – Technical Documentation Contents.

Paragraph 21 emphasizes the manufacturer’s duty to act swiftly when products or processes are non-compliant with essential cybersecurity requirements. Proactive monitoring, clear procedures, and immediate corrective actions or recalls are critical to protecting users, maintaining regulatory compliance, and minimizing security risks.

Manufacturers shall, upon a reasoned request from a market surveillance authority, provide that authority, in a language which can be easily understood by that authority, with all the information and documentation, in paper or electronic form, necessary to demonstrate the conformity of the product with digital elements and of the processes put in place by the manufacturer with the essential cybersecurity requirements set out in Annex I. Manufacturers shall cooperate with that authority, at its request, on any measures taken to eliminate the cybersecurity risks posed by the product with digital elements which they have placed on the market.

What This Obligation Means

This paragraph ensures that manufacturers provide full transparency and cooperation with market surveillance authorities regarding product and process conformity. In practical terms:

• Manufacturers must provide all necessary information and documentation to demonstrate that:

• The product with digital elements complies with essential cybersecurity requirements (Annex I).

• The manufacturer’s processes comply with Annex I requirements.

• Documentation must be provided:

  • Upon a reasoned request from the market surveillance authority.

  • In a language easily understood by the authority.

  • In paper or electronic form.

• Manufacturers must cooperate with the authority on any actions taken to eliminate cybersecurity risks posed by products they have placed on the market.

• The goal is regulatory transparency, accountability, and support for effective market surveillance.

How to Comply in Practice

Organizational Actions

• Assign a compliance liaison or team to respond to market surveillance requests.

• Maintain a centralized repository of technical documentation and risk assessments that can be readily accessed and shared.

• Define internal procedures for translating, formatting, and delivering documentation in line with regulatory requirements.

Policy / Process Updates

• Update Regulatory Compliance Policy to include:

• Procedures for responding to requests from market surveillance authorities.

• Communication protocols to ensure timely and accurate delivery of information.

• Steps for cooperation in addressing cybersecurity risks identified by authorities.

• Integrate with risk management, vulnerability handling, and support processes to ensure complete and current information is available.

Technical Implementations

• Ensure all technical documentation, risk assessments, DoCs, and user instructions are stored in a structured, retrievable format.

• Implement document management systems with language translation capabilities if needed.

• Maintain version control and audit trails for all shared documentation.

• Track and document any follow-up actions requested by authorities regarding cybersecurity risks.

Documentation Requirements

Technical documentation (Annex VII) should include:

• All information and documentation required to demonstrate conformity.

• Records of communications with market surveillance authorities.

• Evidence of cooperation and actions taken to mitigate identified cybersecurity risks.

• Translation of documentation where required.

Common Pitfalls and Readiness Gaps

• Delays in responding to market surveillance requests.

• Incomplete or outdated documentation, risking non-compliance.

• Poor tracking of corrective actions or cooperation measures with authorities.

• Lack of clarity on language and format requirements for authorities.

Tools and Frameworks to Help

• Document management systems: Polarion, Confluence, SharePoint.

• Regulatory compliance platforms: ServiceNow GRC, MetricStream.

• Translation tools: Professional translation services or integrated multilingual document management.

• Reference frameworks: ENISA CRA guidance on regulatory cooperation, Annex I – Essential Cybersecurity Requirements, Annex VII – Technical Documentation Contents.

Paragraph 22 ensures that market surveillance authorities can verify compliance and that manufacturers actively cooperate to mitigate cybersecurity risks. Maintaining structured, current, and accessible documentation, along with clear communication channels, is critical for regulatory transparency and demonstrating ongoing compliance.

A manufacturer that ceases its operations and, as a result, is not able to comply with this Regulation shall inform, before the cessation of operations takes effect, the relevant market surveillance authorities as well as, by any means available and to the extent possible, the users of the relevant products with digital elements placed on the market, of the impending cessation of operations.

What This Obligation Means

This paragraph ensures that users and market authorities are informed when a manufacturer can no longer fulfill CRA obligations due to ceasing operations. In practical terms:

• If a manufacturer ceases operations and cannot continue to comply with CRA requirements:

• They must inform relevant market surveillance authorities before the cessation takes effect.

• They must also inform, by any means available and to the extent possible, the users of affected products placed on the market.

• The objective is to maintain user safety and regulatory oversight even when the manufacturer is no longer operational.

How to Comply in Practice

Organizational Actions

• Establish a Cessation of Operations Plan for CRA compliance.

• Maintain contact information for market authorities and users to facilitate notifications.

• Assign responsibility for communicating the cessation to all stakeholders.

Policy / Process Updates

• Update Regulatory and Product Support Policies to include:

• Procedures for notifying authorities of impending cessation.

• Steps for notifying users of products affected by the manufacturer’s closure.

• Escalation protocols for unresolved product support or vulnerability issues.

• Integrate cessation plans with risk management and product lifecycle processes.

Technical Implementations

• Use email notifications, website announcements, and product portals to inform users.

• Maintain a centralized record of notifications sent and communications with authorities.

• Provide guidance on alternatives for continued support or risk mitigation where possible.

Documentation Requirements

Technical documentation (Annex VII) should include:

• Records of notifications sent to authorities and users.

• Timeline of cessation communications.

• Evidence of procedures followed to meet CRA obligations prior to cessation.

Common Pitfalls and Readiness Gaps

• Failing to notify authorities before operations cease.

• Inadequate user communication, leaving users unaware of potential risks.

• Lack of records documenting the notification process.

• No contingency plan for ongoing cybersecurity risk mitigation after cessation.

Tools and Frameworks to Help

• Communication platforms: Email marketing tools (SendGrid, Mailchimp), corporate websites, product portals.

• Document and record management systems: Confluence, SharePoint, Polarion.

• Reference frameworks: ENISA CRA guidance on manufacturer obligations, Annex VII – Technical Documentation Contents.

Paragraph 23 ensures transparency and continued protection for users and regulators when a manufacturer exits the market. Proactive notification and clear documentation help mitigate risks from unsupported products, even after the manufacturer is no longer operational.

The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I. Those implementing acts shall be adopted in accordance with the examination procedure referred to in Article 62(2).

What This Obligation Means

This paragraph provides a regulatory mechanism for standardizing Software Bill of Materials (SBOMs) to ensure clarity, interoperability, and consistency across the EU. In practical terms:

• The European Commission may issue implementing acts that:

• Define the format and elements of the SBOM referred to in Part II, point (1), of Annex I.

• Take into account European and international standards and best practices.

• Implementing acts are adopted according to the examination procedure in Article 62(2), providing a formal and transparent legislative process.

• The aim is to standardize SBOM practices, ensuring manufacturers provide a consistent, clear, and actionable inventory of software components.

How to Comply in Practice

Organizational Actions

• Monitor Commission implementing acts and updates related to SBOM standards.

• Assign responsibility for SBOM compliance, ensuring internal processes align with mandated formats and elements.

• Train engineering, compliance, and security teams on SBOM generation and management according to upcoming standards.

Policy / Process Updates

• Update Software Development and Component Management Policies to include:

• SBOM creation and maintenance requirements aligned with Commission acts.

• Procedures for integrating SBOMs into technical documentation and risk assessments.

• Mechanisms to update SBOMs when software components change.

Technical Implementations

• Implement tools and platforms capable of generating SBOMs in the required standardized format (e.g., CycloneDX, SPDX, SWID).

• Integrate SBOM generation into the CI/CD pipeline to maintain accuracy and currency.

• Ensure SBOMs can be linked to vulnerability management, patching records, and risk assessments for traceability.

Documentation Requirements

Technical documentation (Annex VII) should include:

• SBOMs in the format and with the elements specified by the Commission.

• Records showing compliance with Part II, point (1), of Annex I.

• Version control and update history for SBOMs.

Common Pitfalls and Readiness Gaps

• Failing to monitor updates to Commission implementing acts.

• Generating SBOMs that do not meet required format or content standards.

• Inadequate integration of SBOMs with risk assessments and vulnerability management processes.

• Lack of traceability for SBOM updates over the product lifecycle.

Tools and Frameworks to Help

• SBOM tools: CycloneDX, SPDX, SWID, Snyk, Anchore.

• CI/CD integration platforms: Jenkins, GitLab CI/CD, GitHub Actions for automated SBOM generation.

• Document management systems: Polarion, Confluence, SharePoint for storing and linking SBOMs.

• Reference frameworks: ENISA CRA guidance on SBOMs, ISO/IEC 27005 for risk mapping, Part II, point (1) of Annex I – SBOM requirement.

Paragraph 24 establishes a forward-looking mechanism for standardizing SBOMs, helping manufacturers produce consistent, traceable, and actionable software component inventories. By aligning with Commission implementing acts and international standards, manufacturers enhance transparency, security, and compliance across the EU market.

In order to assess the dependence of Member States and of the Union as a whole on software components and in particular on components qualifying as free and open-source software, ADCO may decide to conduct a Union wide dependency assessment for specific categories of products with digital elements. For that purpose, market surveillance authorities may request manufacturers of such categories of products with digital elements to provide the relevant software bills of materials as referred to in Part II, point (1), of Annex I. On the basis of such information, the market surveillance authorities may provide ADCO with anonymised and aggregated information about software dependencies. ADCO shall submit a report on the results of the dependency assessment to the Cooperation Group established pursuant to Article 14 of Directive (EU) 2022/2555.

What This Obligation Means

This paragraph focuses on assessing the EU’s and Member States’ dependency on software components, particularly free and open-source software (FOSS). In practical terms:

• The Administrative Cooperation (ADCO) group may conduct a Union-wide dependency assessment for specific categories of products with digital elements.

• Market surveillance authorities can request manufacturers to provide relevant Software Bills of Materials (SBOMs) for these products.

• Based on collected SBOM data, authorities may provide ADCO with anonymized and aggregated information about software dependencies.

• ADCO is required to submit a report on the dependency assessment results to the Cooperation Group established under Article 14 of Directive (EU) 2022/2555.

• The objective is to understand software supply chain risks and dependencies at the EU level, supporting strategic planning and cybersecurity resilience.

How to Comply in Practice

Organizational Actions

• Maintain up-to-date SBOMs for all products, including free and open-source software components.

• Assign responsibility for responding to market authority requests for SBOMs.

• Ensure internal processes can anonymize or aggregate data if requested by authorities for reporting purposes.

Policy / Process Updates

• Update SBOM and Compliance Policies to include procedures for:

  • Sharing SBOMs with authorities upon request.

  • Ensuring data privacy when providing information for aggregated reports.

  • Tracking requests and submissions to ADCO or market authorities.

Technical Implementations

• Implement SBOM management tools capable of generating the required reports quickly.

• Ensure SBOMs can be filtered, anonymized, or aggregated in accordance with authority requests.

• Integrate SBOM data with vulnerability management, patching records, and risk assessments to provide complete visibility if requested.

Documentation Requirements

Maintain evidence of:

• SBOM submission to market surveillance authorities.

• Anonymized and aggregated data shared with ADCO.

• Internal tracking of Union-wide dependency requests and responses.

• Technical documentation (Annex VII) should include procedures for handling such requests.

Common Pitfalls and Readiness Gaps

• Incomplete or outdated SBOMs, leading to delays or non-compliance.

• Failure to anonymize or aggregate data as required by authorities.

• Lack of documented procedures for handling dependency assessment requests.

• Inadequate internal tracking of submissions and communications with authorities.

Tools and Frameworks to Help

• SBOM tools: CycloneDX, SPDX, Snyk, Anchore.

• Document and compliance management systems: Polarion, Confluence, SharePoint.

• Data aggregation tools: Excel, Power BI, or custom scripts for anonymization.

• Reference frameworks: ENISA CRA guidance on SBOMs and dependency assessments, Annex I Part II, point (1) – SBOM requirement.

Paragraph 25 emphasizes the strategic importance of understanding software dependencies, especially open-source components, across the EU. By maintaining accurate SBOMs and cooperating with market surveillance authorities and ADCO, manufacturers support cyber resilience, supply chain transparency, and informed policy-making at the Union level.