EU Cyber Resilience Act (CRA): what companies should know and prepare now

The EU Cyber Resilience Act (CRA) is one of the largest shifts in European product-security thinking: for many goods with digital components, cybersecurity becomes a precondition for market access and serious supplier management — not a side project for security teams running late-stage penetration tests.

This briefing frames the CRA for decision-makers: scope, lifecycle logic, interaction with the EU Cybersecurity Act / ENISA certification, and policy and technical signals from early 2026. Not legal advice; confirm classification and duties with qualified counsel and, where relevant, notified bodies.

Scope: products with digital elements

The CRA focuses on products with digital elements — software, firmware, networked devices, radio modules, controllers and, broadly, anything that creates a tangible cyber surface via updates, configuration interfaces or connectivity. For sectors with long lifecycles — machinery, tele-remote systems, industrial peripherals, or environments touching operational technology — planning consequences stretch across years of audits and recall scenarios.

The practical consequence is consolidation of responsibility across the value chain: manufacturers, importers and distributors carry defined shares of documentation, transparency vis-a-vis authorities and market surveillance, and — depending on product class — conformity-assessment routes. Organisations that still treat security as a per-project tweak face a maturity gap once evidence becomes standard in supply chains and tenders.

Lifecycle, not launch day

A common mistake is “we will do a security review at release.” The CRA thinks bigger: secure-by-design early, traceable vulnerability and update processes, supplier evidence expectations, and incident handling that is not improvised under pressure. For hardware-led firms that means BOM/SBOM discipline, firmware integrity concepts, realistic support and end-of-life windows, and contractual clauses with component vendors.

Market translation is heavily shaped by harmonised standards and official guidance; while that landscape still evolves, caution with premature marketing claims is wise. Industry analyses in the machinery and remote-control space underline that, without a final normative package, blanket claims of full conformity are often not yet methodically supportable — while preparation and structured evidence are already mandatory because reporting and control duties can bite earlier than the end-state conformity date. See Current state of the EU Cyber Resilience Act — Scanreco.

CE, conformity and what “proof” means in 2026

EU product-harmonisation treats conformity as a documented path — not a feeling. The CRA attaches cybersecurity expectations to how products with digital elements are placed on the EU market and supervised afterwards. Firms should clarify early: which conformity modules apply, which artefacts actors in the chain need, and how market-surveillance authorities will test traceability and evidence.

International suppliers also need clarity: shipping into Europe remains CRA-relevant regardless of corporate seat. That shifts investment in platform architecture, shared building blocks and reusable security artefacts.

EU Cybersecurity Act, ENISA and certification — same ecosystem, different layer

While the CRA sharpens product duties, Regulation (EU) 2019/881 supplies institutional and certification infrastructure: a permanent ENISA mandate, EU cybersecurity schemes for ICT products, services and processes, assurance levels from basic to substantial and high, and national coordination via certification authorities (in Germany, BSI/NCCA). A solid structural overview appears at OpenKRITIS — EU Cybersecurity Act (CSA).

Why read both together: if policy and procurement treat certificates as a shared language between sourcing, audit and regulators, scheme choice and evidence formats become competitive factors. Product teams that interpret CRA only internally, ignoring recognised certification paths, invite duplicated effort — legal and security should feed one supplier and vulnerability data model.

Beyond classic “box” products, European digital identity is a major cross-cutting theme: under the European Digital Identity framework, ENISA is tasked inter alia to support certification of EUDI wallets — the wallet infrastructure intended to bind citizens and businesses to trustworthy identity and privacy-preserving evidence. Independent observatories such as the Geneva Internet Platform’s Digital Watch track consultations on draft schemes and member-state rollout expectations; see Digital Watch — ENISA / EU digital wallet certification. Operationally, high-assurance credentials and wallet ecosystems sit in the same evidence universe as CRA-adjacent product data.

Cybersecurity Act revision — signals from Brussels and industry

Alongside CRA implementation, the EU is revising the Cybersecurity Act. Germany’s Bitkom commented on the Commission package presented on 20 January 2026, welcoming in particular that cybersecurity certificates should more strongly serve as recognised evidence for duties in other EU laws — including a presumption of conformity vis-à-vis NIS2 or CRA requirements, improving legal certainty and reducing duplicate testing. Bitkom also warns that “one incident, one report” only works if reporting duties under NIS2, product rules and GDPR are coherently aligned — otherwise parallel channels persist. It further stresses that existing national arrangements on foreign components in sensitive networks must be respected in any phase-out design so digitalisation targets are not derailed. Source: Bitkom press commentary on the Commission package (January 2026).

For enterprises the dual message is: certificates gain value — but only if governance and incident mechanics across organisation (NIS2), product (CRA) and privacy (GDPR) are not three silos.

Technical depth: schemes, assurance and the CSA2 direction

OpenKRITIS documentation summarises the European certification framework: the Union rolling work programme, scheme development, assurance levels, and roles for national certification authorities and conformity-assessment bodies. For CFO and CTO lines that means budgeting certification runs, renewal cycles and product variants as recurring cost — not a one-off workshop.

Concretely, the EU Common Criteria-based cybersecurity certification scheme (EUCC) already anchors a defined route for ICT products at higher assurance; tracks such as EUCS (cloud) or EU5G remain at different maturity stages. The core lesson: there is no single “ENISA certificate for everything,” but a portfolio of schemes with distinct evaluation methods, validity periods, and permitted or forbidden self-assessment. Teams building CRA-relevant products with CC/EUCC-aligned expectations can lift documentation synergy; teams ignoring that path duplicate testing.

Assurance levels are not marketing labels — they reflect depth of evaluation from documentary review to rigorous testing against capable adversaries. In procurement, ask for scheme, level and module — not a vague “ISO” checkbox.

Political drafts around Cybersecurity Act revision also foreground tougher supply-chain and oversight tools (often debated under headings such as an ICT toolbox and supplier risk). Even if trilogue details move, the direction is clear: critical IT building-block decisions will be more evidence- and register-driven. Architecture substitutability and documented supply relations are cheaper today than emergency transitions tomorrow.

Timeline: what “now” vs “later” means

Regulatory roadmaps are rarely linear: parts of CRA logic apply before the full harmonised-standard package lands. Industry commentary notes that vulnerability and incident disciplines may bite ahead of full conformity finality, and that 2026 is when conformity-assessment structures crystallise. Treat internal boards, approvals and budgets as if the next audit wave arrives from two angles at once — product surveillance and sectoral supervision.

Run linked but separate timelines. On the product side: milestones for architecture decisions, first internal conformity readiness, pilot certifications or internal reviews. On the organisation side: NIS2 risk registers, incident playbooks, handovers to privacy where personal data is affected. Where both worlds hit the same supplier issue — e.g. a remote-update module — use one ticket model, not two lost-in-translation chains.

Functional safety meets cybersecurity

In machine-heavy settings, disciplines collide: functional-safety norms reduce physical harm; cybersecurity reduces the chance that digital weaknesses undermine those safety functions — manipulated commands, compromised radio links or unauthorised parametrisation. The CRA makes that intersection a design theme: controls are not a layer pasted after safety, but part of threat modelling and integration.

Engineering-visible examples: secured boot chains for controllers, separation of engineering and operations accounts, signed firmware, hardened maintenance ports, offline fallbacks, consistent logging for security-relevant events and clear accountability when an OEM component vendor ships updates but the machine builder holds system-level responsibility. Negotiate with suppliers early — late contract fixes make remediation expensive.

International supply chains: third-country OEMs and marketplaces

The CRA is not only for EU manufacturers. Global vendors placing products with digital elements on the EU market face the duty landscape of those markets regardless of headquarters. German integrators and brand owners will often need structured, recurring evidence from overseas OEMs — not one-off “security selfies.” For white-label building blocks, contractually clarify who holds surveillance-facing documentation, how coordinated vulnerability disclosure runs and which escalation paths apply for zero-days.

Professional humility on open points

Credible commentary — trade media, vendors or observatories — repeats one nuance: while central guidance (harmonised standards, assessment programmes, public interpretations) is still stabilising, academic precision matters more than marketing superlatives. That is not permission to stall: invest in evidence, testing, documentation and lightweight red-team habits even if the final label cannot yet sit on the box. Keep outward claims measured — it limits liability and reputation risk.

Pitfalls we see in client work

One: splitting “product owns CE” from “SOC owns security” without shared release rituals — evidence rots before surveillance asks.

Two: global suppliers without contractual vulnerability, update and incident clauses — CRA turns “hopefully cooperative” into structural risk.

Three: OT lifecycle blind spots — devices run decades without a support and spare-part story that matches customer and regulator expectations.

Four: hype vocabulary (“zero trust”, “military grade”) instead of evidence-based testing narratives.

90-day starter checklist

Talent and operating impact

The CRA expands demand for hybrids: product security engineers, secure SDLC leads, compliance engineering, OT security architects and supply-chain security. Talent was already scarce — see our talent-market and active sourcing pieces. Early hiring avoids certification-window crunches.

Translator roles matter: people who connect supplier forensics with internal risk language, turn security requirements into backlog-sized epics and draft regulatory communications with legal. Budget career paths and training (product security, secure SDLC coaching) instead of only late headhunting.

Conclusion

The EU Cyber Resilience Act is more than a new paragraph: it moves digital security responsibility into product and supply-chain reality. In parallel, certification logic and the ENISA mandate under the Cybersecurity Act strengthen the “language of proof.” Early-2026 political signals on Cybersecurity Act revision and the role of certificates vis-à-vis NIS2 and CRA make the lesson plain: siloed evidence, reporting and architecture today means double cost tomorrow.

If your organisation treats the next assessment cycles seriously, external transparency and internal discipline are two sides of the same coin: clear facts for supervisors and customers reduce internal friction — and build trust that survives market pressure.

Further reading: EU Cybersecurity Act — Germany / NCCA, Cyber resilience foundations, NIS2 in Germany, DORA explained. Hiring: Cybersecurity recruitment and IT recruitment.