Salt Typhoon’s Real Legacy: Why the 2026 Mandates Force Us to Rethink Network Architecture

The Breach That Changed Everything

We need to talk about what actually happened with Salt Typhoon, because the headlines missed the real story. In late 2024, the FBI and CISA confirmed that Chinese state-sponsored actors had compromised at least nine major US telecommunications carriers, including AT&T and Verizon. The persistence was what got my attention. These weren’t quick smash-and-grab operations. In some environments, the attackers maintained access for over a year without detection. That’s not a vulnerability problem. That’s an architecture problem, and it changes everything about how we need to think about network-adjacent systems.

I spent fifteen years building telecom infrastructure before moving to systems architecture, and I can tell you that networks of this scale operate under constraints most of us never encounter in commercial environments. Carrier-grade systems have to remain operational under conditions that would make most enterprise systems administrators panic. But that operational requirement became a vulnerability vector, because the pressure to keep things running meant legacy systems stayed in place far longer than they should have. Salt Typhoon exploited that gap between what needs to run and what should run.

The Technical Reality: Legacy Configurations as Attack Surface

When CISA published its advisory on Salt Typhoon, it was specific about the attack vectors. Legacy SNMP configurations were in the mix. Unpatched edge devices from Cisco and Fortinet were compromised. Network segmentation was either absent or minimal. These aren’t exotic vulnerabilities. These are foundational architecture problems that exist because replacing them requires downtime, capital expenditure, and risk acceptance conversations that take months.

Here’s what makes me slightly combative about this situation. Cisco disclosed in November 2024 that Salt Typhoon actors exploited CVE-2023-20198 in IOS XE, a vulnerability with a CVSS score of 10.0. That score doesn’t require interpretation. It means remote code execution with no authentication required. The patch had been available for over a year before the exploitation was confirmed. A year. In the telecom industry, a year is neither a long time nor an unusual timeline for patch deployment, but when the vulnerability allows an attacker to establish a foothold in your network management infrastructure, it becomes an existential problem.

The CISA Salt Typhoon advisory laid out the technical picture clearly, but what it couldn’t convey in an advisory document was the organizational complexity of fixing these issues. You’re not patching a web server. You’re managing updates across network management systems that sit at the intersection of operational technology and information technology, where a misconfiguration can affect service availability for millions of people.

The Regulatory Response and What It Actually Means

The FCC’s response came faster than I expected. In January 2025, the commission issued new cybersecurity rules under Section 105 of the Communications Act requiring carriers to submit annual cybersecurity risk management plans. This is the first mandate of its kind at this scale, and it matters because it shifts accountability from a technical checkbox exercise to an operational governance model. The FCC isn’t just asking carriers to be more secure. It’s requiring them to document how they’ve assessed risk, what they’ve done about it, and how they’re measuring whether those actions actually reduce risk.

I have skepticism about mandate-driven security, because mandates often create compliance theater without improving outcomes. But the FCC’s approach here has teeth. Annual submission requirements mean that last year’s plan won’t work for this year. There’s no resting on past decisions. The FCC cybersecurity rulemaking proceeding is structured so that carriers have to actively engage with their risk model every twelve months. That’s the part that changes behavior, because behavior is what matters in security.

The mandate itself is specifically shaping how engineers build network-adjacent systems. When you know you’re going to have to document your security architecture annually and defend those decisions to federal regulators, your design choices change. Legacy SNMP isn’t just a technical debt item anymore. It’s a compliance liability. Unpatched edge devices aren’t just a maintenance backlog. They’re a regulatory risk. Network segmentation isn’t nice to have. It’s mandatory. The regulations are forcing architectural honesty.

The Cost of Remediation: What’s Really Happening Right Now

Mandiant released a report in February 2025 analyzing post-Salt Typhoon remediation efforts across affected organizations. The findings were stark. Seventy-three percent of affected organizations required full re-architecture of their carrier-grade network management interfaces. Not updates. Not patches. Re-architecture. Complete redesign of the systems that manage the systems that carry voice, data, and everything else.

The average remediation cost exceeded forty-seven million dollars per carrier. That number should make you uncomfortable, because it represents a systemic failure to maintain infrastructure appropriately. When you need to spend that kind of capital to fix what should have been maintained incrementally, you’re paying a massive penalty. But you’re also getting something that didn’t exist before: systems designed with the assumption that threats are not hypothetical. Network architecture that assumes compromise is possible and contains it. Management interfaces that don’t expose operational control to unauthenticated access.

What’s interesting about these remediation efforts is that they’re not just throwing money at the problem. Engineers are working through the architectural constraints that prevented fixes from being applied earlier. Some of those constraints are technical. Some are operational. Some are financial. Understanding which is which is the only way to build systems that don’t accumulate the same debt again.

Building Forward: What 2026’s Mandates Mean for Engineers

By 2026, the new regulatory requirements will be fully in effect, and carriers will be operating under a different set of constraints. That’s not necessarily bad. Constraints often force better design decisions than we’d make without them. An engineer designing a network management system in 2026 will have to assume from day one that the system needs to be segmentable, patchable, and auditable. Those aren’t optional add-ons anymore. They’re architectural requirements.

The shift also changes staffing and skill requirements. You need people who understand both operational technology and security architecture, who can talk to regulators and operators simultaneously, who can make tradeoffs between availability and security and defend those tradeoffs when challenged. Those people exist, but they’re not abundant, and the industry is going to be competing hard for that talent.

My sense from talking to folks still in carrier environments is that there’s relief mixed with frustration. Relief because the mandate creates cover for investment that should have happened already. Frustration because it took a major breach for those investments to happen. But that’s how infrastructure security has always worked. We react to failures and build stronger systems as a result.

The Salt Typhoon breach wasn’t inevitable, but given the state of telecom network management when it happened, it was predictable. The response to it, these regulatory mandates, the architectural changes, the investment in security, that’s also predictable. What’s less predictable is whether we’ll actually learn from it, or whether we’ll just shift the problem around and wait for the next breach to reveal what we missed. What’s your take on how effectively these mandates will actually move the needle on network security? I’d genuinely like to know what you’re seeing in your corner of the industry.