ATT&CK for ICS T0838 Modify Alarm Settings Guide

Modify Alarm Settings (T0838) removes the warning before the harm: a widened deadband, a moved trip point or a disabled alarm means operators and automatic responses never react to a dangerous condition. MITRE ATT&CK for ICS places it under the Inhibit Response Function tactic and describes adversaries changing alarm and reporting settings so that events are not reported, which can also stop operators or devices from acting to keep the system in a safe state. Unlike the Impact techniques, T0838 has a concrete footprint: configuration changes on controllers, HMIs, alarm servers and network devices, which ATT&CK v20 now gives four detection analytics for. This guide is for OT security engineers, control and alarm management engineers and incident responders. It covers the scope of the technique, the recorded cases, the detection analytics and how to tune them, the seven ATT&CK mitigations, alarm management governance, and a safety-aware response. For the wider matrix see the MITRE ATT&CK for ICS Guide and the ATT&CK for ICS Inhibit Response Function Tactic Guide.

Key takeaways

Alarm settings are safety-relevant configuration. Thresholds, deadbands, priorities and enable states decide whether a dangerous condition reaches an operator, so they deserve the same change control as controller logic.
The technique spans four platforms. ATT&CK lists Embedded, Windows, Linux and Network Devices, so alarm settings live in PLCs and RTUs, HMI and alarm servers, and SNMP-managed network equipment.
Detection is possible and specific. ATT&CK detection strategy DET0777 has four analytics for unauthorised writes to alarm thresholds, each gated by authorised source, change window and change-control context.
Recorded cases span more than 25 years. The 2000 Maroochy Water Breach disabled alarms at four pumping stations, and ATT&CK records CyberAv3ngers manipulating critical shutdown and alarm logic during the 2026 Iranian Water Campaign.
Most of the seven mitigations are about who may change alarms. Authorisation, authentication, account management, allowlists and segmentation limit alarm changes to designated engineers on designated systems.

What T0838 covers and how it differs from nearby techniques

ATT&CK v20 explains that reporting messages carry state information and acknowledgements that keep operators, engineers and administrators aware of the process. If an adversary changes the reporting settings, certain events may not be reported, and if critical reporting messages cannot trigger the actions that keep the system safe, an impact can follow. ATT&CK notes that methods of suppression often rely on modifying alarm settings, including modifying in-memory code to fixed values or tampering with assembly-level instruction code, citing Wetzels and Krotofil's 2019 research on OT payloads for embedded devices.

Technique	What changes	Typical evidence
T0838 Modify Alarm Settings	The configuration that decides when an alarm fires: thresholds, deadbands, priorities, enable states	Configuration writes on controllers, alarm servers, HMIs or network devices
T0878 Alarm Suppression	Alarm messages for protection functions are prevented from reaching operators, by any means	Missing alarms with settings that may be unchanged
T1691 Block Operational Technology Message	Reporting or command messages are blocked in transit	Traffic drops, communication alarms
T0835 Manipulate I/O Image	The values the controller evaluates	I/O overrides or forces in the PLC
T0889 Modify Program	Controller logic, which may include alarm logic	Program download, logic differs from baseline
T0892 Change Credential	Credentials on a device, often to lock out the owner after changes	Failed logins by legitimate engineers

ATT&CK itself observes that an adversary may need to use T0878 Alarm Suppression alongside T0838, or contend with multiple alarms and alarm propagation. See the T1691 Block Operational Technology Message, T0835 Manipulate I/O Image, T0889 Modify Program and T0892 Change Credential guides, and the T0837 Loss of Protection guide for the consequence.

Real cases recorded by ATT&CK

Maroochy Water Breach (C0020): ATT&CK records that the adversary disabled alarms at four pumping stations, preventing notifications to the central computer. MITRE's case study of the 2000 incident in Queensland, Australia, dates this to the evening of 23 April 2000 and records about 800,000 litres of raw sewage released over the wider series of attacks. It also notes the attacks were not recognised as intentional for some time, that radio links were insecure and that the system lacked the audit logging needed for diagnosis and forensics. The attacker was a former contractor employee.
CyberAv3ngers (G1027), 2026 Iranian Water Campaign (C0065): ATT&CK records that during this campaign CyberAv3ngers manipulated critical shutdown and alarm logic, citing CISA advisory AA26-097A on Iranian-affiliated actors exploiting PLCs. The 2026 U.S. Water Utilities Attacks (C0066) are a separate ATT&CK campaign that is not attributed to any group.

Both cases are in water and wastewater, where small utilities often run remote sites with limited staff and rely on alarms to call operators out. The sector context is in the Water and Wastewater Cybersecurity Guide.

Detection: the four ATT&CK analytics and how to use them

DET0777 Detection of Modify Alarm Settings contains four analytics, one per platform type. Each carries the same OT gate: alert only when the action is not attributable to an authorised operator or engineering source for that target and function, and it is outside an approved change or maintenance window or lacks change-control context.

Analytic	Platform	What it flags	Telemetry needed
AN1909	Network Devices	SNMP SET commands to alarm threshold OIDs on ICS network devices or process monitoring systems from a source outside the approved network management subnet	Network monitoring that decodes SNMP; inventory of the approved management systems
AN2117	Linux	Writes to alarm threshold configuration files on a Linux-based alarm server by a user other than the alarm management service	File integrity or audit logging on the alarm server
AN2211	Embedded	ICS protocol writes to alarm threshold or deadband registers from a source not on the approved engineering list, where the value widens the deadband or moves the trip point beyond the safe envelope, without operator acknowledgement	Protocol-aware OT network monitoring with a register map of alarm parameters
AN2276	Windows	Writes to alarm threshold configuration on an HMI or alarm server from a process other than the recognised alarm management application, with no matching operator session	Endpoint process and file telemetry on HMI and alarm servers, HMI audit trail

Making the analytics work

Build the register map first: AN2211 only works if you know which controller addresses or tags hold alarm limits and deadbands. Start with the alarms that protect people and equipment.
Define the safe envelope with process engineers: a change that moves a trip point beyond the documented safe limit should alert even when it comes from an approved workstation.
Use the master alarm list as the baseline: compare current alarm settings in HMIs and controllers with the approved list on a schedule, so changes made with valid credentials are still found.
Watch disabled and shelved alarms: a rising number of disabled alarms, or alarms shelved longer than policy allows, can be a security signal as well as an alarm management problem.
Alert on the absence of alarms: a site that normally produces a steady trickle of low-priority alarms and suddenly goes silent deserves a check.

Collection design is in the OT Network Security Monitoring Guide and the OT Security Operations Centre Guide.

Mitigations: the seven ATT&CK lists

Mitigation	ATT&CK guidance for T0838	Practical application
M0800 Authorization Enforcement	Only authorised personnel should be able to change alarm settings	Separate HMI roles for operating, acknowledging and configuring alarms
M0801 Access Management	All device changes, including administrative functions, should require authentication; use access management technologies where devices lack strong authentication	Broker engineering access to controllers through a managed jump host
M0804 Human User Authentication	Field controllers should require authentication for all remote or local management sessions	Enable controller passwords or access levels where the device offers them
M0807 Network Allowlists	Host-based allowlists so devices accept connections only from master stations or known engineering workstations	Controller and firewall allowlists per zone
M0813 Software Process and Device Authentication	Authenticate connections from software and devices to protected management functions	Authenticated protocol modes and SNMPv3 for network devices where supported
M0918 User Account Management	Limit privileges so only designated administrators or engineers can change alarm configuration and thresholds	Named accounts, periodic review of who holds alarm configuration rights
M0930 Network Segmentation	Restrict access to critical functions to predetermined management systems	Zones and conduits so alarm configuration is only reachable from the engineering zone

The baseline from the joint CISA, FBI, EPA and DOE primary mitigations applies directly to the water cases: remove OT devices from the public internet, change default passwords, secure remote access with phishing-resistant MFA, segment IT and OT, and keep the ability to operate manually. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide and the PLC Security Guide.

Alarm management governance as a security control

ISA-18.2, Management of Alarm Systems for the Process Industries, was first published in 2009, and its IEC counterpart is IEC 62682. Its alarm management discipline (an alarm philosophy, an approved list of alarms with rationalised settings, and controlled change) gives security teams a ready-made baseline. Where your site already runs an alarm management programme, connect the two:

Record the approved settings: make the rationalised alarm list the reference for every threshold, deadband, priority and enable state on critical alarms.
Require a change record: treat any alarm setting change without an approved change as a security event, not only an alarm management deviation.
Audit shelving and disabling: report alarms shelved or disabled beyond the time the philosophy allows, and who did it.
Compare regularly: run a scheduled comparison of live settings against the approved list, and investigate every difference.
Test critical alarms: proof-test alarms that protect people or the environment, so a silently changed alarm is found before it is needed.

Choosing between options

Situation	Preferred control	Trade-off
Small utility with remote pumping stations	Remove internet exposure, change default passwords, restrict who can change alarm settings, regular comparison with the approved list	Manual effort, low cost
Plant with an alarm management system and OT monitoring	Automated comparison against the master alarm list plus AN2211-style protocol alerts	Register mapping and tuning effort
Controllers without authentication options	Network allowlists and segmentation so only the engineering zone can reach them	Depends on accurate firewall rules
Network devices with SNMP alarm thresholds	SNMPv3 with authentication, management only from the approved subnet, AN1909-style alerting	Migration effort from older SNMP versions

Where identity fits

Alarm configuration rights are often held by shared engineering accounts, vendor support accounts and integration service accounts on alarm servers. Maroochy was carried out by a former contractor employee, which MITRE's case study treats as a supply chain lesson about contractor access and personnel security. Inventory every account that can change alarm settings, remove standing vendor access, give each engineer and vendor a named account with time-bound access, and review alarm configuration rights at least quarterly. See the OT Remote Access Guide.

Safety-aware response

Assume protection may be degraded: operations decides whether to increase field rounds, move to manual or place the process in a safe state while alarms cannot be trusted.
Restore critical alarm settings first: compare with the approved alarm list and restore safety and environmental alarms before less critical ones, with operations confirming each change.
Check the safety layer: confirm the safety instrumented system's own trip settings are unchanged. See the Safety Instrumented Systems Security Guide.
Look for the purpose: alarm changes inhibit a response to something; review process data for abnormal conditions during the period alarms were changed, and look for related logic, parameter or credential changes.
Remove the access path: disable the account, remote access path or host used, and change credentials on affected devices.
Preserve evidence: HMI and alarm server audit trails, alarm and event journals, controller projects read from the device, network captures and change records.

The wider process is in the OT Incident Response Guide.

Metrics that show it is working

Baseline coverage: share of critical alarms with an approved setting recorded and compared with live settings at least monthly.
Unapproved alarm changes: count per month of alarm setting changes with no change record, and share investigated.
Alarm configuration rights: number of accounts able to change alarm settings, trending down, with none shared.
Stale shelved or disabled alarms: count beyond the time the alarm philosophy allows.
Analytic coverage: share of controllers, alarm servers and network devices covered by at least one of the four DET0777 analytics.

Framework mapping

Control area	NIST SP 800-53 Rev 5	NIST CSF 2.0	ATT&CK for ICS mitigation
Who may change alarm settings	AC-3 Access Enforcement; IA-2 Identification and Authentication	PR.AA-05	M0800, M0801, M0804, M0918
Change control on alarm configuration	CM-3 Configuration Change Control; CM-5 Access Restrictions for Change	PR.PS-01	M0800 Authorization Enforcement
Device and software authentication	IA-3 Device Identification and Authentication	PR.AA-05	M0813, M0807
Restricting management paths	SC-7 Boundary Protection	PR.IR-01	M0930 Network Segmentation
Monitoring for unauthorised changes	SI-4 System Monitoring; AU-6 Audit Record Review, Analysis, and Reporting	DE.CM-01; DE.CM-09	DET0777 analytics

For OT tailoring see the NIST SP 800-82 OT Security Guide and the IEC 62443 Guide.

Common failure patterns

Alarm settings outside change control: operators or engineers can adjust thresholds freely, so a malicious change looks like routine tuning.
No audit logging: the Maroochy case study records that the system lacked the logging needed for diagnosis and forensics, which delayed recognition that the faults were deliberate.
Treating alarm floods with blanket disabling: many disabled alarms make one more invisible and train staff to accept silence.
Internet-exposed controllers with default passwords: the condition that the joint CISA, FBI, EPA and DOE guidance addresses first, and the one that lets anyone change alarm logic.
Standing contractor access: accounts and knowledge that persist after a contract ends, as in Maroochy.
Restoring alarms without checking the process: the alarms were changed for a reason; returning them without reviewing what happened while they were off can miss damage or a second action.

Practitioner checklist

Record approved settings for every critical alarm and compare live settings against them monthly.
Map the controller registers and tags that hold alarm limits and deadbands, and alert on writes from unapproved sources.
Monitor HMI and alarm server configuration files and audit trails for changes outside the alarm application or an operator session.
Restrict SNMP management of network devices to the approved subnet and use authenticated SNMP where supported.
Separate operate, acknowledge and configure roles, and review who holds alarm configuration rights each quarter.
Remove internet exposure and default passwords from controllers and HMIs.
Report shelved and disabled alarms against the alarm philosophy limits.
Exercise the response to unexplained alarm changes with operations.

MITRE ATT&CK for ICS T0838 Modify Alarm Settings: Detection and Response in OT