M1060: Out-of-Band Communications Channel
Establish secure out-of-band communication channels to ensure the continuity of critical communications during security incidents, data integrity attacks, or in-network communication failures. Out-of-band communication refers to using an alternative, separate communication path that is not dependent on the potentially compromised primary network infrastructure. This method can include secure messaging apps, encrypted phone lines, satellite communications, or dedicated emergency communication systems. Leveraging these alternative channels reduces the risk of adversaries intercepting, disrupting, or tampering with sensitive communications and helps coordinate an effective incident response.[1][2]
Analyst context for executives and security teams
Out-of-band communications are a resilience control for moments when normal email, chat, collaboration tools, or network services cannot be trusted or are unavailable. The business value is not just “having another chat app”; it is preserving executive, legal, SOC, and incident-response coordination when adversaries may be reading email, mining repositories or messaging platforms, forwarding mail, or disrupting services.
Executive priority
Treat this as an incident-readiness and business-continuity requirement. Leaders should ask whether crisis communications, approval paths, legal notifications, recovery decisions, and executive briefings can continue if corporate email, collaboration platforms, or key services are compromised, monitored, or stopped. It also supports audit and compliance evidence by showing that the organization has planned for secure communications during security incidents and communication failures, consistent with the mitigation’s NIST SP 800-53 reference.
Technical view
Because ATT&CK provides no detection text for this mitigation, validation should focus on readiness testing rather than alert logic. SOC and IR teams should confirm that secure alternate channels exist, are documented, are accessible to required responders, and are independent of the potentially compromised primary network. Relationship context makes this especially relevant to Email Collection, Local/Remote Email Collection, Email Forwarding Rules, Data from Information Repositories, Messaging Applications, and Service Stop: responders should not coordinate sensitive actions through systems that may be collected from, forwarded, mined, or disabled during an incident.
Likely telemetry
- Inventory and ownership records for approved out-of-band communication channels
- Incident-response plans, call trees, escalation rosters, and crisis communication procedures
- Access and membership records for emergency communication groups or systems
- Test/exercise evidence showing responders can use alternate channels during email, chat, SaaS, or network disruption scenarios
- Audit records for changes to emergency contact lists, channel membership, and administrative access
Detection direction
- Do not frame this mitigation as a direct ATT&CK detection; the official object provides no detection guidance.
- Validate decision criteria for switching to out-of-band communications when email collection, forwarding rules, messaging-app collection, repository access, or service stoppage is suspected.
- Tune SOC playbooks so incident details, containment plans, credentials, and recovery steps are not shared through potentially compromised email, chat, or repositories.
- Include false-positive and operational considerations: switching channels too often can create confusion, while switching too late can expose response plans to an adversary monitoring primary communications.
- Confirm exercises capture evidence that responders could coordinate without relying on the primary network or normal collaboration stack.
Mitigation priorities
- Define which incidents require out-of-band communications, including suspected email compromise, collaboration-platform collection, repository exposure, or communication-service disruption.
- Select secure alternate channels that are separate from the potentially compromised primary infrastructure and appropriate for executive, legal, SOC, and IR use.
- Pre-enroll required participants, document escalation paths, and maintain emergency contact information outside normal email or repository dependencies.
- Protect the alternate channel with strong access governance and periodic review so it does not become another unmanaged repository of sensitive incident data.
- Run tabletop and technical exercises that simulate loss or distrust of email, messaging, SaaS repositories, and critical services.
Analyst notes and limits
The strongest decision value of M1060 is in incident command and communication integrity. Its relationship context shows why: several mitigated techniques involve adversaries collecting from email, messaging applications, and information repositories, while Service Stop can impair operational communications. Glexia would assess whether the organization can make high-risk containment and recovery decisions without exposing those decisions through the very systems under investigation.
ATT&CK lists no platforms or tactics directly on this mitigation and provides no official detection text. The related techniques identify relevant risk areas, but local architecture, collaboration tooling, emergency communication design, and incident-response procedures are required to determine actual coverage or gaps.
Out-of-Band Communications Channel
Establish secure out-of-band communication channels to ensure the continuity of critical communications during security incidents, data integrity attacks, or in-network communication failures. Out-of-band communication refers to using an alternative, separate communication path that is not dependent on the potentially compromised primary network infrastructure. This method can include secure messaging apps, encrypted phone lines, satellite communications, or dedicated emergency communication systems. Leveraging these alternative channels reduces the risk of adversaries intercepting, disrupting, or tampering with sensitive communications and helps coordinate an effective incident response.[1][2]
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.
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.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1114.001 | Local Email Collection Sub-technique | Implement secure out-of-band alerts to notify security teams of unusual local email activities, such as mass forwarding or large attachments being sent, indicating potential data exfiltration attempts.CitationTrustedSec OOB Communications |
| Enterprise | T1213 | Data from Information Repositories | Create plans for leveraging a secure out-of-band communications channel, rather than existing in-network chat applications, in case of a security incident.CitationTrustedSec OOB Communications |
| Enterprise | T1114.002 | Remote Email Collection Sub-technique | Use secure out-of-band authentication methods to verify the authenticity of critical actions initiated via email, such as password resets, financial transactions, or access requests. For highly sensitive information, utilize out-of-band communication channels instead of relying solely on email. This reduces the risk of sensitive data being collected through compromised email accounts. Set up out-of-band alerts to notify security teams of unusual email activities, such as mass forwarding or large attachments being sent, which could indicate email collection attempts. Create plans for leveraging a secure out-of-band communications channel, rather than an existing in-network email server, in case of a security incident.CitationTrustedSec OOB Communications |
| Enterprise | T1213.005 | Messaging Applications Sub-technique | Implement secure out-of-band communication channels to use as an alternative to in-network chat applications during a security incident. This ensures that critical communications remain secure even if primary messaging channels are compromised by adversaries.CitationTrustedSec OOB Communications |
| Enterprise | T1489 | Service Stop | Develop and enforce security policies that include the use of out-of-band communication channels for critical communications during a security incident.CitationTrustedSec OOB Communications |
| Enterprise | T1114 | Email Collection | Use secure out-of-band authentication methods to verify the authenticity of critical actions initiated via email, such as password resets, financial transactions, or access requests. For highly sensitive information, utilize out-of-band communication channels instead of relying solely on email to prevent adversaries from collecting data through compromised email accounts.CitationTrustedSec OOB Communications |
| Enterprise | T1114.003 | Email Forwarding Rule Sub-technique | Use secure out-of-band authentication methods to verify the authenticity of critical actions initiated via email, such as password resets, financial transactions, or access requests. For highly sensitive information, utilize out-of-band communication channels instead of relying solely on email. This reduces the risk of sensitive data being collected through compromised email accounts. Set up out-of-band alerts to notify security teams of unusual email activities, such as mass forwarding or large attachments being sent, which could indicate email collection attempts. Create plans for leveraging a secure out-of-band communications channel, rather than an existing in-network email server, in case of a security incident.CitationTrustedSec OOB Communications |
All related ATT&CK context
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 .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | cd88f1a9fcd9… |
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.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
TrustedSec OOB Communications
Tyler Hudak. (2022, December 29). To OOB, or Not to OOB?: Why Out-of-Band Communications are Essential for Incident Response. Retrieved August 30, 2024.
Open source URL -
[2]
NIST Special Publication 800-53 Revision 5
National Institute of Standards and Technology. (2020, September). Security and Privacy Controlsfor Information Systems and Organizations. Retrieved August 30, 2024.
Open source URL -
[3]
mitre-attack M1060Open source URL
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.