The Year We Stopped Pretending Legacy Systems Were Secure
When the FBI and CISA confirmed in late 2024 that Chinese state-sponsored actors had maintained access inside at least nine major US telecom carriers for over a year, something shifted in how we talk about network security. This wasn’t a theoretical exercise anymore. It wasn’t a breach that affected payment cards or consumer data. These were the pipes. The actual infrastructure that carries voice, data, and every digital communication Americans depend on. The intrusion, attributed to a group tracked as Salt Typhoon, exposed something that engineers like me have known for years but couldn’t quite articulate in ways that moved budgets: our telecom networks had been operating under security assumptions built for a different era.
What made this breach particularly instructive wasn’t just the scale, but the method. According to the CISA Salt Typhoon advisory, the attackers didn’t zero-day their way in. They exploited legacy Simple Network Management Protocol configurations that should have been decommissioned years ago. They found unpatched edge devices from vendors like Cisco and Fortinet that had security updates sitting on shelves. They moved freely because network segmentation didn’t exist where it mattered most. In other words, they won because we let them win.
Understanding What Actually Broke and Why It Matters for Your Next Build
Let’s talk specifics, because that’s where clarity lives. Cisco disclosed in November 2024 that Salt Typhoon actors exploited CVE-2023-20198 in IOS XE, a vulnerability with a perfect 10.0 CVSS score. Here’s the part that should make every engineer uncomfortable: patches existed for over a year before anyone confirmed the exploitation was actually happening in production environments. A year. That gap between patch release and confirmed active exploitation tells you something important about how we’ve been managing network infrastructure. We’ve treated “the patch exists” as equivalent to “we’re secure,” when what we’ve actually been doing is playing roulette with the odds tilted sharply against us.
The attack vectors themselves read like a checklist of architectural decisions from 2003. SNMP running without proper authentication. Out-of-band management interfaces accessible from places they shouldn’t be. Network segments that trusted each other by default. Device firmware that never got updated because the change window was scary. If you’re building network-adjacent systems today, these aren’t abstract concerns. These are the patterns you need to deliberately build against.
A February 2025 Mandiant report on organizations remediating after Salt Typhoon found something sobering: 73 percent of affected carriers needed a complete architectural overhaul of their carrier-grade network management interfaces. This wasn’t patching. This wasn’t running a firmware update and moving on. This was rip-and-replace work. The average remediation cost per carrier exceeded 47 million dollars. That number matters because it’s not just financial. It’s a signal about how fundamentally we underestimated what happens when the foundations crack.
The Federal Mandate That Changes Everything Starting in 2026
Here’s where your work intersects with regulation. In January 2025, the FCC issued new cybersecurity rules under Section 105 of the Communications Act. These rules require telecommunications carriers to submit annual cybersecurity risk management plans. Read that carefully. Not optional security audits. Not advisory guidelines. Mandatory, documented plans reviewed by federal agencies. This is the first FCC mandate of its kind, and it’s not going away.
What this means for engineers building network-adjacent systems is straightforward: the security architecture you’re designing now needs to anticipate audit-readiness in 2026. The systems you’re deploying need to be documentable. Every trust boundary needs to be intentional. Every access point needs to have a reason that can be explained to someone who isn’t an engineer. The vague zones where “we assume the network is trusted” need to become explicit policies.
Visit the FCC cybersecurity rulemaking proceeding if you want to see the actual language. The mandate covers incident response timelines, supply chain risk management, and vulnerability disclosure procedures. These aren’t theoretical frameworks. They’re requirements that will affect how you architect systems, how you test them, and how you hand them over to operations.
Building for 2026: Where to Actually Start
If you’re new to this space or reconsidering how you’ve been building systems, don’t let the scale of the problem paralyze you. The Salt Typhoon breach didn’t happen because engineers were stupid. It happened because the incentives were misaligned and the complexity kept growing faster than our ability to secure it. You can change that in your own work right now.
Start where the vulnerability actually existed: network management interfaces. If your system manages other systems on a network, assume that interface is attractive to attackers. Design it as if it will be exposed. Use strong authentication. Implement mutual TLS. Encrypt everything in motion and at rest. Log comprehensively. The logs aren’t just for compliance. They’re your evidence trail if something goes wrong. This is the foundational layer.
Next, think about segmentation. Every system you build should operate on the principle of least privilege, communicating only with what it actually needs to communicate with. This sounds obvious until you’re on a call with operations and they say “we need device X to be able to reach all of Y for troubleshooting.” That conversation is where security gets negotiated away. Have it early. Document the decision. Make it explicit that you’re accepting a risk because the operational need is real.
Third, and I say this from experience: patch management isn’t a checkbox. It’s an architecture decision. You need to design systems so that patches can actually be applied without causing cascading failures. That means redundancy, gradual rollouts, and testing updates in environments that look like production. The vendors will release patches. The question is whether your system is designed in a way that lets you actually use them.
The Conversation We Should Be Having Now
What Salt Typhoon exposed wasn’t a flaw in engineering capability. It exposed a gap between what we know we should be doing and what we’ve been incentivized to do. Security was treated as an additive layer, something you bolt on when regulators force you to. The FCC mandate is saying that’s not sufficient anymore. And honestly, it shouldn’t have been.
If you’re building systems that touch telecom infrastructure, or any critical infrastructure, the mandate coming in 2026 isn’t a threat. It’s permission. It’s your cover to do the work the right way, the thing you can point to when someone pushes back on building for security rather than just for feature velocity.
The question now is what you’re going to build differently. What architectural patterns are you going to implement? How are you going to design for auditability without making the system brittle? I’d genuinely like to hear what you’re thinking. The work ahead isn’t solved yet, and it needs people who understand both the technical constraints and why those constraints exist in the first place.