Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0902: Detection of Unauthorized Message

DET0902 is a detection strategy for identifying unauthorized messages sent to ICS systems or devices. The business significance is that false telemetry or...

ICSDET0902Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

DET0902 is a detection strategy for identifying unauthorized messages sent to ICS systems or devices. The business significance is that false telemetry or unauthorized commands can undermine operator trust, mislead response decisions, or affect process behavior. Even without platform-specific MITRE guidance, this is a high-value validation area for organizations where industrial operations depend on trusted command and reporting flows.

Executive priority

Prioritize this as an operational resilience and cyber-physical risk question: can the organization prove that only authorized systems, users, and workflows can send commands or telemetry-like messages into critical ICS environments? Leaders should ask whether SOC, engineering, and incident response teams have evidence to distinguish legitimate operational messaging from injected or unexpected messages, and whether that evidence is usable during an incident or audit.

Technical view

MITRE provides no official detection text, platforms, or tactics for DET0902, but the related technique T1692 describes adversaries sending unauthorized reporting or command messages to ICS systems and devices. Defenders should validate monitoring around ICS message sources, destinations, message types, command paths, and expected communication patterns. Detection engineering should focus on deviations from approved device-to-device, application-to-device, and operator-to-system messaging baselines, while coordinating closely with control engineers to avoid misclassifying legitimate operational changes.

Likely telemetry

  • ICS network traffic metadata and protocol-aware message logs where available
  • Source and destination asset identity for engineering workstations, controllers, servers, and field devices
  • Records of authorized command paths, expected reporting flows, and approved communicating peers
  • Change, maintenance, and operator activity records to explain legitimate unusual messages
  • Alarm/event logs from ICS applications, historians, gateways, or security monitoring tools when present

Detection direction

  • Validate whether the environment has a known-good baseline for ICS reporting and command message flows.
  • Tune detections for messages from unexpected sources, to unexpected destinations, or outside approved operational context.
  • Correlate suspected unauthorized messages with maintenance windows, operator actions, and engineering changes to reduce false positives.
  • Pay attention to blind spots where ICS protocols, legacy devices, or segmented networks are not captured by SOC telemetry.
  • Use the relationship to T1692 as context: detection should consider both false or misleading telemetry messages and unauthorized command messages.

Mitigation priorities

  • Establish and maintain an inventory of authorized ICS message paths and communicating assets.
  • Restrict command and reporting pathways to approved systems and operational roles where technically feasible.
  • Ensure monitoring coverage exists at network boundaries and key ICS communication points, especially where commands or telemetry cross trust zones.
  • Document response procedures for suspected unauthorized ICS messaging, including coordination between SOC, incident response, and operations engineering.
  • Use detection validation results as evidence for control assurance, audit readiness, and prioritization of segmentation or monitoring improvements.
Analyst notes and limits

This take is based on the DET0902 detection strategy object and its relationship to ATT&CK for ICS technique T1692, Unauthorized Message. Because MITRE did not provide official detection text, platforms, or tactics for this object, the most useful application is as a validation prompt for ICS message integrity, monitoring coverage, and operational response readiness.

The supplied ATT&CK fields do not identify affected platforms, specific protocols, telemetry sources, or concrete detection analytics. Local architecture, asset inventory, ICS protocol use, and operational procedures are required to turn this into deployable detections or control requirements.

Official MITRE ATT&CK definition

Detection of Unauthorized Message

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
ICS T1692 Unauthorized Message This object detects Unauthorized Message.
Relationship explorer

All related ATT&CK context

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
21332edbbb52ff7e...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 21332edbbb52…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0902
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.