Since 11 September 2026, every manufacturer with connected products on the European Union (EU) market has been working against a 24-hour vulnerability reporting clock, and the full weight of the Cyber Resilience Act (CRA) arrives on 11 December 2027. The regulation assigns legal responsibility to whoever places a product on the EU market under their own name. For most outsourced IoT hardware, that is the original equipment manufacturer (OEM), not the factory that built it.

The OEM carries the liability, but much of the evidence that proves compliance is generated on the build partner's production floor.

What Is the Cyber Resilience Act (CRA)?

The Cyber Resilience Act is Regulation (EU) 2024/2847, the first EU-wide horizontal law to set mandatory cybersecurity requirements for hardware and software sold as "products with digital elements". Its scope turns on connectivity rather than product category. Any product whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network falls inside it, from IoT sensors and telematics units to human-machine interface (HMI) panels and the firmware that runs them.

What the CRA does in practice is tie cybersecurity to market access. CRA conformity becomes a condition of CE marking, so from December 2027 a connected product without a conformity route cannot be placed on the EU market at all.

Who Needs to Comply with the Cyber Resilience Act?

The CRA assigns obligations by economic role: manufacturer, importer, distributor, and authorised representative. The manufacturer role carries the heaviest load, and it applies wherever the company is established. An OEM headquartered in Asia or North America that sells into the EU holds the same duties as one based in Munich.

The OEM as Manufacturer

Article 3 defines a manufacturer as anyone who develops or manufactures a product with digital elements, or has it designed, developed, or manufactured, and markets it under its own name or trademark. The second half of that definition settles most cases. Telematics manufacturers and HMI manufacturers that outsource production still hold every manufacturer obligation, because the brand on the label, not the factory address, decides who answers to the regulator.

The same logic reaches further down the chain. An importer or distributor that rebrands a product, or makes a substantial modification to it, takes on manufacturer obligations of its own.

Where the Contract Manufacturer Stands

A contract manufacturing partner that builds to the OEM's design and ships under the OEM's brand does not become the CRA manufacturer, and it assumes none of that liability. 

That does not put it outside the compliance picture. The partner controls the physical and process evidence the OEM's technical file depends on, from which component lot went into which serial number to whether secure boot was enabled before a unit left the line. 

The manufacturing relationship is therefore part of the compliance system, not a supplier arrangement sitting beside it.

Product Classification Under the CRA

Classification is decided by what a product is for, not by what it contains. A telematics unit with a cellular modem and a secure element stays in the default category if its core function is fleet data, while a smart lock built on a similar microcontroller moves up because security is its purpose. Where a function fits more than one class, the stricter class applies, and that class decides who may assess conformity: the manufacturer alone, the manufacturer against a harmonised standard, or a notified body.

Default Category (Minimal Risk)

The default category covers the majority of connected products. Manufacturers self-assess these under internal control (Module A), documenting conformity without a third party. Most telematics units and industrial HMIs sit here, unless their core function matches an Annex III or Annex IV listing.

Important Category (Class I and Class II)

Annex III Class I products, such as routers, smart home security products like door locks and cameras, and microcontrollers with security-related functions, must apply harmonised standards or go through third-party assessment. Class II products, such as firewalls and tamper-resistant microcontrollers, need a notified body. Smart home builds land in Class I more often than OEMs expect, because a security function at the centre of the product's purpose is enough to move it out of the default category.

Critical Category (Elevated Risk)

Annex IV critical products, namely hardware devices with security boxes, smart meter gateways, and smartcards or secure elements, may require European cybersecurity certification. Selecting a secure element for the bill of materials is therefore a component decision with regulatory weight: that part's supplier carries its own CRA obligations, and its conformity becomes part of the OEM's due diligence.

Timelines to Look Out For

Most OEMs read the CRA as a 2027 problem, yet its reporting duty already covers products in the field today. The Annex I design requirements apply only to products placed on the market from December 2027, so a programme in development now will launch into the full regime, while products already shipping carry the reporting duty without having been designed for it.

Enforcement Dates

The reporting obligation reaches back across the current portfolio. It applies to every in-scope product on the EU market, including units shipped before the CRA took effect, so legacy products are already running on the 24-hour clock.

• 10 December 2024: entry into force.
• 11 June 2026: provisions on conformity assessment bodies apply.
• 11 September 2026: Article 14 reporting obligations apply to all in-scope products on the EU market.
• 11 December 2027: full application, with Annex I requirements and CE marking mandatory for products placed on the market.

Operational Timelines

Placing a product on the market starts the OEM's obligations rather than ending them. The support period sets how long security updates must keep flowing, and that in turn decides how long firmware build environments, signing keys, and component records have to stay usable, often years after the last unit leaves the production line.

• Five years: the minimum security support period, unless the product's expected use is shorter.
• 24 hours: the window from awareness of an actively exploited vulnerability or severe incident to the first early warning.
• Ten years: the retention period for technical documentation and the EU declaration of conformity, or the full support period if that runs longer.

Reporting Windows

Reports go through the single reporting platform run by the European Union Agency for Cybersecurity (ENISA) to the coordinating national Computer Security Incident Response Team (CSIRT), in three stages:

1. Early warning: within 24 hours of awareness.
2. Notification: within 72 hours, including the corrective or mitigating measures taken.
3. Final report: within 14 days of a corrective measure being available for a vulnerability, or within one month for a severe incident.

Those windows are a hardware problem as much as a process one. An OEM can only report within 24 hours what it can scope, and scoping depends on knowing which components and firmware versions sit in each shipped unit. Without serial-level records, the first report becomes an estimate.

How the CRA Changes the Landscape

The CRA is a horizontal regulation. It covers the cybersecurity of connected products across their whole lifecycle, and it sits across sector regimes rather than replacing them: a ruggedised telematics unit for a mine site can answer to the CRA, the EU radio equipment rules, and ATEX certification for explosive atmospheres at the same time.

The regulation also sets outcomes rather than prescribing technologies. It does not mandate a particular secure boot scheme or cryptographic library; it requires that a product ships without known exploitable vulnerabilities, is secure by default, and can receive security updates. That leaves the engineering choices with the OEM and places the burden of proof on the technical file. 

In effect, the CRA draws three red lines:

• OEMs cannot claim ignorance: due diligence on third-party components and ongoing vulnerability monitoring are obligations, so an unknown flaw in a sourced module is still the OEM's flaw.
• OEMs cannot contract away responsibility: outsourced manufacturing moves production, not liability, and a supply agreement can allocate cooperation and cost but never the regulatory duty.
• OEMs cannot wait for suppliers before acting: the reporting clock starts at the OEM's awareness, and mitigation is owed to users even while an upstream fix is pending.

What the Build Partner Controls: Evidence Only the Factory Can Provide

Annex VII sets out the technical documentation the manufacturer must hold, and it asks for manufacturing information as well as design information. A substantial share of that material is created on the production line rather than in the OEM's engineering office. An Electronics Manufacturing Services (EMS) provider generates four categories of evidence that no design team can reconstruct after the fact:

• Component traceability: lot and date codes, approved vendor lists, authorised sourcing channels, and substitution records that tie every unit to known silicon.
• Build records: serial-level as-built configuration, including the bootloader and firmware image flashed and any secure provisioning or key injection records.
• Test data: functional and programming verification results, confirmation that debug interfaces are locked and secure boot is enabled before shipment, and results carried through from design verification.
• Change control: records of component obsolescence, product change notices, and approved alternates, since a substituted part can change a product's security posture.

Serial-to-lot traceability is what turns a vulnerability disclosure into a bounded problem. When a flaw in a specific microcontroller revision is actively exploited, the OEM needs to know within hours which serial numbers carry that revision, which firmware build they run, and where they shipped. 

A partner that holds those links lets the OEM answer inside the 24-hour window; one that records builds only at batch level leaves the OEM reporting against its entire installed base.

What OEMs Should Start Doing Now to Be Compliant

CRA compliance works as a programme that runs alongside product development, not a certification step added at the end. Six actions belong on the roadmap now:

1. Classify the portfolio: map every product with digital elements, including legacy products still on sale, to its CRA category.
2. Stand up reporting: assign owners, secure platform access, and rehearse the 24-hour escalation path before a live incident tests it.
3. Set support periods: define and document them per product, with the engineering rationale behind each.
4. Build the component inventory: generate software bills of materials (SBOMs) in a machine-readable format and link them to the hardware bill of materials.
5. Write evidence into manufacturing agreements: specify traceability depth, record formats, ten-year retention, and notification of component changes.
6. Involve the build partner early: select a trusted EMS partner and bring it into design reviews while security decisions are still cheap to change.

How PCI Supports CRA Compliance Across the Product Lifecycle

PCI Ltd is an EMS specialist with over 50 years of experience, and its lifecycle processes generate the evidence OEMs need for their technical documentation. The OEM remains the manufacturer of record; PCI's role is to make sure the factory side of the technical file exists, is complete, and holds up for the full retention period:

• Hardware and firmware design: electronic hardware design and verification that builds debug lockdown, secure boot, and secure element integration from the first revision.
• Supply chain management: controlled sourcing through authorised channels, with component-level traceability on every build.
• Manufacturing records: serial-level build and firmware programming records, captured in an Industry 4.0 environment driven by enterprise resource planning (ERP) systems.
• Testing and certification: failure mode and effects analysis (FMEA), production part approval process (PPAP), ongoing reliability testing (ORT), and full traceability, backed by ISO 9001, IATF 16949, ISO 13485, and ISO/IEC 27001 certification.

Conclusion: Compliance Evidence Starts on the Factory Floor

The CRA makes the OEM accountable for evidence it cannot generate alone. Traceability, build records, and test data are produced where the product is built, so the build partner must be chosen and briefed with that evidence in mind from the first design review. If an HMI, telematics, or IoT programme is heading for the EU market before December 2027, contact us about building traceability and test evidence into it from the start.