Persistence below the patch: what ED 25-03 asked agencies to prove about their firewalls

The week

On September 25, 2025, CISA, the federal Cybersecurity and Infrastructure Security Agency, issued Emergency Directive 25-03 to federal civilian agencies over Cisco Adaptive Security Appliance and Firepower devices, two widely used families of Cisco firewall. An emergency directive is a binding order: agencies must carry out its steps on its deadlines. CISA issues them only when it judges a threat serious and urgent.

Every government agency’s network has a front door: the firewall, a specialized device that sits between the agency and the internet, deciding what traffic may pass and often letting remote staff connect securely from outside. Because it sits at the edge and sees everything, a firewall is one of the most valuable places an attacker can hide.

Cisco disclosed two exploited vulnerabilities, CVE-2025-20333 and CVE-2025-20362, which could be chained. A vulnerability is a flaw an attacker can use; the CVE number is simply its catalog entry. “Chained” means the two flaws could be used one after the other, the first opening a door and the second turning that foothold into deeper control. Cisco linked the activity to the actor behind the ArcaneDoor campaign it had reported in 2024.

The most alarming detail concerned some older ASA 5500-X models without Secure Boot. On those devices, the attackers had modified ROM Monitor firmware so that access survived reboots and software upgrades. Firmware is the low-level code that runs when a device first powers on, before its main operating system loads. Secure Boot is a feature that checks that startup code is genuine before running it. Without it, an attacker who rewrites the startup code can come back to life every time the device restarts, no matter how freshly its main software has been updated.

The directive required agencies to inventory affected devices, collect memory core dumps from public-facing ASA devices for CISA analysis, apply Cisco’s updates, and permanently disconnect ASA hardware reaching end of support by September 30, 2025. A core dump is a snapshot of everything in a device’s working memory at a moment in time.

The UK’s National Cyber Security Centre published analysis of the malware, including a bootkit it called RayInitiator and a loader called LINE VIPER. A bootkit is malicious code that hides in the startup process; a loader is a program whose job is to bring further malicious code onto a device.

Take the chief information officer of a mid-sized federal agency on the morning the directive arrives. Her network team tells her, with some relief, that the agency has a patch process for exactly this kind of thing. Find the devices, apply the update, restart them, report back. It usually takes a few days. Then her security lead reads the next paragraph aloud: on some devices, the attackers’ access survived reboots and software upgrades. The relief fades. If patching and restarting do not remove the attacker, what exactly is the agency supposed to report as “done”?

ED 25-03 carried an uncomfortable message. A patched, rebooted and upgraded firewall could still be under an attacker’s control, because the compromise sat in firmware that runs before the operating system loads. The usual emergency sequence of find, patch and confirm assumes that applying a fix restores trust. Here it did not.

The directive asked agencies to prove four separate things. Each needs different people and evidence: what is installed, whether it was compromised, that the fix is the right one, and that the hardware can be trusted. Before taking them in turn, consider why this kind of attack is so troubling.

Why attacks below the software are different

A device is built like a building with several floors. The top floors are the applications and the operating system, the software that administrators see and manage every day. Patches are applied there. Below them is the ground floor, the firmware, which starts the device and then hands control upward. Below that is the hardware itself.

Most security tools and most patching work on the upper floors. An attacker who gets into the ground floor lies underneath all of that. When the device restarts, the firmware runs first, and if it has been altered, it can reinstall the attacker’s access before any of the protections above it come to life. Upgrading the operating system is like redecorating the upper floors while the intruder keeps a key to the basement.

Secure Boot exists to stop exactly this. When a device with Secure Boot starts, it checks a cryptographic signature from the manufacturer on its startup code, and refuses to run code that does not match. Older devices that lack the feature have no way to check. Their owners cannot easily tell whether the ground floor has been tampered with.

Firewalls and similar “edge devices” are especially attractive to attackers for three reasons. They face the internet by design, so they can be reached from anywhere. They see and handle large amounts of sensitive traffic, including remote staff logins. And they are often monitored less closely than the computers behind them, because they are thought of as part of the defenses rather than as something that needs defending.

What is installed

The inventory requirement looked routine. Agencies had built edge device lists for earlier directives, including those on Pulse Secure and Ivanti VPN appliances. A VPN, or virtual private network, appliance is the device that lets remote staff connect securely into the agency’s network. ED 25-03 asked for more precision: model, software version, whether the device was public-facing, and end-of-support date. Those last two fields drove different actions. Public-facing devices needed forensic collection, and end-of-support devices needed removal.

Network teams often hold this information in configuration tools, while security teams hold the asset inventory, and the two disagree. A device in a field office or a contractor-run enclave may appear in neither. The durable fix is a single edge device register reconciled against external scans of the agency’s own address space, so an unknown device shows up as an exception.

An “address space” is the range of internet addresses an organization owns. Scanning it from the outside, the way an attacker would, reveals every device that answers. Comparing that list with the official register is the simplest way to find the forgotten firewall in a regional office that nobody has updated in years.

The register also needs an owner who can act. In many agencies the network team can touch a firewall but cannot declare an incident, while the security team can declare one but lacks device credentials. A named device owner with authority on both sides shortens the first day of any edge device directive.

Whether it was compromised

The directive required core dumps from public-facing ASA devices before remediation, sent to CISA for analysis. Collection order mattered. Patching or rebooting first could destroy volatile evidence, so the forensic step had to precede the remediation step, under deadline pressure.

“Volatile” evidence is information that lives only in a device’s working memory and disappears when it restarts. For an attacker who hides cleverly, that memory may hold the only clear trace of their presence. An agency that rushes to patch, with the best of intentions, can wipe away the very evidence that would have told it whether it was a victim. This runs against every operational instinct, which says to fix the problem as fast as possible, and it is why the order needs to be written into the runbook in advance.

Few agencies can analyze firewall memory themselves, which is why central analysis by CISA was valuable. State and local governments run the same devices but were not covered by the directive and had no equivalent service. Their practical options were a state security operations center, an incident response retainer that explicitly covers network appliances, or Cisco’s own support channels. Each needs to be arranged before the advisory arrives.

An incident response retainer is a standing contract with a specialist firm that agrees to help quickly when something goes wrong. Many retainers are written around laptops and servers. A county IT director who discovers, in the middle of an emergency, that the retainer does not cover firewall forensics has lost days she does not have.

A clean result also needs careful wording. Analysis of a core dump can find known indicators; it cannot prove that no unknown implant exists. Agencies reporting to leadership or to inspectors general should describe the conclusion as no evidence of compromise found with the methods available, and keep the device on heightened monitoring. Executives should welcome that phrasing rather than push for a more comforting one, because an overconfident “all clear” is very hard to walk back.

That the fix is the right one

Cisco published fixed releases across several software trains. A software train is a parallel line of versions that a vendor maintains at the same time, so that customers on older lines can receive fixes without jumping to the newest one. An agency could upgrade a device, mark it remediated, and still be running a version that did not address both vulnerabilities. Version tracking for appliances is often manual, and release notes across trains are easy to misread under time pressure.

The control is to verify each device against a published minimum version for its train. Remediation records should capture the version actually running after the change, collected from the device or from configuration management, and compare it automatically with the minimum. Credentials, keys and VPN configurations that passed through a possibly compromised device should be rotated whatever the version check says, because exposure may predate the fix.

Rotating credentials means replacing passwords, digital certificates and encryption keys with new ones. If an attacker sat on a firewall for weeks, they may have copied the keys that pass through it. A patch closes the way they came in; it does nothing about keys they have already copied.

This is also where reporting pressure distorts evidence. Directives ask for status by a deadline, and a status field that says patched is easy to fill in. Requiring the reported version string alongside the status, and spot-checking it independently, costs little and catches the most common error.

That the hardware can be trusted

Firmware persistence moves the decision from software to hardware. Devices with Secure Boot can verify that their boot code is genuine. Older models without it cannot rule out tampering, and once out of support they receive no fixes. For those devices the directive’s answer was removal, on a fixed date.

That decision has costs agencies tend to underestimate. Replacement firewalls need procurement, configuration migration and a maintenance window, and a firewall cannot be switched off without another path for traffic. Agencies that hold spare capacity or pre-negotiated replacement terms can act on a directive’s timeline. Others are forced into exceptions.

Secure Boot is a capability, and it only helps when someone checks it. Newer devices can report whether boot verification succeeded and which image they loaded. Those reports should feed the same monitoring that watches firewall logs, so a failed integrity check raises an alert instead of sitting in a device console nobody opens.

Lifecycle data should therefore be treated as security data. Procurement should require secure boot and firmware integrity attestation for edge devices. Attestation is a device’s ability to report, in a trustworthy way, exactly what code it started with. Asset records should carry end-of-support dates, and budgets should schedule replacement a year or more ahead. Devices pulled after suspected compromise should be preserved or imaged for investigation, not sent straight to disposal or trade-in.

A test of budgets, accountability and continuity

Emergency directives can look like a technical team’s problem with a technical team’s deadline. In practice they test leadership as much as engineering.

They test budgets. An end-of-support date is known years in advance, yet replacement is often deferred because the old device still works. When a directive orders removal on a fixed date, deferral turns into an emergency purchase, usually at a worse price and with less time to configure the new device properly.

They test accountability. A directive asks the agency to certify that it has done certain things. The person signing that report is relying on a chain of evidence that may run through several teams and contractors. If the evidence is “someone said it was patched,” the signature carries risk.

They test mission continuity. A firewall is not a desktop computer that can be swapped out over lunch. Removing one without a replacement can cut off remote staff, public services or connections to other agencies. Agency heads need to know which services depend on which edge devices before they are asked to switch any of them off.

Take a state agency that runs the same Cisco devices but is not bound by the federal directive. Its leadership reads ED 25-03 as advice rather than an order, and that is a reasonable reading. The agencies that do best in that position treat the directive as a checklist for themselves: they inventory, they arrange forensic help, they check versions against the published minimums and they plan replacement of unsupported hardware, even without a federal deadline.

One firewall, start to finish

Follow a single device through the four proofs. Suppose a federal agency has a regional office whose internet connection runs through an older ASA firewall. The device faces the internet and handles remote logins for the office’s staff.

On the first day, the inventory step finds it, but only because the security team compares the official register with an external scan. The network team’s configuration tool listed the device; the security team’s asset list did not. The model, the software version, its internet exposure and its end-of-support date are recorded in one place, and a single owner is named.

On the second day, the forensic step comes before anything else. The owner follows the runbook, collects a core dump while the device is still running, and sends it for analysis. Only then does the network team begin remediation. Had they rebooted first, as the old habit would have suggested, the evidence would have been gone.

On the third day, the fix is applied, and the remediation record captures the version the device actually reports afterward, not the version the engineer intended to install. An automated check compares it with the published minimum for that software train. The passwords, certificates and VPN settings that passed through the firewall are replaced as a precaution.

The fourth proof produces the hardest answer. The model lacks Secure Boot and is reaching the end of support. No amount of patching can establish that its startup code is genuine. The device is disconnected on the directive’s date, preserved for investigation rather than sent for disposal, and replaced with a newer model whose boot integrity reports feed the agency’s monitoring.

The office experiences a planned outage of remote access during the swap. That disruption is far smaller because the agency had a spare device and pre-agreed replacement terms. Without them, the same story would have ended in an exception request and an unsupported firewall still guarding the door.

When the agency reports to CISA, each line of its status report is backed by something concrete: a reconciled inventory entry, a forensic submission, a verified version string and a disconnection record. The analysis result is described as no evidence of compromise found with the methods available, and the replacement device is placed on heightened monitoring for its first months in service.

Ready before the next directive

A well-prepared organization has one register of edge devices that matches what an outside scan sees. Each device has a named owner, a known software version, a flag for whether it faces the internet and an end-of-support date. The incident runbook says plainly that evidence is collected before patching when persistent compromise is suspected. Forensic support for network devices is under contract. Remediation is recorded as a running version checked against a minimum, not as a ticked box. And there is a budgeted plan to replace hardware before support ends.

The unprepared organization is the mirror image: two inventories that disagree, patching before collecting evidence, reporting “patched” without checking the version, assuming a reboot cleans a device, leaving credentials unchanged after a possible compromise, and keeping old hardware in service because it still passes traffic.

Inventory, evidence, versions and replacement plans before the next edge directive

• How many internet-facing edge devices do we have, does our register match what an external scan of our address space finds, and who owns each one with authority both to change it and to declare an incident?
• Does our runbook say to collect evidence before patching or rebooting when persistent compromise is possible, and if we needed firewall memory analyzed tomorrow, who would do it?
• When we report a device as remediated, do we record the version it is actually running and check it against the published minimum?
• After a possible compromise, have we replaced the passwords, keys and VPN settings that passed through the device?
• Which of our edge devices lack Secure Boot or are approaching end of support, is their replacement in the budget, and which services would go dark if we had to disconnect one today?

With hindsight

The directive’s deadlines ran into the federal funding lapse that began on October 1, 2025, so agencies were working through its steps while the government itself was partly shut down.

On November 12, 2025, CISA updated its implementation guidance after finding, from agency-reported data, devices marked as patched that were running versions still vulnerable to the activity in the directive. It pointed agencies to guidance on the minimum software versions required and urged all agencies with ASA and Firepower devices to follow it. That episode confirmed the third part of the directive’s burden: an upgrade does not prove remediation. A status field that says “patched” is only as good as the version check behind it.

In April 2026, CISA updated the directive again after a new persistence mechanism was found that survived upgrades to the September 2025 fixed releases. It extended the scope to more Firepower and Secure Firewall models and required a full power-off reset, noting that a reboot was not enough to remove the malware. The distinction matters: a reboot restarts the software while the device stays powered, whereas a full power-off reset cuts the power entirely, clearing what lives only in memory.

Taken together, the two updates showed that the four proofs the directive asked for were not a one-time exercise. What is installed, whether it was compromised, whether the fix is right and whether the hardware can be trusted all had to be answered again as new findings arrived.

Agencies that verified running versions automatically and tracked hardware lifecycle as a security attribute handled later directives with fewer exceptions. In government and beyond, edge devices deserve the same rigor as the systems they protect: one accurate inventory, evidence before action, verified fixes and a funded plan to retire hardware before it becomes a liability.