Smart Meter Security Guide: AMI, Keys and Firmware

A smart meter is a networked computer in every home that holds personal consumption data, accepts remote commands and, in many markets, can disconnect supply. That combination makes advanced metering infrastructure (AMI) one of the largest fleets of non-human identities any utility runs: millions of devices, each with its own keys, firmware and communication path to a head end. This guide covers how AMI is put together, how DLMS/COSEM protects meter traffic, how keys and certificates are managed at fleet scale, how firmware updates are secured, and how two national designs approach the problem: Great Britain's SMETS2 system run through the DCC with the GB Companion Specification (GBCS), and Germany's BSI smart meter gateway under TR-03109. It is written for metering security architects, head end and MDM operators, meter manufacturers and privacy teams. Substation, DER and transmission security are covered separately in the Smart Grid Security Guide.

Key takeaways

Remote disconnect is the critical function. The highest consequence command in AMI is the one that switches supply off, so it needs stronger authorisation than reading a register, and fleet-wide use must be rate limited.
Per-device keys are non-negotiable. DLMS/COSEM security suites and national PKIs only help if every meter has unique keys generated and stored securely; a shared key turns one opened meter into a fleet compromise.
Sign commands end to end. The GB model, where suppliers sign critical commands with SMKI Organisation Certificates and meters sign responses with Device Certificates, keeps a compromised network operator from forging instructions.
Firmware is a fleet-wide change. Signed images, staged rollouts and a tested way to halt a campaign matter more than any single meter hardening setting.
Consumption data is personal data. Interval data can reveal occupancy and habits; EU law requires smart metering security and privacy to comply with Union rules, so collection frequency, retention and access belong in the design.

AMI architecture and where it is attacked

A typical AMI deployment has five layers. Security requirements change at each boundary, and the attack paths below are the ones that recur in assessments and threat models.

Layer	Components	Typical attack path	Primary control
Meter	Metrology, communications module, disconnect relay, optical port	Physical access to optical or debug ports, key extraction, tampering	Unique keys in secure element, disabled debug interfaces, tamper events
Home area network	In-home display, consumer access devices, load control	Rogue device joining, sniffing local traffic	Authenticated joining, device allowlists held centrally
Neighbourhood or wide area network	RF mesh, PLC, cellular, communications hubs, data concentrators	Interception, replay, rogue head end, concentrator compromise	End to end message security, replay counters, hardened concentrators
Head end system	Command and collection platform, key store or HSM	Operator account takeover, mass commands, key theft	HSM, dual control for critical commands, rate limits, PAM
Back office	MDM, billing, customer portals, third party data access	Bulk data exfiltration, API abuse	Least privilege APIs, data minimisation, monitoring of bulk queries

The head end is the single most valuable target: one compromised operator account or API credential can reach every meter. Design so that a head end compromise alone cannot issue a valid disconnect, which is exactly what end to end command signing achieves.

DLMS/COSEM security

DLMS/COSEM (standardised in the IEC 62056 series, with IEC 62056-5-3 as the application layer) is the dominant meter data protocol outside North America. Its security sits at the application layer, so it protects messages independently of whether the transport is RF, PLC or cellular.

Authentication levels

No security: public client access, normally limited to reading non-sensitive identification objects.
Low Level Security (LLS): a static password sent at association. It is still found on optical ports and in older deployments; it is replayable if traffic is visible and should not protect any write or control access.
High Level Security (HLS): a challenge and response between client and server. Mechanisms include MD5, SHA-1, GMAC, SHA-256 and ECDSA variants; for new systems use GMAC or ECDSA and treat MD5 and SHA-1 based HLS as legacy.

Security suites

Suite	Authenticated encryption	Signatures and key agreement	Key transport	Where it fits
Suite 0	AES-GCM-128	None (symmetric only)	AES-128 key wrap	Most deployed meters; needs strong symmetric key management
Suite 1	AES-GCM-128	ECDSA and ECDH on P-256, SHA-256	AES-128 key wrap, ECDH	Public key designs with a meter PKI
Suite 2	AES-GCM-256	ECDSA and ECDH on P-384, SHA-384	AES-256 key wrap, ECDH	Higher assurance or longer key life requirements

The suite in use is signalled in the security control byte of the ciphered APDU. Within an association, the security policy decides whether requests and responses must be authenticated, encrypted, signed or a combination, and access rights on each COSEM object decide what each client role may read, write or execute.

Keys a DLMS meter holds

Global unicast encryption key (GUEK): protects unicast messages between a client and the meter.
Global broadcast encryption key: protects broadcast messages such as tariff updates; scope it carefully because every meter in the group shares it.
Authentication key (GAK): used in GCM authentication and HLS GMAC.
Master key or key encryption key (KEK): wraps the other keys when they are changed. It is the most sensitive key on the device and should be unique per meter and held only in an HSM at the operator.
Invocation counter: a frame counter used with GCM to prevent replay. Monitor for counters that reset or jump, which can indicate cloning or replay attempts.

Conformance testing through the DLMS User Association's test tool (CTT) checks protocol behaviour, but not whether keys were generated and injected securely in the factory. That needs a separate audit.

Key and certificate management at fleet scale

Most AMI security failures are key management failures. The lifecycle runs from manufacturing to decommissioning, and each step should have a named owner. See the Cryptographic Key Management Guide for general principles.

Generation: generate per-meter keys in an HSM, at the manufacturer or the operator, never derived from serial numbers in a predictable way.
Injection: load keys in a controlled factory process; transfer the key file to the operator encrypted to the operator's HSM, with a manifest that is reconciled on delivery.
Takeover: on installation, replace factory or transport keys with operational keys so the manufacturer no longer holds working keys for live meters.
Use: the head end calls the HSM for cryptographic operations; operators never see key material.
Rotation: rotate keys on a schedule and after any suspected compromise, using the KEK; test rotation at scale before you need it.
Change of supplier or operator: rotate keys or replace trust anchors so the previous party loses access.
Decommissioning and refurbishment: revoke certificates and destroy key records; refurbished meters get new keys.

Certificate-based designs add PKI work: certificate profiles, CA separation for devices and organisations, revocation and expiry planning across a 15 to 20 year meter life. See the Machine Identity, PKI and Certificate Lifecycle Guide.

Great Britain: SMETS2, DCC, GBCS and SMKI

Great Britain separated the roles that most markets combine. Energy suppliers (DCC Users) do not talk directly to meters; they send service requests to the Data Communications Company (DCC), which delivers GBCS messages to the meter through a communications hub in the home. The security design is defined in the Smart Energy Code (SEC) and its subsidiary documents, including GBCS (SEC Schedule 8).

SMKI: the Smart Metering Key Infrastructure binds the identities of devices and organisations to keys. The Organisation Certificate Authority issues Organisation Certificates that DCC Users use to sign GBCS commands; the Device Certificate Authority issues Device Certificates that meters use to sign their responses. The SEC overview of SMKI, IKI and DCCKI describes this split.
IKI and DCCKI: the Infrastructure Key Infrastructure authenticates access to SMKI services and signs files such as Threshold Anomaly Detection files and the Certified Products List; DCCKI secures TLS sessions to DCC interfaces and signs SAML assertions for personnel access to the Self-Service Interface.
Critical commands: commands such as supply disconnection are signed by the responsible supplier, so the DCC can deliver them but cannot create them. SEC modification MP129, implemented in the November 2022 release, explicitly permits remote parties to sign critical commands with the CNSA variant of ECDSA alongside the GBCS ECDSA variant.
Threshold anomaly detection: DCC Users set thresholds for the volume of commands, and the DCC can quarantine traffic that exceeds them. This is the fleet-level brake that stops one compromised supplier system issuing mass disconnects.
Product assurance: SMETS2 devices have been assured through the Commercial Product Assurance (CPA) scheme since the first evaluations in 2015. NCSC states that it formally handed the scheme to industry in September 2025: ownership now sits with the SEC Security Sub-Committee, operation is contracted to CyTAL, and DESNZ provides stewardship. NCSC's own CPA page now says its CPA Smart Metering scheme is closed. NCSC reports more than 32 million CPA-certified devices deployed in UK homes.

The lesson for other markets: authorisation of high impact commands should rest with the party accountable for the customer, enforced by signatures the meter checks, with an independent volume control in the network.

Germany: the BSI smart meter gateway and TR-03109

Germany took a different route: rather than securing each meter, it puts a certified smart meter gateway (SMGW) between meters and the outside world. BSI describes the SMGW as the central communications unit of an intelligent metering system, with an integrated security module that stores keys and provides signatures, key generation, key agreement and random number generation. All communication flows are encrypted and protected for integrity and authenticity.

Interface	Connects	Security role
WAN	Gateway to external market participants, especially the SMGW Administrator	Certificate-based mutual authentication via the SM-PKI; administration only by the certified administrator
LMN (local metrological network)	Gateway to electricity, gas, water and heat meters	Encrypted and authenticated meter links (wireless via OMS, wired via HDLC or SML profiles)
HAN (home area network)	Controllable devices such as heat pumps, CHP units and photovoltaic systems, plus the consumer and service technicians	Data provision to the consumer and controlled access for control boxes

The technical guideline TR-03109 is split into parts: TR-03109-1 (interoperability of the communication unit), TR-03109-2 (security module, with an annex on a smart meter mini-HSM), TR-03109-3 (cryptographic requirements, which refers to TR-03116 Part 3 for algorithms and key lengths), TR-03109-4 (SM-PKI), TR-03109-6 (gateway administration) and a test concept. Gateways are also evaluated against a Common Criteria Protection Profile, and BSI publishes certificate records under section 24 of the Metering Point Operation Act (MsbG). Check the BSI page for current part versions before quoting them in requirements.

Choosing between the models: a gateway design concentrates certified security in one device per premises and lets simpler meters sit behind it, at the cost of a more complex device and an administrator role that must itself be secured. A per-meter design (DLMS suites or GBCS) needs every meter to carry strong cryptography but avoids a separate gateway. Most markets end up with a per-meter design; the German model suits markets that also want the metering point to be a secure control channel for flexible loads.

Firmware security

A firmware update is the only change that can alter every security property of a meter at once, and in a fleet it is a mass change. See the Firmware and Boot Security Guide for the device side.

Signed images: the meter verifies a manufacturer signature before activation; the signing key lives in an HSM with dual control.
Separate authorisation from signing: the manufacturer signs the image; the operator authorises deployment to its meters with its own credentials, so neither party alone can push code.
Staged rollout: pilot group, then cohorts by region and hardware revision, with telemetry checks between stages and a defined halt criterion.
Rollback and recovery: keep the previous image available where the hardware supports it, and plan field replacement for meters that fail to activate.
Anti-rollback: prevent reinstallation of older vulnerable versions.
Software bill of materials: require one from manufacturers so you can find which meters contain a vulnerable component.

Privacy and smart metering data

In the EU, Article 20 of Directive (EU) 2019/944 requires that the security of smart metering systems and data communication comply with relevant Union security rules (point b), that customer privacy and data protection comply with Union data protection rules (point c), and that customers receive advice on how their personal data is collected and processed (point f). Article 19(6) adds that meters installed before 4 July 2019 which do not meet these functionalities may stay in service only until 5 July 2031.

Granularity: collect interval data at the frequency the purpose needs; half hourly or finer data can reveal occupancy patterns.
Purpose and consent: separate billing data from optional services, and record the legal basis for each.
Third party access: customer-authorised data access for energy services should use scoped, revocable credentials, not shared portal logins.
Retention and aggregation: aggregate for network planning where individual data is not needed.

See the Privacy by Design Guide for Engineering Teams.

Detection and measurement

Head ends and gateways generate the security telemetry; feed it to the SOC rather than leaving it in operational dashboards. Watch for: tamper and cover-open events; optical port sessions; failed HLS authentications; invocation counter anomalies; unexpected key change or firmware commands; command volumes against threshold; and bulk data exports from MDM.

Key uniqueness: percentage of the fleet on unique operational keys (target 100%, with factory keys retired).
Legacy authentication: number of meters still accepting LLS for any write access, trending to zero.
Critical command control: share of disconnect and key change commands that were signed and passed volume checks.
Firmware currency: percentage of meters on a supported, signed firmware version, by hardware revision.
Tamper response: median time from tamper event to investigation.
Key rotation readiness: time to rotate keys for a cohort of 100,000 meters in a test.

Framework mapping

Control area	NIST CSF 2.0	NIST SP 800-53 Rev. 5	ATT&CK for ICS technique addressed
Device identity and keys	PR.AA-01	IA-3, SC-12, SC-17	T0859 Valid Accounts, T1694.001 Default Credentials
Message protection	PR.DS-02	SC-8, SC-13	T0830 Adversary-in-the-Middle, T0887 Wireless Sniffing
Command authorisation	PR.AA-01	AC-3	T1692.001 Command Message, T0848 Rogue Master
Firmware integrity	PR.PS-02	SI-7, CM-14, SI-2	T1693 Modify Firmware
Network access	PR.IR-01	SC-7	T0860 Wireless Compromise
Data at rest and privacy	PR.DS-01	SC-28, PT-3	Not applicable
Monitoring	DE.CM-01	SI-4, AU-6	T0816 Device Restart/Shutdown
Supplier assurance	GV.SC-05	SR-3, SR-11	Not applicable

Common failure patterns

One key for the fleet: a global or batch key derived from a predictable value, so extracting it from one meter opens many.
LLS left on the optical port: a static password, often documented or shared among field technicians, that allows configuration changes on site.
Manufacturer keeps working keys: no key takeover at installation, so the factory key file remains a live credential for the fleet.
Head end operators can issue mass disconnects: no dual control, no volume threshold and no end to end signature, so one stolen account becomes a supply interruption event.
Firmware rolled out in one wave: a faulty image pushed to every meter of a type at once, with no halt criterion.
Telemetry not monitored: tamper and authentication failure events stay in the head end and never reach security monitoring.

Practitioner checklist

Confirm every meter uses unique keys generated in an HSM and that factory keys are replaced at installation.
Remove LLS from any write or control access and move to HLS GMAC or ECDSA.
Choose a DLMS security suite deliberately and enforce authenticated and encrypted security policies for all non-public clients.
Require end to end signing or dual control, plus volume thresholds, for disconnect, key change and firmware commands.
Run firmware campaigns in signed, staged cohorts with a tested halt and recovery plan.
Feed tamper, authentication failure and invocation counter events into the SOC.
Rehearse a key rotation for a large cohort before an incident forces it.
Document data minimisation and retention for interval data against GDPR and Directive (EU) 2019/944.
For GB or German deployments, track SEC modifications, CPA scheme changes and BSI TR-03109 updates.

Standards and references

Related NHI Mgmt Group resources: IoT Security Guide · OT Security Guide · OT and ICS Identity and Access Guide · IEC 62443 Guide

Smart Meter Security Guide: Metering Infrastructure, Keys and Firmware