Scaling the SMGW backend: meter data management and PKI for millions of devices

The three layers of the SMGW backend

Behind every smart meter gateway stands a backend of three systems. Only their interplay turns raw readings into billable data, so it makes sense to look at each layer before asking how the whole thing scales.

The GWA system handles the administration: it configures the gateways, manages their key material and runs the gateway administrator role. The head-end system (HES) is the layer that actually talks to the field, it carries the WAN communication with the gateways. Meter data management (MDM) sits at the end of the chain and does the data work: it validates the readings, processes them and provides them to billing and market communication.

• GWA system: administration, configuration and key material of the gateways.
• Head-end system (HES): the WAN communication with the devices in the field.
• Meter data management (MDM): validation, processing and provision of the readings.
• Underneath: the smart meter PKI and the hardware security modules (HSM).

Below these three layers sit the smart meter PKI and the hardware security modules. They are not a fourth box in the data flow but the foundation that carries it: without valid certificates and the key handling in the HSM, none of the three layers can do its job. That is why scaling the backend always means scaling the PKI and the HSM with it.

The smart meter PKI and the certificates

The PKI is the trust framework of the whole system. Without valid certificates no gateway talks to the backend, and that is exactly what makes the PKI demanding in mass operation rather than a one-off setup task.

The smart meter PKI follows BSI TR-03109-4 and is three-level. At the top sits the root CA at the BSI as the trust anchor. Below it are the private sub-CAs, operated by service providers and utilities. At the bottom are the end entities: the gateways, the GWA, manufacturers and external market participants. Currently 11 sub-CAs are registered under the root CA.

• Three-level structure: root CA at the BSI, private sub-CAs, end entities.
• 11 registered sub-CAs: run by service providers and utilities.
• Separate certificates: signature, encryption and TLS per communication relationship.
• Single purpose: a private key may only be used for its defined purpose.

Each end entity needs separate key pairs per purpose. Per communication relationship there are distinct signature, encryption and TLS certificates, and a private key may only be used for the purpose it was issued for. Multi-year certificate lifetimes are common in practice, but the exact values are set in the certificate policy and are not fully confirmed here. The takeaway for the backend is that the number of certificates to manage grows several times faster than the number of devices.

The data volume: 15-minute values at scale

Scaling is above all a volume problem. A harmless quarter-hourly value turns into billions of data points per day once the installed base is large enough, and the backend has to absorb that without losing accuracy.

At 15-minute metering each device produces 96 data points per day. Extrapolated to tens of millions of devices, that comes to billions of values per day, which the head-end system and meter data management have to take in and process. The total figure is an extrapolation, but the order of magnitude is what drives the sizing, not the exact count.

The MDM cannot simply store these values. It has to validate them, form substitute values where readings are missing or implausible, and serve the market communication that depends on them. On top of that, dynamic tariffs and Section 14a control raise the reading frequency further, so the volume the backend has to handle keeps growing even before the device count does.

The certificate lifecycle at scale

What can be handwork at a thousand devices has to run automatically at millions. A missed rollover takes the communication down, so the certificate lifecycle moves from an administrative chore to a critical backend function.

The backend has to monitor expiring certificates continuously, that is a mandatory function rather than a nice-to-have. When a certificate nears its end of life, an automatic rollover has to issue and deploy the new certificate, with parallel operation of the old and new certificate during the transition so that no communication breaks while the swap is in progress.

• Continuous monitoring: tracking expiring certificates as a mandatory function.
• Automatic rollover: parallel operation of old and new certificate during the transition.
• Single point of failure: expired certificates stop the communication.
• Hardware security modules: key holding and crypto operations, throughput as a bottleneck.

The stakes are high because an expired certificate stops the communication, which makes the rollover a possible single point of failure across the whole base. The hardware security modules carry the key holding and the crypto operations, and their throughput and availability are the bottlenecks to plan for, not an afterthought. Crypto throughput and availability have to be sized for the peak, not the average.

Run it yourself or GWA-as-a-service

At the end stands a make-or-buy decision. The scale advantage of large backends is measurable, and it pushes small operators toward outsourcing rather than running everything themselves.

SaaS platforms advertise the administration of over a million metering systems per environment, and that scale shows in the numbers. Large metering operators reach higher rollout quotas than very small ones, 27.1 versus 14.6 percent at the end of 2025. In-house operation gives data sovereignty and full control, but it costs scaling and the hardware security modules that come with it. Geo-redundant, ISO 27001 certified data centres are standard on either path, so the choice is less about security baseline and more about scale and sovereignty.

For the neighbouring topics, the certification duty of the GWA role under TR-03109-6 sets the security frame any operator or service provider has to meet, and the GWA change in the mass rollout describes the handover process when a metering point moves between administrators. The wider rollout context is in the piece on the smart meter rollout and AI, and the financial and billing side in the article on the MsbG amendment and its price caps.

What companies should do now

Whoever sizes the backend for the target device count of 2030 rather than today's installed base avoids expensive retrofitting later. The certificate rollover belongs automated from the start, not bolted on once the base has grown.

• Size for the target device count. Dimension the backend capacity for the 2030 and 2032 target device count, not for today's base, so the scaling does not have to be redone.
• Automate the certificate lifecycle. Automate the certificate lifecycle and plan in continuous monitoring and the parallel operation of old and new certificates during the rollover.
• Calculate make-or-buy honestly. Weigh the scale advantage of GWA-as-a-service against the data sovereignty of in-house operation with real numbers, not assumptions.
• Put HSM, WAN and TR-03109-6 on the roadmap. Add hardware security module and WAN capacity as well as TR-03109-6 conformity to the roadmap, since they are the bottlenecks at scale.

Further reading

Frequently asked questions