Threat Intelligence2026-05-128 min read

Salt Typhoon and the Telecom Backbone: Why Application-Layer Encryption Just Became Non-Negotiable

The Salt Typhoon intrusions into major US telecom carriers exposed lawful intercept systems and call metadata at unprecedented scale. The takeaway for software teams: assume the transport layer is hostile.

What Salt Typhoon Exposed

Salt Typhoon, a Chinese state-sponsored cyber espionage group named by Microsoft (with reported activity overlap with the Earth Estries cluster tracked by Trend Micro, though full equivalence between the two is debated in the threat intel community), conducted a multi-year campaign against major US telecommunications carriers. The breach was publicly disclosed in October 2024 by FBI and CISA, with continued investigation through 2025 and into 2026. Carriers identified in public reporting as targeted or compromised include Verizon, AT&T, and Lumen Technologies; T-Mobile reported it was targeted but stated the attempt did not result in material customer data exposure.

The most consequential disclosure was the compromise of CALEA (Communications Assistance for Law Enforcement Act) systems. These are the legally mandated wiretap interfaces that telecom providers maintain for law enforcement requests. By breaching CALEA infrastructure, the attackers gained visibility into which targets US agencies were monitoring, the surveillance logs themselves, and call metadata at scale.

For application security teams, the relevant lesson is not the geopolitical angle. It is the structural one: the network transport layer cannot be assumed to provide confidentiality or integrity at backbone scale. Anything that depends on TLS termination at a network boundary outside your application is now operating in a demonstrably hostile environment.

The TLS-Is-Not-Enough Argument

Standard enterprise architecture terminates TLS at the load balancer or API gateway, then forwards plaintext or re-encrypted traffic to internal services. The trust model assumes the network between the gateway and the application is controlled.

Salt Typhoon's reported TTPs included compromise of Cisco edge routers and persistent access to carrier-level infrastructure. Carrier-level positioning of this kind makes traffic interception and routing manipulation (including at the BGP layer) a plausible capability for an attacker, even if specific BGP-level interception against named victims has not been publicly attributed. In that threat model, "internal network" includes the same fiber and routing infrastructure an attacker may already sit on.

Application-layer encryption is the response. Data is encrypted by the application before it touches the network, and decrypted only by the intended recipient application. Network compromise does not yield plaintext.

Code-Level Implications

The CWEs relevant to this threat model:

CWE-319 (Cleartext Transmission of Sensitive Information): At application boundaries you do not fully control, sensitive data should be encrypted by your code, not just by the transport layer. A request body sent over TLS to a third-party API is still cleartext from the application's perspective.

CWE-311 (Missing Encryption of Sensitive Data): For inter-service communication, mTLS combined with application-layer payload encryption is the dual-layer approach that survives network compromise.

CWE-295 (Improper Certificate Validation): Certificate pinning narrows the trust set so a network-positioned attacker cannot trivially substitute a valid-looking certificate signed by any public CA. Most clients accept any cert signed by any trusted CA, which is itself an attack surface.

CWE-757 (Selection of Less-Secure Algorithm During Negotiation): TLS downgrade attacks remain practical against clients that allow weak cipher negotiation. Pinning minimum versions in code, not just in server config, closes this.

What Application Code Should Look Like

For sensitive payloads, the pattern is application-layer envelope encryption using a key the application controls:

  1. The application encrypts the payload with a data encryption key (DEK).
  2. The DEK is wrapped with a key encryption key (KEK) from a KMS or HSM.
  3. The wrapped DEK and ciphertext travel together.
  4. Only the recipient application with KMS access can unwrap.

This pattern is implemented in AWS KMS envelope encryption, Google Cloud KMS, and HashiCorp Vault transit. The point is that compromise of the network path, the load balancer, or the receiving server's TLS termination does not reveal plaintext. Only KMS access does.

Compliance Mapping

The Salt Typhoon disclosures intersect directly with multiple compliance frameworks:

HIPAA 164.312(e)(1) (Transmission Security): The Security Rule's encryption requirements read differently in light of demonstrated backbone compromise capability. Cleartext ePHI on any "trusted internal network" is increasingly difficult to defend.

PCI-DSS v4.0 Req 4: Cardholder data must be protected during transmission across public networks. v4.0 tightened the requirements but still anchors on transport. Application-layer encryption is becoming a defensible interpretation of "strong cryptography."

CMMC L2 SC.L2-3.13.8 (Cryptographic Protection): CUI in transit requires cryptographic protection. After Salt Typhoon, "in transit" reasonably extends to internal traffic that traverses carrier infrastructure.

FedRAMP SC-8 (Transmission Confidentiality and Integrity): The interpretation that cleartext on internal segments is acceptable is being reconsidered in current PMO guidance.

How Deva Addresses This

Deva's scanner flags transmission patterns that rely solely on transport-layer security for sensitive data. CWE-319 detections include not only literal plaintext sends, but also TLS-only protection for payloads classified as sensitive in code annotations or schema definitions.

For envelope encryption patterns, the scanner verifies that application-layer encryption is applied before transport-layer encryption, and that key wrapping uses approved KMS interfaces rather than hardcoded or environment-variable keys.

The local model is structurally aligned with this threat profile. Source code containing payload schemas, encryption logic, and key material handling never leaves the machine. There is no inference API path between the developer's workstation and an external endpoint for an adversary on the wire to intercept.

PostShare

Matthew Conrad

Threat research, application security analysis, and defensive engineering insights from the DevSecCode team.

Related Articles

Discussion

Loading comments...