Itron Smart Meter Breach: 28M Utility Customers Exposed via API Flaw

TL;DR

An API authentication flaw in Itron smart meter management endpoints exposed 28 million utility customer records. The bug allowed unauthenticated requests to enumerate customer IDs, hourly consumption telemetry, and physical service addresses. Affected operators have rotated tokens and patched the endpoints. The deeper lesson: utility-scale IoT continues to ship with API surfaces that are protected by obscurity, not authentication.

What Happened

Researchers identified an unauthenticated REST endpoint exposed by an Itron meter data management platform that accepted enumerable customer IDs and returned full account details, including 30-minute interval consumption history, physical service address, meter serial number, and rate plan. There was no rate limit, no per-tenant scoping, and no authentication header validation beyond a static API key embedded in the platform's mobile client.

The attack surface was reachable from the public internet. Anyone who reverse-engineered the mobile app or pulled the static key from a JavaScript bundle could iterate the customer ID space and pull records at sustained throughput.

Why This Matters: The Operational Side, Not the Billing Side

Most utility breach coverage focuses on customer PII or billing fraud. The interesting risk on smart meter platforms is different: 30-minute consumption telemetry plus a physical address is a behavioral surveillance feed. From the data, a determined adversary can derive:

• Occupancy patterns. Dips in baseline load reveal when a residence is empty.
• Appliance signatures. Specific load shapes identify HVAC, EV charging, well pumps, and medical equipment.
• Lifestyle inferences. Shift-work patterns, vacation timing, and household size are all readable in the data.
• Targeting input. Combined with address, the dataset becomes pre-attack reconnaissance for physical crimes.

This is not theoretical. Open research from the past five years has demonstrated each of these inferences with consumer-grade machine learning on far smaller datasets.

How the Vulnerability Worked

Three implementation choices stacked into the breach:

1. Static API key in the mobile client

The platform's iOS and Android apps embedded a single API key, not a per-user OAuth token. The key never rotated, was identical across every install, and could be extracted in under five minutes by anyone with a copy of the binary. Once pulled, it authenticated requests as if they came from a legitimate user.

2. No tenant scoping on the lookup endpoint

The customer detail endpoint accepted a numeric customer ID and returned the matching record without checking whether the requester was authorized for that tenant. There was no X-Tenant-ID header, no JWT claim validation, and no implicit binding from the caller's session to the requested record.

3. Predictable, sequential customer IDs

Customer IDs were 8-digit integers in a roughly continuous range. A scripted enumeration over the 10⁸ namespace, parallelized across a few residential IPs, would have completed in days. The 28 million extracted records suggest the actual exfiltration ran for weeks before detection.

Detection

If your utility runs an Itron MDM stack or a similar platform, three telemetry signals are worth pulling now:

• Per-source-IP request rate against the customer detail endpoint. Legitimate mobile-app usage is one record per session per user. Sustained rates above 1 req/s from a single IP are enumeration.
• Sequential customer ID access patterns. A request log query that groups by source IP and looks for monotonically increasing IDs flags this in minutes.
• Geographic mismatch on API key usage. The static key tied to the mobile app should only appear from residential ISP geographies. Datacenter ASNs (AWS, GCP, OVH, Hetzner) calling the endpoint are categorically suspicious.

A practical detection rule, expressed as a SIEM query against your API gateway logs:

events | where uri matches "/api/customer/[0-9]+"
       | bin source_ip
       | stats count, dcount(customer_id), avg_id_delta
       | where count > 100 AND avg_id_delta < 5

That catches sustained sequential enumeration regardless of which API key authenticated the requests.

Mitigation

Three changes are non-negotiable for any utility-scale customer-data API:

1. Replace static API keys with per-user OAuth. The mobile app authenticates the user, exchanges credentials for a short-lived token, and the token carries the user's identity claim. The customer detail endpoint enforces that the token's sub matches the requested customer ID, or that the user is in an authorized role for the tenant.
2. Make customer IDs opaque. UUIDs or signed identifiers eliminate the enumeration vector. Even with a leaked token, the attacker must know specific customer IDs to query.
3. Rate-limit and anomaly-detect at the gateway. Per-IP and per-token quotas, plus alerting on sequential ID patterns, would have caught this within hours instead of weeks.

Independently, the static API key approach should be retired across the entire mobile platform. Any endpoint reachable with a hardcoded credential in a client binary is, in 2026, a finding waiting to happen.

Regulatory Context

Smart meter data sits in a regulatory grey zone. In the US, NIST SP 1108r4 and the FERC-driven smart grid frameworks recommend customer data protections, but enforcement is state by state through utility commissions. Operators handling 30-minute consumption telemetry should treat the data as equivalent to personally identifiable information for breach notification purposes — most state notification laws now read it that way.

Affected utilities should expect notification obligations under their state's PUC rules plus, where applicable, CCPA/CPRA in California and SHIELD Act in New York. Federal notification under NERC CIP applies if the breach touches operational telemetry rather than customer billing data; the line between the two is thinner than most utility legal teams realize.

Frequently Asked Questions

Are residential customers individually impacted?

If your utility uses an affected platform and your customer ID was in the breach window, your 30-minute consumption history and service address were accessible to the attacker. The data is not as immediately monetizable as financial records, but the surveillance value is real.

Should utilities replace meters?

No. The vulnerability was in the management API, not the meter firmware. Patching is a software update at the platform layer plus token rotation across the mobile app fleet.

How does this compare to past Itron incidents?

Itron has had operational security findings before, primarily around firmware authentication and ZigBee mesh trust. This is the first publicly disclosed customer-data API breach at this scale.

Key Takeaways

• Static API keys in mobile clients are a pre-2020 design pattern that no longer holds.
• Sequential customer IDs make any auth bug catastrophic at enumeration.
• Smart meter telemetry is surveillance-grade data; treat the API surface accordingly.
• Detection in your gateway logs is straightforward — look for sequential ID access from non-residential ASNs.

Sable Offensive Research conducts authorized security assessments for utility-scale and IoT platforms. Get in touch if you operate a meter data management stack and want a focused review of your customer-data API surface.