Important Guidelines Before You Upgrade
Check for upgrade guidelines and limitations, and configuration migrations for each operating system.
ASA Upgrade Guidelines
Before you upgrade, check for migrations and any other guidelines.
Version-Specific Guidelines and Migrations
Depending on your current version, you might experience one or more configuration migrations, and have to consider configuration guidelines for all versions between the starting version and the ending version when you upgrade.
9.24 Guidelines
-
ASDM 7.24 requires Java 11—ASDM 7.24 now requires Java 11. For the Oracle version, which is the version bundled with the ASA image, you will need to install Oracle JDK 11: https://www.oracle.com/java/technologies/javase/jdk11-archive-downloads.html. Later versions are not compatible. To minimize risk and ensure better compatibility and stability with Java, we are taking a phased approach to moving off of Java 8, starting with this move to Java 11. If you upgrade to the ASDM Launcher 1.9(10) or later that comes with 7.24, you can still launch earlier versions of ASDM.
For the OpenJRE version, you do not need to install Java; it is built-in.
-
ASA Virtual cannot be downgraded from 9.24—After upgrading to 9.24, which includes a new Grub bootloader, you cannot downgrade to an earlier version. To upgrade to later versions, you will first have to upgrade to 9.24.
9.23 Guidelines
-
The ASA SSH stack was deprecated in 9.23—You can no longer use the ASA SSH stack. The Cisco SSH stack is now the only stack. Because the Cisco SSH stack does not support EDDSA, before you upgrade you must change your configuration for a supported key pair:
-
Generate the default key pair.
crypto key generate {ecdsa elliptic-curve size | rsa modulus size}
Do not add the label keyword; SSH only uses the default key pair (named Default-type-Key).
-
If you configured the ssh key-exchange hostkey eddsa command, you need to remove it with the no form. If you use this command, you may get unexpected results.
-
9.22 Guidelines
-
Smart licensing default transport changed in 9.22—In 9.22, the smart licensing default transport changed from Smart Call Home to Smart Transport. You can configure the ASA to use Smart Call Home if necessary using the transport type callhome command. When you upgrade to 9.22, the transport is automatically changed Smart Transport. If you downgrade, the transport is set back to Smart Call Home, and if you want to use Smart Transport, you need to specify transport type smart . Note also that the licensing URL for Smart Transport is https://smartreceiver.cisco.com (compared to tools.cisco.com), so be sure to allow that URL on upstream routers.
-
For models with built-in-switches, subinterfaces can't use VLAN 1 in 9.22 and later—For models with built-in switches, you cannot create a subinterface using VLAN 1. VLAN 1 is reserved for the logical VLAN interface for switch ports. If you upgrade a 1010 to 9.22(1) or later, and you have assigned VLAN 1 to a subinterface, you must first change the VLAN ID for your subinterface to a new VLAN. After upgrading, if present, VLAN 1 will be removed from the subinterface.
9.20 Guidelines
-
Smart licensing default transport changed in 9.20(4)—In 9.20(4), the smart licensing default transport changed from Smart Call Home to Smart Transport. You can configure the ASA to use Smart Call Home if necessary using the transport type callhome command. When you upgrade to 9.20(4), the transport is automatically changed to Smart Transport. If you downgrade, the transport is set back to Smart Call Home, and if you want to use Smart Transport, you need to specify transport type smart . Note also that the licensing URL for Smart Transport is https://smartreceiver.cisco.com (compared to tools.cisco.com), so be sure to allow that URL on upstream routers.
-
OSPFv3 redistribute commands that specify a route-map that matches a prefix-list will be removed in 9.20(2)—When you upgrade to 9.20(2), OSPFv3 redistribute commands where the specified route-map uses a match ip address prefix-list will be removed from the configuration. Although prefix lists have never been supported, the parser still accepted the command. Before upgrading, you should reconfigure OSPFv3 to use route maps that specify an ACL in the match ip address command.

Remember
Redistribution of route maps with IPv4 prefix list on OSPFv2 is supported.
9.19 Guidelines
-
ASDM 7.19(1) requires Oracle Java version 8u261 or later—Before you upgrade to ASDM 7.19, be sure to update Oracle Java (if used) to version 8u261 or later. This version supports TLSv1.3, which is required to upgrade the ASDM Launcher. OpenJRE is not affected.
9.18 Guidelines
-
ASDM signed-image support in 9.18(2)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)
-
9.18(1) upgrade issue if you enabled HTTPS/ASDM (with HTTPS authentication) and SSL on the same interface with the same port—If you enable both SSL (webvpn > enable interface) and HTTPS/ASDM (http ) access on the same interface, you can access AnyConnect from https://ip_address and ASDM from https://ip_address/admin, both on port 443. However, if you also enable HTTPS authentication (aaa authentication http console), then you must specify a different port for ASDM access starting in 9.18(1). Make sure you change the port before you upgrade using the http command. (CSCvz92016)
-
ASDM Upgrade Wizard—Due to ASD API migration, you must use ASDM 7.18 or later to upgrade to ASA 9.18 or later. Because ASDM is backwards compatible with earlier ASA versions, you can upgrade ASDM to 7.18 or later for any ASA version.
9.17 Guidelines
-
ASDM signed-image support in 9.17(1.13)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)
-
No support for Clientless SSL VPN in 9.17(1) and later—Clientless SSL VPN is no longer supported.
-
webvpn—The following subcommands are removed:
-
apcf
-
java-trustpoint
-
onscreen-keyboard
-
port-forward
-
portal-access-rule
-
rewrite
-
smart-tunnel
-
-
group-policy webvpn—The following subcommands are removed:
-
port-forward
-
smart-tunnel
-
ssl-clientless
-
-
-
ASDM Upgrade Wizard—Due to an internal change, starting in March 2022 the upgrade wizard will no longer work with pre-ASDM 7.17(1.152) versions. You must manually upgrade to 7.17(1.152) to use the wizard.
9.16 Guidelines
-
ASDM signed-image support in 9.16(3.19)/7.18(1.152) and later—The ASA now validates whether the ASDM image is a Cisco digitally signed image. If you try to run an older ASDM image with an ASA version with this fix, ASDM will be blocked and the message “%ERROR: Signature not valid for file disk0:/<filename>” will be displayed at the ASA CLI. ASDM release 7.18(1.152) and later are backwards compatible with all ASA versions, even those without this fix. (CSCwb05291, CSCwb05264)
-
SNMPv3 users using MD5 hashing and DES encryption are no longer supported, and the users will be removed when you upgrade to 9.16(1)—Be sure to change any user configuration to higher security algorithms using the snmp-server user command before you upgrade.
-
SSH host key action required in 9.16(1)—In addition to RSA, we added support for the EDDSA and ECDSA host keys for SSH. The ASA tries to use keys in the following order if they exist: EDDSA, ECDSA, and then RSA. When you upgrade to 9.16(1), the ASA will fall back to using the existing RSA key. However, we recommend that you generate higher-security keys as soon as possible using the crypto key generate {eddsa | ecdsa} command. Moreover, if you explicitly configure the ASA to use the RSA key with the ssh key-exchange hostkey rsa command, you must generate a key that is 2048 bits or higher. For upgrade compatibility, the ASA will use smaller RSA host keys only when the default host key setting is used. RSA support will be removed in a later release.
-
In 9.16 and later, certificates with RSA keys are not compatible with ECDSA ciphers—When you use the ECDHE_ECDSA cipher group, configure the trustpoint with a certificate that contains an ECDSA-capable key.
-
ssh version command removed in 9.16(1)—This command has been removed. Only SSH version 2 is supported.
-
When you upgrade to 9.16 or later, you might see a different certificate serial number—In 9.16, the ASA started using OpenSSL, which causes negative values in certificates to be computed differently, so you may see a different serial number after upgrading. This change does not affect operation. (CSCvv30338)
-
SAMLv1 feature removed in 9.16(1)—Support for SAMLv1 was removed.
-
No support for DH groups 2, 5, and 24 in 9.16(1)—Support has been removed for the DH groups 2, 5, and 24 in SSL DH group configuration. The ssl dh-group command has been updated to remove the command options group2, group5, and group24.
Clustering Guidelines
There are no special requirements for Zero Downtime Upgrades for ASA clustering.
![]() Note |
Zero Downtime Downgrades are not officially supported with clustering. |
Failover Guidelines
There are no special requirements for Zero Downtime Upgrades for failover with the following exceptions:
-
Upgrade issue with GTP inspection—There could be some downtime during the upgrade, because the GTP data structures are not replicated to the new node.
FXOS Upgrade Guidelines
Before you upgrade, read the release notes for each FXOS version in your chosen upgrade path. Release notes contain important information about each FXOS release, including new features and changed functionality.
Upgrading may require configuration changes that you must address. For example, new hardware supported in an FXOS release might also require that you update the FXOS firmware.
FXOS release notes are available here: https://www.cisco.com/c/en/us/support/security/firepower-9000-series/products-release-notes-list.html.
Feedback