CRA Smart Metering: Gateway in Annex IV

Last updated: 2026-10-09

When your meter becomes a critical component

The energy sector is digitising generation, distribution and metering: smart meter gateways in a growing number of households, connected charge point controllers, 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 the CRA intervenes 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 - shapes CRA implementation in this sector. 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 product's core function (Article 7(1), Article 8(1)), not the marketing name; a built-in partial function alone does not raise a device's classification. For the energy sector the picture is schematically as follows - the actual classification must always be checked case by case:

Product	Likely band	Rationale	Conformity path
Smart meter gateway (SMGW)	Annex IV - critical	Expressly listed as a critical product (Annex IV No. 2)	a European scheme where a delegated act requires one, otherwise Module B+C, Module H or a European scheme of at least “substantial”
Secure element / smartcard as a product in its own right	Annex IV - critical (for the element's manufacturer)	Secure elements are listed in Annex IV No. 3; built into the meter, the element does not raise the meter's classification (Article 7(1), second sentence)	as above, for the element's manufacturer
Grid RTU / telecontrol	Default, class I or II depending on core function	Class I or II only if routing (class I) or firewall/IDS (class II) is the device's core function; a built-in filtering function alone is not enough	Class II: Module B+C, Module H or a European scheme of at least “substantial”. Class I: Module A only with full application of harmonised standards, common specifications or a European cybersecurity certification scheme (at least “substantial”), otherwise Module B+C or H
Charge point controller	Likely default	Class I only if an Annex III category is the core function, such as issuing digital certificates (No. 9); managing certificates is not enough	Module A or class I path
PV/battery inverter with cloud connection	Default	Networked, but without an Annex III core function	Self-assessment (Module A)
Energy management gateway / submetering concentrator	Default, class I where routing is the core function	Class I (No. 12) only if routing is the core function; a built-in filtering function alone is not enough	Module A or class I path

Matrix with the schematic classification of typical products in energy and smart metering into the bands default (not in Annex III/IV), class I and class II (Annex III) and critical (Annex IV). PV/battery inverter with cloud connection: default; Charge point controller: default; Energy management gateway, submetering concentrator: default or class I (depending on core function or scope); Grid RTU, telecontrol: default (depending on core function or scope) or class I (depending on core function or scope) or class II (depending on core function or scope); Smart meter gateway: critical; Secure element, smartcard as a product of its own: critical. Assessment routes: default self-assessment (module A), module B+C, H or an EU scheme also possible; class I module A only if harmonised standards, common specifications or a European cybersecurity certification scheme (assurance level at least substantial) are fully applied, otherwise modules B+C or H; class II modules B+C, module H or a European cybersecurity certification scheme at assurance level at least substantial; critical a European cybersecurity certification scheme where required by delegated act, otherwise as class II. What counts is the core function (Art. 7(1)); integrating a component with an Annex III core functionality does not in itself trigger the class I or II procedures (Art. 7(1), second sentence); schematic orientation, not a classification of an individual case. — Typical products in energy and smart metering and their schematic classification; sources: Art. 7, Art. 8, Art. 32, Annexes III and IV of Regulation (EU) 2024/2847.

The technical descriptions of the important and critical categories are specified by Implementing Regulation (EU) 2025/2392. The practical core: wherever a notified body has to be involved (class II, Annex IV, class I without fully applied standards), time-to-market lengthens. Plan the notified body 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. Manufacturers of electronic products or electrical equipment can themselves fall under NIS2 from medium size upwards (Annex II point 5); supplier requirements from your customers come on top. The RED Delegated Regulation 2022/30 applies to certain radio equipment, in particular equipment that can communicate over the internet (such as radio-enabled meters or inverters with a cellular module), and overlaps with the CRA until it is repealed with effect from 11 Dec 2027; until then, clarify which requirements are covered by what. If an AI system is built in (e.g. anomaly detection in the grid), the AI Act applies in addition, with duties depending on the risk level. 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), possibly 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 software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)), as part of the technical documentation. The Regulation does not prescribe a specific format; the Commission may specify format and elements by implementing act (Article 13(24)). The German BSI guideline TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. 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 has to be coordinated with the certification procedure. 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 your early-warning system: it shows which field devices are affected by a new CVE and is the prerequisite for manageable vulnerability handling over 15 years.

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

Since 11 September 2026 the reporting duty under Article 14 has applied. It requires a reliable PSIRT/CVD process with a staged cascade - and the deadlines are easily shortened incorrectly:

24 hours - early warning: without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability or a severe incident.
72 hours - notification: without undue delay and in any event within 72 hours of becoming aware, with the general information available and the corrective or mitigating measures taken.
Final report - here the CRA distinguishes two cases: for an actively exploited vulnerability, within 14 days of a corrective or mitigating measure becoming available; for a severe 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 via the single reporting platform (Article 16), through the endpoint of the CSIRT designated as coordinator in the Member State of your main establishment, simultaneously accessible to ENISA - a single submission. The internal process must be set up and rehearsed regardless. 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. Since 11 September 2026 the reporting duties under Art. 14 have applied, 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 already be in place now. In parallel runs the longer construction site of product conformity - especially for Annex IV products whose assessment involves a notified body. Plan the notified body early.

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 - as long as no delegated act requires a European scheme, the class II procedures apply (Module B+C, Module H or a European scheme of at least “substantial”), so a notified body must be planned in. 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 (early warning without undue delay and within 24 h at the latest, notification within 72 h at the latest, final report after 14 days or 1 month) and coordinated 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 at least ten years after placing on the market or for the longer support period (Article 13(13)). Its timeline: reporting process live since September 2026, conformity assessment with the notified body scheduled early.

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: a technical assessment of which of your products are PDE, which are likely to fall under Annex III/IV and where the RED additionally applies, for review by your legal department.
SBOM setup: building a machine-readable SBOM, for example in CycloneDX or SPDX, straight from your build pipeline, coordinated with the people responsible for your certifications.
PSIRT and CVD: building the reporting and vulnerability-handling process including the correct Art. 14 cascade and connection to the single reporting platform.
Risk assessment and threat modeling: the documentation-obligatory risk analysis under Art. 13 and Annex I, methodically grounded.
Technical documentation: building the documentation under Annex VII up to the EU declaration of conformity, including preparation of the conformity assessment with 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.

Frequently asked questions

Why is the smart meter gateway critical?+

The SMGW is listed in Annex IV of the CRA as a critical product (No. 2) - the highest tier. If a delegated act requires a European certification scheme, that scheme must be used; otherwise the class II procedures apply: Module B+C, Module H or a European scheme of at least “substantial” (Article 8(1), Article 32(3) and (4)). The reason is the gateway's anchor role for the security of the entire metering ecosystem. The actual classification must be checked case by case; this is not legal advice.

Does the existing BSI TR-03109 certification replace CRA conformity?+

No. TR-03109 and the CRA are separate requirement worlds. An existing BSI certification provides a considerable head start on security substance and can be built upon, but the CRA adds its own elements: CE marking, EU declaration of conformity, a machine-readable SBOM in the technical documentation and a CVD policy. Both worlds should be aligned so that security updates and re-certification interlock.

Which SBOM format makes sense in metering?+

The CRA requires a software bill of materials in a commonly used machine-readable format covering at least the top-level dependencies (Annex I Part II(1)); it does not prescribe a specific format, and the Commission may specify one by implementing act (Article 13(24)). BSI TR-03183-2 (v2.1.0) recommends CycloneDX 1.6 or later or SPDX 3.0.1 or later; it is a national recommendation, not a CRA obligation. The SBOM is part of the technical documentation and must be available to market surveillance; there is no general publication duty. For firmware with a long life cycle, an SBOM generated continuously from the build pipeline is recommended.

What exactly are the reporting deadlines under Art. 14?+

Staged: early warning without undue delay and within 24 hours at the latest, notification with the general information available and the measures taken without undue delay and within 72 hours at the latest, then the final report. Important is the two-case rule for the final report: for an actively exploited vulnerability within 14 days of a corrective or mitigating measure becoming available, for a severe incident within 1 month of the 72-hour notification. Reporting goes through the single reporting platform to the CSIRT designated as coordinator, simultaneously accessible to ENISA.

What should an energy device manufacturer tackle first - 2026 or 2027?+

Reporting capability first. Since 11 September 2026 the Art. 14 reporting duty has applied. PSIRT, CVD policy and the cascade process must therefore already be in place, regardless of the product's conformity status. Full applicability of all product requirements follows on 11 December 2027. Especially for Annex IV products whose assessment involves a notified body (unless a European scheme is used), the conformity assessment should nonetheless be scheduled early.

Does a radio-enabled meter fall under the CRA or the RED?+

Possibly under both, with a need for demarcation. The RED Delegated Regulation 2022/30 addresses cybersecurity aspects of certain radio equipment, in particular equipment that can communicate over the internet, the CRA product cybersecurity in general. Reg. 2022/30 is repealed with effect from 11 Dec 2027; from then on the CRA covers these requirements. Where requirements overlap, it must be clarified which duty is covered by what, to avoid duplicate work. A case-by-case assessment is advisable; this is not legal advice.

Sources

This content provides general technical and organizational information on the Cyber Resilience Act (Regulation (EU) 2024/2847) and does not constitute legal advice (no legal services within the meaning of the German RDG).