The Breach Is Older Than Most of Your Deployment Pipelines
Let’s start with the timeline. In December 2024, U.S. government agencies confirmed what had been quietly suspected: Salt Typhoon, a Chinese state-sponsored threat group, had compromised at least nine major telecommunications providers. We’re talking AT&T, Verizon, and their peers. The attackers harvested metadata on over a million individuals. That’s not a security incident. That’s a systemic failure at scale, and it’s still happening.
The reason I’m writing this now, in early 2026, isn’t because the breach is fresh. It’s because most developers haven’t actually changed anything. You’re still shipping the same authentication patterns. You’re still trusting the same carrier infrastructure. And Salt Typhoon is still inside those networks. Mandiant confirmed in February 2026 that the group maintains persistent access through unpatched edge devices, primarily Cisco IOS XE and Fortinet FortiGate appliances. These aren’t obscure systems. These are the boxes that sit between your API and the internet.
SMS-Based 2FA Is Now Officially Deprecated, But Nobody Told Your Users
In January 2026, CISA published updated guidance with teeth. They recommended deprecating SMS-dependent authentication flows. Not “consider moving away from.” Not “SMS is suboptimal.” Deprecating. This matters because roughly half the APIs shipping today still treat SMS as a legitimate second factor. Your user gets a six-digit code. Your app validates it. Everyone feels secure. Everyone is wrong.
CISA’s reasoning is straightforward: telecom infrastructure can be compromised at the carrier level. Salt Typhoon proved this. If an attacker controls the network backbone, SMS isn’t authentication. It’s theater. They intercept the message before your user ever sees it. The guidance recommends end-to-end encrypted communications instead, which means moving to authenticator apps, push notifications routed through your own backend, or FIDO-compliant hardware keys. For most shops, this is a six-to-eighteen-month migration. You should have started last quarter.
The brutal part? Your compliance framework probably hasn’t updated yet. You’re still passing security audits with SMS 2FA. Your insurance policy still covers it. Your SOC still monitors for the wrong attacks. The gap between what regulators know is broken and what your procurement team has actually updated is a canyon. That canyon is where attackers live.
Passkeys Aren’t Hype Anymore. They’re Infrastructure.
Between Q1 2025 and Q1 2026, passkey adoption among top-1000 websites jumped 210 percent. This acceleration happened for one reason: enterprise security teams looked at the Salt Typhoon disclosure, looked at their own SMS 2FA implementations, and started sweating. They demanded passkey support. Vendors shipped it. Developers implemented it. The whole landscape shifted inside twelve months.
This isn’t optional anymore. If you’re building APIs that serve enterprise customers, passkey support needs to be in your roadmap before Q2. The conversation with your CISO isn’t “should we support passkeys.” It’s “when will we require them.” Your API design needs to account for FIDO2 attestation flows. Your token lifecycle needs to support asymmetric key rotation. Your audit logs need to track which authenticator performed which action. This is foundational work that touches authentication, identity, audit, and network layers. You can’t retrofit this in two weeks.
The other shift: end users are starting to expect this. They’re not asking permission anymore. They check whether you support passkeys the way they used to check for social login. Your user experience is now competing on authentication security as a feature. Ignore this and you’re shipping an inferior product.
Post-Quantum Migration Isn’t 2030. It’s Contractual Now.
NIST finalized post-quantum cryptography standards in August 2024. That’s not a research milestone. That’s a finish line. By Q1 2026, at least fourteen state and federal procurement requirements explicitly mandate that new APIs support post-quantum algorithms. No exemptions. No “legacy systems” carve-outs. If you want government contracts, financial sector partnerships, or healthcare integrations, you need a migration timeline.
I’ve talked to API teams who read this and think, “our keys are only 256-bit anyway, so we’re fine.” Stop. The threat model isn’t current eavesdropping. The threat model is “harvest now, decrypt later.” Attackers are already collecting encrypted traffic assuming quantum computers will exist before current keys retire. Your TLS handshake. Your API tokens. Your database encryption. All of it is being copied to storage facilities right now, waiting for decryption hardware. The NIST post-quantum cryptography standards exist to make this harvest worthless.
The practical work is manageable if you start now. You need to audit where cryptographic operations happen in your stack. Certificate authorities need to support hybrid certificates that include both classical and post-quantum algorithms. Your dependency trees need updates. Your compliance team needs new testing procedures. This is eighteen to thirty-six months of work, depending on system complexity. If you wait until Q4 2026, you’ll be firefighting procurement deadlines while trying to maintain production reliability. Bad position.
The Actual Risk Isn’t Salt Typhoon. It’s Your Organization.
Salt Typhoon is a symptom. The real problem is that critical infrastructure operators don’t deploy security patches. The CISA guidance on People’s Republic of China telecom intrusions is comprehensive and specific. It names vulnerable products. It lists mitigations. Carriers had three months to act. Many didn’t. Now we’re shipping APIs on top of infrastructure that’s been compromised for over a year.
What does this mean for your team? It means you can’t trust the network to be secure. You can’t trust SMS to be private. You can’t trust yesterday’s encryption to protect today’s data. You need to assume your infrastructure is already compromised and design accordingly. Defense in depth. Multiple authentication factors that don’t depend on carrier networks. Encryption layers that survive quantum computers. Audit trails you can actually trust because they’re not stored on the compromised systems.
The developers I respect most aren’t the ones who shipped the fastest. They’re the ones who shipped defensible systems despite uncertain infrastructure. That’s what 2026 demands. What does your authentication architecture look like when you assume the carrier can’t be trusted? What does your encryption strategy look like when you assume current keys might be exposed in five years? Start answering those questions now. Your users deserve infrastructure built on evidence, not hopes.