Every 30 minutes, around 32 million smart meters across the UK silently transmit your energy consumption data across a layered communication stack that most people, and frankly, most journalists, have never looked at properly. I’ve spent some time pulling apart how this system actually works, and what I found is a genuinely interesting piece of national infrastructure with some architectural decisions that should make any security researcher raise an eyebrow. The SMETS2 smart meter architecture is more complex, more distributed, and in some ways more fragile than Ofgem’s public-facing messaging ever lets on.
What SMETS2 actually is (and why SMETS1 was a disaster)
SMETS stands for Smart Metering Equipment Technical Specifications. The first generation, SMETS1, was an embarrassment. Meters were locked to individual energy suppliers, switch supplier and your smart meter reverted to a dumb one, sending you back to manual readings. Roughly 4 million SMETS1 meters had to be remotely upgraded or physically replaced. The core problem was that each supplier built proprietary comms stacks with no interoperability layer underneath.
SMETS2 fixed that by routing everything through a central intermediary: the Data Communications Company, or DCC. The DCC is a licensed body regulated by Ofgem, and it runs the Wide Area Network (WAN) relay that sits between your meter and your supplier’s systems. Every command, whether it’s a firmware update, a tariff change, or a remote disconnection, has to pass through the DCC’s infrastructure. In theory, this creates accountability. In practice, it creates a single point of architectural trust that’s worth examining closely.
The three-layer comms stack: HAN, WAN, and DCC relay
The SMETS2 communication stack has three distinct layers, and understanding each one is essential before you can reason about its attack surface.
The Home Area Network (HAN) is the local mesh between your smart meter, your In-Home Display (IHD), and any Consumer Access Devices (CADs) you’ve authorised. It runs on Zigbee, specifically Zigbee Smart Energy Profile 1.x (SEP 1.x), operating at 2.4GHz. The HAN uses AES-128 encryption with pre-provisioned keys baked into devices during manufacture. The Zigbee coordinator role sits in the Communications Hub, which is a separate module physically attached to or integrated with the meter itself. Range is typically 10-15 metres through walls, so in a terraced house, your neighbour’s HAN and yours can physically overlap in signal space, even if they can’t join each other’s network without the right keys.
The Wide Area Network (WAN) is the cellular uplink. SMETS2 meters use GPRS (2G) as the baseline, with some deployments using 3G or LTE depending on the Communications Hub variant. The WAN carries traffic between the Communications Hub and the DCC’s network. The WAN uses a separate security layer on top of the cellular transport, specifically DLMS/COSEM (Device Language Message Specification / Companion Specification for Energy Metering) with elliptic-curve cryptography for authentication and TLS for transport. The metering protocol itself is IEC 62056 compliant.
The DCC relay layer is where it gets interesting. The DCC doesn’t just passively route messages, it enforces a role-based access model. Every party that wants to send a command to a meter (your supplier, a network operator, a third-party service provider) has to authenticate with the DCC’s Remote Party Message Broker and have the correct authorisation level for that command type. Command types are categorised: read-only commands, critical commands (like remote disconnection), and firmware updates sit in different security tiers. The DCC also logs every transaction, which creates a fairly comprehensive audit trail, though I’ll come back to what that audit trail actually covers in a moment.
Known protocol weaknesses worth actually worrying about
Let me be clear: the SMETS2 stack is meaningfully more secure than SMETS1 and than many comparable deployments in other countries. But “more secure” doesn’t mean “without issues.”
The HAN’s reliance on Zigbee SEP 1.x is the most obvious concern. Zigbee SEP 2.0 exists and uses TLS 1.2 over TCP/IP, which is substantially more robust. The decision to stay on SEP 1.x was largely a commercial and backwards-compatibility decision made years ago when the rollout began. Researchers at Lancaster University published work in 2020 demonstrating traffic analysis attacks against Zigbee SEP deployments, not breaking the encryption, but inferring occupancy and appliance usage from packet timing and size. Your HAN is leaking behavioural metadata even when the payload is encrypted.
The WAN’s dependence on 2G GPRS is a more pressing concern in 2026, given that most UK operators have either switched off or are in the process of switching off their 2G networks. EE completed its 2G shutdown in 2024. Vodafone and Three are in progress. Ofgem and DESNZ have been managing a rolling Communications Hub replacement programme, but it’s slow. There are still tens of thousands of meters on GPRS connections that are increasingly operating on legacy spectrum kept alive specifically for IoT devices, a narrower, less resilient band that’s also more predictable for anyone doing signal intelligence work in the area.
At the DCC relay layer, the audit trail I mentioned covers command transactions but does not independently verify the integrity of the consumption data the meter itself reports. The meter’s tamper detection is physical and firmware-based. A sophisticated attacker with physical access to the meter, a rented property is the obvious scenario here, and enough knowledge of the firmware could theoretically manipulate readings before they’re signed and transmitted. This isn’t a theoretical edge case: researchers at Eurecom demonstrated analogous attacks against smart metering infrastructure at the IEEE S&P symposium in 2023. The DCC’s logs would show a meter reporting, but not necessarily that the reported values were authentic.
What a targeted attack on household energy telemetry would actually look like
I want to be specific here, because vague threat modelling is useless. A realistic targeted attack isn’t someone cracking AES-128 from a van parked outside your house. It looks more like this:
A malicious Communications Hub firmware update pushed through the DCC’s update mechanism, if an attacker compromised a DCC-authorised third party’s credentials and had sufficient access tier, they could potentially push a rogue firmware package to a subset of meters. The DCC does code-sign firmware, but the security of that signing infrastructure is itself a supply chain concern that isn’t publicly documented in any meaningful detail. For context, you can look at how UK public repositories have leaked credentials and API keys across government systems, the assumption that signing infrastructure is hardened everywhere isn’t one I’d make by default.
More practically, a rogue CAD on the HAN is a lower-effort attack. Consumer Access Devices are authorised via the HAN joining process, and while that process requires a PIN, social engineering a householder into adding a device is trivial. Once a CAD is on the HAN, it can read meter data in near-real-time. Occupancy inference from energy telemetry is accurate enough to be useful for burglars, stalkers, or corporate competitors in commercial premises.
Landlords navigating the energy compliance ecosystem face this from multiple directions. They’re dealing simultaneously with smart meter obligations, mandatory EPC assessments, and a tenant population that may have already authorised third-party CADs. Getting a Landlord EPC certificate is straightforward enough, but the broader smart metering compliance picture is something most letting agents have zero technical understanding of. The EU Cyber Resilience Act’s obligations for UK vendors are going to start touching smart home device manufacturers imminently, which will eventually push better HAN device standards, but that’s 2027 at the earliest.
Data retention and what Ofgem’s guidance actually says
Under the Smart Meters (Licensable Activity) Regulations 2016, the DCC is required to retain smart meter data for defined periods, but the specifics depend on what type of data and who’s requesting it. Half-hourly consumption data held by suppliers is typically retained for 24 months for billing purposes. The DCC’s own transaction logs have different retention windows. What Ofgem’s consumer-facing documentation doesn’t spell out clearly is that third-party service providers you’ve authorised, an energy monitoring app, a smart home platform, may retain your granular consumption data under their own privacy policies, for much longer, and with significantly weaker security obligations than the DCC itself imposes on licensed parties.
I’d also point to the comparison with how personal data flows from UK public registers into commercial broker pipelines, smart meter data is potentially even more granular and valuable, and the third-party authorisation ecosystem around CADs creates exactly the same kind of downstream leakage problem.
What you can actually do
Audit your CAD authorisations. Most IHDs have a menu that shows authorised devices on your HAN. If you see something you don’t recognise, contact your supplier to revoke it. Be very reluctant to authorise any third-party energy app unless you’ve actually read their data retention terms.
If you’re a landlord or a tenant in a property with a meter in an accessible common area, understand that physical access to that meter means physical access to the Communications Hub. Lock it properly. And if you’re renting out a property, know that your smart meter’s half-hourly data can infer your tenant’s behaviour at quite a fine grain, that’s data protection territory that most landlords haven’t thought about once.
The SMETS2 architecture is genuinely well-designed in its core cryptographic assumptions. The weaknesses are at the edges: legacy 2G WAN links, the Zigbee HAN’s metadata leakage, third-party CAD authorisation creep, and an audit trail that verifies transactions but not data integrity. None of that is going to be fixed by Ofgem telling you your smart meter is “safe.” Know the stack. Know what it’s actually doing.
Frequently Asked Questions
How does a SMETS2 smart meter actually communicate with my energy supplier?
Your SMETS2 meter sends data through a Communications Hub that connects to the Data Communications Company (DCC) via a cellular WAN link, typically GPRS or LTE. The DCC then relays commands and data between the meter and your supplier’s systems. Neither your supplier nor any third party can communicate directly with your meter without going through the DCC’s authentication and authorisation layer.
Can my SMETS2 smart meter be hacked remotely?
Directly cracking the cryptography is highly unlikely for a typical attacker. The realistic risks are at the edges: compromised third-party credentials giving DCC access, rogue Consumer Access Devices added to your Home Area Network, or traffic analysis revealing occupancy patterns from your HAN’s Zigbee traffic. Remote disconnection commands do exist in the SMETS2 command set and require DCC-tier authorisation, but the security of who holds those authorisations is worth scrutinising.
What is the DCC and why does it matter for smart meter security?
The Data Communications Company is the Ofgem-licensed body that acts as the central relay for all SMETS2 meter communications in Great Britain. Every command sent to your meter, from a tariff update to a firmware push, must pass through the DCC’s infrastructure and be authenticated against its role-based access model. This creates a single architectural trust point, meaning its own security posture matters enormously for the entire national smart metering estate.
How long is my smart meter consumption data kept, and who can see it?
Suppliers typically retain half-hourly consumption data for 24 months under billing regulations. However, any third-party apps or Consumer Access Devices you’ve authorised on your Home Area Network may retain your data under their own, often less stringent, privacy policies and for longer periods. The DCC maintains transaction audit logs separately. Checking and revoking unnecessary third-party authorisations is worth doing via your IHD menu or supplier account.
Is the Zigbee protocol used in smart meters secure?
SMETS2 uses Zigbee Smart Energy Profile 1.x with AES-128 encryption, which provides reasonable payload security. The known weakness is metadata leakage, researchers have shown that packet timing and size can reveal occupancy and appliance usage patterns even without decrypting the payload. Zigbee SEP 2.0 (which uses TLS over TCP/IP) would be more robust, but the SMETS2 rollout committed to SEP 1.x for compatibility reasons and changing that now would require widespread Communications Hub replacements.