Cisco ASA and Firepower Threat Defense (FTD) firewalls sit on the internet edge of a large share of enterprises, and their remote access VPN web services have become a favoured way in for capable attackers. In September 2025 CISA issued Emergency Directive 25-03 after CVE-2025-20333 and CVE-2025-20362 were exploited in a campaign Cisco links to ArcaneDoor, in which attackers modified ROMMON on older ASA 5500-X models so that persistence survived reboots and upgrades. More than a dozen ASA and FTD flaws sit in the CISA Known Exploited Vulnerabilities catalogue. This guide covers how administrator and VPN identity work on ASA, FTD and the Firewall Management Center (FMC), the management and VPN hardening Cisco documents, the logs that matter, and what to do when integrity is in doubt. It is for firewall engineers, network architects and SOC analysts. For the cross-vendor view, see the VPN Security Guide.
Key takeaways
- VPN web services are the exposure. Cisco states that devices without SSL VPN or IKEv2 client services enabled were not affected by the 2025 campaign vulnerabilities; where those services must run, patching speed is the main control.
- Retire hardware without Secure Boot. The compromised models were ASA 5500-X platforms without Secure Boot and Trust Anchor support; CISA ordered US federal agencies to disconnect models at end of support by 30 September 2025.
- Use TACACS+ for administrators. Cisco's best practices prefer TACACS+ because RADIUS does not support command accounting, and pair it with command authorisation and a single local fallback account.
- Turn on remote access VPN threat detection. Supported ASA and FTD releases can automatically shun sources of repeated failed authentication, incomplete client initiations and attempts against internal tunnel groups.
- A compromised firewall needs a rebuild, not a patch. Cisco advises treating the configuration as untrusted, factory resetting or reimaging, and replacing every password, certificate and key the device held.
How identity and access work in Cisco ASA and FTD
ASA and FTD share a heritage but are managed differently, and the identity controls follow the management model.
| Platform | How it is managed | Administrator identity | Where hardening is set |
|---|---|---|---|
| ASA (hardware, ASAv, ASA on Firepower 1000, 2100, 3100, 4100, 9300) | CLI over SSH, ASDM over HTTPS, or Cisco Security Cloud Control | Local users with privilege levels 0 to 15, or AAA server groups (TACACS+, RADIUS, LDAP) | Running configuration: ssh, http, aaa, logging commands |
| FTD managed by FMC or cloud-delivered FMC | FMC web interface and REST API push policy to devices | FMC user accounts with predefined or custom roles, optionally external LDAP or RADIUS; device CLI users separate | FMC platform settings policy (SSH, HTTPS, syslog, SNMP), access control and remote access VPN policies |
| FTD managed locally by Firewall Device Manager | FDM web interface and API on the device | Local or external users on the device | FDM system settings and policies |
| Firepower chassis (FXOS on 4100, 9300) | Chassis manager and FXOS CLI | Separate FXOS users | FXOS platform settings |
Remote access VPN users authenticate through connection profiles (tunnel groups) and group policies, against AAA servers, SAML identity providers or certificates. Two default connection profiles, DefaultWEBVPNGroup and DefaultRAGroup, exist on every ASA and are reserved for internal use, which is why attackers aim password spraying at them.
Machine identities matter as much as people: TACACS+ and RADIUS shared keys, LDAP bind accounts, SNMP credentials, VPN pre-shared keys, identity certificates and their private keys, FMC REST API users and Security Cloud Control onboarding credentials. All of them live in the device or FMC configuration, and that configuration is what attackers copy after exploitation.
Admin roles and privileged access
ASA management access
- SSH and HTTPS only: generate an RSA key of at least 2048 bits, set
ssh version 2, usehttp redirectso ASDM is only reached over HTTPS, and do not enable Telnet. Copy files with SCP rather than FTP or TFTP. - Source and interface restriction: the
sshandhttpcommands take a subnet, mask and interface. Permit only the management subnet or jump hosts on the inside or management interface, never on outside. - Dedicated management interface: set
management-onlyon the management interface so it carries management protocols and not transit traffic. - Timeouts and session caps: set
ssh timeoutandconsole timeout(the default is 5 minutes) and cap concurrent management sessions with the management session quota. - Banner: a
banner loginthat states use is restricted and monitored, without the device name, model, software version or owner.
AAA, authorisation and accounting
- Define a TACACS+ server group with
aaa-serverand point SSH and console authentication at it withLOCALfallback (aaa authentication ssh console <group> LOCAL), and the same for HTTP so ASDM uses the AAA server. - Enable exec and command authorisation so the TACACS+ server decides what each administrator may run, and command accounting (
aaa accounting ssh console <group>) so every EXEC command is recorded centrally. - Keep one local privilege 15 account for outages, stored in a PAM vault. Cisco notes that privilege 15 accounts are not locked out by
aaa local authentication attempts max-fail, so keep their number to the minimum and alert on every use. See the Break-Glass Account Guide. - Apply the lockout setting (Cisco's example is 5 attempts) to the remaining local accounts, and enable the master passphrase so stored secrets are encrypted with AES.
- Require MFA at the TACACS+ or identity provider layer for every administrator, and route administrator sessions through a recorded jump host. See the Privileged Session Management Guide.
FMC and FTD roles
- Separate roles: use FMC predefined roles (Administrator, Network Admin, Security Analyst, Security Analyst (Read Only), Maintenance User) or custom roles, and FMC domains to limit who can deploy to which devices. Few people need Administrator.
- External authentication: configure LDAP or RADIUS external authentication objects so FMC users come from the directory with MFA, and keep a vaulted local admin.
- Device CLI: FTD and FXOS have their own CLI users. Include them in the same inventory, rotation and alerting as FMC users.
Integrations, API tokens and service accounts
- FMC REST API: clients POST to
/api/fmc_platform/v1/auth/generatetokenwith Basic authentication and receive anX-auth-access-tokenvalid for 30 minutes and anX-auth-refresh-tokenthat can refresh it up to three times. Cisco advises keeping script users separate from UI users, because the same account used in the GUI and API at once is logged out. Enable the API only where needed (System > Configuration > REST API Preferences), give each pipeline its own account with the smallest role, and store its password in a secrets manager rather than the script. See the API Key Management Guide. - AAA shared keys: TACACS+ and RADIUS keys are configured per server on each device. Make them long and unique per environment, and rotate them after any suspected compromise. See the RADIUS Security Guide.
- LDAP bind accounts: used for VPN authorisation and FMC external authentication. Use LDAPS, a dedicated read-only directory account with interactive logon denied, and monitor it.
- SNMP: use SNMPv3 with the
privoption. Cisco's page still shows an MD5 and 3DES example; choose the strongest algorithms your release offers. KEV contains old ASA SNMP and CLI flaws (CVE-2016-6366, CVE-2016-6367), a reminder to limit SNMP to management hosts. See the SNMP Security Guide. - Certificates and VPN keys: identity certificates for the VPN headend, SAML signing trust, and site-to-site pre-shared keys all need an owner, an expiry and a rotation plan. Prefer certificate authentication for site-to-site tunnels.
Remote access VPN hardening
| Control | What it does | Notes from Cisco guidance |
|---|---|---|
| Threat detection for remote access VPN | Shuns sources of repeated failed authentication, incomplete client initiations and connections to internal tunnel groups | Supported from ASA 9.16(4)67, 9.17(1)45, 9.18(4)40, 9.19(1).37, 9.20(3), 9.22(1.1) and FTD 7.0.6.3, 7.2.9, 7.4.2.1, 7.6.0 (not 7.1 or 7.3); shuns stay until removed by an administrator |
| Lock down default connection profiles | Removes AAA authentication and Hostscan from DefaultWEBVPNGroup and DefaultRAGroup | Recommended where threat detection is not available; reduces but does not prevent denial of service |
| Group URLs instead of group aliases | Users reach their profile by a specific URL, and the drop-down list of profiles is not shown | Stops attackers enumerating connection profiles |
| MFA on every connection profile | SAML or RADIUS with phishing-resistant factors or number matching | Combine with certificate or posture checks for managed devices |
| Disable unused VPN web services | Turns off SSL VPN and IKEv2 client services where not used | Cisco's temporary mitigation for the 2025 campaign; it breaks SSL remote access, so plan the change |
The Cisco breach of 2022 shows why the MFA row matters: a password synced to a personal browser account and repeated push prompts gave an attacker VPN access, after which they enrolled their own MFA devices. See the Phishing-Resistant MFA Guide.
Logging and detection
Cisco's guidance is to send logs to a central server with logging host, set logging trap and logging buffered to level 6 (informational), turn off logging console and logging monitor, and enable logging timestamp. Syslog defaults to unencrypted UDP, so use TCP with TLS where the collector supports it. By default ASA hides usernames in failed login messages; no logging hide username shows them, which helps password spray investigation but puts mistyped passwords at risk of appearing in logs, so decide deliberately.
| Syslog message | Meaning | Use |
|---|---|---|
| %ASA-6-113005 | AAA authentication rejected by the server | Password spraying against VPN or management |
| %ASA-6-113015 | User not found in the local database | Username guessing |
| %ASA-6-716039 | WebVPN authentication rejected | SSL VPN brute force |
| %ASA-5-111008 and %ASA-5-111010 | A user executed a command; a user made a configuration change | Change outside a window, or by an unexpected account |
| %ASA-6-605004 and %ASA-6-605005 | Management login denied or permitted | Admin access from outside the jump host range |
The 2025 campaign is a warning about relying on device logs alone: Cisco observed attackers disabling logging, intercepting CLI commands and deliberately crashing devices. Alert when a firewall stops sending syslog, when the logging configuration changes, and on unexpected reloads or crash files. After upgrading a non-Secure Boot 5500-X, check disk0: for firmware_update.log, which Cisco says is written when the upgrade finds and removes the ROMMON persistence mechanism. Use show aaa-server counters to spot rising rejection rates. For FTD, Cisco published Snort rules 65340 and 46897 for CVE-2025-20333 and CVE-2025-20362. See the VPN and Firewall Log Detection Guide.
Metrics
- Patch latency: hours from a Cisco advisory affecting VPN web services to fixed code on every exposed device (CISA set 48 hours for federal agencies under ED 25-03).
- Unsupported hardware: count of ASA devices past end of support or without Secure Boot still in service (target: zero).
- Exposed management: devices answering SSH or ASDM on outside interfaces (target: zero).
- Command accounting coverage: percentage of devices sending TACACS+ accounting records.
- VPN spray signal: daily 113005 and 716039 counts and the number of auto-shunned sources.
Hardening baseline
- Inventory and retire: list every ASA, ASAv, FTD, FXOS chassis and FMC with model, software, Secure Boot support and exposure. Plan replacement for 5500-X models; the 5525-X, 5545-X and 5555-X reached end of support on 30 September 2025. See the Edge Device End of Life Replacement Playbook.
- Patch exposed VPN headends first: move to fixed releases from Cisco's tables, upgrading the standby unit of a failover pair first. Test VPN logins from a pilot group before cutting over.
- Restrict management: remove outside-interface
sshandhttpstatements, enforce SSH version 2 and HTTPS, set timeouts and session quotas, and restrict ICMP to management subnets. Verify from an external host that nothing answers. Keep the previous configuration saved to roll back. - Move administrators to TACACS+ with MFA: enable command authorisation in monitor mode on the TACACS+ server first, review a week of accounting, then enforce. Keep the local fallback account tested.
- Harden VPN: enable remote access VPN threat detection, lock down default connection profiles, switch to group URLs, require MFA everywhere, and disable unused SSL VPN and IKEv2 client services.
- Logging: central syslog at level 6, timestamps, NTP with authentication, alerts for silence and configuration change.
- Protect secrets: enable the master passphrase, rotate AAA keys, SNMP credentials and VPN keys, and move FMC API users to dedicated accounts.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | CIS Controls v8.1 | ATT&CK technique addressed |
|---|---|---|---|---|
| Patch VPN web services, retire EoS hardware | SI-2 | ID.RA-01, PR.PS-02 | 2.2, 7.7 | T1190 Exploit Public-Facing Application |
| Management restriction | SC-7, CM-7 | PR.PS-01 | 4.1, 12.3 | T1133 External Remote Services |
| TACACS+, command authorisation, MFA | IA-2, AC-6, AU-12 | PR.AA-01, PR.AA-05 | 5.4, 6.5 | T1078 Valid Accounts |
| VPN threat detection and MFA | AC-7, AC-17 | DE.CM-01 | 6.4 | T1110 Brute Force |
| Image and ROMMON integrity | SI-7 | DE.CM-09 | 4.1 | T1601 Modify System Image |
| Log protection and silence alerts | AU-6, AU-9 | PR.PS-04 | 8.2, 8.9 | T1685 Disable or Modify Tools |
ISO/IEC 27001:2022 Annex A equivalents are A.8.2, A.8.5, A.8.8, A.8.9, A.8.15 and A.8.20.
Common misconfigurations
- Old hardware kept running behind a support contract that has ended: the platforms that lacked Secure Boot were exactly the ones where attackers achieved ROMMON persistence.
- Upgrading a compromised device and moving on: Cisco advises treating the configuration as untrusted after compromise: upgrade, factory reset (
configure factory-default, orwrite eraseand reload), reimage FTD, then rebuild with new passwords, certificates and keys. The same lesson came out of the Ivanti Connect Secure exploitation of 2024, where stolen appliance credentials outlived the patch. - AAA left enabled on DefaultWEBVPNGroup and DefaultRAGroup: gives sprayers a target that no real user needs.
- RADIUS for administrators with no accounting: no record of which commands an attacker or insider ran.
- ASDM open on the outside interface: many historic KEV entries (for example CVE-2020-3452 and CVE-2018-0296) were in web services; management on outside widens every such flaw.
- One FMC account for every script: token collisions log users out, and the audit trail cannot tell pipelines apart.
Practitioner checklist
- Inventory all ASA, FTD, FXOS and FMC instances with model, release, Secure Boot support and VPN services enabled.
- Replace ASA hardware past end of support or without Secure Boot.
- Run fixed releases for every KEV-listed ASA and FTD vulnerability, VPN headends first.
- Remove SSH and ASDM from outside interfaces; enforce SSH version 2, HTTPS, timeouts and a login banner.
- Authenticate administrators with TACACS+ and MFA, with command authorisation and accounting, and one vaulted local account.
- Enable remote access VPN threat detection, lock down default connection profiles and use group URLs.
- Give each FMC API integration its own least-privilege account and store credentials in a secrets manager.
- Send syslog at level 6 to a central collector and alert on silence, logging changes and unexpected reloads.
- Keep a compromise runbook: collect core dumps and show tech output, rebuild from factory state and rotate every secret.
Standards and references
- Cisco: Firewall Best Practices
- Cisco: Event Response, Continued Attacks Against Cisco Firewalls
- Cisco: Password Spray Attacks Impacting Customers with Remote Access VPN
- Cisco: How to Generate an Authentication Token for the FMC REST API
- CISA: ED 25-03 Identify and Mitigate Potential Compromise of Cisco Devices
- CISA: Known Exploited Vulnerabilities Catalog
- NIST: SP 800-53 Rev. 5
- MITRE ATT&CK: Modify System Image
Related NHI Mgmt Group resources: VPN Security Guide · Network Device Management Plane Hardening Guide · Cisco IOS XE Hardening Guide · Edge Device Compromise Investigation Playbook · Cisco ISE Hardening Guide