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

The week

On September 25, 2025, CISA issued Emergency Directive 25-03 to federal civilian agencies over Cisco Adaptive Security Appliance and Firepower devices. Cisco disclosed two exploited vulnerabilities, CVE-2025-20333 and CVE-2025-20362, which could be chained, and linked the activity to the actor behind the ArcaneDoor campaign it had reported in 2024. On some older ASA 5500-X models without Secure Boot, the attackers had modified ROM Monitor firmware so that access survived reboots and software upgrades. 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. The UK’s National Cyber Security Centre published analysis of the malware, including a bootkit it called RayInitiator and a loader called LINE VIPER.

Earlier in this series we argued that internet-facing remote-access appliances are an architecture decision as much as a patch queue. ED 25-03 added a second claim. 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.

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. 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.

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.

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.

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.

That the fix is the right one

Cisco published fixed releases across several software trains. 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.

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. 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.

With hindsight

The directive’s deadlines ran into the federal funding lapse that began on October 1, 2025. 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. CISA said it was tracking exploitation of those versions in federal agencies. It published minimum fixed versions for each software train and told agencies to update all ASA and Firepower devices, not just public-facing ones. That episode confirmed the third part of the directive’s burden: an upgrade does not prove remediation. Through 2026, edge devices remained a preferred target for state-linked actors. Agencies that verified running versions automatically and tracked hardware lifecycle as a security attribute handled later directives with fewer exceptions.