The CRA Guide to Smart Meter Gateways and Energy Metering

What the CRA Requires for Smart Meter Gateways

The CRA treats a smart meter gateway as one product made of many digital elements. The product can include the meter firmware, the gateway operating system, the communication module, the DLMS/COSEM (the standard metering-data protocol) or proprietary meter-protocol stack, the SIM, eSIM or radio credential, the key store, the head-end connector (the link to the utility's central collection system), the local display, a mobile app, a cloud portal, the update service, the installer tool and the vulnerability-handling process. It normally excludes the utility's billing system, the legal metrology approval, the grid-operation systems and the customer energy contract, unless the same manufacturer supplies those as part of the product.

That boundary is the heart of the file. The evidence has to keep cybersecurity separate from legal metrology, while still documenting the interfaces between the gateway, the meters and the head-end. Metrology approval under the Measuring Instruments Directive and the national metering rules answers a different question from the CRA. One proves the measurement is correct and sealed. The other proves the connected product resists attack across its support period. A maker that blurs the two ends up with a file that satisfies neither reviewer.

The cybersecurity requirements and the technical file that proves them work the same for every CRA product, and the technical-documentation guide covers those. This page sticks to what is specific to a metering gateway: the Critical classification, the conformity route, the gateway architecture, and the metering-specific evidence.

Is Your Device in the Critical Tier?

The Critical label is narrow, and a metering product can sit on either side of it. A device is the Critical gateway when it is the communication unit of the metering system: it controls the link to utilities, processes the meter and personal data, runs the cryptography, and can firewall the system and control other devices. A meter that only measures and reports stays on the standard route, and using strong cryptography to protect an ordinary function does not make a device Critical either. Commission Implementing Regulation (EU) 2025/2392 (the Implementing Regulation), binding since 21 December 2025, sets that test and extends it to gas and heat gateways, not only electricity. Settle the answer once in the boundary memo. The Summary table above maps the common variants to their route.

How the Architecture Differs Across the EU

Germany uses a separate-gateway model with a discrete communication unit, the model the Critical listing was drawn around. France, Spain and Italy do not meter that way. They run integrated meters that measure and communicate in one sealed unit and reach a data concentrator in the secondary substation directly, with no in-home gateway box. The concentrator handles the aggregation and the upstream link, so the CRA evidence still attaches, but to different devices, and the Critical-route question moves with it. The German model gets its own section below.

The shape is the same in all three markets: an integrated meter at the customer, narrowband power-line carrier up the low-voltage line, a concentrator in the distribution substation, then a cellular link to the operator. What changes is the power-line technology, the consumer channel and, in Italy, a second radio interface. In each, the concentrator is the node that aggregates many meters and controls the communication with authorised third parties. The integrated meter is normally a standard-route connected product. Neither call is automatic. The Implementing Regulation turns the category on core functionality, so a meter whose own functions match the gateway description can be argued into the Critical tier, and the maker fixes the split in the boundary memo rather than assuming it.

France: Enedis Linky

The Linky meter does both jobs. It measures consumption and it communicates upstream from a single unit, reaching a concentrator in the HTA/BT (medium- to low-voltage) secondary substation directly rather than through an in-home gateway. The link is narrowband power-line carrier in the CENELEC A band, the low-frequency utility band, predominantly the G3-PLC profile, with a portion of the fleet on the first-generation S-FSK scheme. The concentrator backhauls to the Enedis central system over public cellular, GPRS in the original design. Enedis is the distribution system operator that runs the system, not the meter maker. The consumer interface is optional: the meter exposes a TIC information port that an in-home display can read through a separate radio module, an add-on rather than standard Enedis equipment. The rollout began in 2015 and reached around 35 million meters.

Spain: PRIME and Meters and More

Spain runs the same three-tier shape: an integrated DLMS meter at the premises, a concentrator in the centro de transformación, and a head-end at the DSO. The low-voltage power-line technology splits by operator. Iberdrola (i-DE) and UFD run PRIME, while Endesa (e-distribución) runs Meters and More. The concentrator aggregates the meters, relays commands and supervises the low-voltage grid, and it talks to the head-end over the STG-DC supervisor protocol. It backhauls over a public network link, commonly cellular and often over a VPN. The legal backbone is Orden ITC/3860/2007, which required replacing meters with remote-management units, so Spain reached near-complete coverage early, at around 27 million low-voltage meters.

Italy: e-distribuzione Open Meter

Italy was the first large EU rollout, with the Telegestore first generation from 2001, and is now on the Open Meter second generation, around 30 million meters installed by 2023. ARERA allows Chain 1 to run over power-line band A, a 169 MHz radio interface or other telecom technologies, and the Open Meter carries a double Chain 1 interface combining power-line band A and 169 MHz radio. A separate Chain 2 power-line channel in band C reaches optional consumer User Devices, standardised by the CEI TS 13-82 to 13-85 series and mandated by ARERA resolution 87/2016. The concentrator in the MT/BT (medium- to low-voltage) substation is, in e-distribuzione's own words, the information hub and actuator for network automation, and it backhauls over the public GSM, GPRS, UMTS or PSTN network.

None of this declares the concentrator a Critical product. It is usually the stronger candidate. The determination is device-and-use specific, it turns on the core-functionality description in the Implementing Regulation, and it belongs in the maker's boundary memo. The decision below is the short version of that test.

How a Separate-Gateway System Is Built (the German model)

This is the separate-gateway model, the one with a discrete communication unit as its own box. In the integrated-meter markets described above, France, Spain and Italy, these same evidence boundaries exist, but they collapse into the meter and the grid concentrator rather than a discrete gateway. A smart meter gateway is the central communication unit of an intelligent metering system. The BSI describes it as the central component that receives and stores data from meters and processes it for the market participants entitled to see it. The Federal Network Agency (Bundesnetzagentur) calls it the heart of the system. The gateway sits between three networks, and the trust anchor for all of them is a dedicated security module. Each boundary is where a piece of CRA evidence attaches, so the architecture is worth drawing precisely.

The three networks each carry a different risk and a different control:

• The local metrological network (LMN) connects the gateway to the meters, electricity, gas, water or heat, of one or more final consumers. This is where readings enter the product. The evidence here covers how the gateway authenticates a meter, how it rejects readings from an unauthorised meter, and how the meter-to-gateway link is paired and protected.
• The home-area network (HAN) connects the gateway to controllable local systems such as rooftop solar, combined heat and power, heat pumps and EV charging, to a service technician during maintenance, and to the consumer who is entitled to view their own consumption. The evidence here covers isolation between the consumer view and the device secrets, and the scope of any control commands that reach a local system.
• The wide-area network (WAN) connects the gateway to external market participants, the energy suppliers, grid operators and the metering point operator, and to the gateway administrator. This is the fleet path. The evidence here covers mutual authentication, certificate custody, the pseudonymisation of meter data before it reaches a market participant, and the processing profiles that decide which data goes where.

The security module is the trust anchor. The BSI defines it as the secure storage location for the cryptographic key material, providing the cryptographic core routines for signature creation and verification, key generation, key agreement and random-number generation. If the security module is sound, the gateway can prove who it is on every network. If it is weak, every other control downstream rests on sand. The CRA file should treat the security module as a named component with its own supplier evidence, its own update story and its own boundary in the diagram.

The gateway administrator (GWA) configures, administers and monitors the gateway remotely over the wide-area network. It pushes firmware, sets configuration and processing profiles, and watches the fleet. From a CRA point of view the gateway administrator is a privileged remote-control path, much like the auto-configuration server on a router. The file has to record the administrator's identity, the scope of the commands it can issue, the trust anchor it authenticates against, and the audit trail it leaves.

Several controls then layer on the wire, and each one is a separate piece of evidence in the file.

National scheme, separate track. Germany already runs a detailed national regime for this device under the Metering Point Operation Act, built on a stack of BSI standards:

• TR-03109-1: interoperability requirements for the communication unit, in the wider TR-03109 family. Now at version 2.0.
• TR-03109-4: the Smart Metering public-key infrastructure.
• BSI-CC-PP-0073: Common Criteria protection profile for the gateway. V2.0 certified December 2024.
• BSI-CC-PP-0077: Common Criteria protection profile for the security module.

The earlier PP-0073 v1.3 and TR-03109-1 v1.1 baselines stay valid through 31 December 2027.

The CRA does not adopt TR-03109. Its route runs through its own harmonised standards developed under the Commission standardisation request. The point of mentioning the German scheme is honest framing: regulators already demand this depth of security architecture from the very device the CRA now lists as Critical, so the bar a gateway maker has to clear is not theoretical. Germany is not the only pre-2027 bar either. A radio-equipped meter already owes the RED cybersecurity requirements today, in every market, as the overlap with RED, MID, GDPR and NIS2 sets out below.

How the Conformity Route Works for a Critical Product

Because a gateway is Critical, the self-declaration route an Important Class I router can use is closed. It takes the external route under Article 32: a third-party examination or a full quality-assurance audit, or a European cybersecurity certification scheme once one applies under Article 8. No scheme has been made mandatory for gateways yet, so today the route is the third-party or quality-system assessment, with the scheme as a future trigger to track. The mechanics of each procedure are in the conformity-assessment guide. The metering-specific catch is the metrology boundary: a CRA assessment does not sign off the legally relevant measurement function, so keep the conformity evidence and the metrology approval as separate records.

What Evidence the Technical File Should Contain

The file should let a reviewer follow the gateway from product identity to security controls without guessing. The table below lists the file-specific records that the requirements table above did not already cover: identity, the Critical determination, the conformity output and the component inventory. The two records that carry most of the weight for a metering gateway, the key and certificate lifecycle and the split between metrology-relevant and cybersecurity-only changes, are drawn in full below it.

Release gate: no batch secret, installer credential or retired gateway binding should remain able to authenticate as a live meter gateway after rotation or replacement. The stale-trust window is a product and operator commitment, not a universal constant. Artifact: revocation-drill result.

The security module makes the key lifecycle different from a generic IoT key story. A per-device secret is injected at the factory and never leaves the module in the clear. At installation, the installer binds the gateway to its meters and to the operator role without ever handling a batch key, so a leaked installer credential cannot impersonate a fleet. In operation, the gateway authenticates to the head-end with the configured trust anchor and records every reading, tamper event and update. Rotation is scheduled, incident-driven or triggered by a role change, and it updates both the gateway and the operator's record. At retirement, the old binding is revoked and the keys are destroyed or disabled, so a returned or swapped gateway cannot continue to act as a live meter gateway.

The second metering-specific record is the split between legally relevant metrology software and cybersecurity-only changes. A gateway maker will ship security fixes far more often than metrology changes, and the file has to show that a security update did not quietly alter the approved measurement function. The matrix below is the decision aid: it tells the maker where to record the cybersecurity decision, and where an adjacent metrology approval or an operator-coordinated change window is needed.

Metrology versus cybersecurity update split. Security fixes must be assessed against legally relevant software without pretending the CRA replaces metrology approval.

Decision gate: this split is not a shortcut around metrology or utility approval. It tells the maker where to record the cybersecurity decision, and where an adjacent approval or operator hold is needed. The question it answers: can this fix ship as a cybersecurity update, or does it touch legally relevant metrology software? Artifact: metrology-impact decision record per release.

What a Real Metering Risk Assessment Looks Like

Use this as an example of the depth a Critical-tier file needs. The maker still has to run the assessment against its real gateway, security module, meter-protocol stack, communication module, supplier components, update ownership, sales claims and support-period promise.

Asset Inventory

Example product: ExampleCo GridMeter G2, a smart meter gateway paired with electricity meters, a cellular communication module, a hardware security module, a utility head-end connector, a consumer display interface, signed firmware updates and an installer commissioning tool.

The product boundary includes the gateway hardware, the security module, the meter interface, the communication module, the key store, the head-end connector, the consumer display interface, the firmware update service, the installer tool, the coordinated-disclosure intake and the advisory process. It excludes the utility's billing system, the legal metrology approval, the grid-operation systems and the customer energy contract, unless the same operator supplies them as part of the product.

A gateway's most privacy-sensitive output is the interval reading. Fine-grained consumption data can reveal occupancy, appliance use and behaviour, so the file needs a clear minimisation choke point and a clear answer to what support can see during an investigation. The flow below ties that back to the pseudonymisation and processing-profile controls from the architecture section.

Trust Boundaries

Threat Scenarios

Initial Risk Register

Control and Evidence Mapping

Residual Risk After Controls

What Goes in a Smart Meter Gateway SBOM?

The generic SBOM mechanics, format choice and signing live in the SBOM guide, the HBOM guide and the BSI TR-03183 guide. What is specific to a gateway is the shape of the tree. It is a hardware product that ships many digital elements on separate update cycles, rarely fewer than ten and often closer to twenty top-level components, each with its own supplier, update cadence and advisory feed. List them as one product-level inventory with element-separated sections, or one inventory per shipped element, as long as it stays machine-readable and covers the top-level dependencies.

Keep the obligation honest. The CRA asks for a machine-readable inventory covering at least top-level dependencies, refreshed across the support period, with supplier-advisory monitoring so a known vulnerability in the modem firmware or the protocol library is triaged rather than missed. It does not yet mandate one fixed format or a depth beyond top-level dependencies. Mirror that wording rather than inventing a stricter rule.

The inventory is not a passive list. Article 13 makes you exercise due diligence when you integrate a third-party component, including open-source, so it does not weaken the gateway's cybersecurity. It goes further on vulnerabilities. When you find one in an integrated component, you report it to the entity that manufactures or maintains that component, you fix it in your product under the Annex I vulnerability-handling rules, and where you have built a software or hardware fix you share the relevant code or documentation back with that maintainer. The cellular module and the security module are not just line items. Each is a product with digital elements in its own right, carrying its own CRA obligations, so the modem baseband advisory and the security-module errata are part of your watch and your upstream reporting, not someone else's problem.

How Should Support, Updates and Reporting Work?

A meter fleet outlives most consumer electronics. Gateways stay in walls for a decade or more, so the support model is part of the file, not an afterthought. Support evidence should cover the metrology firmware, the gateway firmware, the security module, the communication module, the head-end connector and the installer tools. Long-lived fleets also need evidence for certificate-authority continuity, signing-key expiry, spare-gateway baselines, and the separation between legally relevant metrology software and cybersecurity-only updates.

Security updates have to be coordinated with the utilities and the gateway administrator so the field rollout, the metrology impact and the user notice are traceable. A gateway maker cannot push a fleet update the way a phone app does. The operator owns the change window, and the file should show that coordination rather than assume it. The reporting duties under Article 14 start on 11 September 2026, so the disclosure policy and the single contact should be working before then, while the rest of the CRA applies from 11 December 2027, the date by which the conformity route and the technical file have to be complete.

One transitional rule matters more to a meter fleet than to almost any other product. A product placed on the market before the application date is caught by the full CRA only if it is substantially modified afterwards, so a meter installed years earlier does not retroactively need the conformity route. One duty breaks that rule. The reporting of actively exploited vulnerabilities and severe incidents reaches every in-scope product already on the market, deployed fleet included (Article 69). So the maker of meters fielded years ago still owes that reporting for its deployed fleet, and a utility carries it only where it is the manufacturer of record, for example after re-branding or a substantial modification. Map the deployed fleet against this split early, because the reporting obligation lands before the rest of the file.

What Importers, Distributors and Utilities Must Check

A gateway often splits its roles across more economic operators than a consumer product: a meter maker, a gateway maker, a utility that may re-brand or operate the fleet, a gateway administrator and an installer. The handoff map below shows who owns each pre-sale check and what stops the gateway at each role.

Custody gate: the gateway should not pass a role until the received build matches the assessed build. A re-branded firmware, a new operator cloud or a changed administrator profile reopens the role analysis. Artifact: incoming-build acceptance record.

The generic importer and distributor duties apply as for any product. The metering-specific checks are about the build and the keys. Importers and distributors should confirm the received build is the assessed build, not a re-branded fork. Utilities and installers should check key provisioning, the firmware baseline, the revocation and replacement workflow and the gateway-administrator profile before accepting a batch. A utility that places the gateway under its own name, runs the management cloud, or substantially modifies the firmware takes on manufacturer obligations for that branded fleet, including the vulnerability-reporting contact.

A non-EU meter or module maker may appoint an EU authorised representative under Article 18. The article says "may", so it is an option, not a duty, and you should not record an authorised representative as mandatory. The routing is what is not optional. An own-brand or substantially-modified product turns whoever placed or changed it into the manufacturer. The file has to name who receives a vulnerability report and who keeps the documentation available when the maker sits outside the EU. Decide that routing in the boundary work, not at the border.

How This Sits Alongside RED, MID, GDPR and NIS2

The CRA does not land on an empty desk. A smart meter already carries other CE obligations, and the utility that runs the fleet has its own duties. Four overlaps decide how much of the file is genuinely new.

A single EU declaration of conformity lists every act that applies, RED, MID, RoHS and the CRA among them. Two things catch makers out.

RED cybersecurity already binds a radio meter today. It has to meet the standards EN 18031-1, -2 and -3 now, ahead of the CRA. Keep meeting both until Delegated Regulation (EU) 2026/339 repeals the RED cybersecurity rules on 11 December 2027, the CRA application date.

EMC and the Low Voltage Directive are not listed twice. On a radio meter, RED already carries the EMC and safety objectives. Those two directives apply on their own only to a non-radio variant.