Your carrier’s routers belong in your threat model

The week

On June 7, 2022, three US agencies published a document that challenged a comfortable assumption. Most organizations treat their phone and network carrier the way they treat the electricity company: as infrastructure that just works, kept safe by someone else.

The National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA) and the FBI issued a joint cybersecurity advisory on People’s Republic of China state-sponsored cyber actors, catalogued as AA22-158A and revised three days later. It described how they had exploited publicly known flaws in network devices to compromise telecommunications companies and network service providers. These are the firms that run the private connections between a bank’s branches, link a hospital to its clinics, and carry internet traffic for agencies and businesses.

The advisory did not arrive out of nowhere. It cited a run of earlier warnings. An NSA advisory in October 2020 covered publicly known vulnerabilities exploited by Chinese state-sponsored actors. A 2021 NSA overview described the same actors’ observed tactics. CISA’s May 2022 advisory covered weak security controls that attackers routinely exploit for initial access. Two months earlier, in April 2022, the Justice Department had announced the court-authorized disruption of Cyclops Blink, a botnet of firewall and router devices attributed to a Russian military intelligence unit. Edge devices were already in the news. This advisory moved the attention to the carriers behind them.

The flaws were not secret. The advisory’s table listed the network device vulnerabilities these actors had most exploited since 2020, in products from Cisco, Citrix, DrayTek, D-Link, Fortinet, MikroTik, Netgear, Pulse Secure, QNAP and Zyxel. Most allowed remote code execution or authentication bypass. Several dated from 2018 and 2019, and one from 2017. Routers are the traffic directors of a network: boxes that decide where each packet of data goes next. When they are not updated, known holes stay open for years.

The advisory named the tools the actors used to find those holes. RouterSploit and RouterScan are open-source frameworks that identify the make, model and known weaknesses of routers exposed to the internet. Nothing about them required state resources. The skill lay in what came next.

The advisory also described the attackers using compromised small office and home office routers and storage devices as relays to hide their activity. Bouncing traffic through such devices hides where it really came from, and a forgotten router in a dentist’s office could become one link in that chain.

The most instructive passage walked through an intrusion into telecommunications networks. After gaining an initial foothold, the actors identified a critical RADIUS server, the system that checks logins for network equipment. They reached its underlying SQL database with credentials they had obtained and dumped stored credentials, some in cleartext and some hashed.

With those credentials, custom scripts logged in to Cisco and Juniper routers over SSH, ran commands and saved the output, including full router configurations, which were then taken out of the network. Using valid credentials and those configurations, the actors routed, captured and exfiltrated traffic. The advisory included sample commands for setting up tunnels, changing routes and mirroring traffic on Juniper routers.

The actors also covered their tracks. They used standard command-line tools to modify or delete local log files on routers. They used a common utility, PuTTY Link, to build encrypted tunnels from inside the victim networks to servers they had leased elsewhere.

The recommended mitigations were familiar. Patch promptly, and replace end-of-life equipment that the manufacturer no longer supports. Isolate management interfaces (the control panels used to configure devices). Require multi-factor authentication for administrators, so a stolen password alone is not enough to log in. The list went further than many readers noticed. It called for an out-of-band management network, dedicated administrator systems and accounts, segmentation to block lateral movement, and logging and review of network infrastructure access, configuration changes and authentication services.

The advisory did not disclose a new vulnerability. It described a strategy aimed at the companies that carry everyone else’s traffic, and a method that relied on stolen credentials and legitimate commands once the door was open. That is what made it important for every organization that buys network services, as well as for the carriers themselves.

Suppose you run a regional bank. Your branches connect to your data center over a private network your carrier provides. Your firewalls are managed by an outside security firm whose engineers can log in to them at any hour. And your view of what happens between your branch and your data center is, essentially, whatever the carrier tells you. Now suppose the carrier has been compromised. Few of those assumptions survive.

The Cyclops Blink takedown had shown that small edge devices are part of state-actor infrastructure. This advisory pointed one layer further out. The target was the provider: the carrier that runs a bank’s wide area network, the network service provider that connects a health system’s clinics, the managed service provider that operates an agency’s branch firewalls. Those organizations operate inside their customers’ trust boundaries by design. Private circuits are assumed private. Provider engineers have administrative access to customer equipment. And customers usually see little of what happens in the provider’s own network.

An attacker inside a provider inherits all three assumptions. That makes the provider a design consideration for every customer rather than an item on a vendor risk questionnaire. The response has three layers: the transport the provider carries, the administrative access the provider holds, and the visibility the customer keeps for itself.

The article first explains how traffic moves through a provider and why the advisory’s intrusion path matters to customers. It then takes the three layers in turn. It closes with why the work tends to go unowned, and with what prepared customers had in place.

How your traffic actually travels

When a branch office sends data to headquarters, it does not travel down a dedicated wire laid just for you. It moves through equipment the carrier owns and operates, shared with many other customers. A wide area network, or WAN, is the name for the web of connections that links an organization’s sites across a region or country.

Many organizations buy WAN service as private circuits, often using a technology called MPLS. The easiest way to picture MPLS is a postal service that keeps each customer’s mail in separate, labeled bins as it moves through shared sorting centers. Your mail is not mixed with your neighbor’s. But the bins are not locked. Anyone who controls the sorting center can open them.

Technically, the separation lives in the carrier’s routers. Each customer gets its own virtual routing table on the provider’s edge equipment, and labels keep traffic for different customers apart as it crosses the core. Separation of that kind is a configuration. Whoever can change the configuration can change the separation, add a copy of the traffic, or send it somewhere else.

On top of that, many organizations outsource the day-to-day running of their network and security devices to a managed service provider. Those providers use central management systems to log in to hundreds or thousands of customer devices. That is efficient. It also means one compromised management system can be a master key.

Finally, there are the small devices at the edge: routers, VPN gateways and network storage boxes in branch offices, home offices and small businesses. VPN gateways are the secure doors that let remote staff into the internal network. These devices are often installed once and forgotten, which is exactly why attackers like them as relays.

Why carriers are such attractive targets

From an attacker’s point of view, a carrier connects thousands of organizations at once. Breaking into one bank takes effort and yields one bank. Breaking into the company that connects many banks, hospitals and agencies can yield a view of all of them. The advisory’s description fits that logic: get in through known, unpatched flaws in network devices, then hunt for credentials and configurations that open further doors.

Configurations matter more than they sound. A router’s configuration is its instruction sheet: which traffic goes where, who may log in, and which other systems it trusts. Stolen configurations are a map of a network, and sometimes contain passwords. Credentials, the usernames, passwords and keys that prove identity, are the keys that go with that map. Together they let an intruder move unnoticed, using legitimate access rather than noisy break-ins that security tools are designed to catch.

For a customer, this has an uncomfortable implication. An attack on your carrier may never touch your own systems directly, yet still expose your data in transit or hand an attacker the access your provider holds. Your security program can be excellent and still miss it, because the event happens in someone else’s building.

What the intrusion path tells a customer

The advisory’s account of the telecommunications intrusion is worth reading step by step, because each step maps to a customer exposure.

The first prize was the RADIUS server. RADIUS and its cousin TACACS+ are the protocols most networks use to check who may log in to routers, switches and firewalls. One central server answers for hundreds of devices. That design makes administration manageable, and it makes the authentication server the single most valuable system in a network operator’s estate. When the actors dumped its database, they collected the keys to every device that trusted it.

The second step was configuration capture. With valid logins, the scripts did nothing a network engineer would not do on a normal day: connect, run display commands, save the output. No exploit fired. No malware was needed on the router. Intrusion detection tuned to spot attacks sees nothing unusual in an authorized engineer reading a configuration.

The third step was traffic handling. Port mirroring is a standard feature that copies traffic passing through one interface to another, normally so engineers can troubleshoot. Tunnels and routing changes can send that copy, or the original, to a destination of the operator’s choosing. A customer whose circuit runs through a mirrored interface would see no outage and no latency change worth noticing.

The fourth step was cleanup. The actors edited or deleted local router logs. A provider that keeps logs only on the device, or ships them late, loses its own record of what happened. Any customer relying on that provider’s account of events inherits the gap.

Different providers, different exposures

The word “provider” covers several kinds of firm, and the exposure differs by kind. A national carrier operating MPLS and internet transit holds the transport. A regional internet service provider serving rural branches or county offices often runs a smaller, thinner security operation on similar equipment. A managed service provider may own no circuits at all, yet hold administrative credentials for the customer’s firewalls and switches. A managed security service provider may hold the logs. Many customers buy two or three of these roles from one firm, which concentrates every exposure in a single relationship.

The response differs accordingly. Transport risk is handled by encryption the customer controls. Administrative risk is handled by governing the provider’s access. Visibility risk is handled by keeping an independent record. The three sections that follow take them in that order.

The transport: encrypt as if the circuit were public

Many regulated organizations still send sensitive traffic unencrypted over private circuits such as MPLS networks, on the reasonable assumption that the carrier separates customers from each other. That separation is a routing property, not a cryptographic one. If an attacker controls provider routers, traffic on those circuits can be copied or redirected.

Encryption is the fix. It scrambles data so that only the intended recipient, holding the right key, can read it. A copied message is useless gibberish to anyone else. In the postal analogy, it is the difference between an unlocked bin and a locked safe inside the bin.

The architectural answer is to treat every provider link as untrusted and encrypt end to end, between sites and between applications. Practical options include IPsec or encrypted SD-WAN tunnels between branch and data center, TLS for application traffic even inside the corporate network, and encrypted replication for storage and backups. IPsec and SD-WAN tunnels wrap all traffic between two sites in an encrypted envelope. TLS is the same technology that puts the padlock in your web browser, applied to internal applications. Most of this is available in equipment organizations already own.

The two approaches protect different things. Site-to-site tunnels protect everything on the link at once, including old applications that cannot speak TLS, but traffic is in the clear again inside each site. Application-level TLS protects data all the way to the server, including across the data center network, but only for applications that support it. Well-run programs use both: tunnels for breadth, TLS for depth on the most sensitive systems.

The key material matters as much as the cipher. If the managed service provider generates and holds the keys for the customer’s tunnels, a compromise of the provider’s management systems can expose the keys along with the configurations. Customers that want the tunnel to protect them against the provider should hold the keys, or at least control the certificate authority that issues them.

The costs are real but manageable: some throughput overhead, key and certificate management, and troubleshooting that becomes harder when packet contents are no longer visible on the wire. Certificates are the digital ID cards that let systems prove who they are before exchanging encrypted data; they expire and must be renewed, which takes discipline.

Sequencing the work

Sequencing helps. Start with the flows that would do the most harm if copied: payment and core banking traffic, clinical data moving between hospitals and clinics, case records moving between agency offices, and replication to backup sites. Then cover administrative protocols, which carry credentials. Internal traffic with little sensitivity can follow later. A simple register of which links are encrypted, and with what, gives auditors and the board a clear measure of progress.

Administrative protocols deserve their place near the top of that list. Older devices still accept logins over Telnet and older SNMP versions, which send credentials in readable form. On a circuit the carrier controls, those credentials are exposed to anyone who can mirror the port. Moving administration to SSH and SNMPv3, and switching the old protocols off, is cheap and closes a path the advisory described directly.

What the rules ask for, by type of organization

The regulatory pressure differs by sector, and precision matters. For banks, the Interagency Guidelines Establishing Information Security Standards under the Gramm-Leach-Bliley Act list encryption of customer information in transit over networks that unauthorized people may access as a measure to consider. Federally insured credit unions work under NCUA guidelines built on the same model. Neither set treats a carrier’s private circuit as automatically safe.

Nonbank financial firms that fall under the FTC’s Safeguards Rule, such as many fintechs and consumer lenders, face a firmer line. The FTC’s 2021 amendments require encryption of customer information in transit over external networks, unless encryption is infeasible and the program’s qualified individual approves effective alternative controls. Compliance with that provision became due in June 2023.

Broker-dealers and investment advisers have their own obligations under SEC rules, including Regulation S-P. Their recordkeeping rules also shape which encrypted messaging tools they can approve. A firm cannot simply move sensitive conversations to an app that does not capture business communications.

Under HIPAA, transmission security is an addressable implementation specification. Covered entities and business associates must assess whether encryption is reasonable and appropriate, and document the decision if they choose otherwise. A health system that relies on its carrier’s MPLS separation for clinical traffic should expect that documentation to be read closely after any carrier incident.

Federal agencies were already under instruction. OMB memorandum M-22-09, issued in January 2022, set a zero trust strategy for federal agencies. It told them to encrypt DNS requests and HTTP traffic within their environments and to stop relying on network location as a basis for trust. State and local agencies that handle criminal justice information are subject to the FBI’s CJIS Security Policy, which requires that such information be encrypted when it travels outside a physically secure location. A county sheriff’s office sending records over a carrier circuit has a clear answer already.

What encryption does not fix

Encryption protects content. It does not hide who is talking to whom, when, and how much. An attacker inside a carrier can still learn that a bank’s branch sends large volumes to a particular processor at month end, or that a hospital’s clinics connect to a specific cloud service. For most organizations that metadata is far less damaging than content, but for some, such as agencies doing sensitive investigations, it matters.

Encryption also does nothing for availability. A carrier whose routers are controlled by someone else can drop or misroute traffic, encrypted or not. Diverse circuits from different providers, and a tested failover, are the controls for that risk. They belong in the same design review.

Voice and messaging deserve their own line. Calls and text messages carried by carriers are not end-to-end encrypted by default. Executives and staff who handle sensitive matters should use approved, encrypted communication tools, and policies should say which tools are approved for which conversations. Financial institutions must still capture business communications under recordkeeping rules, which shapes which encrypted tools they can approve.

The administrator: provider access is privileged access

Managed network and security services work because provider staff can log in to customer devices. That access is usually broad, persistent and governed by the provider’s own tools and controls. An attacker who compromises the provider’s management systems can reach every customer’s devices at once.

“Privileged access” is the security term for logins that can change how systems work, rather than merely use them. Inside most organizations, privileged accounts are the most tightly controlled of all: few people have them, every use is logged, and multi-factor authentication is mandatory. The principle behind this layer is simple: a provider engineer with access to your firewall is a privileged user, whatever their employer.

How provider access usually works, and where it breaks

In a typical managed service, customer devices are configured to accept logins checked against the provider’s own RADIUS or TACACS+ servers. The provider adds and removes its engineers centrally. The customer often cannot see the list. That is convenient for the provider and exactly the structure the advisory described attackers abusing at the carriers. If the provider’s authentication server falls, every customer device that trusts it falls with it.

The alternative is to make the customer the authority. Provider engineers can be given accounts in the customer’s own identity system, with the customer’s multi-factor authentication. Devices then check logins against the customer’s servers, not the provider’s. The provider still does the work, but the customer decides who may do it and can revoke access in minutes.

Customers should govern provider access the way they govern their own administrators. Contracts can require multi-factor authentication for every provider login to customer equipment, unique named accounts rather than shared credentials, access only from defined management networks, and session logging that the customer can review. They can require notice within a set time of any compromise of the provider’s management environment, whether or not the provider believes customer systems were touched.

Where possible, access should be brokered through a customer-controlled jump host or privileged access tool. A jump host is a single, guarded entry point: provider engineers log in there first, under the customer’s rules and recording, and only then reach the devices. Better tools issue access for a limited window, tied to an approved change ticket, and expire it automatically.

That adds friction for the provider’s engineers, and some providers will price it accordingly. It also means a provider-side compromise does not automatically become a customer-side compromise. For the most critical devices, such as core firewalls and data center routers, some organizations keep administration in house and buy only monitoring from the provider.

Break-glass and the jump host’s own risk

Two design details decide whether this layer holds up under stress. First, every device needs a local emergency account that does not depend on any central server, with its password held in a customer vault and changed after each use. If the customer cuts off the provider during an incident, someone must still be able to log in.

Second, the jump host itself becomes a high-value target and a single point of failure. It needs the same hardening, patching and monitoring as any other privileged system. A poorly kept jump host simply moves the master key from the provider’s building to the customer’s.

Notification: where the rules stop and contracts start

Regulation covers some of this, unevenly. For banks, the federal computer-security incident notification rule, whose compliance date was May 1, 2022, requires a bank to notify its primary federal regulator within 36 hours of certain significant incidents. It also requires bank service providers to notify their bank customers as soon as possible when an incident has materially disrupted, or is reasonably likely to disrupt, covered services for four or more hours.

That trigger is about disruption. A provider whose management systems were silently read, with no outage, may have no notice duty under that rule at all. The contract has to fill the gap, with a duty to report suspected compromise of the systems used to manage customer devices, regardless of service impact.

Other sectors have different instruments. Under HIPAA, a carrier that only transmits data is generally treated as a conduit rather than a business associate, so there may be no business associate agreement with it at all. A managed service provider that administers devices handling protected health information is usually a business associate, and the agreement is the place to set access and notice terms. Contractors with access to criminal justice information must sign the CJIS Security Addendum, which gives agencies a ready hook for access controls. Organizations should ask counsel how each rule applies to their own providers.

The view: keep your own eyes on the boundary

Customers of managed network services often rely on the provider for monitoring as well as operation. If the provider’s environment is compromised, its monitoring is the least reliable source of truth.

Independent visibility does not require duplicating the provider’s operations center. It requires sending logs from customer-premises equipment to the customer’s own security platform: configuration changes, administrative logins, firmware changes and routing changes. Logs are the running diary each device keeps of what happened to it. Firmware is the built-in software that makes the device work. It requires a baseline of normal traffic patterns at key boundaries, so that new destinations or unusual volumes stand out. And it requires periodic verification that device configurations match what the customer expects, compared against a stored known-good copy.

The signals that matter most

A short list catches most of what the advisory described. Administrative logins from unexpected sources or at unexpected times. Configuration changes that do not match an approved change ticket. New tunnels, new mirror sessions or new static routes. Changes to the device’s logging settings, or a gap in its logs. A firmware image whose hash no longer matches the vendor’s published value.

Because the actors in the advisory edited logs on the routers themselves, timing matters. Logs should leave the device as they are written, to a collector the provider cannot alter. A log that sits on the router until a nightly job collects it can be rewritten before anyone reads it.

Flow records add a second, independent view. Most routers and firewalls can export summaries of which addresses talked to which, on which ports, and how much. At the boundary between branch and core, a baseline of those flows makes a new destination or a sudden copy of traffic stand out, without the customer needing to inspect packet contents.

The NSA had already published guidance in 2020 on out-of-band network management, which the advisory cited. A separate management network, used only for administering devices, means administrative traffic and production traffic do not share a path. It also gives the customer a cleaner place to watch who is logging in.

Separation of duties and its cost

The strongest form of this layer separates the operator from the observer. The firm that runs the network should not be the only firm watching it. A large health system or a federal agency may already have its own security operations center and can absorb this easily. A small credit union or a rural county usually cannot.

For smaller organizations, a workable compromise is narrower. Send a handful of high-value signals, such as administrative logins and configuration changes, to a platform the provider does not operate, and have someone review the exceptions weekly. That costs far less than a second operations center. It still means a provider compromise leaves a trail the provider cannot erase.

This layer also covers the edge devices the advisory listed. Organizations should know which of their own routers, VPN gateways and storage appliances are internet-facing, keep them supported, and retire end-of-life units. A compromised customer device is both a door into the customer and a relay for attacks on others.

The three layers reinforce each other. Encryption limits what a compromised carrier can read. Governed access limits what a compromised manager can change. Independent monitoring shortens how long either goes unnoticed. An organization that has only one of the three is betting that the provider is never the target, and the advisory said plainly that it already was.

Why the problem falls between chairs

These controls are not exotic, yet they tend to fall between chairs. Network teams assume the carrier handles security; procurement assumes the contract covers it; the security team may not have visibility of the circuits at all. Leaders should care for concrete reasons.

• Customer data and confidentiality. Payment details, patient records and case files crossing an unencrypted circuit are exposed to anyone who controls the carrier’s routers.
• Regulatory exposure. Regulators expect firms to manage third-party risk. “We assumed the carrier’s network was private” is a weak answer after a breach.
• Concentration of risk. One managed service provider may hold keys to hundreds of customers. Its compromise is your incident, whatever the contract calls it.
• Executive communications. Sensitive conversations over ordinary calls and texts may be readable by whoever controls carrier systems.
• Bargaining power over time. Security terms are easiest to add at renewal. Waiting means living with weaker terms for years.

How the ownership gap forms

Carrier contracts are often long, bought on price and bandwidth, and renewed by a network or telecom manager reporting to infrastructure. Managed security contracts are bought by the security team. Vendor risk management reviews both, but usually through questionnaires about the provider’s own controls, not about how the provider reaches the customer’s devices. Each group sees a slice, and nobody sees the access path end to end.

A practical fix is to name one owner for “provider trust” across all three layers, usually in the security architecture function, with a seat at every network and managed service renewal. That owner keeps the link register, the provider access list and the log coverage report, and reports them together.

The case against, and why it mostly fails

The strongest objection runs like this. Large carriers have substantial security teams. State actors inside a carrier are hunting for intelligence on governments and telecom targets, not for a regional bank’s wire files. Encrypting every circuit, re-papering every managed service contract and building independent monitoring is expensive work aimed at an unlikely scenario.

Parts of that are true. A small organization’s traffic is rarely the target in itself. But the controls are mostly ones the organization should have for other reasons. Encryption in transit is expected under several of the rules above. Named, multi-factor provider accounts are standard privileged access hygiene. Logs that leave the device are basic incident response. The carrier scenario adds urgency to work that was already due, rather than creating new work.

The objection also misses the relay problem. An organization’s own forgotten edge devices can become part of an attacker’s infrastructure regardless of whether its data is interesting. And a provider compromise discovered from a news story still forces an investigation, which is far cheaper when the logs and access records already exist.

Where the objection does hold is in pacing. A small credit union does not need to re-engineer its network in a quarter. It needs a plan that encrypts its most sensitive flows first, fixes provider access at the next renewal, and adds the minimum independent logging it can sustain.

Take a county that runs a dozen offices connected by a carrier’s private network, with firewalls managed by an outside firm. After reading the advisory, its CIO takes three steps over a year. First, the county turns on encrypted tunnels between offices using features already in its firewalls, starting with social services case records and backups. Second, at the managed service renewal, it requires named accounts, multi-factor authentication and recorded sessions through a county-run jump host, plus notice of any compromise of the provider’s management systems. Third, it sends firewall logs to its own security monitoring and keeps known-good copies of configurations. The project costs some staff time and a modest increase in the managed service fee. In return, a carrier or provider compromise no longer gives an attacker easy access to county data.

A health system would follow a similar path with different priorities. Clinical systems that cannot tolerate added latency, such as some imaging transfers, need testing before tunnels go in. Medical devices that cannot be patched often sit behind firewalls the provider manages, which raises the stakes on provider access. And the business associate agreement with the managed service provider is the natural place to add access and notice terms.

What prepared customers had in place

• A register of every network link, showing whether it is encrypted and how.
• Contract terms that treat provider engineers as privileged users, with named accounts, multi-factor authentication, logged sessions and compromise notification.
• A customer-controlled jump host or privileged access tool for the most critical devices.
• Logs from customer-premises equipment flowing to the organization’s own security platform.
• Known-good configuration copies and periodic comparisons.
• An inventory of internet-facing edge devices, with end-of-life units scheduled for replacement.
• A short list of approved encrypted communication tools, consistent with recordkeeping obligations.

The evidence an examiner or auditor asks for

Controls that exist only in a policy rarely survive an examination. Prepared organizations could produce a small, specific set of evidence on request. The link register, with dates and encryption method. The current list of provider accounts, reconciled against the provider’s staff list in the last quarter. Session recordings for a sample of provider logins. A report showing which devices send logs to the customer’s platform, and which do not. The last configuration comparison and any exceptions it found.

Federal banking regulators set out their expectations for third-party relationships in interagency guidance issued in June 2023. It emphasized ongoing monitoring and contract terms over one-time due diligence. The evidence list above is what ongoing monitoring of a network provider looks like on paper.

Metrics worth tracking

A few numbers tell a board whether this is improving. The share of sensitive flows that cross provider links encrypted. The number of provider accounts with access to customer devices, against the number of provider engineers actually assigned. The time it takes, in a test, to revoke all provider access and confirm it is gone. The share of critical devices whose logs reach the customer’s platform within minutes. Each can be measured without new tools, and each moves when the work gets done.

Where customers slip

• Equating private with encrypted. A private circuit keeps traffic separate in normal operation; it does not protect it from someone controlling the carrier’s equipment.
• Relying on questionnaires. An annual vendor survey cannot substitute for technical controls over how provider staff reach your devices.
• Shared provider logins. If five engineers use one account, you cannot tell who did what, or whether it was an engineer at all.
• Outsourcing the only pair of eyes. If the provider both runs and monitors your network, its compromise blinds you.
• Forgetting the small boxes. Old branch routers and storage devices are exactly what the advisory said attackers used as relays.
• Letting the provider hold the keys. Encrypted tunnels whose keys live in the provider’s management system protect against outsiders, not against a compromised provider.

Plan for the day the provider is the incident

Most incident plans assume an attack on the organization itself. Few prepare for the organization learning, from a news story or a government notice, that its carrier or managed service provider has been breached. In that moment, the questions come quickly. The first is whether our traffic is exposed. The next is whether the provider’s engineers, or someone pretending to be them, are still logged in to our firewalls. Then come whether we even have the passwords to run those devices ourselves, and who at the provider will tell us the truth, quickly.

One more preparation is worth making: an incident playbook for provider compromise. It should cover how to cut off provider access quickly and who can take over device administration. It should also say where current configurations are stored and how to reach the provider’s security team outside the normal support line. Rehearsing it once, in a tabletop with the provider present, usually exposes gaps in both organizations.

The playbook should also cover the first days after the cut-off. Who reviews every configuration change made in the exposure window. Which credentials are rotated, in what order, and by whom. Whether regulators, auditors or business associates must be told. And when, and under what conditions, the provider’s access comes back.

Encryption, provider accounts, logs and a rehearsed cut-off

A CIO or CISO can test the position in an afternoon with five questions, one per control.

1. Which of our network links carry sensitive data without encryption today, and what is the plan and date to change that?
2. How many provider staff can log in to our network and security devices, and do they each use a named account with multi-factor authentication?
3. Does our contract require the provider to tell us, within a set time, if its own management systems are compromised, even if it thinks we were not affected?
4. Do logs from our routers and firewalls go to our own security platform, or only to the provider?
5. If our provider were compromised tomorrow, who would cut off its access and who would take over administration? Have we rehearsed it?

Answers that come back vague are the work plan. Answers that come back specific, with dates and names, are the evidence.

With hindsight

The advisory proved to be an early chapter in a longer story, and later events bore out its warnings.

In May 2023, Microsoft and U.S. and allied agencies described another China-linked group, widely called Volt Typhoon, using compromised small office routers to reach critical infrastructure. That was the relay technique from the 2022 advisory, pointed at critical infrastructure. In February 2024, CISA and partner agencies went further, warning that Volt Typhoon appeared to be pre-positioning inside critical infrastructure networks for possible disruption, not espionage alone.

In January 2024 the Justice Department announced a court-authorized operation to disrupt a botnet of such routers, known as the KV botnet. A botnet is a network of hijacked devices controlled remotely by an attacker, often without their owners ever noticing. According to the Justice Department, most of the devices were Cisco and Netgear routers that had reached end of life and no longer received security updates. The forgotten branch router of 2022 had become a documented national security problem.

In September 2024, the FBI announced the disruption of a second, larger botnet of routers, cameras and storage devices, attributed to a group called Flax Typhoon and to a Beijing-based company, Integrity Technology Group. In January 2025 the Treasury Department sanctioned that company.

In November 2024, the FBI and CISA said China-linked actors had compromised networks at multiple U.S. telecommunications companies, including copying some information subject to court-ordered law enforcement requests; the group is often called Salt Typhoon. That was the scenario the 2022 advisory had sketched: attackers inside the carriers, with access to what flows through them. In January 2025 the Treasury Department also sanctioned a Sichuan-based company it said was directly involved in Salt Typhoon’s activity.

The method matched too. In February 2025, Cisco’s Talos research group published an analysis of the telecom intrusions it had investigated. In all but one case, it reported, the actors got into Cisco devices with legitimate credentials rather than a new vulnerability. Once in, they pulled further credentials from device configurations and captured authentication traffic, including RADIUS and TACACS+. In the one exception, Talos said, the actors likely exploited a Cisco Smart Install flaw that had appeared on the 2022 advisory’s list.

In December 2024, CISA and partner agencies issued hardening guidance for communications infrastructure, and CISA followed with mobile communications guidance for highly targeted individuals. The second document echoes the advice about executive communications: assume ordinary calls and texts can be read, and use encrypted tools for sensitive matters. In August 2025, U.S. agencies and international partners issued a further joint advisory on these actors, describing activity against telecommunications, government, transportation, lodging and military networks worldwide.

Policy for the carriers themselves moved less steadily. In January 2025 the Federal Communications Commission issued a ruling that read a duty to secure networks into the wiretap law, CALEA, and proposed annual cybersecurity certifications. In November 2025 a new commission majority voted 2-1 to rescind that ruling and withdraw the proposal, citing carriers’ voluntary improvements. For customers, the practical result was that no new federal rule would make the carrier’s security their assurance.

By 2026, the idea that a carrier’s network should be treated as untrusted transport is mainstream guidance rather than a specialist view. That shift moves the burden of proof. A board can now reasonably ask why sensitive traffic is not encrypted, rather than why it should be.

What held up best was the advisory’s emphasis on credentials and configurations. Patching the listed flaws mattered, but the later intrusions show that stolen logins and legitimate commands did most of the work. Customers who governed provider accounts and kept their own logs were better placed than those who only tracked patch levels.

Many organizations still run unencrypted traffic over private circuits, and provider access governance remains uneven. Those two gaps are the practical place to start. Both can usually be closed with equipment already owned and contract terms negotiated at the next renewal. The 2022 advisory gave organizations an early warning. The events since then have removed any doubt that the threat to carriers is real and continuing.