Skip to main content
search
AI SecurityAll BlogsCyber NewsGovernment CybersecurityZero Trust

CISA’s Emergency Directive on Cisco VPNs [CISA ED 25-03]: Short-Term and Long-Term Response Strategy

By October 3, 2025 No Comments

Author: Amit Pawar, VP of Consulting and Services, Xage Security 

Urgent Directive for Cisco ASA/Firepower – A Symptom of Bigger Issues

Late September 2025 saw U.S. federal agencies scrambling under CISA Emergency Directive 25-03, which mandates immediate action on Cisco Adaptive Security Appliance (ASA) and Firepower devices. An advanced threat actor, ArcaneDoor 2, has been exploiting zero day flaws (CVE-2025-20333 and CVE-2025-20362) to achieve unauthenticated remote code execution on ASA VPN endpoints and even modify the device firmware (ROMMON) for boot-persistent malware. 

In response, CISA’s directive isn’t a mere “please patch when convenient” notice, but an urgent call for patching, forensic triage, and reporting within days. CISA is also advising EOL’d Cisco ASA and Firepower devices to be replaced immediately. This whirlwind response highlights a hard truth: our legacy VPN perimeter devices – once the remote access workhorses of enterprise and industrial networks – have become high-risk single points of failure. And while emergency patches will put out this fire, a more structural solution is needed to prevent the next one.

CISA Emergency Directive 25-03

Inside CISA’s Emergency Directive 25-03

Emergency Directive (ED) 25-03 requires Federal Civilian Executive Branch agencies to “identify and mitigate potential compromise” of all Cisco ASA and Firepower instances. CISA’s orders are explicit and time-bound.

Key Dates

Triage/patch by Sept 26, 2025    EOS ASA Removal by Sept 30, 2025    Reporting by Oct 2, 2025

Required Actions

  • Identify All Devices: Immediately account for every Cisco ASA platform (hardware, virtual, modules) and all Cisco Firepower Threat Defense appliances in use. Nothing can be left untracked, as unseen devices could be backdoors into agency networks.
  • Forensic Triage (Core Dumps): For every internet-facing Cisco ASA, follow CISA’s detailed core dump collection and hunt procedures and upload memory dumps to CISA’s malware portal by September 26, 2025, 11:59PM EDT. This allows CISA to analyze devices for the telltale signs of compromise. If any ASA shows “compromise detected,” agencies must immediately disconnect it from the network (but not power it off) and report the incident, working with CISA on containment.
  • Patch or Disconnect: By the same urgent deadline (Sept 26, 2025), apply all available Cisco software updates on devices that show no signs of compromise. Notably, any ASA models that have end-of-support dates on or before Sept 30, 2025 must be permanently disconnected by Sept 30, 2025. This is essentially the forced retirement of legacy boxes that can’t be fully secured. Even slightly newer models (supported through 2026) had to be patched by Sept 26 and must install any future patches within 48 hours of release.
  • Fortify Virtual & Firepower Appliances: Virtual ASAv and physical Firepower appliances weren’t spared. They also required updates by Sept 26 and rapid patching of any new fixes within 48 hours.
  • Report Outcomes: By October 2, 2025, every agency head must report back a complete inventory of affected products and the actions taken (patched, removed, compromised) using CISA’s template. This ensures CISA can gauge compliance and remaining exposure across the federal enterprise.

These aggressive timelines (essentially 24 to 48 hours to triage and patch) underscore the directive’s urgency. And for good reason. Cisco and government investigators revealed a “widespread” exploitation campaign in the wild. The attackers (identified with the codename ArcaneDoor) have been modifying ASA firmware to plant hidden bootkits that survive reboots and even software upgrades. In other words, an unpatched ASA could remain infected even after a normal update or restart, thanks to malware burrowed in its ROM. This is every network operator’s nightmare: a trusted firewall/VPN appliance turned into a persistent threat actor beachhead.

Cisco’s analysis of compromised devices found the attackers were highly sophisticated. They disabled logging, intercepted CLI commands, and even intentionally crashed devices to thwart forensic analysis. They targeted ASA 5500-X series units with VPN web services enabled, deploying a malicious ROMMON implant (dubbed “RayInitiator” by UK’s NCSC) and an in-memory Linux shellcode loader (“LINE VIPER”) to maintain access. In short, this isn’t the work of opportunistic script kiddies; it’s likely a nation-state or well-resourced group that has turned a critical remote access tool into a foothold for espionage or attack.

CISA’s directive is the correct short-term antidote: find the compromises, rip out or fix vulnerable devices, and report the scope of impact. Federal CISOs and network teams have treated it as a four-alarm fire, working around the clock to comply. But as the dust settles, a sobering question remains: how do we stop getting here in the first place? To answer that, we must recognize a pattern that has played out repeatedly in recent years: a pattern of VPN and remote access solutions becoming Achilles’ heels.

A Recurring Pattern: VPN Vulnerabilities from Ivanti to Cisco ASA

A recent precedent: In early 2024, CISA’s ED 24-01 forced rapid remediation of Ivanti Connect Secure after zero days enabled authentication bypass, device takeovers, and persistence. The pattern mirrors ASA: an internet-facing VPN portal plus implicit network access created a high-value attack path that required emergency disconnection and rebuild—an architectural, not vendor-specific, problem.

Sound familiar? An internet-facing VPN gateway, a zero day used to bypass logins, leading to hidden webshells or implants and long-term stealthy access. The Ivanti incident was almost a preview of what we’re now seeing with Cisco ASA. In both cases, an ostensibly secure remote access solution became an open door. 

And it’s not just Ivanti or Cisco. We’ve seen VPN credentials and flaws lead to major breaches before. The Colonial Pipeline ransomware attack in 2021 famously began via a single leaked VPN password. According to the 2025 Verizon DBIR report, stolen or abused credentials are still the top attack vector responsible for breach – and VPN portals are a prime target for password guessing, theft, or exploit.

The common thread is that traditional VPN architectures present a tantalizing combination to attackers: they are both exposed to the internet (often with web-based logins or clients accessible 24/7 from anywhere) and, once breached, they provide deep network access. A single vulnerability or stolen login can potentially let an intruder roam freely inside critical networks. The VPN architecture is inherently insecure.

In Ivanti’s case, the attackers who bypassed the VPN could “gain administrative access to compromised networks without detection,” even reaching domain controllers to attempt full enterprise takeover. With Cisco ASA, the ArcaneDoor group didn’t even need valid credentials. The zero-days let them get code execution as “unauthenticated” users and from there, they turned the VPN device itself into a beachhead.

The Path Forward: Moving Beyond VPNs

CISA’s latest emergency directive is yet another reminder that VPNs, regardless of vendor, remain a fragile foundation for remote access. Their architecture inherently exposes organizations to unacceptable risks, forcing security teams into a cycle of urgent patches and late-night incident response. To truly break this pattern, we need to move away from a network-centric, perimeter-based model and adopt an identity-centric Zero Trust model. By embracing Zero Trust Access, organizations can enable secure, granular, and resilient remote connectivity without exposing themselves to the vulnerabilities that continue to plague legacy solutions.

For a deeper look into this incident and how Xage Zero Trust Access mitigates VPN risks, download the full technical brief. The brief showcases how Xage designed to structurally eliminate the risks that ED 25-03 and its predecessors keep highlighting, diving deep into what  different Xage platform capabilities do and how they enforce controls and reduce risk. 

For a deeper look at why VPNs and jump servers fall short as an effective strategy for OT remote access and urgently need to be replaced, explore our blog: Why VPNs and Jump Servers Fall Short for OT Remote Access.

Forward-looking companies like Pacific Canbriam are already moving beyond VPNs. By replacing their VPN with Xage Zero Trust Access, they have built a future-ready OT security architecture. You can read their full story here: Beyond VPNs: How Pacific Canbriam Built a Future-Ready OT Security Architecture