The Breach Nobody’s Talking About Enough
Last December, the U.S. government confirmed what security researchers had been tracking for months: Salt Typhoon, a Chinese state-sponsored operation, had successfully compromised at least nine major telecommunications carriers including AT&T and Verizon. We’re not talking about a limited intrusion. The scope here is staggering. Over 1 million individuals had their metadata accessed, and the attackers maintained persistent access to critical telecom infrastructure. This wasn’t a smash-and-grab operation. This was a sustained, patient campaign designed to maintain footholds in systems that underpin American communications.
What makes this different from most breach announcements is the infrastructure involved. These weren’t consumer-facing databases getting ransomed by opportunistic actors. These were the backbone systems that route voice calls, manage authentication tokens, and log communications metadata across the country. If you ship APIs, if you build distributed systems, if you use standard authentication flows, you need to understand that the telecom layer beneath your applications was compromised and, frankly, may still be compromised.
The SMS Problem You Can’t Ignore Anymore
In January 2026, CISA updated their guidance on telecommunications security. The recommendation was direct: stop relying on SMS-based two-factor authentication flows. Deprecate SS7-dependent authentication mechanisms. This isn’t a suggestion. This is now embedded in federal guidance, and it’s cascading through enterprise security teams who set the compliance requirements that your customers care about.
Here’s why this matters for you specifically. Millions of applications still use SMS as the delivery mechanism for second factors. It’s simple, it works, and it’s been the path of least resistance for a decade. But SMS travels through the same telecom infrastructure that Salt Typhoon compromised. The attack surface is real. An adversary with persistent access to telecom metadata and call routing systems can intercept SMS messages, manipulate delivery, or combine that data with other attack vectors. You probably have users relying on SMS 2FA right now. In 2026, that’s becoming a liability.
The replacement isn’t theoretical anymore. Enterprise clients are mandating passkey support, push-based authenticators, and hardware security keys. If your API still treats SMS as a primary authentication factor, you’re going to face friction from the organizations you should be targeting. The timeline isn’t distant. It’s now.
Unpatched Edge Devices Are Still the Weak Link
A Mandiant report from February 2026 provided tactical clarity on how Salt Typhoon maintained persistence. The culprit: unpatched edge devices. Specifically, Cisco IOS XE and Fortinet FortiGate appliances were the most commonly exploited initial access vectors. These aren’t obscure targets. They’re the firewalls, VPN concentrators, and gateway devices that connect private networks to the internet. They’re everywhere.
The pattern is familiar to anyone who’s worked in infrastructure. Devices get deployed, they work, and then they become invisible. Patching cycles slip. Critical updates lag because production teams fear disruption. Then adversaries exploit the known vulnerabilities for months or years before detection. Salt Typhoon understood this psychology and exploited it methodically.
The implication for API developers is indirect but real. If your APIs connect to customer networks, if you operate infrastructure that touches enterprise systems, you need to audit what’s happening at the perimeter. You need to know if your partners, your ISPs, or the carriers handling your traffic are running unpatched edge devices. This isn’t something you can delegate entirely to security ops. You need visibility. Ask questions. Include device patch status in your threat modeling.
Post-Quantum Cryptography Is Moving from Research to Requirement
NIST finalized their post-quantum cryptography standards in August 2024. By early 2026, these standards were cited in at least fourteen state and federal procurement requirements. This is the point where cryptographic agility stops being an academic discussion and becomes a compliance checkbox.
Here’s what that means for your API development timeline. If you’re shipping APIs to federal agencies, government contractors, or enterprises subject to these new procurement rules, you need to plan a migration from traditional RSA and elliptic curve cryptography to post-quantum resistant algorithms. This isn’t optional in 2026. It’s contractual. The migration path isn’t trivial either. Your keys need to rotate. Your certificates need to update. Your API consumers need compatible libraries. You have runway to plan this, but you don’t have runway to delay.
The good news is that tools and libraries exist now. The bad news is that most teams haven’t started thinking about it. If you wait until a contract requires it, you’ll be scrambling. Start the planning now. Assess which cryptographic operations in your systems need updating. Test the available implementations. Build a timeline. You’ll be ahead of the rush.
The Passkey Momentum Is Real and Accelerating
Between Q1 2025 and Q1 2026, the FIDO Alliance reported a 210% increase in passkey adoption among top-1000 websites. That’s not gradual improvement. That’s acceleration. Enterprise security teams, reacting to the telecom breach disclosures, are mandating passkey support from their vendors and service providers. That’s a market force that’s hard to ignore.
Passkeys solve multiple problems at once. They eliminate SMS dependency. They reduce phishing risk. They work across devices without requiring users to manage passwords. From a developer perspective, the FIDO2 spec is mature. The implementation libraries are solid. The user experience, while still improving, is no longer a blocker. The friction now is organizational. Teams need to commit to the work, test thoroughly, and communicate the changes to users.
If you haven’t started offering passkey authentication to your API consumers, 2026 is the year to move it from backlog to sprint. You don’t need to deprecate passwords immediately. But you need to support passkeys alongside them. Enterprise security teams are making this a selection criterion for vendors. If your API doesn’t support passkeys, you’re already losing deals to competitors who do.
What This Means for Your Roadmap
Salt Typhoon’s presence in U.S. telecom infrastructure isn’t a past event. It’s a persistent condition that shapes the security requirements of 2026 and beyond. The guidance is clear now. CISA guidance on People’s Republic of China telecom intrusions is specific. Deprecate SMS-dependent authentication. Support end-to-end encryption. Monitor your supply chain.
Tactically, this means your 2026 development priorities should include passkey implementation, an audit of edge device patching across your infrastructure and your partners’, and scoping of post-quantum cryptography migration. The NIST post-quantum cryptography standards give you a clear target. The market shift toward passkeys is already visible. The infrastructure vulnerabilities are documented.
You don’t need to panic. You do need to prioritize. Start with the easiest win: add passkey support to your authentication flows. Then audit your cryptographic dependencies and plan the post-quantum migration. Then work with your infrastructure team to ensure edge devices are patched and monitored. These are concrete actions. They’re defensible. They move the needle on security posture in 2026. If you’ve already started, good. Keep pushing. If you haven’t, now is the time. What’s your current blocker on passkey adoption? What questions do you have about post-quantum migration? I’m listening.