The EU Cyber Resilience Act: An Overview for IoT OEMs

Why CRA changes the landscape

Until now, the EU regulatory landscape covered cybersecurity in fragments:

• GDPR governs personal data processing.
• NIS2 governs critical and important entities.
• RED and EN 18031 apply to radio equipment.
• Sector-specific rules apply to medical, automotive, aviation, and marine industries.
  

What was missing was a horizontal regulation covering the cybersecurity of connected products throughout their lifecycle. CRA changes that.

It applies broadly to “products with digital elements” placed on the EU market, including consumer IoT, industrial devices, enterprise software, and cloud-connected systems. Exemptions exist, but they are relatively narrow. For most IoT OEMs, CRA becomes the primary cybersecurity regulation governing the product itself.

CRA focuses on outcomes, not specific technologies

CRA does not prescribe exact technologies such as AES-256, TLS 1.3, or specific hardware architectures, because one regulation must apply simultaneously to consumer devices, industrial systems, enterprise software, and cloud-connected products.

Instead, CRA defines security outcomes. The detailed technical mechanisms are expected to be implemented through harmonized standards such as EN 18031, ETSI standards, and IEC standards. In practice:

• CRA defines what must be achieved.
• Harmonized standards increasingly define how.

The three parts of CRA OEMs must understand

CRA’s enforceable obligations are concentrated in three areas.

Annex I — Essential cybersecurity requirements

Defines what the product itself must provide:

• secure-by-default configuration
• vulnerability handling
• update capability
• access protection
• attack surface reduction
• integrity protection
  

Articles 13 and 14 — Manufacturer obligations

Define what the OEM must continuously operate across the product lifecycle, including:

• security updates
• vulnerability handling
• incident reporting
• coordinated disclosure
  

Annex VII — Technical documentation

Defines:

• what records must be maintained
• how long they must remain retrievable
• what market surveillance authorities may request

CRA entered into force in 2024 — but enforcement happens in stages

CRA officially entered into force on 10 December 2024, but the operational obligations activate over time.

Two enforcement dates matter operationally

These two dates are not redundant. September 2026 activates the reporting clock, including:

• 24-hour early warning
• 72-hour structured notification
• final remediation reporting
  

December 2027 becomes the market-access threshold: products newly placed on the EU market must fully satisfy CRA requirements. From December 2027 onward, both timelines operate simultaneously.

The three timelines OEMs must operate against

Beyond the enforcement dates, CRA introduces three long-term operational timelines.

Five years — security support obligation

CRA Article 13(8) establishes a minimum support period:

• at least five years
• or the expected product lifetime if shorter
  

For most IoT products, this effectively means five years of security support.

24 hours — vulnerability reporting

CRA Article 14 requires reporting within:

• 24 hours for early warning
• 72 hours for structured reporting
• 14 days after remediation becomes available
  

Importantly, the clock starts when the OEM becomes aware — or reasonably should have become aware.

Ten years — documentation retention

Annex VII requires technical documentation to remain retrievable for ten years after the product was last placed on the EU market. This is frequently underestimated. A product sold until 2032 may still require retrievable records in 2042.

CRA’s reporting clock is stricter than many OEMs expect

The 24-hour reporting requirement is the most operationally disruptive part of CRA for many organizations. Under CRA Article 14, once an actively exploited vulnerability becomes known:

“Becoming aware” is one of the most important phrases in CRA

CRA does not define awareness narrowly. Regulators are widely expected to interpret “becoming aware” to include what an OEM reasonably should have known.

That means:

• not monitoring NVD
• ignoring vendor advisories
• lacking vulnerability intake capability
  

may not be considered valid excuses. For engineering teams, this changes the question from:

“Did we see the alert?”

to:

“Should we reasonably have seen the alert?”

Vulnerability monitoring therefore becomes:

• an operational capability
• a compliance requirement
• a legal exposure boundary

CRA places responsibility on the CE-mark holder

CRA assigns responsibility to the manufacturer holding the CE marking.

Not:

• the silicon vendor
• the OTA provider
• the cloud platform
• the contract manufacturer
  

That responsibility cannot be contractually delegated. Supplier agreements may redistribute commercial risk, but they do not transfer regulatory accountability. This also applies regardless of geography. A manufacturer shipping from Shenzhen into the EU carries the same CRA exposure as a manufacturer based in Munich.

The fine is only part of the risk

CRA’s penalty structure closely mirrors GDPR.

But for many OEMs, the larger risk is operational rather than financial. CRA grants market surveillance authorities powers to:

• restrict sales
• order corrective action
• require product withdrawal
• initiate recalls
• revoke CE marking
  

In practice, recall logistics, channel disruption, recertification, and downstream contractual impact can exceed the fine itself.

Three red lines CRA effectively creates

Regardless of supplier agreements:

1. OEMs cannot claim ignorance

“Becoming aware” includes what the OEM reasonably should have known.

2. OEMs cannot contract away responsibility

Commercial agreements do not transfer regulatory liability.

3. OEMs cannot wait for suppliers before acting

The OEM’s reporting timeline runs independently from supplier timelines.

CRA is becoming the global reference point for product cybersecurity regulation

CRA is not just an EU issue. It increasingly represents the direction global product cybersecurity regulation is moving toward.

Comparable frameworks now exist across:

• the UK
• the United States
• Japan
• Singapore
• Australia
  

Each differs in scope and enforcement strength, but the overall direction is converging toward:

• lifecycle responsibility
• vulnerability disclosure
• secure update capability
• supply-chain visibility
• product accountability
  

Why CRA stands out globally

Among existing product-security frameworks, CRA is unusual in three ways.

1. Broad horizontal scope

CRA applies across consumer IoT, industrial systems, enterprise software, and connected infrastructure. Most comparable regimes focus on only one segment.

2. Mandatory lifecycle obligations

CRA legally requires:

• vulnerability handling
• coordinated disclosure
• security update capability
• minimum support periods
  

Many comparable standards remain voluntary or sector-specific.

3. Time-bound reporting obligations

CRA introduces hard reporting timelines:

• 24 hours
• 72 hours
• final remediation reporting
  

Few comparable frameworks impose similar legally binding clocks.

CRA is not asking OEMs to do entirely new security work

In many cases, CRA is formalizing security practices mature organizations already operate:

• vulnerability management
• update delivery
• incident response
• lifecycle documentation
• supply-chain governance
  

What changes is that these capabilities become:

• auditable
• enforceable
• time-bound
• legally accountable
  

The OEMs preparing now are preparing for more than Europe

Teams aligning to CRA today are not only preparing for EU compliance. They are preparing for the broader direction of global product cybersecurity regulation over the next decade.

The organizations that establish:

• lifecycle visibility
• vulnerability governance
• update traceability
• supply-chain accountability
  

before September 2026 will likely become the OEMs regulators, customers, and procurement organizations trust first.

This overview reflects Snowball’s interpretation of CRA text and EC/ENISA guidance through April 2026. It is not legal advice.