Attackers use alarm suppression to prevent operators from seeing alerts that would reveal tampering, unsafe conditions, or failed controls. They may mute alarms directly, alter thresholds, or disable notification paths. Defenders should protect alarm configuration, compare active alarms with expected process behaviour, and treat unexpected silence as a suspicious signal.
How attackers suppress alarms without breaking the system’s other signals
alarm suppression is an attacker’s way of reducing visibility, not necessarily stopping the underlying activity. The goal is to keep operators focused on normal-looking telemetry while tampering, unsafe conditions, or control failures continue underneath. In OT environments, that can mean changing alarm settings, disabling notification routes, or altering thresholds so the process still runs but the warning layer goes quiet.
The practical issue is that suppression often targets the control plane of monitoring, not the process itself. A system can appear healthy while alarms are muted, delayed, or redirected. That is why defenders need to understand both the expected process behaviour and the alarm logic that should expose abnormal states.
Attackers also use suppression to buy time. If an alarm does not fire, or if it fires somewhere no one is watching, the attacker can keep manipulating equipment, conceal a failed safety action, or stretch dwell time before the issue is investigated. In operations where human response is part of the safety chain, a missing alarm can be as important as a visible one.
What gets manipulated when alarms are suppressed
Suppression can happen at several points in the alerting path. The attacker may mute an alarm at the source, change threshold values so the condition no longer crosses the trigger, disable forwarding to the console or pager, or selectively filter which events are sent onward. In some cases the process still generates data, but the presentation layer is made to look harmless or incomplete.
This makes alarm integrity a configuration-security issue as much as a monitoring issue. If alarm definitions, routing rules, or notification dependencies are writable by too many people or systems, suppression becomes a low-friction abuse path. The most dangerous cases are those where the operator assumes silence means safety, when it may only mean the detection path has been altered.
For industrial and process environments, this is closely tied to loss of view and false-normal conditions. The attacker is not always trying to disable everything. Often the more effective move is to preserve just enough telemetry to avoid immediate suspicion while suppressing the specific alarms that would reveal tampering or unsafe operation. NHIMG’s OT Security Guide is a useful reference for the surrounding OT context, including alarm-related manipulation and process visibility issues.
How defenders spot alarm suppression before it becomes an incident
Detection usually depends on comparing alarm behaviour with the process, not just watching for alerts to appear. If process conditions, sensor values, or operator actions indicate a problem but the alarm stream stays quiet, that mismatch is itself evidence. Unexpected silence is often more suspicious than noisy alerting, because suppression is designed to remove the warning signal without visibly breaking the plant or application.
Teams should also watch for administrative changes to alarm baselines, notification destinations, and escalation rules. A legitimate tuning change may be necessary, but the same mechanisms can be abused to hide anomalous states. The key judgement is whether the modification was authorised, documented, and consistent with a known maintenance or optimisation activity.
Direct evidence also matters. If an operator reports a condition that should have alarmed, check whether the relevant threshold, route, or suppression rule was changed before the event. If alarm logs, engineering workstation activity, and process historian data do not line up, treat that as a possible sign of tampering rather than a nuisance configuration issue.
Risk and Threat Considerations
Alarm suppression is dangerous because it converts a visible failure into an invisible one. The attacker does not need to stop the process immediately if they can stop the warning that would trigger human intervention, safety action, or containment.
Failure mechanism: The adversary alters alarm thresholds, mutes notifications, or changes routing so the alert path no longer reflects actual process state. That breaks the assumption that silence means normal operation.
Impact: Operators may miss tampering, unsafe conditions, or failed controls long enough for the attack or fault to escalate into equipment damage, service disruption, or safety consequences.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1562 — Impair Defenses | Alarm suppression directly impairs detection and alerting. |
| Recommendation — Map alarm changes to impairment activity and hunt for defensive tampering. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Alert suppression is often exposed through audit and configuration logs. |
| Recommendation — Centralise and protect logs for alarm and notification changes. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored to find anomalies and events | Alarm suppression undermines continuous monitoring of abnormal events. |
| Recommendation — Validate that monitoring still detects abnormal process behaviour when alarms are muted. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Alarm suppression can be revealed by reviewing changes and anomalies in alert logs. |
| Recommendation — Review alarm and configuration logs for unauthorized suppression changes. | ||
| ISO/IEC 27001:2022 | A.8.15 — Logging | Alarm suppression requires dependable logging of changes to alerting configuration. |
| Recommendation — Protect logging for alarm configuration and notification changes. | ||
Practitioner Guidance
What to verify: Confirm that alarm suppression requires explicit, logged authorisation and that changes to thresholds, routes, and notification rules are visible in audit logs. Cross-check recent alarm changes against maintenance windows, engineer actions, and process trends before trusting silence as a healthy state.
Decision rule: If a process condition suggests an alert should have fired but nothing appeared, treat the gap as a security signal first and a tuning issue second. Investigate configuration changes, notification dependencies, and account activity before assuming the alarm is simply miscalibrated.
Practitioner takeaway: The real control is not just generating alarms, it is preserving the integrity of the alarm path so operators can trust that meaningful silence is genuine, not engineered.