Join our Newsletter — 33% off our NHI Course
Home› Guides› Cisco ASA and Firepower Threat Defense Hardening Guide:…
Guide Network Security

Cisco ASA and Firepower Threat Defense Hardening Guide: Management, Remote Access VPN and Integrity

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 27 October 2026 13 min read
On this page

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.

PlatformHow it is managedAdministrator identityWhere hardening is set
ASA (hardware, ASAv, ASA on Firepower 1000, 2100, 3100, 4100, 9300)CLI over SSH, ASDM over HTTPS, or Cisco Security Cloud ControlLocal 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 FMCFMC web interface and REST API push policy to devicesFMC user accounts with predefined or custom roles, optionally external LDAP or RADIUS; device CLI users separateFMC platform settings policy (SSH, HTTPS, syslog, SNMP), access control and remote access VPN policies
FTD managed locally by Firewall Device ManagerFDM web interface and API on the deviceLocal or external users on the deviceFDM system settings and policies
Firepower chassis (FXOS on 4100, 9300)Chassis manager and FXOS CLISeparate FXOS usersFXOS 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, use http redirect so 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 ssh and http commands 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-only on the management interface so it carries management protocols and not transit traffic.
  • Timeouts and session caps: set ssh timeout and console timeout (the default is 5 minutes) and cap concurrent management sessions with the management session quota.
  • Banner: a banner login that states use is restricted and monitored, without the device name, model, software version or owner.

AAA, authorisation and accounting

  1. Define a TACACS+ server group with aaa-server and point SSH and console authentication at it with LOCAL fallback (aaa authentication ssh console <group> LOCAL), and the same for HTTP so ASDM uses the AAA server.
  2. 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.
  3. 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.
  4. 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.
  5. 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/generatetoken with Basic authentication and receive an X-auth-access-token valid for 30 minutes and an X-auth-refresh-token that 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 priv option. 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

ControlWhat it doesNotes from Cisco guidance
Threat detection for remote access VPNShuns sources of repeated failed authentication, incomplete client initiations and connections to internal tunnel groupsSupported 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 profilesRemoves AAA authentication and Hostscan from DefaultWEBVPNGroup and DefaultRAGroupRecommended where threat detection is not available; reduces but does not prevent denial of service
Group URLs instead of group aliasesUsers reach their profile by a specific URL, and the drop-down list of profiles is not shownStops attackers enumerating connection profiles
MFA on every connection profileSAML or RADIUS with phishing-resistant factors or number matchingCombine with certificate or posture checks for managed devices
Disable unused VPN web servicesTurns off SSL VPN and IKEv2 client services where not usedCisco'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 messageMeaningUse
%ASA-6-113005AAA authentication rejected by the serverPassword spraying against VPN or management
%ASA-6-113015User not found in the local databaseUsername guessing
%ASA-6-716039WebVPN authentication rejectedSSL VPN brute force
%ASA-5-111008 and %ASA-5-111010A user executed a command; a user made a configuration changeChange outside a window, or by an unexpected account
%ASA-6-605004 and %ASA-6-605005Management login denied or permittedAdmin 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

  1. 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.
  2. 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.
  3. Restrict management: remove outside-interface ssh and http statements, 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.
  4. 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.
  5. 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.
  6. Logging: central syslog at level 6, timestamps, NTP with authentication, alerts for silence and configuration change.
  7. 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 areaNIST SP 800-53 Rev. 5NIST CSF 2.0CIS Controls v8.1ATT&CK technique addressed
Patch VPN web services, retire EoS hardwareSI-2ID.RA-01, PR.PS-022.2, 7.7T1190 Exploit Public-Facing Application
Management restrictionSC-7, CM-7PR.PS-014.1, 12.3T1133 External Remote Services
TACACS+, command authorisation, MFAIA-2, AC-6, AU-12PR.AA-01, PR.AA-055.4, 6.5T1078 Valid Accounts
VPN threat detection and MFAAC-7, AC-17DE.CM-016.4T1110 Brute Force
Image and ROMMON integritySI-7DE.CM-094.1T1601 Modify System Image
Log protection and silence alertsAU-6, AU-9PR.PS-048.2, 8.9T1685 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, or write erase and 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

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

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 27 October 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org