Cisco ASA Upgrade and Backup Procedure

Backup before you change. Upgrade in a maintenance window. Test the rollback path before you need it. The Cisco ASA upgrade and backup procedures are unglamorous but they are the difference between a smooth Tuesday and a 2am bridge call. This article walks the production-ready procedure: what to back up, how to copy it off-box, how to stage a new image to flash, set the boot variable, reload, verify, and roll back if needed. The procedure works equally for a single ASA and a failover pair, with the pair-specific notes called out where they matter.

This is an Operations article in the Cisco ASA cluster. It pairs with common outages (which covers what to do when an upgrade goes wrong) and active/standby failover (which is the foundation for zero-downtime upgrades).

What to Back Up Before Touching Anything

The "external record" rows are the most-overlooked part of an ASA backup. The text config does not contain the actual PSK or shared secret values; the box stores them encrypted and prints ***** in show running-config. You cannot reconstruct a tunnel-group from the config alone if you lose the original PSK list.

Copy the Config Off-Box

SCP is the modern way. SFTP and FTP also work. TFTP is for the lab only.

ASA-PERIM# copy running-config scp://backup-user@10.10.0.30/asa-perim/asa-perim-2026-05-10.cfg
Source filename [running-config]?
Address or name of remote host [10.10.0.30]?
Destination username [backup-user]?
Destination password []? **********
Destination filename [asa-perim/asa-perim-2026-05-10.cfg]?
Writing file scp://10.10.0.30/asa-perim/asa-perim-2026-05-10.cfg
!!!!!!!!!!!!!!!!!
12834 bytes copied in 1.220 secs (10519 bytes/sec)

For automated nightly backups, set up a scheduled cron on a backup host that pulls via SSH and the show-running-config command, or use a config-management tool (Solarwinds NCM, Oxidized, etc.) that does the same in a structured way.

Export Certificates and Keys

Identity certificates and the private keys behind them ride in the running config in encrypted PKCS#12 form. To export them, pick a passphrase (record it in your vault) and run:

ASA-PERIM(config)# crypto ca export ASDM-CERT pkcs12 BackupPassphr@se
Exported pkcs12 follows:
-----BEGIN PKCS12-----
MIIJ4QIBAzCCCacGCSqGSIb3DQEHAaCCCZgEggmUMIIJkDCCBgkGCSqGSIb3DQEHAaCCBfoEggX2
[base64 continues for several KB]
-----END PKCS12-----
ASA-PERIM(config)#

Copy the entire base64 block (between the BEGIN and END lines) into a file in your secrets store. To restore on a replacement ASA, paste it back with crypto ca import TRUSTPOINT pkcs12 PASSPHRASE. See trustpoints and certificates for the full cert lifecycle.

Stage the New Image to Flash

Cisco distributes ASA images as .SPA files on cisco.com. Get the file (and the MD5/SHA512 from the download page), then push it to the ASA's flash:

ASA-PERIM# copy scp://image-user@10.10.0.30/asa9-23-2-smp-k8.SPA disk0:/
Address or name of remote host [10.10.0.30]?
Source filename [asa9-23-2-smp-k8.SPA]?
Destination filename [asa9-23-2-smp-k8.SPA]?
Destination password []? **********
Accessing scp://image-user@10.10.0.30/asa9-23-2-smp-k8.SPA...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
116231632 bytes copied in 24.560 secs (4732097 bytes/sec)

Verify the image is intact and is what Cisco signed:

ASA-PERIM# verify /sha-512 disk0:/asa9-23-2-smp-k8.SPA
Verifying file integrity of disk0:/asa9-23-2-smp-k8.SPA...
....................................................................
Computed Hash:   SHA2:7a3c8f2d ... [matches the value from cisco.com]
Embedded Hash:   SHA2:7a3c8f2d ... [matches Cisco's embedded signature]
Computed signature: PASS
ASA-PERIM#

Both hashes match and the embedded-signature check passes. If either fails, do not boot the image - re-download from Cisco. A bad image will not boot, and on a remote box that means a console-cable trip.

Set the Boot Variable

The boot system command tells the ASA which image to load on the next reload. Multiple boot system lines are allowed; the ASA tries them in order and falls back if the first is corrupted or missing.

ASA-PERIM(config)# show running-config boot
boot system disk0:/asa9-23-1-smp-k8.SPA
!
ASA-PERIM(config)# boot system disk0:/asa9-23-2-smp-k8.SPA
ASA-PERIM(config)# no boot system disk0:/asa9-23-1-smp-k8.SPA
ASA-PERIM(config)# boot system disk0:/asa9-23-1-smp-k8.SPA      ! re-add the old as the fallback
!
ASA-PERIM(config)# show running-config boot
boot system disk0:/asa9-23-2-smp-k8.SPA
boot system disk0:/asa9-23-1-smp-k8.SPA
ASA-PERIM(config)# write memory

Order matters. The first boot system wins; the second is the safety net. If the new image refuses to boot, the ASA falls back to the second line and you reload back into the working version.

Reload and Verify

Single-ASA reload is one command:

ASA-PERIM# reload
Proceed with reload? [confirm]

The box drops the console for 3-5 minutes (longer on hardware ASA with bigger image trees). After it comes back:

ASA-PERIM# show version | include System image|Compiled
System image file is "disk0:/asa9-23-2-smp-k8.SPA"
Compiled on 2026-04-15 12:34 by builder

Image is the new one. Sanity-check the rest:

ASA-PERIM# show interface ip brief        ! All data interfaces up?
ASA-PERIM# show route                     ! Default + static routes intact?
ASA-PERIM# show xlate count               ! Traffic flowing?
ASA-PERIM# show conn count                ! Conns building?
ASA-PERIM# show vpn-sessiondb summary     ! Active VPN sessions?
ASA-PERIM# show failover                  ! (if HA pair) Both units up, sync OK?

If anything looks wrong, the rollback path is just another reload after re-ordering the boot system lines.

Upgrading a Failover Pair (Hitless)

Active/standby failover lets you upgrade with no traffic loss. The Cisco-recommended sequence:

1. Copy the new image to both units' flash. The standby auto-syncs config, but does not auto-sync image files.
2. Set boot system disk0:/NEW-IMAGE.SPA on both units (config replicates).
3. Reload the standby first: failover reload-standby. This reloads the standby unit only; it boots the new image and rejoins the pair as a now-current standby.
4. Verify on the active: show failover state should show standby unit healthy and on the new version.
5. Force a switchover: no failover active on the active (or failover active on the standby). The standby (new image) becomes active. Existing TCP conns survive because of stateful failover. See stateful failover.
6. Reload the now-standby (which is on the old image): failover reload-standby.
7. Both units now on the new image. Optionally failover active back to the original primary if you care about which physical unit is active.

Cisco's TAC notes that some major-version jumps are not "hitless-failover-safe" - the version skew during the rolling upgrade is not always clean. Read the release notes for your target version's "Upgrade Path" section. The 9.x to 9.x point-version upgrades are almost always safe; cross-major (8.x to 9.x or 9.x to 10.x) often require both units off-active for the cutover.

Rollback

Two scenarios:

The box booted the new image but something is broken. Re-order the boot system lines so the old image is first, save, reload.

ASA-PERIM(config)# no boot system disk0:/asa9-23-2-smp-k8.SPA
ASA-PERIM(config)# no boot system disk0:/asa9-23-1-smp-k8.SPA
ASA-PERIM(config)# boot system disk0:/asa9-23-1-smp-k8.SPA
ASA-PERIM(config)# boot system disk0:/asa9-23-2-smp-k8.SPA
ASA-PERIM(config)# write memory
ASA-PERIM# reload

The box did not come back up after the upgrade reload. You are in ROMmon-or-console territory. Console in, interrupt the boot, set the ROMmon boot variable to the old image:

rommon> boot disk0:/asa9-23-1-smp-k8.SPA

Once it boots, fix the boot lines in the running config and save. The remote restore-from-backup procedure (TFTP server reachable from the management interface, point ROMmon at it) is what to use if disk0 itself is corrupt - which is rare but does happen.

Restore from Backup

To restore a config to a fresh ASA:

! Console into the new box.
! Set up enough of the management interface to reach SCP source.
ciscoasa(config)# interface Management0/0
ciscoasa(config-if)#  nameif management
ciscoasa(config-if)#  ip address 10.10.99.1 255.255.255.0
ciscoasa(config-if)#  no shutdown
ciscoasa(config)# route management 10.10.0.0 255.255.0.0 10.10.99.254 1
!
ciscoasa# copy scp://backup-user@10.10.0.30/asa-perim/asa-perim-2026-05-10.cfg running-config

The config loads, the interfaces re-IP themselves, and SSH/AAA come back online. Save it: write memory. Then re-import any certificates with crypto ca import from your PKCS#12 backup.

Pre-Upgrade Checklist

1. Read the release notes for the target version's Upgrade Path and Open Caveats.
2. Confirm sufficient flash free space (show disk0:).
3. Back up startup-config, running-config, certificates, PSK list.
4. Stage the new image to flash on both units (failover pair).
5. Verify the image hash and signature.
6. Set boot system NEW with the old image as the fallback.
7. write memory.
8. Identify and notify users of the maintenance window.
9. Have console access ready in case the remote management interface is the thing that breaks.
10. Reload (failover pair: standby first), then run the verification show commands.

Key Takeaways

Backups before changes, image hashes before reloads, two boot system lines for rollback safety, and console access at the ready. SCP is the modern transport for both config and image transfers. PKCS#12 export is the only way to back up certificates and their private keys. Failover pairs upgrade hitless if you reload the standby first and let stateful sync carry the conns through the switchover.

For the things that go wrong during or after an upgrade, see common outage scenarios. For the rest of the cluster, the Cisco ASA pillar has the full reading order.