§ IA

Salt Typhoon and the Carrier Trust Collapse: A Defender’s Field Guide

By the time CISA and FBI put their names on the joint statement in November 2024, the Salt Typhoon intrusions into U.S. telecom carriers were already old news to anyone who’d been reading the WSJ reporting. Eighteen months in, the assumption underneath most enterprise threat models, that the carrier transit layer is at worst lossy rather than actively adversarial, is no longer defensible. PRC-aligned actors had access to lawful intercept systems at multiple Tier 1 carriers. They had it long enough to pull call detail records and, in a smaller targeted set, actual content. The official posture, as of mid-2026, is still that the full scope is unknown.

That last part is the operationally relevant sentence.

If your threat model assumes the SMS path is private, the SS7 control plane is friendly, or the carrier’s management network is somebody else’s problem, you are working off a model that doesn’t match the ground. The model hasn’t matched the ground for two years. It does not match the ground today. None of the Tier 1s has, at the time of writing, published a transparent post-remediation statement confirming the completion of eviction or the exact scope of data exfiltration. The sweeping executive order people kept saying was coming on telecom supply chain hardening has stalled out in committee. The readouts that do reach enterprise customers, when they happen, are anodyne to the point of insult.

What’s actually compromised, briefly

Salt Typhoon (Microsoft’s name; also tracked as GhostEmperor, Earth Estries) hit at least nine U.S. carriers per the White House’s December 2024 readout, with confirmed names including Verizon, AT&T and Lumen. The intrusion path the public reporting converges on: compromise of edge and provider-edge routers, persistence on network infrastructure devices, then access to the CALEA lawful intercept infrastructure that carriers are legally required to maintain. The same infrastructure built to give the FBI court-ordered access gave a foreign intelligence service court-ordered-shaped access.

Volt Typhoon is the adjacent story you should be reading in the same breath. Different objective (pre-positioning on U.S. critical infrastructure for disruptive effect rather than collection), overlapping tradecraft on edge devices and living-off-the-land. If you’re an electric utility, water authority, or anything CISA calls Tier 1 critical infrastructure, Volt is your scarier neighbor. If you’re an enterprise whose executives’ phones matter, Salt is.

The framing problem

The press settled on a victim narrative for the carriers somewhere around early 2025 and has not really revisited it. That narrative doesn’t survive a minute with the timeline.

CALEA mandated the lawful intercept architecture in 1994. The carriers have had three decades to harden the path it created. The publicly available guidance for hardening telecom-side management planes has been out there for years. SP 800-53 has covered network infrastructure auditability since Rev 3 (2009). CISA has published telecom infrastructure hardening guidance, repeatedly, in the years before the disclosure. None of the guidance is classified, novel, or expensive. Enterprise customers paying carrier-grade prices for transit had a reasonable expectation that the thing they were buying wasn’t running a privileged management plane built when CALEA was new.

The Tier 1s have collectively published, as of this writing, zero acknowledgements of remediation completion. None has said “we know what got accessed, here is the scope, here is what we changed.” Carrier-issued public statements on Salt Typhoon TTPs have, in aggregate, contained less actionable detail than the CISA advisories they reference. That is a corporate choice. In any other software supply chain context — Equifax, SolarWinds, Okta — the executive team would already be facing multi-state AG action and aggressive SEC scrutiny. The carriers are not, and the only thing distinguishing their situation is the political weight of the FCC’s regulatory codependency and the operational dependence enterprise security teams have on accepting whatever transit posture they get.

That is a defensible call by the FCC. It is also why your threat model has to assume what they will not publicly confirm.

The detection problem nobody wants to say out loud

You are not going to detect Salt Typhoon inside a carrier from your enterprise SIEM. The compromise is upstream of every log source you own. What you can do, and what the December 2024 CISA mobile communications guidance is telling you to do without quite saying it, is reduce the attack surface that the carrier compromise exposes and detect the downstream consequences when a high-value account’s session metadata leaks.

The downstream consequences look like:

  • Targeted phishing or smishing that demonstrates knowledge of who an executive was talking to and when. The content is the giveaway: it’s the metadata, recovered from CDRs.
  • SIM swap attempts on a narrow set of accounts that correlate with people whose communications are interesting to a nation-state collector.
  • Unexplained MFA push prompts on accounts where SMS is still the fallback channel.
  • Account recovery flows triggered through carrier-mediated channels (number port, voicemail PIN reset, carrier-portal logins) on a tighter cluster of identities than random fraud would produce.

None of these are clean detections. All of them get drowned in normal fraud noise. The signal you are hunting for is the clustering on identities of intelligence interest, not the raw event rate.

Concrete hunts that survive contact with a real index

If you run Splunk, start with the identity provider logs, not the network. For Entra ID:

index=azuread sourcetype="azure:signinlogs" "authenticationDetails{}.authenticationMethod"=SMS
| mvexpand userPrincipalName
| search userPrincipalName IN ([| inputlookup high_value_targets.csv | fields userPrincipalName])
| stats count by userPrincipalName, ipAddress, deviceDetail.operatingSystem

Volume is the wrong threshold. The threshold is any non-zero count on the named watchlist. SMS shouldn’t be in the auth path for those identities at all. If the query returns hits, the policy and the configuration aren’t agreeing. Fix the configuration.

The Okta equivalent uses eventType=user.authentication.auth_via_mfa and outcome.reason containing “OTP”. The field shape changed between the 2023 and 2024 schema updates, so check your parser before you trust the dashboard. (The 2024 Okta release notes were clear about it; the current docs bury it.)

For number-port and SIM-swap-shaped events, you need carrier-side telemetry the carrier doesn’t give you cleanly. The workable proxy is your MDM. In Intune, the device compliance event where imei or serialNumber changes against a stable userPrincipalName is the SIM-swap-on-the-corporate-device signal.

Expect low single digits per week of legitimate device refreshes in a 5,000-seat shop. The tuning work in week one is carving out the device-replacement workflow so the on-call SOC analyst stops getting paged at 0300 for HR-provisioned phone swaps.

For the network side, if you operate your own edge — and you should assume the carrier’s edge is hostile, so this matters more than it used to — hunt on configuration-change events on your border routers and VPN concentrators against your change ticketing system. Cisco IOS %SYS-5-CONFIG_I outside an approved change window should be a near-zero rate. On a Fortinet fleet with FortiAnalyzer, the equivalent is logid=”0100032002″ (config change) cross-referenced via a lookup table against your CAB ticket index. The brittle part is a recurring deployment pattern: FortiAnalyzer ingests into Splunk via syslog, the timestamp parser breaks on daylight savings transitions, and the lookup logic falls apart twice a year. Worth checking before you wire an alert to it.

NetFlow on the edge devices themselves is where Volt Typhoon got caught more than once. Long-duration, low-volume sessions from a router’s management interface to an external IP that isn’t your TACACS, syslog, or SNMP collector. The detection is straightforward. The operational cost is not. At carrier scale you’re sampling 1:1000 or worse, and the long-tail flows are exactly what sampling drops. For enterprise edge it’s tractable, but expect a week of tuning to carve out vendor phone-home (Cisco Smart Licensing, Fortinet FortiGuard, Palo Alto update servers, all of which look exactly like the pattern you’re hunting for, which is the joke).

SMS MFA, lawful intercept, and the policy questions you can’t punt

CISA’s December 2024 guidance was unusually direct: stop using SMS for MFA, especially for senior officials and people of intelligence interest. The Bureau’s own director said roughly the same thing in plainer language. If your organization still has SMS as a fallback factor for privileged accounts in 2026, the right output is not a finding write-up. The right output is a remediation plan with a close date this quarter.

FIDO2 hardware keys (YubiKey 5 series, Titan, Feitian) are the right answer for the executive tier. The pushback you’ll get is operational: lost-key recovery, BYOD users who don’t want to carry a key, the VP who refuses. The compromise position most shops land on is phishing-resistant MFA enforced for a defined privileged tier with passkey fallback, and pure number-matching push with no SMS for everyone else. That is a defensible posture. SMS-as-fallback-just-in-case is not.

The harder policy question is what you do about CALEA exposure for sensitive internal communications. Assume the carrier’s voice and SMS path is collected, and route the conversations that actually matter onto end-to-end encrypted transport (Signal, or your enterprise’s vetted equivalent; not Teams, not standard Webex, not WhatsApp for the obvious metadata reasons). This is the part where someone always asks if Signal is FedRAMP’d. It is not. The risk calculus on a board call discussing an acquisition is not the risk calculus on a CUI-bearing system, and the controls you reach for differ accordingly.

Where this lands in 800-53

The control mappings are not exotic. What’s changed is which ones you can no longer treat as inherited from the carrier.

Control What changes post-Salt Typhoon
IA-2(1), IA-2(2) SMS OTP is no longer a defensible second factor for privileged users. Phishing-resistant MFA moves from “strong recommendation” to baseline for the privileged tier.
SC-8, SC-8(1) Transmission confidentiality assumptions over carrier-mediated channels (voice, SMS, MMS) need to be restated explicitly as not provided. End-to-end encryption above the carrier layer becomes the control, not a defense-in-depth bonus.
SC-7, SC-7(8) Boundary protection assumptions need to include the case where the provider-edge router is adversary-controlled. Egress filtering and explicit allowlisting of management-plane destinations matter more.
AU-6, AU-6(4) Audit review correlation now has to include identity-system signals (MFA method used, account recovery channel) joined to threat-intel-driven watchlists.
SR-3, SR-6 Supply chain risk for telecom services is now in scope as an SR finding, not just SA. Whether you can do anything about it is a separate question.
CM-3, CM-6 Configuration change detection on network infrastructure devices is no longer hygiene. It is the primary signal for the post-exploitation activity you actually care about.

The SR-3 finding is the one ISSOs are going to fight with their AOs about. There is no realistic carrier substitute for most organizations, and the compensating-controls conversation is awkward because the compensating controls (E2EE overlays, FIDO2, killing SMS) are the actual fix and live above the carrier layer entirely. Honest paperwork on the SR-3 reads: no compensating control available at the carrier layer; residual accepted at the AO. Most AOs in 2026 will sign that, because the alternative is rejecting an authorization for inability to control something the customer cannot in fact control.

That should feel uncomfortable. It is also probably correct.

What teams get wrong on the first pass

Three patterns are worth naming, though they show up in different combinations depending on the shop.

The most common is the urge to detect Salt Typhoon. You can’t, not from where you’re sitting. The carrier’s SOC might; yours won’t. Stop writing detection content against TTPs you have no visibility into and write detection content against the consequences: credential reuse, SIM swap, executive-targeted phishing that demonstrates metadata knowledge, anomalous account recovery.

The second is the executive-protection framing. The executive tier is the obvious target. But the engineer with production database credentials and SMS as a recovery factor is the more interesting pivot for a patient collector, and FIDO2 rollouts scoped by org chart will miss them every time. Scope by privilege and data sensitivity instead.

The third is the one that keeps coming back in postmortems: disabling SMS MFA without first auditing the account recovery flows. The standard SaaS recovery flow allows password reset via SMS-recoverable email, which means the carrier path comes right back in through the side door. Number-port-out PINs on the carrier portal, voicemail PIN strength, and the SaaS recovery chain all have to move together. Otherwise you’ve hardened the front door and left the back gate on a 2018 default, and yes, vendors that left that default in place still ship it.

The Tier 1s will eventually publish remediation statements. The CALEA architecture will eventually be revisited. Neither of those is this quarter’s work. This quarter’s work is the FIDO2 rollout, the audit of recovery flows, the configuration-change detection on your own edge, and the uncomfortable conversation with the AO. None of it is glamorous. All of it is mandatory.

Sources