EU Cyber Resilience Act (CRA): What Manufacturers and Product Owners Need to Do Now

We’ve been talking to a lot of manufacturers and product owners about the EU Cyber Resilience Act over the past few months, and the same questions keep coming up: are we already behind, what category does our product fall into, and does the work we do for the EU compliance support compliance in other regions? This article works through those three questions.

If you haven’t started CRA work yet, you’re not too late. But the gap between “we’ll get to it” and “we’re ready” is narrower than most product teams assume, and the first real deadline isn’t the one most people are watching.

The CRA entered into force on 10 December 2024. Most manufacturers treat 2027 as the deadline that matters. It isn’t the first one. Two earlier dates apply before then, and missing them creates problems that are harder to fix retroactively.

Classification: where most manufacturers get it wrong

The CRA splits products into three tiers. Which one you land in changes your compliance path, cost and timeline, so this is worth getting right before anything else.

Default (Low Risk) covers roughly 90% of in-scope products: standard software applications, consumer electronics, and lower-risk IoT devices. Self-assessment is permitted. Connected sensors, wearables, general embedded controllers, and most consumer and industrial IoT devices without a dedicated security function sit here.

Important (Class I and Class II) covers products with specific functions that pose higher cybersecurity risks due to their core functions, connectivity, or administrative capabilities.

• Class I (Annex III, Part I) includes identity management and privileged access management software and hardware, standalone and embedded web browsers, password managers, anti-malware software, VPN products, and network management systems. Self-assessment should be possible if the product fully complies with the harmonised standard – otherwise, conformity assessment via a notified body would be required.
• Class II (Annex III, Part II) covers higher-risk functions: hypervisors, firewalls, industrial intrusion detection systems, and tamper-resistant microprocessors. Third-party assessment via a notified body is always mandatory, regardless of whether harmonised standards are applied.

Critical (Annex IV) is the highest tier: products that the EU’s critical infrastructure may depend on, such as hardware security modules, smart meter gateways and smartcards. Third-party, notified body assessment is mandatory.

Where it gets grey: classification turns on core function, not every embedded component. Classification is not purely a feature checklist; it turns on design intent and core functionality, while still requiring a defensible, product-level security assessment that accounts for integrated components as appropriate. The standard example: a smartphone that integrates a password manager is still in the Default category because its core function isn’t password management.

This cuts both ways across product categories. An industrial sensor, a piece of manufacturing equipment, or a connected router is typically Default. But the moment any of them incorporates VPN functionality, identity management, or a hypervisor layer as a core, marketed feature rather than an incidental one, it can move into Important.

Consumer broadband routers are generally Default class products subject to self-assessment. However, routers marketed with advanced security or management functions need closer scrutiny, and the same logic applies to a smart camera with built-in access control, an edge gateway running network management software, or an industrial controller with embedded firewall capability. It’s exactly the sort of call that looks straightforward until your specific product is the one being assessed.

Implications of getting classification wrong

Misclassification surfaces at the worst time, and the two failure directions cost you differently.

Classify too low (treat an Important or Critical product as Default) and you self-certify a product that legally requires a notified body involvement. If a market surveillance authority disagrees after the product is shipping, it can require corrective action within a deadline it sets, and if you fail to act within that deadline, it can itself prohibit, restrict, withdraw, or recall the product.

Manufacturers must keep records of non-conformities, vulnerabilities, and incidents for 10 years after the product is placed on the market, so these don’t quietly age out. And formal paperwork compliance is not a shield if the product still presents a significant cybersecurity risk: a correct-looking technical file won’t help if the underlying classification was wrong.

Classify too high, and you commit to engaging the notified body, third-party assessment, and the associated lead times and fees for a product that didn’t need them. Given the backlog risk before September 2026, that’s time and budget spent on assurance you didn’t legally require.

Either way, the downstream exposure is the same regime: fines of up to €15 million or 2.5% of global annual turnover, whichever is higher, for the most serious infringements, alongside product withdrawal, recalls, and bans on market availability, which, for many manufacturers, cause more damage than the fine itself. For a product already in the field, a recall is a logistical and reputational cost that lands on commercial teams as much as on engineering teams.

Classification deserves an early, documented assessment, not a quick internal call you’ll have to defend later. It dictates the level of security scrutiny, conformity assessment, and post-market surveillance your products will face. Get a second opinion before you commit to a roadmap for either path.

Regional applicability: CRA as your baseline, not an EU-only cost

CRA-aligned engineering isn’t EU-only spend.

Setting your product baseline to CRA aligns well with UK PSTI. PSTI overlaps with CRA in banning default passwords, mandating vulnerability disclosure contacts, and setting minimum update periods, though CRA goes further in scope and requires CE marking.

The direction is convergence. Australia’s approach is closely aligned with the UK’s PSTI regime, and the US is developing similar requirements through the National Cybersecurity Strategy and the Cyber Trust Mark programme. The underlying engineering work, secure-by-design, SBOM discipline, coordinated vulnerability disclosure, and support-period transparency are largely the same regardless of which market you’re shipping into.

One caveat to mention: compliance in one jurisdiction doesn’t automatically guarantee compliance in another, even where regimes look structurally similar. CRA gets you most of the way to PSTI and a head start on Cyber Trust Mark, but each still has jurisdiction-specific marking and reporting mechanics.

For a manufacturer launching across the UK, EU, and US in the same product generation, the practical approach is to engineer to the more stringent standard (usually EU CRA) once and treat regional variations as a documentation layer on top rather than as a parallel engineering effort.

Where this gets difficult in practice

None of this is conceptually hard. What can make EU CRA compliance expensive is timing and judgment: getting classification right before committing to a conformity route and having reporting infrastructure live before September rather than after an incident exposes the gap.

Most teams know this in principle. Fewer teams have blocked out the time to act on it.