M1009: Encrypt Network Traffic
Application developers should encrypt all of their application network traffic using the Transport Layer Security (TLS) protocol to ensure protection of sensitive data and deter network-based attacks. If desired, application developers could perform message-based encryption of data before passing it for TLS encryption.
iOS's App Transport Security feature can be used to help ensure that all application network traffic is appropriately protected. Apple intends to mandate use of App Transport Security [1] for all apps in the Apple App Store unless appropriate justification is given.
Android's Network Security Configuration feature similarly can be used by app developers to help ensure that all of their application network traffic is appropriately protected [2].
Use of Virtual Private Network (VPN) tunnels, e.g. using the IPsec protocol, can help mitigate some types of network attacks as well.
Security context for executives and security teams
Encrypting mobile application network traffic is a baseline resilience control: it reduces the chance that sensitive data or app communications can be observed or manipulated on untrusted networks. For leaders, the decision value is not simply “use TLS,” but whether mobile apps, APIs, and any VPN-dependent traffic paths are consistently protected and whether exceptions are documented, justified, and auditable.
Executive priority
Treat M1009 as a mobile application security and compliance evidence item. Executives should ask whether all business-critical mobile apps enforce protected transport, whether iOS App Transport Security and Android Network Security Configuration are used where applicable, and whether any cleartext or exception-based traffic is risk-accepted. This matters for customer data protection, incident response confidence, and reducing exposure to network-based attacks such as adversary-in-the-middle activity.
Technical view
For SOC, detection engineering, mobile security, and IR teams, validate the control rather than looking for a MITRE-provided detection analytic, because ATT&CK does not provide detection guidance for this mitigation. Review mobile app configurations, build artifacts, runtime behavior, and network captures to confirm TLS is used for application traffic. For iOS, validate App Transport Security settings and exceptions. For Android, validate Network Security Configuration and cleartext traffic settings. Relationship context indicates this mitigation is relevant to Android and iOS techniques including Internet Connection Discovery and Adversary-in-the-Middle, so analysts should pay attention to traffic that exposes connectivity checks, routing behavior, or sensitive app communications.
Likely telemetry
- Mobile application configuration files and build settings related to transport security
- iOS App Transport Security configuration and exception records
- Android Network Security Configuration files and cleartext traffic settings
- Mobile application network traffic captures from controlled testing
- API gateway, web server, and TLS termination logs showing protocol and certificate use
Detection direction
- Because official ATT&CK detection is not provided, focus on assurance testing and control validation rather than claiming behavioral detection coverage.
- Test whether mobile apps transmit any sensitive data over unencrypted channels or allow downgrade/exception paths.
- Review ATS and Android Network Security Configuration exceptions for business justification and expiration or compensating controls.
- Use controlled network observation to confirm TLS protects application traffic and to identify unexpected cleartext endpoints.
- Tune SOC expectations carefully: encrypted traffic may reduce content visibility, so coverage may depend on metadata, endpoint telemetry, server logs, and mobile app security testing rather than packet payload inspection.
Mitigation priorities
- Require TLS for mobile application network traffic by default.
- Use platform-supported controls such as iOS App Transport Security and Android Network Security Configuration where applicable.
- Document and risk-review any transport security exceptions, especially cleartext traffic or legacy endpoints.
- Consider message-level encryption for sensitive data before TLS when the application risk model requires additional protection.
- Use VPN tunnels, such as IPsec-based approaches, where they appropriately reduce network attack exposure, while recognizing they do not replace secure application transport.
Additional notes and limits
This is a course-of-action object, not an adversary technique. Its value is as a control validation anchor for mobile application security programs. The supplied relationships show mitigation relevance to Internet Connection Discovery and Adversary-in-the-Middle in the mobile domain, with related platforms Android and iOS. Local app architecture, API design, certificate handling, and exception usage determine the real risk reduction.
ATT&CK provides no official detection text, no tactics, and no platforms directly on the mitigation object. The object supports general mobile application transport encryption guidance but does not prove any organization has coverage, exposure, exploitation, or compliance. Environment-specific testing is required.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Encrypt Network Traffic
Application developers should encrypt all of their application network traffic using the Transport Layer Security (TLS) protocol to ensure protection of sensitive data and deter network-based attacks. If desired, application developers could perform message-based encryption of data before passing it for TLS encryption.
iOS's App Transport Security feature can be used to help ensure that all application network traffic is appropriately protected. Apple intends to mandate use of App Transport Security [1] for all apps in the Apple App Store unless appropriate justification is given.
Android's Network Security Configuration feature similarly can be used by app developers to help ensure that all of their application network traffic is appropriately protected [2].
Use of Virtual Private Network (VPN) tunnels, e.g. using the IPsec protocol, can help mitigate some types of network attacks as well.
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 |
|---|---|---|---|
| Mobile | T1638 | Adversary-in-the-Middle | Applications that properly encrypt network traffic may evade some forms of AiTM behavior. |
| Mobile | T1422.001 | Internet Connection DiscoverySub-technique | Ensure that traffic is encrypted to reduce adversaries’ ability to intercept, decrypt and manipulate traffic. |
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 | 73a622a36c5e… |
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]TechCrunch-ATS
Kate Conger. (2016, June 14). Apple will require HTTPS connections for iOS apps by the end of 2016. Retrieved December 19, 2016.
Open source URL - [2]Android-NetworkSecurityConfig
Google. (n.d.). Network Security Configuration. Retrieved December 19, 2016.
Open source URL - [3]Android-NetworkSecurityConfig
Google. (n.d.). Network Security Configuration. Retrieved December 19, 2016.
Open source URL - [4]TechCrunch-ATS
Kate Conger. (2016, June 14). Apple will require HTTPS connections for iOS apps by the end of 2016. Retrieved December 19, 2016.
Open source URL - [5]mitre-attackM1009Open source URL
- [6]mitre-attackM1009Open 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.