Cyber Resilience Act

Last Updated on 2025-10-27

If you build or buy meters, DCUs, routers, or gateways for European utilities, the EU’s Cyber Resilience Act (CRA) just turned “security-by-design” from a slogan into a legal requirement. The regulation entered into force in December 2024; early reporting duties start on 11 September 2026, and full obligations apply from 11 December 2027. After that date, non-compliant products with digital elements can’t be placed on the EU market. Open Source Security FoundationPillsbury Law

This post translates the CRA into practical implications for AMI/SCADA buyers and for manufacturers like us who supply cellular DCUs, industrial routers, battery loggers, and load-control boxes. It also explains why we invested years ago in ENCS-grade security—and why that decision made CRA alignment much easier.

(The 450MHz Alliance organization has posted a news on its website about our new secure router – according ENCS examination of the strict security requirements.)

The CRA in one page: scope, timeline, and why utilities care

Scope. The CRA covers products with digital elements—that’s hardware + software and their remote data processing—sold in the EU, regardless of where they’re made. That includes cellular modems/routers in metering cabinets, DCUs at transformer stations, and edge gateways in water or gas networks. The regulation introduces baseline cybersecurity requirements across design, development, manufacturing, and maintenance, and it binds importers and distributors too. Digital StrategyVenable

• In force: 10–11 December 2024 (Official Journal publication and entry into force).
• Reporting starts: 11 September 2026 (first set of vulnerability/incident reporting obligations).
• Full application: 11 December 2027 (core obligations and market access controls). Open Source Security FoundationOpen Regulatory Compliance Working Group
  

Why utilities care. CRA shifts risk left. Instead of relying only on NIS2-style organizational controls at the DSO, the device itself must be secure by design, supported throughout its lifecycle, and monitored for vulnerabilities with mandatory reporting to ENISA and national CSIRTs on strict deadlines. For critical infrastructure—arguably the most targeted sector in Europe—this changes procurement checklists and vendor accountability. European Commission

What the CRA actually requires (practical view for AMI/IIoT)

1) Security-by-design and state of the art

Manufacturers must design, develop, and produce products to reduce attack surface, ship with secure default configurations, and avoid known exploitable vulnerabilities. Documentation must prove how risks were mitigated. Expect stronger evidence requests in tenders: secure boot chains, signed firmware, RBAC, encrypted management, protected debug ports, and hardening guides. Digital Strategy

2) Vulnerability handling & incident reporting

You need a formal vulnerability handling process (triage, fixes, dissemination). And when something serious happens, you must notify via ENISA’s single reporting platform: an early warning within 24 hours, a detailed notification within 72 hours, and follow-ups thereafter. The trigger isn’t “any bug,” but actively exploited vulnerabilities and severe incidents affecting product security. This is a major operational lift for any OEM shipping firmware. Pillsbury LawEuropean Cyber Resilience ActGlobalnorm

3) SBOMs and technical documentation

CRA makes SBOMs (software bill of materials) part of the technical file: at least top-level dependencies in a machine-readable format (e.g., SPDX, CycloneDX), kept up to date across the lifecycle and available to market-surveillance authorities. If you don’t already generate SBOMs during CI/CD, you’ll need tooling and policy—fast. QtAnchore

4) Support period and updates

Manufacturers must provide security support aligned to the expected product lifetime, with a floor of five years unless the product is expected to be used for a shorter period. Practically, you’ll have to declare the support period, maintain update channels, and keep released security updates available long after shipment. For long-lived industrial gear, this drives component choices, BSP updateability, and LTS kernel strategy. ConsiliumOrrick

5) Conformity assessment & CE marking

Depending on product classification and use of harmonized standards, you’ll either self-assess or involve a notified body. Either way, you’ll need a technical file proving compliance (threat modeling, secure development practices, SBOM, test evidence, VDP/PSIRT process, and update policy) to back your CE marking. Pillsbury Law

Bottom line: CRA turns what used to be “good practice” checkboxes into market access conditions. From 11 Dec 2027, no CE = no sale if you haven’t met the CRA’s security and lifecycle obligations. Pillsbury Law

How CRA interacts with other rules you already juggle

• Radio Equipment Directive (RED) cybersecurity: For radio/wireless gear (like LTE routers, cellular DCUs), the RED Delegated Act “3(3)(d)(e)(f)” imposes cybersecurity essentials from 1 August 2025—two years ahead of CRA’s full application. Design choices you make for RED (credential protection, network resilience, data & privacy safeguards) dovetail with CRA evidence. Treat 2025 as your “pre-CRApractice run.” BSISGSCorp
  
• NIS2: Focuses on organizational risk management at operators (e.g., DSOs), while CRA targets the product. Procurement teams will increasingly require device-level proofs to satisfy their own NIS2 duties. European Commission
  

What this means specifically for smart metering and utility IoT

For DSOs and water/gas utilities (buyers):

• Expect tenders to require SBOM delivery on request, documented PSIRT/VDP, and declared support periods aligned with meter/router lifetimes.
• Demand secure boot, signed updates, encrypted management, and audit logs as standard in routers/DCUs.
• Validate that vendors can meet 24/72-hour reporting obligations without disrupting operations. (Ask to see the playbook, not just a slide.) Pillsbury Law
  

For OEMs and integrators (sellers):

• Build a PSIRT and a VDP that actually runs—ticketing, SLAs, embargo handling, and coordinated disclosure.
• Bake SBOM generation into CI/CD; maintain dependency policies and CVE monitoring; automate delta SBOMs per release.
• Plan for long-term updateability: partitioned firmware, A/B updates, signed images, rollbacks, and offline packages for locked-down sites.
• Prepare a CRA technical file template now; your notified body (or your customer) will ask for it in 2026–27. Qt
  

Why our ENCS journey mattered (and what we changed in our routers)

Years before the CRA vote, we committed to meeting ENCS (European Network for Cyber Security) procurement and security requirements because we work with some of the most demanding—and most targeted—utilities in Europe. ENCS publishes smart meter and data concentrator security requirements and related test plans used widely by DSOs; conforming to them often forces deep architectural decisions rather than cosmetic patches. ENCS+1E.DSO

We’re proud that our secure industrial router was analyzed and approved by ENCS, and that milestone didn’t come cheap: we redesigned our Industrial 2 routers essentially from scratch to meet those requirements. That redesign touched the secure boot chain, key storage & rotation, firmware signing, hard-separation of management/data planes, and role-based access with audit logging—the same building blocks the CRA now expects as evidence of secure-by-design practice. m2mserver.com

Concretely, ENCS-driven changes that now pay dividends for CRA readiness:

• Supply-chain transparency: We already maintain component manifests and dependency policies; turning these into CRA-compliant SBOMs was an incremental step, not a green-field project. Qt
  
• Update strategy: Our routers support signed, atomic A/B firmware updates with rollback, making long-term support workable even on remote, latency-prone links (vital for the CRA’s multi-year support mandate). Consilium
  
• Vulnerability handling: Our VDP and PSIRT runbook—originally built to satisfy ENCS buyers—map cleanly onto CRA’s 24/72-hour reporting We aligned triage severities with CRA definitions of “actively exploited vulnerabilities” and “severe incidents.” Pillsbury LawGlobalnorm
  

In short: ENCS made us do the hard work early. CRA formalizes it.

A quick buyer’s checklist (use in RFPs and FAT/SAT)

• Vendor lifecycle commitment
  • Declared support period (≥ 5 years or expected lifetime) and EoL/EoS policy; evidence of LTS kernel/BSP plans. Consilium
• Secure development & documentation
  • Threat model, hardening guide, pen-test/functional test summaries, and technical file structure aligned to CRA annexes. Pillsbury Law
    
• SBOM & supply-chain transparency
  • SPDX/CycloneDX SBOM with top-level dependencies at minimum; policy for delta updates and vulnerability monitoring. Qt
    
• Update mechanism
  • Signed firmware, rollback, staged/atomic updates; offline package options for air-gapped substations. (Maps to both CRA and RED.) BSI
    
• PSIRT/VDP & reporting
  • Documented 24/72-hour incident/vulnerability reporting workflow; evidence of previous coordinated disclosures (redacted). Pillsbury Law
    

What to do between now and December 2027

• If you’re a utility/DSO: bake CRA-style requirements into procurement now, not in 2027. Ask for support-period declarations, SBOM on request, and proof of secure update mechanisms. If you run pilots in 2025–26, align them with RED cybersecurity so you don’t have to retest later. BSI
  
• If you’re a device OEM/integrator: stand up or tune your PSIRT, finalize VDP language, and exercise your reporting playbook with tabletop drills. Wire SBOM tooling into CI/CD and start producing release-qualified SBOMs now so you can baseline technical debt ahead of 2026–27. Qt
  

Where we can help

Because we already aligned to ENCS security requirements and redesigned our Industrial 2 routers accordingly, our portfolio ships with the controls and evidence trails CRA demands: secure boot with signed firmware, RBAC + audit logs, hardened remote access, OTA with rollback, and documented SBOM/VDP/PSIRT processes. For rollouts and retrofits, we provide:

• A CRA readiness pack (sample SBOMs, update policy, hardening checklist, and a PSIRT/VDP summary).
• A migration audit for legacy 2G/3G estates and mixed PLC/cellular backhaul, aligning RED 2025 and CRA 2027 requirements so you don’t redo work. SGSCorp
  

References & further reading

• European Commission policy page for the CRA (overview and objectives). Digital Strategy
  
• OpenSSF summary of CRA dates and applicability. Open Source Security Foundation
  
• Law-firm explainer on full application from 11 Dec 2027 and market access. Pillsbury Law
  
• Reporting timelines (24/72 hours) and ENISA/CSIRT platform. Pillsbury Law
  
• CRA SBOM requirement (top-level dependencies; machine-readable). Qt
  
• ENCS security requirements and our ENCS approval ENCSm2mserver.com