Tamper Detection and Physical Security at the Device Level
A meter sitting unattended in a public or semi-public location for fifteen years faces a different threat model than any device in a data centre. Physical security has to be designed in, not bolted on.
A server sits behind locked doors, badge access and a monitored perimeter. A meter sits on an exterior wall, in a basement, or in a street cabinet, accessible to anyone who wants to spend a few minutes with it. That difference in exposure is permanent, not a gap to be closed — which means tamper detection has to be designed into the device itself, not layered on afterwards.
Detection alone isn't the goal. A tamper event that's flagged but never transmitted, or transmitted but never investigated, provides no protection at all. The full chain — sense, transmit, log, investigate — has to work end to end.
This briefing sets out the common tamper vectors, how detection and response should be designed, and the risks worth naming before treating a tamper flag as either meaningless noise or unquestionable proof.
What tampering looks like
Detection is only the first step
Figure 1. A tamper event detected but never transmitted provides no protection — the alert path needs its own resilience, independent of the primary comms link where possible.
Six risk points worth naming
Detection without reliable transmission
A tamper event flagged locally is worthless if the device's comms path is exactly what's being tampered with.
False positives from legitimate maintenance
Routine field work can trigger the same alarm as malicious tampering, eroding trust in the signal.
Evidentiary quality
A tamper flag alone rarely supports enforcement action without a defensible, timestamped log.
Sensor degradation over time
Mechanical switches and sensors can fail or drift over a 15-year life, silently reducing coverage.
Bypass techniques evolve faster than the device
A design frozen at manufacture can't adapt to new bypass methods discovered years later.
No clear response process
A stream of tamper alerts with no defined investigation workflow generates data without action.
Designing the full chain
Design an independent, low-power alert path
Not dependent on the primary comms link alone.
Tune sensitivity against real maintenance activity
And review false-positive rates regularly.
Log events in a tamper-evident, timestamped format
Suitable for enforcement use, not just internal alerts.
Monitor sensor health across the fleet
Don't rely on day-one calibration alone.
Build a defined investigation and response workflow
Before alerts start arriving at scale.
A meter's physical exposure isn't a flaw to fix — it's the operating environment it has to be designed for from day one. Detection, transmission, evidence and response all have to work together, because a tamper-detection feature that only works on the datasheet protects nothing in the field.
How a read moves across the estate
HOVER OR TAP A STAGE TO EXPAND TECHNICAL SPECS
Chris Gales
Chris Gales leads CEHG. He converts complex technical and commercial choices into clear decisions and dependable outcomes for utilities running connected device estates at scale.
He writes these field notes from the practice — on bearer migration, smart metering architecture, procurement and operations — to help estates start counting down early.