Practical Playbooks for AMI Anomaly Detection

As AMI networks grow in scale and complexity, both visibility and interpretation become increasingly difficult.

IT and security teams responsible for both IT and OT networks need a practical way to understand which network-level anomalies matter and how to validate them. Smart meters, concentrators, and gateways communicate in predictable patterns, making deviations valuable early indicators of configuration issues, operational irregularities, or security concerns. The challenge is detecting these deviations quickly and validating them consistently.

The anomaly types covered in this blog represent the most frequently observed network-level situations in real AMI environments. Mendel continuously detects these patterns through passive network monitoring, allowing teams to identify unexpected devices, communication changes, configuration drift, and abnormal behavior without disrupting AMI operations.

Each section links a specific AMI anomaly to its detection in Mendel and provides a practical validation checklist to support consistent, explainable decision-making across IT, OT, and operations teams.

Common AMI Anomalies Detectable via Network Monitoring

AMI monitoring tools typically help teams detect and validate the following recurring issues:

• New or previously unseen devices appearing in AMI network segments
• First-seen protocols, ports, or communication patterns
• Communication outside approved AMI network boundaries
• Unauthorized or unexpected changes in DLMS/COSEM parameters

All of the anomaly types described below are continuously detected by Mendel through passive network monitoring in live AMI deployments.

New Device Appearing in the AMI Network

Smart meters, concentrators, and supporting systems are deployed according to planned processes and do not change frequently. When a new device appears in the network, it often reflects routine field work such as meter replacement or vendor diagnostics, but it also introduces uncertainty about whether the change was expected, authorized, and correctly recorded. This makes new devices an event teams usually want to validate against current records and operational intent.

Mendel detects

Mendel detects and alerts when new devices appear in a monitored subnet and displays them in the inventory. It also automatically classifies devices based on their role, such as DLMS/COSEM server or DLMS/COSEM client, and assigns corresponding tags. These tags provide a practical basis for defining policies that track how different device types behave on the network.

Validation checklist

Recommended steps upon detecting a new device:

✅ Service verification: Confirm recent maintenance or meter replacement in the area 
✅ Communication analysis: Review which protocols the device uses and its main communication peers 
✅ Pattern comparison: Compare its behavior with known meter types in the same subnet 
✅ Coordination: Assess whether this event needs coordination with vendor or field teams

-> Potential field action

If the device remains unknown after the validation checklist, a physical verification may be appropriate to confirm the installation and ensure asset records reflect the actual field state. New devices in AMI networks often point to misconfiguration, unauthorized vendor access, or early intrusion activity.

First-Seen Communication Patterns

Meters and concentrators typically rely on a small, well-defined set of protocols and ports to communicate. When new communication appears, for example a previously unseen port or protocol, it usually reflects a change in configuration, tooling, or device behavior. In practice, these changes may be linked to firmware updates or diagnostics, but they can also indicate misconfigurations or unintended activity that deserves validation to ensure communication still aligns with expected and authorized AMI operation.

Mendel detects

Mendel detects when a device starts communicating in a way that has not been observed before, for example by initiating a new type of connection. Analysts can see the first-seen communication in context, including the source device, source and destination subnet, destination, protocol, and port. This helps them quickly verify whether the new communication is expected, for example due to a configuration change or update. If not, it may indicate unauthorized or unintended activity that needs to be validated.

Validation checklist

Recommended steps upon detecting unusual communication:

✅ Network standards: Verify whether the protocol/​port is part of standard AMI operation
✅ Maintenance context: Compare with recent firmware rollouts or vendor activities
✅ Scope of impact: Check if the activity is limited to a single device or widespread
✅ Source legitimacy: Determine whether communication originates from expected AMI components
✅ Geographic review: Ensure that the destination country is not a concern

-> Potential field action

If the communication remains inconsistent with approved AMI services, a field-level configuration review of the relevant concentrator or gateway may be appropriate to confirm that only intended services are available.

Forbidden Communication Violating Network Segmentation

AMI networks are typically designed so that smart meters and concentrators communicate only with explicitly approved systems, such as data concentrators or head-end platforms. Communication outside these boundaries is usually restricted by design. When traffic appears outside approved paths, it often indicates a change in the network setup, for example routing, gateway configuration, or operational settings. This is typically a situation teams want to review and validate.

Mendel detects

Mendel detects and alerts on communication outside approved network boundaries based on defined policies. These policies cover communication from AMI subnets to external networks, such as the internet, as well as communication to other internal network segments where it is not allowed. Analysts can see which device initiated the communication, where it was going, and which policy was triggered, helping them validate whether the activity is authorized.

Validation checklist

Recommended steps upon communication to unauthorized segments:

✅ Localization: Identify the source device and the destination network or system
✅ Architectural alignment: Verify whether the destination is part of the approved AMI communication design
✅ Change audit: Check for recent routing, firewall, or gateway configuration changes
✅ Operational context: Confirm whether maintenance or vendor activity could explain the connection

-> Potential field action

If communication outside approved network boundaries persists, teams may need to review how the relevant concentrator or gateway is configured and adjust it so that AMI traffic is restricted to approved destinations.

Unexpected Changes in DLMS/COSEM Data or Parameters

AMI devices regularly exchange application-layer data that reflects their configuration, operational state, and measured values. While many of these exchanges are part of normal operation, unexpected changes in parameters or settings can indicate configuration errors, incomplete updates, or actions outside standard procedures. In some cases, they may also reflect intentional manipulation, for example when legitimate protocol functions are misused to modify values or issue unauthorized commands. These situations are typically worth validating to ensure devices behave as intended.

Mendel detects

Mendel detects DLMS/COSEM SET operations at the application layer, which are the mechanism used to change meter values or parameters. It makes it visible which devices perform these operations, allowing analysts to review which IP addresses initiate them and compare them against the set of devices that are expected and authorized to do so. Once this baseline is established, Mendel alerts when a previously unseen or unapproved device performs a SET operation, helping teams identify policy violations, misconfigurations, or potentially unauthorized activity.

Validation checklist

Recommended steps upon detecting unauthorized parameter changes:

✅ Change identification: Identify which value, parameter, or setting changed
✅ Baseline comparison: Compare the new value with the expected or baseline configuration
✅ Event correlation: Check when the change occurred and whether it aligns with planned activities
✅Source attribution: Verify which system or device initiated the change and whether it was authorized

-> Potential field action

If the change cannot be explained through planned updates or authorized activity, teams may need to restore the expected configuration and further review how the change was initiated before returning the device to normal operation.

Maintaining Control Over AMI Network Communication

As AMI environments scale, maintaining confidence in how devices communicate becomes increasingly important. Network-level visibility makes it possible to observe actual behavior across the metering infrastructure and validate that it aligns with expected operation.

The playbooks outlined here show how anomaly detection can serve as a practical operational control, supporting both operational stability and security oversight. By applying consistent validation steps and clear follow-up actions, teams can use AMI network data to confirm expected behavior, detect deviations early, and maintain a predictable, well-understood environment.