The Breach That Changed Everything (And Probably Your Threat Model)
Last December, the U.S. government confirmed what security researchers had been muttering about in Slack channels for months: Chinese state-sponsored actors had successfully compromised at least nine major American telecommunications companies. We’re talking AT&T, Verizon, and others. The attackers didn’t just peek at the network topology—they accessed metadata on over a million individuals and maintained persistence that’s still being rooted out as of now. This wasn’t a smash-and-grab operation. This was a patient, methodical campaign designed to give an adversary long-term surveillance capabilities embedded in core telecom infrastructure.
If you’re building APIs in 2026, this matters to you directly. Your authentication flows, your customer notifications, your incident response procedures—they all sit downstream from infrastructure that’s currently being actively exploited. The good news? This is exactly the kind of problem that gives us permission to build things the right way. The kind where “we’ve always done it this way” stops being an acceptable answer.
Why SMS 2FA Is Now a Liability (Not a Feature)
Here’s where it gets tangible. CISA released updated security guidance in January 2026 that essentially says: stop relying on SMS-based two-factor authentication. Move to end-to-end encrypted communications for sensitive authentication flows. This directly impacts millions of applications that treat SMS as the default second factor, which, if we’re being honest, is most applications built in the last decade.
The problem is architectural. SMS travels through the same telecom infrastructure that Salt Typhoon has been exploring. If an attacker can access telecom metadata and maintain persistence on carrier networks, they can intercept SMS messages. They can see which OTP codes are being sent to which numbers. Your 2FA mechanism, built to protect users, becomes a potential attack vector. The vulnerability isn’t in your application code—it’s in the infrastructure layer below you. That’s both terrifying and clarifying.
So what do you do? You migrate away from SMS. This isn’t a suggestion anymore. It’s a requirement with a deadline. And the replacement technologies are genuinely better. Passkeys, hardware tokens, push-based authentication—these aren’t experimental anymore. CISA guidance on People’s Republic of China telecom intrusions makes it explicit. The path forward is away from SMS, period.
The Real Vector: Unpatched Edge Devices Still Matter Most
A Mandiant report from February 2026 added important context to the Salt Typhoon picture. The sustained presence wasn’t some magical zero-day exploit. It was unpatched edge devices. Specifically, Cisco IOS XE and Fortinet FortiGate appliances that hadn’t been updated, despite patches being available for months. This is the kind of detail that either makes you groan or makes you nod with recognition, depending on how many internal alerts you’ve escalated that got caught in the procurement backlog.
This has a direct implication for how you think about your API infrastructure. Your application code is probably reasonably well patched. Your cloud environment probably gets security updates pushed regularly. But what about the firewalls, load balancers, and edge devices sitting between your APIs and the public internet? What about the devices at your cloud provider’s edge that your traffic flows through? Those edge systems are the current attack surface. That’s where persistence is being established.
If you’re shipping APIs in 2026, you need to understand your infrastructure dependencies. You need to know what devices are between your code and users, and you need a realistic patch management timeline for all of them. This isn’t theoretical risk management. The attackers are literally still there.
Passkeys Are Winning (And That’s Your New Normal)
Here’s a number that should make you sit up: passkey adoption among the top 1000 websites grew 210 percent between Q1 2025 and Q1 2026. Most of that growth is being driven by enterprise security teams responding directly to the telecom breaches. They looked at the threat landscape, looked at their user authentication methods, and made a decision. The FIDO Alliance reported this surge, and it’s not slowing down.
What does this mean for you as an API developer? Passkeys are no longer a nice-to-have security feature. They’re becoming the baseline expectation. Users are getting more comfortable with them. Platform support keeps improving. If your API still requires SMS 2FA and you haven’t started planning a passkey migration, you’re swimming against the current, and not just for security reasons. The user experience argument is real too.
The good news is that implementing passkey support is actually straightforward. The FIDO2 standard is stable. Libraries exist in every major language. You don’t need to reinvent anything. You need to understand the basics—public key cryptography, credential registration, assertion verification—and then pick a library that handles the complexity. Start with documentation. Plan your migration path. Test with real users. This is the kind of project that looks daunting until you break it down, then becomes genuinely satisfying to ship.
Post-Quantum Cryptography Is Now a Procurement Requirement
NIST finalized its post-quantum cryptography standards in August 2024. That was over a year ago. Now those standards are showing up in at least fourteen new state and federal procurement requirements taking effect in 2026. If you’re building APIs for government clients, or for companies that serve government clients, or really for anyone tied to federal contracts, you need a post-quantum cryptography migration timeline.
This isn’t about the quantum threat happening tomorrow. This is about cryptographic agility happening today. When your encryption choices get dictated by federal procurement requirements, you need to support new algorithms without rebuilding your entire infrastructure. NIST post-quantum cryptography standards give you specific algorithms to plan around. ML-KEM, ML-DSA, SLH-DSA—these are the names you’ll be seeing in compliance documents.
You probably don’t need to deploy post-quantum algorithms in production right now. But you do need to understand which cryptographic primitives are in your critical path. You need to know where they can be swapped out. You need to start planning migrations that won’t require you to reissue every certificate or rebuild every key exchange mechanism. It’s infrastructure work, but it’s the kind you can plan for systematically in 2026.
Building Forward From Here
The Salt Typhoon breach didn’t create these problems. It revealed them. It made obvious what was always true: infrastructure matters, defaults matter, and the security tools you built five years ago might not be adequate for the threat landscape you’re operating in today. You can fix this incrementally. No complete rewrite required. Just deliberate choices.
Start somewhere. Maybe it’s planning your SMS 2FA migration. Maybe it’s understanding your edge device inventory. Maybe it’s running a pilot passkey implementation with a small user cohort. Pick one thing that feels achievable, then actually do it. Share what you learn. The developers shipping secure APIs right now are the ones making these changes, documenting what works, and helping the rest of us understand the path forward.
What’s on your roadmap for 2026? What friction are you hitting when you try to move these pieces? I’d genuinely like to know what’s blocking you and what solutions you’re finding actually work.