Obligations of Manufacturers

Article 13(1) requires manufacturers to design, develop, and produce products with digital elements in accordance with the essential cybersecurity requirements in Annex I Part I of Regulation (EU) 2024/2847. This is an active design-phase obligation.

Article 13(2) mandates a cybersecurity risk assessment before placing a product on the market. Manufacturers must apply the outcome of this assessment across planning, design, development, production, delivery, and maintenance.

Under Article 13(3), manufacturers must document the risk assessment and update it during the support period. The assessment must indicate which essential cybersecurity requirements in Annex I Part I point (2) apply to the product. Article 13(4) requires manufacturers to include the risk assessment in the technical documentation required pursuant to Article 31 and Annex VII.

• Default secure configuration. Products must ship in a secure default state with no universal default passwords and minimal attack surface.
• Access control. Authentication and access control mechanisms must match the risk level of the product and its data.
• Confidentiality and integrity. Products must protect stored and transmitted data against unauthorised access or corruption.
• Minimal data collection. Products must process only data necessary for their intended functions.
• Resilience against attacks. Products must withstand and recover from common exploitation techniques and denial of service attempts.

Manufacturers must demonstrate that the risk assessment informed the design process. Completing a risk assessment after finalising product design violates Article 13.

Article 13(5) requires manufacturers to exercise due diligence when integrating components sourced from third parties. The duty to identify and document software components in an SBOM arises under Annex I Part II point (1) of Regulation (EU) 2024/2847.

Article 13(24) allows the European Commission to adopt implementing acts specifying the format and elements of the SBOM. Under Article 13(25), market surveillance authorities may request SBOMs when ADCO conducts Union-wide dependency assessments. Manufacturers must maintain the SBOM within the technical documentation rather than publishing it openly.

• Screening components against vulnerability databases before integration.
• Monitoring integrated components continuously for new vulnerabilities after market placement.
• Verifying that component maintenance aligns with the product support commitment.

If a manufacturer discovers a vulnerability in an integrated component, Article 13(6) requires reporting it upstream to the component maintainer. See the dedicated upstream reporting section below for detailed guidance on this duty.

Manufacturers remain fully responsible for the security of the complete product. Sourcing components from third parties does not transfer any Article 13 compliance duties.

Article 13(9) requires manufacturers to ensure that each security update remains available for at least 10 years after issue, or for the remainder of the support period, whichever is longer. Under Annex I Part II point (2), manufacturers must remediate vulnerabilities without delay through security updates and provide security updates separately from functionality updates where technically feasible. This allows users to install critical security fixes without accepting unwanted functional changes.

Annex I Part II point (8) requires manufacturers to disseminate available security updates without delay and free of charge, accompanied by advisory messages providing users with relevant information.

Under Annex I Part I point (2)(c), products that support automatic updates should enable this mechanism by default, while allowing users to opt out. When automatic updates are not feasible, manufacturers must provide a clear way for users to check and apply updates manually.

Article 13(10) provides relief for iteratively developed software. Manufacturers may address vulnerabilities only in the version last placed on the market, provided earlier users can upgrade free of charge without extra costs. Article 13(11) permits manufacturers to maintain public software archives if they clearly inform users of the associated risks.

Support periods are determined under Article 13(8) and must be at least five years unless the product expected lifetime is shorter. See the dedicated support period section below for complete guidance on support period duration and rules.

Article 13(8) requires manufacturers to ensure effective vulnerability handling throughout the product support period in accordance with Annex I Part II of Regulation (EU) 2024/2847. Article 13(7) mandates systematic documentation of all relevant cybersecurity aspects, including any vulnerabilities discovered.

• Internal code vulnerabilities identified through regular security testing, static analysis, and penetration testing.
• Third-party component vulnerabilities identified through CVE feeds, security advisories, and supplier alerts.
• Threat intelligence relevant to the specific product category and deployment environment.

• Evaluating vulnerability severity using standard metrics such as CVSS.
• Developing and testing security patches or workarounds without delay.
• Distributing security updates to impacted users quickly.
• Providing interim mitigation guidance when an immediate patch cannot be deployed.

Article 13(13) requires manufacturers to keep the technical documentation and the EU declaration of conformity available to market surveillance authorities. They must retain these records for at least 10 years after placing the product on the market, or for the support period, whichever is longer. Documentation must cover all identified vulnerabilities and all remediation actions taken.

Article 13(8) requires manufacturers to put in place appropriate policies and procedures, including coordinated vulnerability disclosure policies referred to in Annex I Part II point (5). Under these provisions, manufacturers must take the following actions.

1. Establish a CVD policy. Put in place a publicly accessible, documented process for how security researchers and others can report vulnerabilities in your products.
2. Acknowledge receipt. Confirm to the reporter that the report has arrived. The CRA sets no deadline for this step. The 48-hour target is a self-imposed SLA rather than a statutory deadline.
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.

The 48-hour acknowledgment window is the single most misquoted number in CRA advice, including in material sold by consultants. It is worth being precise about where it comes from.

What the CRA says. Article 13 requires a coordinated vulnerability disclosure policy and requires manufacturers to address and remediate vulnerabilities without delay. It sets no fixed clock for acknowledging a report to its reporter. The regulation's hard reporting deadlines (24 hours, 72 hours, 14 days) live in Article 14 and run to CSIRTs and ENISA, for actively exploited vulnerabilities and severe incidents.

What the 48 hours is. The figure is a self-imposed SLA rather than a statutory deadline. CVD Portal applies 48 hours as its default acknowledgment target and a company can set its own. Market surveillance authorities will read a documented, met SLA as evidence of a functioning process.

Why treat it as binding anyway. A reporter who hears nothing goes public. An unacknowledged report that turns into a zero-day is an Article 14 problem with a paper trail showing you were told first. CVD Portal tracks the 48-hour acknowledgment as an SLA with breach alerts for exactly this reason.

Practical implication: You need a monitored inbox, ticketing system, or dedicated vulnerability disclosure portal so that 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, as defined by RFC 9116.
• 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(8) and Annex I Part II point (5) mandate coordinated vulnerability disclosure rather than 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 and Annex I set out obligations for market surveillance cooperation, user communication, and contact points.

MSA cooperation. Under Article 13(22), manufacturers must cooperate with market surveillance authorities on a reasoned request. Manufacturers must provide all information and documentation necessary to demonstrate product conformity. This includes technical documentation, product samples, access to test instances, and information about the supply chain. Where an authority issues a corrective action order, manufacturers must comply within the specified timeframe.

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

Single point of contact. Under Article 13(17), 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.

Regulation (EU) 2024/2847 defines roles for the European Union Agency for Cybersecurity (ENISA) and national Computer Security Incident Response Teams (CSIRTs) in Articles 15 and 16.

Under Article 15, manufacturers may voluntarily notify their designated CSIRT or ENISA of vulnerabilities discovered in their products. In some cases, such as when vulnerabilities affect critical infrastructure or large numbers of users, CSIRTs may act as coordinators between manufacturers and researchers.

Under Article 16, ENISA maintains the European Vulnerability Database (EUVD) to record and coordinate publicly disclosed vulnerabilities.

When you publicly disclose fixed vulnerabilities under Annex I Part II point (4), market practice favours machine-readable advisories in CSAF 2.0 format (Common Security Advisory Framework).

CSAF 2.0 is a machine-readable JSON format, standardised by OASIS, 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 that ISO 29147 has no equivalent for, in Article 14: a 24-hour early warning, a 72-hour notification, and a final report. The 48-hour acknowledgment is the other way round, a self-imposed SLA with no CRA deadline behind it.
• 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.

Article 13(8) sets the support period by reference to the time the product is expected to be in use, judged against reasonable user expectations, the nature of the product including its intended purpose, and relevant Union law determining product lifetimes. It must be at least five years unless the product is expected to be in use for less.

Commission guidance C(2026) 5252 point 126 corrects a common misreading. The five-year minimum operates only as a safeguard, and recital 60 means products reasonably expected to be in use for longer than five years should have correspondingly longer support periods. Five years is not the default for all products.

Each substantially modified version placed on the market needs its own declared support period complying with Article 13(8). Article 13(10) provides relief for iterative software, allowing a manufacturer to address and remediate vulnerabilities only for the version last placed on the market where users of earlier versions can upgrade free of charge without additional costs. The guidance reads additional costs narrowly. Personnel time, routine testing, configuration adjustments and dependency upgrades are ordinary and do not count. Mandatory new hardware, infrastructure replacement or fundamental changes to the operating environment do.

Article 13(6) requires manufacturers to report vulnerabilities in integrated components to whoever manufactures or maintains that component, and to share any software modification they develop to fix such a vulnerability.

Commission guidance C(2026) 5252 narrows this usefully. You report only in respect of the version of the component you integrate. Where the maintainer has a security policy, a coordinated vulnerability disclosure process or a designated reporting channel, use it. You are not required to report where you can confirm the maintainer already knows, and manufacturers are encouraged to check public vulnerability databases, project advisories and issue trackers first to avoid duplicate reports burdening open-source maintainers. No report is owed where the component no longer has a maintainer, or where you no longer rely on that maintainer for new versions or fixes, although informing users through community mechanisms or public vulnerability records is encouraged.

Only vulnerabilities in the component itself are reportable upstream, rather than defects arising from how you integrated it. Where integration reveals behaviour that was not apparent in isolation, sharing that is encouraged. Security fixes should be shared in a machine-readable, verifiable form, under a licence compatible with the component. Neither side is obliged to accept the other's proposed fix.