MITRE ATT&CK M1060: Out-of-Band Communications — and How YUDU Sentinel Measures Up

The problem: responding from inside the breach

Most incident response plans quietly assume that Teams, Slack, email and the corporate directory will still be there when the incident starts. In a serious cyber attack, they are the first things you should stop trusting.

If an attacker has a foothold in your identity system or mail tenant, your crisis team may be coordinating its response in front of the very adversary it is trying to remove. If ransomware or a defensive shutdown takes those systems offline, the team may not be able to coordinate at all.

MITRE ATT&CK, the industry's most widely used knowledge base of adversary behaviour, addresses this directly in mitigation M1060: Out-of-Band Communications Channel. This post sets out what M1060 says, which attack techniques it counters, and where YUDU Sentinel does and does not map to it.

What MITRE ATT&CK M1060 says

M1060 advises organisations to establish secure out-of-band communication channels so that critical communications continue through security incidents, data integrity attacks and in-network communication failures. MITRE added it to ATT&CK in August 2024.

The definition is the important part. MITRE describes an out-of-band channel as a separate communication path that does not depend on the primary network infrastructure, which may itself be compromised. It lists secure messaging apps, encrypted phone lines, satellite communications and dedicated emergency communication systems as examples.

The stated purpose is twofold: reduce the risk that adversaries intercept, disrupt or tamper with sensitive communications, and keep incident response coordinated. MITRE cites TrustedSec's guidance on OOB for incident response and NIST SP 800-53 Rev. 5 as its references.

The attack techniques M1060 is designed to counter

M1060 is mapped to three ATT&CK techniques and four sub-techniques. Each describes a way an attacker turns your everyday communication tools against you.

The common thread: if your incident response runs through the systems the attacker controls or has switched off, the attacker sees your moves or you cannot make them.

How YUDU Sentinel maps to M1060

Sentinel is built for the core of M1060: keeping incident and crisis communications running, and private, when primary systems are compromised or down. It does not cover every recommendation, and we would rather say so than imply otherwise.

In short, Sentinel is the dedicated emergency communication system M1060 describes. It sits alongside, not in place of, your detection and identity controls.

What makes a channel genuinely out-of-band

M1060's test is independence: the channel must not depend on the infrastructure that may be compromised. A second Teams tenant, a WhatsApp group on corporate-managed phones, or a tool that signs in through your own identity provider can all fail that test. Sentinel is designed to pass it in four ways.

Independent hosting. Each customer runs a single-tenant instance on AWS, with its own operating system, outside Microsoft 365 and Azure. It is not connected to a shared SaaS platform or central YUDU systems, so there is no shared point of failure whose compromise reaches other customers.

Independent identity. Authentication happens entirely on Sentinel, with no dependency on your directory or single sign-on. Passkeys are live across the estate and MFA can be enforced. If your identity provider is compromised, the attacker does not inherit access to your crisis channel. Where an HR feed is used, it runs one way into Sentinel and administrators can freeze it the moment an incident is declared.

Independent reach. SMS, recorded voice calls and push notifications reach people on their own devices, with acknowledgement tracking on SMS. Recipients need no app installed to receive an SMS alert.

Evidence that holds up. A tamper-evident, exportable audit log records who knew what and when. That matters for regulators and post-incident review, and Sentinel can carry regulator notifications when primary systems are down.

Sentinel won the 2025 BCI European Continuity and Resilience Provider Award.

Five questions to test your own OOB readiness

1. If your Microsoft 365 or Google tenant were compromised tonight, where would your crisis team meet?

2. Does that channel authenticate through the same identity provider the attacker may control?

3. Can you reach every member of the crisis team, and wider staff, without corporate email or a managed device?

4. Is the switch to OOB written into policy, with a named trigger, or left to judgement on the night?

5. When did you last rehearse an incident with primary systems assumed lost?

M1060 does not ask for a product. It asks for a channel your adversary cannot see, stop or impersonate, and a plan to use it. If any of these questions gave you pause, talk to us about what that looks like in practice.

MITRE ATT&CK® is a registered trademark of The MITRE Corporation. MITRE does not endorse vendors or products; this mapping is YUDU's own assessment.

Sources

• MITRE ATT&CK, M1060 Out-of-Band Communications Channel (v1.0, last modified 12 October 2024)
• Tyler Hudak, TrustedSec, To OOB, or Not to OOB? (29 December 2022)
• NIST, SP 800-53 Rev. 5 (September 2020)