M1020 SSL/TLS Inspection: Where Decryption Helps Against C2 and What It Breaks

Most command and control now travels inside TLS, so a network sensor that cannot see inside the session sees only a destination and a byte count. MITRE ATT&CK's M1020 SSL/TLS Inspection is the mitigation for that blind spot: decrypt, inspect and re-encrypt traffic at a choke point. In ATT&CK v20 it maps to just four entries, all in Command and Control, which makes it one of the narrowest Enterprise mitigations and one of the most expensive to run. This guide looks at M1020 from the ATT&CK side: what it actually mitigates, what it does not, how to scope it so it pays for itself, and the exceptions that matter for pinned applications, privacy and non-human identity traffic. It is for detection engineers, network security architects and SOC leads. The mechanics of building an inspection deployment are in the TLS Inspection Guide; this page does not repeat them.

Key takeaways

• M1020 is a visibility enabler, not a blocker. D3FEND models it as an infrastructure dependency that supports D3-NTA Network Traffic Analysis; the mitigation value comes from the detection and prevention tools that read the decrypted stream.
• Four ATT&CK entries, all command and control. T1090 Proxy, T1090.004 Domain Fronting, T1573 Encrypted Channel and T1573.002 Asymmetric Cryptography.
• Domain fronting is where it is uniquely useful. Fronting hides the real destination in the HTTP Host header inside TLS, and M1020 is the only mitigation ATT&CK v20 lists for T1090.004.
• Exceptions are part of the design. MITRE itself says to avoid decrypting sensitive or privacy-related traffic such as financial and healthcare sites; pinned apps and mutual TLS workloads also need documented bypasses.
• The inspection platform becomes a crown jewel. Its interception CA key can mint trusted certificates for any site, and its decrypted logs can hold tokens and credentials of human and non-human identities.

What M1020 is in ATT&CK v20

MITRE describes SSL/TLS inspection as decrypting encrypted traffic to examine it for signs of malicious activity, then re-encrypting and forwarding it. The mitigation page lists six measures:

• Deploy inspection at choke points: appliances or services placed where coverage is greatest.
• Configure decryption policies: rules by application, port or domain, and avoid decrypting sensitive or privacy-related traffic such as financial or healthcare websites to comply with regulations.
• Integrate threat intelligence: correlate inspected traffic with known indicators of compromise.
• Integrate with security tools: feed decrypted traffic to SIEM and NDR tools for alerting.
• Manage certificates: use trusted internal or third-party certificates for re-encryption and keep certificate authorities up to date.
• Monitor and tune: review inspection logs and adjust policies to reduce false positives.

In the D3FEND ontology the M1020 entry carries the comment that D3FEND models it as an infrastructure dependency to support D3-NTA, which D3FEND defines as analysing intercepted or summarised network traffic to detect unauthorised activity. That framing is the right one for planning: budget M1020 as an enabler for detection, not as a control in its own right.

Techniques M1020 mitigates

The co-mitigation column is the key planning point. For T1573, ATT&CK's other mitigation is M1031, whose signatures only work on content they can see; inspection is what makes those signatures useful against TLS-wrapped command and control. For T1090.004, ATT&CK v20 lists no alternative, because the fronted destination sits inside the encrypted HTTP layer. ATT&CK describes domain fronting as using different domain names in the TLS SNI field and the HTTP Host header, so that a CDN serving both routes to the hidden one.

Adjacent techniques that benefit without being mapped

Decrypted web traffic also gives content-level visibility for techniques ATT&CK does not map to M1020, such as T1071 Application Layer Protocol (T1071.001 Web Protocols), T1102 Web Service, T1105 Ingress Tool Transfer, T1567 Exfiltration Over Web Service and T1572 Protocol Tunneling over HTTPS. Treat this as an NHI Mgmt Group observation for coverage planning, not as ATT&CK's mapping: report it separately so your coverage numbers stay honest.

Where to inspect, and where not to

Scope is the decision that decides whether M1020 is worth its cost. An NHI Mgmt Group recommendation is to plan by traffic class:

Two protocol changes narrow what a passive or SNI-based approach can see. RFC 9849 TLS Encrypted Client Hello (Proposed Standard, March 2026) encrypts the inner ClientHello so the real server name is hidden behind a public name; the RFC notes that managed enterprises may choose to disable ECH by group policy, and that a proxy not authoritative for the public name cannot forge a signal to disable it. QUIC carries TLS over UDP, so inspection designs usually block UDP 443 egress or disable QUIC by browser policy so traffic falls back to TCP. The TLS Inspection Guide covers both in depth.

Small and large organisations

A small organisation will usually get M1020 through a cloud secure web gateway or firewall subscription with category-based decryption and a vendor-maintained bypass list; the key work is a short, documented exception list and protecting the gateway's CA. A large organisation may run several inspection points; NSA's advisory on managing TLS inspection risk recommends breaking and inspecting TLS only once in the enterprise, so map every inspection point and remove double inspection. Both need legal sign-off on what is decrypted and who can read it.

Where non-human identities fit

TLS inspection touches non-human identities in three ways, all NHI Mgmt Group recommendations rather than ATT&CK text:

• The interception CA is a machine identity of the highest value: its private key, trusted by every managed device, can impersonate any site to your users. Keep it in an HSM or the platform's key store, restrict and log access, and give it a rotation and revocation plan. See the Enterprise PKI Design and CA Hierarchy Guide.
• Decrypted traffic contains workload credentials: bearer tokens, API keys in headers and OAuth codes pass through the inspection point in clear text. Do not log full headers or bodies by default; mask authorisation headers; restrict who can run packet captures on decrypted streams.
• Workload and agent egress needs its own policy: CI/CD runners, service accounts and AI agents call a predictable set of APIs. Destination allow-listing, with inspection where mTLS is not used, catches stolen tokens being used from inside or data sent to an unexpected endpoint. See the Agent Egress Control and Network Isolation Guide and Cloud Egress Filtering.

Implementing M1020 as a mitigation

1. Define the detection goals first: list the analytics that need decrypted content (domain fronting checks, IPS signatures for known command and control protocols, file inspection), so that inspection scope follows detection value.
2. Inventory existing inspection points: firewalls, proxies, secure web gateways and cloud gateways that already decrypt, to avoid double inspection.
3. Deploy the trust anchor: distribute the interception CA certificate to managed devices only, through device management, and keep a separate CA per environment.
4. Pilot in monitor mode: decrypt for a pilot user group and server segment, log breakage, and build the bypass list from what fails.
5. Enable detections on the decrypted stream: SNI and Host header mismatch for T1090.004, IPS signatures for T1573, file analysis for downloads.
6. Expand in rings: extend by department and server segment, reviewing breakage and privacy exceptions at each ring.
7. Roll back cleanly: keep a policy toggle that returns a ring to bypass without removing the CA, so an outage can be reversed in minutes.
8. Review exceptions every quarter: every bypass needs an owner, a reason and an expiry date.

What M1020 does not stop

• Custom encryption inside TLS: ATT&CK's T1573 covers adversaries using their own encryption rather than relying on the protocol. If the payload is encrypted again inside the TLS session, inspection only reveals another layer of ciphertext; detection then relies on behaviour such as beacon timing, destination rarity and volume.
• Traffic that bypasses the choke point: devices off the corporate network, unmanaged devices, direct cloud egress and alternative protocols such as DNS tunnelling are outside its view.
• Bypassed categories: anything on the exception list is uninspected; attackers who use a trusted, bypassed service as infrastructure stay hidden.
• Pinned and mTLS channels: malware that pins its own certificate fails under inspection, which is visible as a failed connection, but its content stays hidden.
• Endpoint compromise: once code runs on a host, inspection only sees what leaves it; host controls and EDR carry the rest.

Detection and measurement

Metrics that show M1020 is earning its place:

• Decryption coverage: percentage of outbound TLS sessions decrypted, by user and server segment, against the scope you set.
• Detection yield: number of true positive alerts per month that needed decrypted content to fire.
• Exception hygiene: share of bypass entries with an owner and an unexpired review date.
• Breakage rate: help-desk tickets per month attributed to inspection, trending down after each ring.
• Double inspection: number of traffic paths decrypted more than once, which should be zero.
• CA key access: number of people and systems with access to the interception CA key, reviewed quarterly.

Common failure patterns

• Decrypting without detections: buying inspection capacity but sending the decrypted stream nowhere that alerts, so the cost buys nothing against T1573.
• Weak upstream validation: an inspection point that accepts invalid or self-signed upstream certificates hides man-in-the-middle attacks from users, who only see the trusted interception certificate. See MITRE ATT&CK T1557 Adversary-in-the-Middle.
• Unprotected interception CA: the CA key exported to many appliances or stored without access logging.
• Logging secrets: full request headers stored in the SIEM, exposing bearer tokens and API keys of service accounts.
• Permanent exceptions: bypass lists that only grow, eventually covering the services attackers favour.
• Ignoring server egress: inspecting user browsing while servers and build agents reach the internet directly.

Framework mapping

Related mitigations: M1031 Network Intrusion Prevention, which reads the decrypted stream, and M1037 Filter Network Traffic, which controls destinations without decryption.

Practitioner checklist

• List the detections that need decrypted content before setting inspection scope.
• Map every existing inspection point and remove double decryption.
• Bypass privacy-sensitive categories, pinned applications and mutual TLS workloads, each with an owner and review date.
• Keep the interception CA key in an HSM or protected key store, with logged and reviewed access.
• Mask authorisation headers and tokens in inspection logs.
• Enable SNI and Host header mismatch detection and IPS signatures on decrypted traffic.
• Decide your ECH and QUIC policy for managed devices and document it.
• Apply destination allow-lists to server, CI/CD and AI agent egress.
• Roll out in rings with a one-step rollback to bypass.

Standards and references

• MITRE ATT&CK: M1020 SSL/TLS Inspection
• MITRE ATT&CK: T1090.004 Domain Fronting
• MITRE ATT&CK: T1573 Encrypted Channel
• MITRE D3FEND: Network Traffic Analysis
• CISA: NSA Releases Cyber Advisory on Managing Risk from Transport Layer Security Inspection
• IETF: RFC 9849 TLS Encrypted Client Hello
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: TLS Inspection Guide · Certificate Pinning · T1090 Proxy Defensive Guide · Agent Egress Control and Network Isolation Guide · How TLS Works Guide