Obligations of Manufacturers

Article 13(1)–(5) requires manufacturers to ensure that products with digital elements are designed, developed, and produced in accordance with the essential cybersecurity requirements set out in Annex I Part I. This is not a post-production checklist — it is a design-phase obligation.

At the core of this is the cybersecurity risk assessment: before placing a product on the market, manufacturers must carry out an assessment of the cybersecurity risks associated with the product and use the results to inform the design, development, and production process. The risk assessment must be documented and kept as part of the technical documentation required under Article 30.

• Default secure configuration: Products must ship in a secure default state (no universal default passwords, minimal attack surface, secure by default settings).
• Access control: Authentication mechanisms must be appropriate to the risk level of the product and the data it processes.
• Confidentiality and integrity: Data stored and transmitted by the product must be protected at a level appropriate to the risk.
• Minimal data collection: The product must be designed to limit data collection to what is necessary for the product's functions.
• Resilience against attacks: Products must be able to tolerate and recover from denial-of-service attacks and common exploitation techniques.

Manufacturers must be able to demonstrate that the risk assessment was performed and influenced the design. A risk assessment completed after the product design is finalised does not satisfy Article 13.

Article 13(6)–(8) introduces the Software Bill of Materials (SBOM) requirement: manufacturers must identify and document the components in their products — both software components and, where relevant, hardware components with software interfaces — with sufficient granularity to assess vulnerability exposure.

The SBOM is not required to be publicly disclosed, but it must be maintained as part of the technical documentation and must be available to market surveillance authorities on request. The level of detail required includes, at minimum, the component names, versions, and, where applicable, CVE references for known vulnerabilities affecting those components.

• Checking components against known vulnerability databases before integration
• Including components in the ongoing vulnerability monitoring process after market placement
• Ensuring that the support lifecycle of integrated components aligns with the manufacturer's own support commitment

Manufacturers cannot outsource their Article 13 obligations to third-party component suppliers. The manufacturer of the final product remains responsible for the security of all components in their product.

Article 13(9)–(11) sets out the manufacturer's obligation to provide security updates for the duration of the product's support period, and to communicate that support period to users.

Key requirements:

Support period duration: The support period must be commensurate with the expected product lifetime and the nature of the product. For most consumer products, the Commission has indicated that five years is the expected minimum; products intended for longer deployment (industrial control systems, embedded systems) should have correspondingly longer support periods. The support period is set by the manufacturer but must be disclosed.

Security updates during the support period: Manufacturers must provide security updates promptly — meaning as quickly as practicable given the severity of the vulnerability. Updates must be provided separately from feature updates where technically feasible, so users can apply security fixes without being forced to accept other changes.

Automatic updates: Where the product supports automatic updates, the automatic update mechanism should be enabled by default, with users able to opt out. Where automatic updates are not technically feasible, manufacturers must provide a mechanism for users to check for and apply updates manually.

Post-support communication: When the support period ends, manufacturers must clearly communicate to users that the product will no longer receive security updates, and must provide information about available alternatives where possible. Products sold after the support period ends must clearly disclose this to buyers.

Article 13(12)–(14) requires manufacturers to actively monitor products after market placement, not merely respond reactively to reported vulnerabilities.

• New vulnerabilities in the product's own code (through internal security testing, automated scanning, penetration testing)
• New vulnerabilities in third-party components used in the product (by monitoring CVE databases, component vendor advisories, and relevant CERT publications)
• Threat intelligence relevant to the product category

• Assessing the severity of the vulnerability using a recognised scoring system (CVSS or equivalent)
• Developing and testing a patch or workaround
• Deploying the fix to affected users promptly
• Where a fix cannot be deployed immediately, providing interim risk mitigation guidance to users

Documentation of corrective actions: Manufacturers must keep records of all identified vulnerabilities and the corrective actions taken. These records must be available to market surveillance authorities on request and must be retained for the duration of the support period plus at least ten years.

Article 13(15)–(17) — the coordinated vulnerability disclosure provisions — require manufacturers to:

1. Establish a CVD policy — A publicly accessible, documented process for how security researchers and others can report vulnerabilities in your products.
2. Acknowledge receipt — You must acknowledge a vulnerability report within 48 hours of receiving it.
3. Inform the reporter — Provide the reporter with an initial assessment and expected timeline for a fix.
4. Coordinate disclosure — Work with the reporter before any public disclosure to agree on timing and content.
5. Publish advisories — Issue a security advisory when a vulnerability is fixed or when a workaround is available.

All of these obligations apply from 11 December 2027.

One of the most operationally challenging requirements is the 48-hour acknowledgment window. From the moment you receive a vulnerability report through any channel - email, your submission portal, a security researcher's direct contact - you must send an acknowledgment within 48 hours.

This acknowledgment does not need to confirm the vulnerability is valid. It simply confirms receipt and signals that you are processing the report. Failure to acknowledge within 48 hours can constitute a CRA violation, even if you subsequently fix the vulnerability.

Practical implication: You need a monitored inbox, ticketing system, or dedicated vulnerability disclosure portal to ensure no report goes unacknowledged.

Your CVD policy is the public-facing document that explains your vulnerability disclosure process. At a minimum, it must include:

• Contact information: How to reach your security team (email, submission form, or both). This is typically enforced via a security.txt file at /.well-known/security.txt.
• Scope: Which products and versions are covered.
• Process: What happens after you receive a report - acknowledgment timeline, triage, remediation, and disclosure.
• Safe harbour: A commitment not to pursue legal action against researchers who act in good faith.
• Disclosure timeline: When and how you will publicly disclose the vulnerability.

The CVD policy should be publicly accessible - typically linked from your product documentation, website, or security.txt file.

Article 13 specifically mandates coordinated vulnerability disclosure, not simply responsible disclosure. The distinction matters:

• Responsible disclosure traditionally means the researcher gives you time to fix the issue before going public, with the researcher setting the timeline.
• Coordinated disclosure means both parties - you and the researcher - agree on the disclosure timeline and content. The CRA requires this mutual coordination.

In practice, this means you must actively engage with researchers, not simply receive their reports and act unilaterally. If a researcher sets a 90-day deadline for public disclosure, you need to either fix the vulnerability, provide a workaround, or negotiate an extension - not ignore the deadline.

Article 13(18)–(20) sets out manufacturers' obligations to cooperate with market surveillance authorities (MSAs) and to communicate security information to users.

MSA cooperation: Manufacturers must cooperate with national MSAs when requested to do so, including by providing technical documentation, product samples, access to test instances, and information about the manufacturer's supply chain. Where an MSA issues a corrective action order, manufacturers must comply within the timeframe specified.

• Publishing security advisories in accessible language for the product's intended audience
• Notifying users of available security updates through the update mechanism or other appropriate channels
• Providing clear information about the product's support period end date and what it means for users

Single point of contact: Manufacturers must designate a single point of contact to enable users and researchers to communicate directly and rapidly with them about security issues. This contact point must be easily identifiable from the product documentation or website. A generic customer support email is not sufficient if it does not route to staff with the authority and competence to handle security reports.

Article 13 establishes a role for the European Union Agency for Cybersecurity (ENISA) and national Computer Security Incident Response Teams (CSIRTs) in the vulnerability disclosure process.

Manufacturers may voluntarily notify their national CSIRT of vulnerabilities discovered in their products. In some cases - particularly where vulnerabilities may affect critical infrastructure or large numbers of users - CSIRTs may act as coordinators between manufacturers and researchers.

ENISA also maintains the European Vulnerability Database (EVDB), which manufacturers should use when registering CVEs (Common Vulnerabilities and Exposures) for vulnerabilities in their products.

When you publish a security advisory under Article 13, the CRA recommends (and market practice is moving toward requiring) that you publish it in CSAF 2.0 format (Common Security Advisory Framework).

CSAF is a machine-readable JSON format that enables automated vulnerability management tools to ingest your advisories. Publishing CSAF advisories alongside human-readable advisories is increasingly expected by enterprise customers and conformity assessment bodies.

CVD Portal can automatically generate CSAF 2.0 advisories from your vulnerability tracking data.

If your organisation already follows ISO/IEC 29147 (Vulnerability Disclosure) and ISO/IEC 30111 (Vulnerability Handling Processes), you are well-positioned for the CVD provisions of Article 13 compliance. The CRA's CVD requirements largely align with these international standards.

• The CRA adds statutory timelines (48-hour acknowledgment) that ISO 29147 only recommends.
• The CRA ties non-compliance to market access - non-compliant products can be withdrawn from the EU market.
• The CRA introduces ENISA reporting for severe vulnerabilities (see Article 14).
• The CRA goes beyond ISO 29147 by also requiring security-by-design, SBOM, update obligations, and post-market monitoring — obligations that have no equivalent in the ISO CVD standards.

Following ISO 29147 addresses only the CVD provisions of Article 13. Manufacturers need to address the full scope of Art 13 obligations separately.