Edge Device Persistence in 2026: Defending Network Appliances from Nation-State Implants

The Salt Typhoon disclosures of late 2024 made one thing clear to anyone running a perimeter: the appliances at your network edge are no longer the boundary of your trust model — they are the soft, opaque, infrequently-patched interior of someone else’s. Through 2025 and into 2026, PRC- and Russia-aligned operators have continued to harvest unauthenticated RCE and authentication bypass chains in Ivanti Connect Secure, Fortinet FortiOS, Cisco IOS XE, Palo Alto PAN-OS, SonicWall, and Citrix NetScaler — and have moved persistence progressively below the operating system into bootloader, ROMMON, and SPI flash. The result is a class of intrusion where reimaging from the vendor image does not actually evict the adversary, and where most SOCs have no telemetry primitive that would catch it. This post is about what to do about that.

The shift toward edge-resident persistence

The attractiveness of the edge appliance to a nation-state operator is not subtle. It sits on both sides of the inspection boundary, terminates VPN and management traffic, holds long-lived credentials and certificates, runs a vendor-supplied OS that the customer is contractually discouraged from instrumenting, and almost never produces host-based EDR telemetry. Through 2025, three trends crystallized:

• Living off the appliance. Operators are abandoning custom binaries in favor of abusing vendor-shipped Perl, Python, BusyBox, and Lua interpreters already present on the device. The Volt Typhoon-aligned activity against SOHO and edge gear demonstrated this; the post-Salt Typhoon telecom intrusions extended it into carrier-grade equipment.
• Sub-OS persistence. Implants resident in GRUB, U-Boot, ROMMON, or vendor SMM/UEFI surfaces survive vendor reimage, factory reset, and most field replacement procedures that do not include flashing the recovery partition from a known-clean fixture.
• Lawful intercept and management plane abuse. Where present, LI subsystems and out-of-band management interfaces (iDRAC/iLO/BMC class) are being used as covert channels because they are explicitly designed to be invisible to in-band monitoring.

The defender problem is not that any single one of these is novel. It is that the combination collapses several traditional assumptions at once: that a clean reimage restores integrity, that vendor signatures on the running image are sufficient evidence of integrity, and that the device’s own logs are a faithful record of what happened on it.

How the implants actually survive

The persistence techniques observed in incident reporting through 2025–2026 cluster into a few categories. Modifications to the writable portions of the boot chain — typically the bootloader configuration, initrd, or a vendor recovery partition — let an operator re-stage userland tooling on every reboot even after the running OS image is replaced. SPI flash modifications targeting the device’s UEFI or platform firmware are rarer but have been confirmed on enterprise gear; these survive board-level service. Configuration-resident persistence — Lua scripts installed via documented vendor extension points, EEM applets on IOS, custom SSL/TLS profiles on FortiGate — is the most common because it is the cheapest and the hardest to distinguish from legitimate administrative work.

The operator’s goal in all cases is the same: make the next legitimate management action by the customer a no-op against the implant. If your eviction plan is “reload from vendor image,” the implant is designed to outlive that.

What detection actually looks like

If you are relying on the appliance’s own log stream to tell you it has been compromised, you have already lost. Detection here is built on three pillars that do not depend on the device’s cooperation.

Off-box telemetry. Mirror the device’s north and south traffic to a sensor you control. Egress to unexpected ASNs, long-lived TLS sessions to residential or hosting ranges, DNS for non-vendor domains from the management VRF, and ICMP/UDP covert channels from management interfaces are all useful indicators. Pair NetFlow/IPFIX with full PCAP retention on management subnets specifically — these are low-volume and high-signal.

Integrity attestation against a known-good baseline. For Cisco platforms, this means pulling and verifying the output of show software authenticity running, show platform integrity, and where supported, hardware-anchored boot integrity measurements. For Fortinet and Palo Alto, hash the running image and config and diff against a baseline captured at a known-clean state under change control — not against the vendor’s published hash, which the implant can satisfy by leaving the on-disk image alone and modifying only the loader. CISA’s published guidance on Cisco IOS XE integrity verification and the vendor-specific forensic guides released in 2024–2025 are the right starting points.

Memory forensics and offline image extraction. When an appliance is suspected compromised, do not reboot it. A reboot is what the implant is waiting for. Acquire volatile memory and the contents of all writable flash regions through a documented forensic procedure, ideally with vendor TAC engaged, and analyze offline. The diagnostic shells exposed by most enterprise gear are sufficient for memory acquisition; the harder problem is having a baseline to compare against.

Useful behavioral signals: new or modified scheduled tasks and EEM applets, unexpected processes parented to the web management daemon, configuration changes outside change windows, certificate or SSH host key rotation that nobody requested, and management plane authentications from accounts that should not be using the management plane.

Remediation when you find one

The instinct to immediately reboot and reimage is wrong. The sequence that has actually worked in 2025 incident response engagements looks closer to this: isolate the device at the upstream switch while preserving power, capture volatile state, capture all writable flash, rotate every credential and certificate the device has touched (including IKE PSKs, RADIUS shared secrets, BGP MD5 keys, and any TLS private keys), assume any traffic that transited the device during the suspected window is compromised, and replace the hardware unit rather than reimaging it unless the vendor can supply a fixture-level reflash procedure with attestation. Treat the removed unit as evidence. Re-establish trust on the replacement before returning it to service — fresh keys, fresh certificates, configuration rebuilt from version control rather than restored from the compromised device’s own backup.

Control mapping

What this changes for the program

The edge appliance has to be treated like any other high-value asset: under configuration management you control rather than the vendor controls, with off-box telemetry, with an incident response runbook that assumes sub-OS persistence, and with a procurement process (SR-3, SR-5) that contractually requires firmware attestation and timely vulnerability disclosure. The vendors will catch up unevenly. The operators will not wait.