CISA Advisory AA26-194A, published July 13, 2026 with co-signatories from nineteen agencies across thirteen countries, describes a Russian FSB Center 16 campaign to harvest router configurations from critical infrastructure networks globally. The attack technique is operationally straightforward: query network-facing routers using default SNMP community strings (public/private), retrieve running configurations via SNMP OID walks or Cisco Smart Install, and exfiltrate the results via TFTP to FSB-controlled collection infrastructure.
For IT network administrators, the advisory’s mitigations are relatively clear: migrate to SNMPv3 with authPriv, disable Cisco Smart Install, block TCP 4786 and UDP 69 at the perimeter. For OT environments, the calculus is different. Routers at the OT perimeter don’t just hold network configuration — they hold the keys to critical operational infrastructure, and the consequences of compromise extend beyond data theft to potential operational disruption.
Why OT perimeter routers are high-value collection targets
An energy utility’s demilitarised zone (DMZ) router, or the IT/OT boundary firewall-router combination, typically contains:
VPN tunnel configurations: Site-to-site VPN tunnels connecting substations, pumping stations, or remote SCADA outstations to the control centre. These tunnels use pre-shared keys (PSK) in IKEv1 deployments — PSKs extracted from a running configuration can be used to decrypt captured VPN traffic or establish new authenticated tunnels.
OT network topology: Routing tables and interface configurations reveal the IP architecture of the OT network behind the router — which subnets exist, what the addressing is, and how traffic flows between OT zones. This is reconnaissance data for lateral movement planning.
OSPF/BGP authentication keys: In larger critical infrastructure environments, routing protocol authentication keys appear in router configurations. These keys control which devices can inject routes into the routing domain — compromising them enables route poisoning attacks.
SNMP community strings for downstream devices: The router configuration often includes SNMP community strings used to monitor PLCs, RTUs, and HMIs behind it. An attacker with the perimeter router config has the credentials to query all SNMP-enabled OT devices on the other side.
AAA credentials and NTP server references: Centralised authentication configuration points to RADIUS/TACACS servers; NTP references reveal time synchronisation infrastructure. Both are lateral movement pivot points.
The intelligence value of a single OT boundary router configuration to a nation-state with interest in critical infrastructure is therefore significantly higher than an equivalent enterprise IT router. The advisory’s framing — “harvesting credentials and network topology” — understates the OT-specific risk.
Identifying exposure in OT environments
The first step is identifying which devices in the OT environment’s perimeter are potentially exposed. Key questions:
Are any SNMP-enabled devices reachable from untrusted network segments? The OT DMZ design should restrict SNMP management to specific management station IPs in the IT management network. If SNMP (UDP 161) is accessible from the WAN interface or from less-trusted network segments, the device is exposed to the collection technique in AA26-194A.
Is Cisco Smart Install running on any IOS devices?
Run show vstack config on IOS/IOS-XE devices. If it returns a director address or shows Smart Install as enabled, the device is vulnerable. Smart Install was designed for flat LAN provisioning environments — it should never be running on a device with internet-accessible interfaces or in a segmented OT environment.
! Check Smart Install status on IOS
show vstack config
! Disable if active
conf t
no vstack
end
write memory
What SNMP version is in use?
Run show running-config | include snmp-server on Cisco devices. If you see snmp-server community public RO or snmp-server community private RW, those are the credentials the FSB campaign is exploiting. SNMPv1 and SNMPv2c community strings appear in running configs in plaintext.
OT-specific hardening considerations
Standard IT guidance (migrate to SNMPv3 authPriv, disable Smart Install) applies, but OT environments have additional constraints that affect implementation.
Legacy device SNMP support: Not all OT-adjacent devices support SNMPv3. Older SCADA RTUs, HMIs, and managed switches in OT environments were often deployed with SNMPv1 or SNMPv2c as the only available option. For these devices, SNMPv3 migration requires firmware upgrades or device replacement — both of which require change management processes with significant operational risk consideration in active control environments.
Where SNMPv3 migration on legacy devices is not immediately feasible:
- Restrict SNMPv1/v2c access with ACLs to specific management station IPs
- Rotate all community strings off defaults to randomised values
- Monitor SNMP traffic for access from unexpected sources
VPN PSK rotation after exposure assessment: If any OT perimeter router may have been accessible with default SNMP credentials during the advisory’s timeframe, assume the running config has been collected. This means assuming VPN PSKs are compromised. The operational implications of rotating IKEv1 PSKs across multiple remote sites simultaneously require coordination with site operations — plan the rotation carefully, but do not defer it indefinitely.
Purdue model compliance check: Advisory AA26-194A’s technique targets devices at the network boundary. In a correctly implemented Purdue model architecture, Layer 2/3 devices at the IT/OT boundary (Levels 3.5 and above) should have management access restricted to the management network (Level 4 or dedicated OOB management). If management plane access to these devices is possible from the WAN or from untrusted network segments, the architecture does not match the model.
Passive monitoring at the OT perimeter: Many OT environments have limited active monitoring at network device level — syslogs from routers may not be collected, and SNMP traffic may not be recorded. Deploy network flow monitoring or packet capture capability at the IT/OT boundary to capture SNMP and TFTP traffic. Retrospective analysis of captured traffic can identify whether the SNMP collection technique has already been used against your environment.
Specific TFTP monitoring for OT environments
TFTP (UDP 69) has legitimate uses in OT environments for firmware distribution to field devices. This legitimate use can mask exfiltration. Monitor for TFTP connections originating from router management IPs (rather than from the firmware distribution server) and for TFTP connections with unusual file naming patterns (.cfg, -running.cfg, startup-config) that indicate configuration file transfers.
If your OT environment uses TFTP for firmware distribution, restrict it to specific source/destination IP pairs via firewall rules and alert on any TFTP traffic outside those pairs.
Immediate actions
This week:
- Audit SNMP configuration on all IT/OT boundary routers — identify default or weak community strings
- Check for Cisco Smart Install on all IOS/IOS-XE boundary devices (
show vstack config) - Verify TCP 4786 is blocked inbound at the internet perimeter
- Verify SNMP (UDP 161) is blocked inbound at the internet perimeter
This month:
- Migrate boundary routers to SNMPv3 authPriv where device capability permits
- Rotate all SNMP community strings to unique random values; remove
publicandprivate - Document which OT-adjacent devices cannot support SNMPv3 and implement ACL compensation controls
- Review VPN PSK rotation timeline and coordinate with remote site operations
If compromise is suspected: If any perimeter router may have been accessible with default SNMP credentials during the advisory window, treat the running configuration as compromised. Rotate all VPN PSKs to affected sites, rotate BGP/OSPF authentication keys, and review SNMP community strings used to monitor downstream OT devices — all of those credentials should be treated as known to the adversary.
The advisory is clear that FSB Center 16 has been actively collecting router configurations from critical infrastructure networks. OT perimeter routers represent among the highest-value targets in that collection effort, and the remediation actions are well-understood, well-documented, and achievable in most environments with planned maintenance windows.