The Breach That Won’t Go Away

In December 2024, the U.S. government confirmed what security researchers had been quietly studying for months: Salt Typhoon, a Chinese state-sponsored threat group, had successfully compromised at least nine major U.S. telecommunications providers. We’re talking about AT&T, Verizon, and others that form the backbone of American communications infrastructure. The breach didn’t just expose call logs or billing information. It gave attackers access to metadata spanning over one million individuals. That’s not a contained incident. That’s a persistent structural weakness in systems that billions of people rely on daily.

I’ve been building distributed systems long enough to recognize what this looks like from the inside. You find one vulnerability, you patch it, you move on. Except Salt Typhoon didn’t leave after being discovered. The attackers established footholds deep enough that they’re still there. According to Mandiant’s February 2026 report, ongoing persistence comes directly from unpatched edge devices. Cisco IOS XE and Fortinet FortiGate appliances keep showing up as the initial access vectors. These aren’t exotic zero-days that only nation-states know about. These are known vulnerabilities that vendors have patched. But patches don’t install themselves, and networks this massive operate under real constraints.

The Authentication Reckoning

Here’s where this hits your codebase directly. CISA released updated guidance in January 2026 that formally recommends deprecating authentication flows that depend on SS7, the ancient signaling protocol that powers SMS. If your application sends a one-time code via text message for two-factor authentication, you’re using a system that’s been fundamentally compromised at the network level. The Salt Typhoon breach revealed that attackers with access to telecom infrastructure can intercept SMS traffic. They didn’t need to break your application. They just needed to read the message your application was relying on.

I remember the debates from years past about why SMS-based 2FA was so widespread despite its obvious weaknesses. The answer was practical: SMS reaches every phone, requires no additional software, and works everywhere. But practicality and security exist in tension, and that tension resolved itself the moment attackers could reach into the telecom backbone. The CISA guidance on People’s Republic of China telecom intrusions spells this out plainly. End-to-end encrypted communications. No more SS7 dependencies. This is no longer advisory. This is the direction institutions are moving, and your API surface needs to move with them.

The industry response has been swift. The FIDO Alliance tracked a 210% increase in passkey adoption among the top 1,000 websites between Q1 2025 and Q1 2026. That’s not hype. That’s enterprises and startups both looking at the breach reports and reaching the same conclusion: we need authentication that doesn’t rely on telecommunications infrastructure controlled by someone else. Passkeys work locally. They don’t transit through networks you don’t control. They’re cryptographically bound to specific devices and services.

The Cryptography Question Arriving Early

While you’re rearchitecting authentication, there’s another timeline squeezing down on you. NIST finalized its post-quantum cryptography standards in August 2024. On their own, these are academic accomplishments. Organizations publish standards constantly. But then they get cited in procurement requirements. As of 2026, at least 14 state and federal procurement requirements now mandate post-quantum readiness for contracts involving critical infrastructure, financial systems, or federal agencies. If you’re building APIs for any of those sectors, you’re not planning a migration for 2030. You’re planning one for right now.

The reason this matters isn’t abstract. Current encryption standards rely on the difficulty of factoring large numbers. Quantum computers, if they reach sufficient scale, would make this problem trivial. Your encrypted data doesn’t need to be decrypted today for this to matter. An attacker can capture your encrypted traffic now, store it, and decrypt it later when quantum computers become available. The intelligence value of data captured in 2026 and decrypted in 2035 is real. Governments know this. They’re not waiting.

The NIST post-quantum cryptography standards give you concrete algorithms to migrate toward. But migration timelines for cryptography across distributed systems measure in years, not months. The calculations that protect your customer data, your authentication tokens, and your inter-service communications need to be audited now. You need to understand which cryptographic components you’re using, where they live in your stack, and what the replacement path looks like. This isn’t a year-end project. It starts in your architecture review meetings this quarter.

What You Actually Need to Do

Let me be direct about what this looks like in practice. First, audit your authentication layer. If you’re still accepting SMS for 2FA, understand the timeline for migrating users to a passwordless or hardware-backed solution. This doesn’t mean cutting off SMS overnight and breaking existing deployments. It means starting the migration now, communicating the change clearly, and having a deprecation timeline customers can work with. FIDO2 and passkey infrastructure exists. App-based 2FA exists. Hardware security keys exist. Pick your approach based on your user base, but pick one and start moving.

Second, inventory your cryptography. Know what encryption standards you’re using in transit and at rest. Know which protocols depend on assumptions that quantum computing would invalidate. Work with your infrastructure team to understand your TLS configurations, your key exchange mechanisms, and your long-term data storage encryption. This isn’t a security team problem. It’s an engineering problem that spans backend systems, database layers, and the protocols your APIs use to communicate with clients.

Third, understand the edge devices in your deployment chain. The Salt Typhoon breach persists because of unpatched network equipment. If you’re running Cisco, Fortinet, or similar appliances, you’re not unique. Thousands of organizations run the same hardware, which makes you both vulnerable and a predictable target. Patching cadences matter. Vulnerability monitoring matters. This is infrastructure governance, and it matters at the API level because your APIs sit behind this equipment.

A Decade of Being Reactive

Looking back at the past decade of API security, we’ve largely been reactive. A vulnerability drops, we patch. An attack technique emerges, we add detection. But telecom infrastructure compromises at this scale force something different. They force you to consider that the baseline assumptions your security model rests on might not hold. The phone network isn’t as trustworthy as we assumed. Data persistence isn’t as temporary as we hoped. Future computing capabilities will unravel past encryption work.

This isn’t cause for panic. It’s cause for deliberate action. The organizations moving first on passkeys, on post-quantum planning, and on edge device hygiene aren’t overreacting. They’re seeing what the Salt Typhoon breach actually reveals: security exists in layers, and when one layer fails, the others have to work harder. Your API design decisions in 2026 will determine whether your systems can adapt to these realities or crack when the next structural weakness surfaces.

The work is real. The timeline is real. The stakes are real. What’s your current state, and where does your organization stand on these migrations? I’d be genuinely interested in hearing what you’re seeing in your own infrastructure assessments.