CRA in energy & smart metering

When your meter becomes a critical component

The energy sector is digitising generation, distribution and metering at a pace that was unthinkable a few years ago: smart meter gateways in millions of households, charge point controllers on every corner, telecontrol units in substations, inverters with permanent cloud connections. Each of these devices is a "product with digital elements" (PDE) — and therefore potentially within the scope of the Cyber Resilience Act (Regulation (EU) 2024/2847). For manufacturers and importers in this sector this is not an academic matter but an intervention right in the middle of already regulation-dense product development.

The real pain of this industry is the overlap of regimes. In Germany a smart meter gateway (SMGW) already undergoes BSI certification against a protection profile and TR-03109 — a demanding, change-averse procedure. Now the CRA sits alongside it, with its own CE marking, its own technical documentation, its own vulnerability reporting duty. At the same time energy providers as operators are regulated under NIS2 and pass security requirements down to their suppliers. Anyone building devices here juggles several requirement worlds that overlap but are not identical.

Add to this the reality of long life cycles: a meter or grid component stays in the field for 10, 15 or 20 years. The CRA demands vulnerability handling across the entire support period — for products whose firmware can barely be touched for certification reasons. This very tension — high-assurance certification meets CRA update expectations — makes the sector one of the most demanding CRA cases of all. This article is a technical overview, not legal advice.

Typical products and their likely Annex III/IV classification

The CRA splits products into three bands: default (self-assessment, Module A), "important" products under Annex III (class I and II) and "critical" products under Annex IV. Classification follows the security function, not the marketing name. For the energy sector the picture is schematically as follows — the actual classification must always be checked case by case:

The technical descriptions of the important and critical categories are specified by Implementing Regulation (EU) 2025/2392. The practical core: once a notified body is mandatory (class II, Annex IV), time-to-market lengthens considerably — capacity planning for conformity assessment should start early.

Sector standards and demarcation from adjacent regimes

The CRA formulates security objectives, not detailed norms — you provide the evidence via established standards. For the energy sector these are in particular:

• IEC 62443 — the reference framework for industrial automation and control systems (processes and product security).
• BSI TR-03109 — the German regime for smart meter gateways including protection profile and technical guideline.
• IEC 62351 — security for energy communication protocols (e.g. IEC 61850, DNP3).

The CRA case builds on this substance — anyone already certified to TR-03109 and developing to IEC 62443 has a considerable head start, but must add the CRA-specific elements (CE, EU declaration of conformity, SBOM in the technical documentation, CVD policy).

Important is the demarcation from neighbouring regimes: NIS2 addresses the operation of essential/important entities (energy providers) — not the products themselves; as a manufacturer you are affected indirectly through supplier requirements. The RED Delegated Regulation 2022/30 applies to radio equipment (such as radio-enabled meters or inverters with a cellular module) and overlaps with the CRA — here it must be clarified which requirements are covered by what. If AI comes into play (e.g. anomaly detection in the grid), the AI Act may become relevant in future. CRA, NIS2, RED and the AI Act are separate legal acts and must not be equated.

SBOM and supply-chain reality in metering

The typical software stack of an energy device is deeply layered: an embedded Linux or RTOS, a cryptographic library (OpenSSL, mbedTLS), a TLS stack, protocol implementations (COSEM/DLMS, IEC 61850, OCPP for charge points), often a communication module with its own firmware blob. This is exactly where the supply-chain risks lurk: end-of-life components whose upstream no longer ships patches, and open-source libraries with known CVEs "frozen" into change-averse, certified firmware.

The CRA requires a machine-readable SBOM as part of the technical documentation — at least at the level of top-level dependencies. Concretely accepted are the formats CycloneDX from version 1.6 or SPDX from version 3.0.1 (BSI TR-03183-2, v2.1.0). There is no general publication duty — the SBOM must be available to market surveillance, not published openly.

The metering specificity: every SBOM update and every security patch must remain compatible with the certification status. An OpenSSL update that is a finger exercise elsewhere can trigger a re-assessment here. A continuously maintained SBOM integrated into the CI/CD pipeline is therefore not bureaucratic self-purpose but the early-warning system that tells you which of the millions of field devices are affected by a new CVE — the prerequisite for manageable vulnerability handling over 15 years.

Reporting capability and PSIRT: the Art. 14 cascade done correctly

From 11 September 2026 the reporting duty under Article 14 applies. It requires a robust PSIRT/CVD process with a staged cascade — and the deadlines are frequently shortened incorrectly:

• 24 hours — early warning from becoming aware of an actively exploited vulnerability or a severe security incident.
• 72 hours — full notification including initial corrective and mitigating measures.
• Final report — here the CRA distinguishes two cases: for an actively exploited vulnerability, within 14 days of a corrective measure becoming available; for a severe security incident, within 1 month of the 72-hour notification.

The blanket shortening to "24 h / 72 h / 14 days" is factually wrong — the one-month case for severe incidents must not be lost. Reporting goes through the ENISA Single Reporting Platform (SRP) as a single notification to the competent CSIRT and ENISA. The platform is to be provided by 11 September 2026; in mid-2026 it is not yet fully operational — the process should nonetheless be set up and rehearsed now. For energy devices in the field this means: defined escalation paths between firmware team, certification owners and reporting point, so the 24-hour clock does not run out in internal responsibility disputes.

Which deadline counts first: 11 Sep 2026 vs. 11 Dec 2027

Two dates structure the preparation. 11 September 2026 brings the reporting duties under Art. 14 — the first hard manufacturer obligation, regardless of whether your product is already fully CRA-compliant. 11 December 2027 brings full applicability of all product requirements: security-by-design, SBOM, technical documentation, CE marking, conformity assessment.

In practice this means: reporting capability first. PSIRT, CVD policy and the cascade process must be in place in 2026. In parallel runs the longer construction site of product conformity — especially for Annex IV products with a mandatory notified body whose assessment capacity is likely to become scarce. Anyone starting the conformity assessment only in 2027 risks not getting a slot.

Worked scenario: an SMGW manufacturer

A mid-sized manufacturer produces a smart meter gateway, already BSI-certified to TR-03109, in the field with several metering point operators. The CRA hits it in several places at once. The SMGW is to be classified as an Annex IV product — a notified body must be planned in, and a future EU certification scheme should be kept in view, which would need to be harmonised with the existing BSI regime.

Operationally it builds three things: first, a machine-readable SBOM (CycloneDX 1.6) from the build process, mapping the full stack from embedded Linux via the crypto library to the DLMS/COSEM layer and feeding into the technical documentation. Second, a PSIRT/CVD process serving the Art. 14 cascade (24 h / 72 h / 14 days or 1 month) and compatible with the certification regime — including a rule for when a security update triggers a re-certification. Third, the technical documentation and EU declaration of conformity, which it must retain for 10 years. Its timeline: reporting process live by September 2026, conformity assessment with the notified body scheduled as early as possible so that December 2027 does not become the bottleneck.

What Blackfort Technology does for you

Blackfort Technology supports manufacturers and importers in the energy and metering sector along the entire CRA path — pragmatically and tailored to the peculiarities of certified, long-lived products:

• Scope and applicability analysis: which of your products are PDE, which are likely to fall under Annex III/IV, where do RED or NIS2 additionally apply?
• SBOM setup: building a machine-readable SBOM (CycloneDX ≥ 1.6 / SPDX ≥ 3.0.1) directly from your build pipeline, compatible with your certification status.
• PSIRT and CVD: building the reporting and vulnerability-handling process including the correct Art. 14 cascade and ENISA SRP connection.
• Risk assessment and threat modeling: the documentation-obligatory risk analysis under Art. 13 and Annex I, methodically grounded.
• Technical documentation: structure and content for conformity assessment and market surveillance — including preparation for the notified body.

A good first step is our applicability check. For an overview of deadlines and duties see Cyber Resilience Act, and for smaller manufacturers the SME page. Talk to us directly via contact.