Why US manufacturers need to care
The Cyber Resilience Act is an EU product regulation. If a product with digital elements is made available on the Union market, the relevant manufacturer and other economic operators need to determine which CRA obligations apply. Direct EU sales are not the only route: distributors, importers and OEM / white-label structures can all matter.
Two dates matter now
11 September 2026 — Article 14 reporting
Manufacturers are required to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements. The process includes an early warning within 24 hours and a notification within 72 hours through the CRA Single Reporting Platform.
11 December 2027 — main CRA application
The broader product cybersecurity, conformity, technical-documentation and vulnerability-handling requirements become applicable. Waiting until late 2027 is risky because the evidence base — risk assessment, SBOM, vulnerability process, support commitments and traceability — is built inside product engineering, not at the end of a documentation sprint.
The product-level questions
1. Is the product in scope?
The CRA generally covers products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network, subject to specific exclusions and special regimes.
2. Who is the manufacturer?
Own-name and own-trademark placement is important, as are design/manufacturing arrangements. White-label structures deserve separate review: a distributor or importer that places a product on the market under its own name or trademark can assume manufacturer obligations for CRA purposes.
3. What is the classification?
The core functionality of the product matters. The integration of an important component does not automatically make the whole product important. Conversely, where the product itself has the core functionality of an Annex III category — for example relevant routing, VPN or network-management functionality — an Important Class I or II path may need to be assessed.
4. Is Article 14 operational?
A general incident-response process is not automatically the same as a CRA reporting process. The organisation needs an owner, reportability criteria, escalation, clocks, submission capability and a practical workflow.
5. Does the technical evidence exist?
Typical readiness evidence includes a product-specific cybersecurity risk assessment, machine-readable SBOM, vulnerability-handling process, security-update capability, support-period rationale, security requirements and traceability into the product and its verification evidence.
Why Important Class I matters
For Important Class I products, the conformity route can change. Internal control (Module A) remains available only under the CRA conditions for applying relevant harmonised standards, common specifications or qualifying European cybersecurity certification schemes. Where those conditions are not met, a third-party conformity-assessment path is required for the relevant requirements.
What a useful readiness project should produce
A useful CRA project should not end with “you need an SBOM” or “you might be Class I.” It should leave the product team with documented scope and classification reasoning, a traceable evidence-gap picture, the operational reporting gaps, the support-period decision, and a prioritized remediation path.