September 2026 EU Compliance Deadlines for Connected Product Manufacturers

At a Glance

• Two EU deadlines arrive in September 2026: CRA Article 14 vulnerability and incident reporting applies from 11 September 2026; Data Act Article 3(1) access-by-design obligations apply from 12 September 2026 to connected products and related services placed on the market from that date.
• Scope is product-specific: Connected products may fall within both regimes, but medical devices, motor-vehicle products, and other sector-regulated products need separate scope analysis.
• Sectors particularly affected: Manufacturing, technology, health care (medical devices), financial services (smart terminals), and agritech. US-headquartered companies with EU-market activity should pay close attention: both regulations can apply without an EU establishment.

Table of Contents

1. Vulnerability and Incident Reporting under the Cyber Resilience Act

2. Data Act Article 3(1) — Data Accessibility by Design

3. Where These Obligations Overlap

4. What Should You Do Now?

1. Vulnerability and Incident Reporting under the Cyber Resilience Act

   The Cyber Resilience Act (Regulation (EU) 2024/2847) (CRA) was adopted as part of the EU's broader effort to address rising cybersecurity threats across digital supply chains. Before the CRA, the EU lacked an all-sector mandatory cybersecurity framework for hardware and software products, although manufacturers could self-certify or follow voluntary schemes with limited market-surveillance consequences. The CRA replaces that patchwork with binding requirements covering the entire product lifecycle, from design through end-of-support. These obligations are much broader and more comprehensive than US laws and require distinct processes and procedures to be implemented for products in the EU market. The Article 14 reporting requirements are the first of those obligations to take effect, giving manufacturers an early compliance milestone ahead of the full regime in December 2027.

   What Is Required?

   The CRA requires manufacturers of "products with digital elements" (hardware and software) placed on the EU market to report two categories of cybersecurity events:

   • Actively exploited vulnerabilities: where there is reliable evidence that a malicious actor has exploited a vulnerability in the product.
   • Severe incidents: incidents that negatively affect, or are capable of negatively affecting, a product's ability to protect the availability, authenticity, integrity, or confidentiality of sensitive or important data or functions. A severe incident also includes an event that has led, or could lead, to the introduction or execution of malicious code in the product or in a user's network and information system.

   Scope — Broader Than You Might Think

   • Article 14 applies from 11 September 2026 to all in-scope products with digital elements made available on the EU market, which is not limited solely to new products. Article 14 is separate from the broader CRA obligations, which generally apply from 11 December 2027.
   • Article 14 reporting is distinct from the CRA's support-period vulnerability-handling obligations (which require manufacturers to identify and document vulnerabilities, provide security updates free of charge, and publicly disclose fixed vulnerabilities throughout the product's defined support period) and should be assessed for products that remain in use, including after the stated support period ends.
   • There is no general small and medium-sized enterprise (SME) exemption from Article 14. For other Article 14 breaches, Article 64 permits administrative fines up to EUR 15 million or 2.5% of total worldwide annual turnover, whichever is higher, subject to national enforcement rules. Article 64 does not apply administrative fines to micro and small enterprises for missing the 24-hour early-warning deadline. These are penalty limitations, not exemptions from reporting.
   • Only new active exploitation first identified or confirmed on or after 11 September 2026 is reportable. This will include in some cases previously known underlying vulnerabilities that are only exploited after this date.

   Reporting

   Article 14 uses a staged sequence that begins when the manufacturer becomes aware of the event, with European Commission guidance framing awareness as the point at which an initial assessment gives the manufacturer a reasonable degree of certainty that the product is being actively exploited or that a severe incident has occurred. Detection, a report lacking reliable support, or a known but unexploited vulnerability do not necessarily start the clock, but should be carefully assessed and documented:

   • Within 24 hours: Submit an initial alert to the Computer Security Incident Response Team (CSIRT) designated as coordinator. The coordinating CSIRT is identified by the manufacturer's main establishment in the EU, which the CRA defines as the Member State where decisions related to the cybersecurity of its products are predominantly taken. If that Member State cannot be determined, or if the manufacturer has no EU establishment, the CRA provides fallback rules for identifying the relevant CSIRT. This is a much more aggressive timetable than most US businesses will have in place and may require EU-specific detection and escalation procedures.
   • Within 72 hours: Provide a fuller notification, including the available technical description, an initial assessment of the event, and the products or markets affected.
   • Final report: For an actively exploited vulnerability, provide a final report no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, a final report must be submitted within one month after the 72-hour incident notification.

   Where to report: Manufacturers must submit Article 14 notifications through the European Union Agency for Cybersecurity's (ENISA) Single Reporting Platform (SRP) which integrates national and ENISA notification systems.

   User notification: Manufacturers must inform impacted users and, where appropriate, all users of the vulnerability or incident and any corrective or mitigating measures that users can take. If the appropriate user notification is not made in a timely manner, the relevant CSIRT may inform affected users, where proportionate and necessary.

   NIS2 coordination: Companies subject to NIS2 should coordinate their CRA reporting with existing NIS2 incident reporting processes to avoid duplication. For more information on NIS2 obligations, see our earlier article "NIS2 Implementation: Key Steps for Compliance Professionals".

2. Data Act Article 3(1) — Data Accessibility by Design

   The Data Act responds to a longstanding imbalance in the connected-product economy: manufacturers and service providers have typically controlled the data that users and their devices generate, limiting users' ability to access, port, or share that data with third-party providers. The Data Act aims to unlock the economic value of IoT-generated data while giving users (both consumers and businesses) greater control over information produced by products they own or lease.

   What Is Required?

   Article 3(1) requires manufacturers and providers of related services to design products and services so that product data and related-service data, including necessary metadata, are by default easily and securely accessible, free of charge, in a format that is comprehensive, structured, commonly used, and machine-readable, with direct access where relevant and technically feasible. This design obligation applies to connected products and related services placed on the EU market after 12 September 2026. For a summary of other Data Act obligations already in force, see our previous alerts: "The EU Data Act: Impact on Connected Products and Device Manufacturers" and "The EU Data Act — Data Switching Rights for EU Customers".

   What Is a "Connected Product"?

   The Data Act defines a connected product as "an item that obtains, generates or collects data concerning its use or environment and that is able to communicate product data via an electronic communications service, physical connection or on-device access, and whose primary function is not the storing, processing or transmission of data on behalf of any party other than the user" (Article 2(5)).

   Examples include:

   • IoT devices, smart home appliances, and wearables
   • Connected vehicles
   • Medical devices (for example, connected monitors or implants, where the Data Act applies).
   • Agricultural machinery (GPS-enabled tractors, smart harvesters)
   • Industrial equipment and smart manufacturing tools

   Key Nuances

   • Direct versus indirect access: Article 3(1) does not require every product architecture to provide the user with an unrestricted on-device feed. Where direct access is not relevant or technically feasible, the data holder must still provide access to readily available data through alternative means, provided it is of the same quality as that available to the data holder and is provided in a structured, commonly used format (Article 4(1)). In a vehicle context, the access method may involve an onboard interface, a remote backend, or another controlled channel, subject to the Data Act's quality and accessibility requirements.
   • Pre-contractual disclosure: Articles 3(2)–3(3) require sellers and lessors of connected products, and providers of related services, to disclose clear information to users before contracting, such as data type, format volume, storage arrangements, and access methods.
   • Micro and small enterprise carve-out: The Article 3(1) design obligation does not apply to products manufactured by microenterprises or small enterprises (subject to conditions and exclusions).
   • Extraterritorial scope: The Data Act can apply to non-EU manufacturers, related-service providers, data holders, and recipients, when the EU-market conditions are met. Where required, a non-EU entity that makes connected products available or offers services in the EU must designate a Data Act legal representative to act as an authority contact. Member states set Data Act penalties, which must be effective, proportionate, and dissuasive.

3. Where These Obligations Overlap

   Manufacturers of connected products with digital elements may face both sets of obligations simultaneously. A coordinated review can address CRA security-by-design and reporting alongside Data Act access-by-design, while testing whether security, privacy, trade-secret, and sectoral constraints affect the chosen architecture.

   Where both regimes apply, key points of overlap include:

   • Product architecture: The CRA requires secure products and robust cybersecurity reporting processes; the Data Act requires redesign of products for data accessibility.
   • Extraterritorial effect: Both regulations can reach non-EU businesses when their EU-market triggers are met.
   • Governance and escalation: Both require clear ownership, documented processes, and evidence that issues are identified and handled promptly. Coordinate these controls with GDPR, NIS2, DORA, sector rules, and contracts.

   For US-Based Companies

   A US headquarters does not avoid these rules: making a product or related service available in the EU can trigger the CRA or Data Act even without an EU subsidiary. Neither framework has a direct US equivalent combining product-cybersecurity duties with user data-access rights. The CRA's 24-hour reporting clock is especially aggressive, so EU requirements should be built into global product development, security, data-architecture, and release processes from the outset.

4. What Should You Do Now?

   CRA Reporting Readiness

   • Map in-scope products: Identify new and existing products with digital elements, related services, and the relevant transition timelines.
   • Establish coordinated detection and escalation processes: Implement monitoring, triage, and 24-hour escalation routes for vulnerabilities and severe incidents. Align CRA reporting with NIS2, GDPR, DORA, sector-specific rules, coordinated vulnerability disclosure, insurance, and customer-notification workflows.
   • Prepare SRP reporting: Designate an Assigned Representative, complete EU login, and identify the relevant coordinating CSIRT.

   Data Act Design Compliance

   • Assess product and service scope: Determine whether your products and services qualify as "connected products" or "related services" under the Data Act.
   • Map data flows: Record product and related-service data, metadata, personal and nonpersonal data, where they are stored, who is the data holder, and who can access or receive them.
   • Implement access routes: For products placed on the market from 12 September 2026, build access by design; separately prepare Article 4(1) request-based access where direct access is not relevant or technically feasible.
   • Update documents and contracts: Refresh pre-contractual disclosures, contracts, terms of service, and pre-contractual information to reflect user access rights, data categories, access methods, quality of service, and relevant trade-secret safeguards.

   For Both

   • Confirm representative requirements separately: Assess CRA authorised-representative arrangements for non-EU manufacturers and Data Act legal representative requirements for non-EU entities in scope under the Data Act, noting that the role and trigger for each requirement differs.