VMware ESXi and vSphere Cluster Management

Secure Cisco IOS Images and Configuration Files with IOS Resilient Configuration

Learn how Cisco IOS Resilient Configuration protects the running IOS image and startup configuration, how to enable it, verify the primary bootset, and plan recovery.

Cisco IOS Resilient Configuration protects recovery copies of two critical device assets: the IOS software image and the startup configuration. This lesson explains how to enable and verify that protection, how it affects remote and console access, and which complementary controls are still required.

Why protect IOS software and configuration files?

A router depends on its IOS image to boot and operate. The image is a Cisco IOS software file normally stored in flash. If it is deleted, corrupted, or replaced with an unsuitable image, the device may fail to boot normally or may operate with unexpected software.

The startup-config is the saved configuration loaded when the device starts. It commonly contains interface settings, routing parameters, management controls, authentication settings, and other operational information. It is traditionally stored in NVRAM.

These files can be affected by accidental deletion, unauthorized remote access, incorrect maintenance commands, malicious replacement, hardware or storage problems, or a failure to save a known-good configuration. Losing the startup configuration can also remove the configuration needed to recover normal management access.

Protecting these files is a management-plane security measure. The management plane consists of the functions and interfaces used to configure, monitor, and administer a device. Resilient Configuration helps protect management-plane assets; it does not filter ordinary user traffic or replace data-plane security controls such as access control lists and segmentation.

What is Cisco IOS Resilient Configuration?

Cisco IOS Resilient Configuration is an IOS feature that creates protected working copies of the active IOS image and the startup configuration for recovery purposes. Together, these protected copies are called the primary bootset.

The protected copies are retained in flash and are intended to assist recovery when normal software or configuration files are damaged or removed. The feature is not a general backup system. It creates local protected copies on the device, so independently stored backups remain necessary.

Command availability and behavior depend on the Cisco platform and IOS release. Always confirm support, storage requirements, and maintenance procedures in the documentation for the specific device and software version before enabling, refreshing, replacing, or removing protected content.

Protection boundaries and access implications

Protected bootset files cannot be removed through remote access sessions. Disabling the resiliency feature requires access through the local console. A console session is a direct local management connection to the device console port; a remote session is a network-based administrative connection such as SSH.

Console-only removal is a safeguard against a remote administrator deleting the recovery copies. It is not a substitute for physical security. Anyone who can obtain unauthorized physical access may be able to interfere with the device, its console connection, or its storage.

Continue to use least privilege for remote administrative accounts. Apply AAA, role-appropriate authorization, secure SSH administration, logging, and strong authentication. An administrator who can make necessary configuration changes should not automatically receive every possible device-management privilege.

Storage locations and protected components

ComponentOriginal operational locationProtected copy locationWhy it matters
IOS imageFlash; this is the software file used to boot the deviceFlash, as part of the protected primary bootsetProvides a local recovery copy of the running system software
Startup configurationNVRAM; loaded during startupFlash, as a protected configuration copyPreserves a recoverable configuration even if the ordinary startup configuration is damaged or removed

Securing the running IOS image

The running image is the IOS software currently loaded and executing on the device. Before enabling protection, identify the running image and confirm that flash has sufficient capacity for the protected copy. Record the image filename, flash location, software version, and device identity.

Enter global configuration mode and run the image-protection command:

enable
configure terminal
secure boot-image

The command enables resiliency for the currently running IOS image. A successful operation reports that IOS image resiliency has been activated. Record that confirmation and later verify that an image entry appears in the protected bootset output.

Securing the startup configuration

The running-config is the active, in-memory configuration currently applied to the device. The startup-config is the saved configuration used at the next startup. Changes made to running-config do not automatically become part of startup-config.

Before protecting the configuration, review the active configuration and decide whether it is the intended boot-time state. If it is, save it:

copy running-config startup-config

Then enable configuration resiliency from global configuration mode:

enable
configure terminal
secure boot-config

The protected configuration copy is stored in flash rather than relying only on NVRAM. A successful operation reports that configuration resiliency has been activated. Save intended changes before creating or refreshing protected configuration state; otherwise, the protected copy may represent an older configuration.

IOS Resilient Configuration commands

CommandConfiguration modePurposeExpected result
secure boot-imageGlobal configuration modeProtects a copy of the currently running IOS imageIOS image resiliency activation message and a protected image entry after verification
secure boot-configGlobal configuration modeProtects a copy of the saved startup configurationConfiguration resiliency activation message and a protected configuration entry after verification
show secure bootsetPrivileged EXEC modeDisplays the protected primary bootsetOutput describing protected image and configuration state

Safe operational workflow

  1. Inspect current files. Identify the running IOS image, review flash contents, and compare running-config with startup-config.
  2. Save the desired configuration. Use copy running-config startup-config only after confirming that the active configuration is approved.
  3. Enable image protection. Enter global configuration mode and run secure boot-image.
  4. Enable configuration protection. Run secure boot-config after the intended startup configuration has been saved.
  5. Verify the bootset. Run show secure bootset and confirm both protected components.
  6. Document the baseline. Record the device identity, image filename, software version, flash paths, configuration state, activation date, and console-access procedure.

Planned IOS upgrades and significant configuration changes require an operational review of the protected bootset. Back up the existing configuration, collect the current verification output, follow the platform-specific upgrade process, and check the protected state again after the change. Consult platform documentation before attempting to replace, remove, or refresh resiliency-protected content.

Verifying the protected bootset

Run the following command from privileged EXEC mode:

show secure bootset

Use the output to confirm whether image and configuration resiliency are active. Typical fields include the router identifier, IOS resilience version, activation time, secure file location, protected file type, file size, image execution details, and configuration size.

Use the activation timestamps to determine when each protected component was created or refreshed. Compare the displayed file paths, image filename, software version, and size with the approved baseline. Confirm that the configuration timestamp corresponds to the recent approved change window.

  • An output containing only an image entry shows image protection but does not prove that configuration protection is active.
  • An output containing both an IOS image entry and a configuration entry indicates that both parts of the primary bootset are represented.
  • A configuration entry with an old activation time may be valid but stale relative to recent running or startup configuration changes.
  • A path or image identity that differs from the approved baseline should be investigated before relying on the protected copy for recovery.

Example: protect a known-good image

  1. Confirm which IOS image is currently running and verify sufficient flash capacity.
  2. Enter global configuration mode.
  3. Run secure boot-image.
  4. Confirm the successful image resiliency activation message.
  5. Run show secure bootset.
  6. Check that an image entry shows the expected flash path, filename, image details, and size.

Example: protect a finalized configuration

  1. Review running-config and startup-config.
  2. Save the active configuration if it is the intended boot configuration.
  3. Enter global configuration mode.
  4. Run secure boot-config.
  5. Confirm the successful configuration resiliency activation message.
  6. Run show secure bootset and confirm that a configuration entry appears.

Example: validate both components after hardening

  1. Run show secure bootset.
  2. Confirm separate entries for the IOS image and configuration.
  3. Compare the image identity and file location with the approved software baseline.
  4. Confirm that the configuration activation time matches the recent change window.
  5. Record the output and result in the device change record.

Preparing for an IOS upgrade

Before an IOS upgrade, back up the configuration off the device and collect the current bootset status. The upgrade process may change image files, boot variables, storage requirements, or resiliency behavior. Review the requirements for the exact platform and IOS release instead of assuming that the existing protected state will automatically be appropriate after the upgrade.

After the approved upgrade, verify the intended running image, startup configuration, boot settings, and protected bootset state. Record any required refresh or maintenance action. Do not delete or replace protected content through unsupported procedures.

Troubleshooting

Protection command is unavailable

If secure boot-image or secure boot-config is rejected, possible causes include an unsupported platform or IOS version, an incorrect command mode, or insufficient privilege.

  • Confirm that the prompt indicates global configuration mode for the secure commands.
  • Check the IOS version and platform feature support.
  • Consult platform documentation for command syntax and restrictions.
  • Use an appropriately privileged administrative session.

Verification shows an image but no configuration

The configuration command may not have been executed, the operation may not have completed, or the device may have been checked before the operation finished. Confirm that the intended startup-config is saved, run secure boot-config in global configuration mode, and run show secure bootset again.

Protected configuration does not include recent changes

Recent changes may exist only in running-config, or startup-config may not have been updated before protection was enabled. Compare both configurations, save the approved state, and follow the platform-specific process for refreshing protected configuration state after a change window.

Remote administrator cannot remove protected files

This is expected protection behavior. Use authorized local console access for operations that require disabling the protection. Validate identity, authorization, maintenance approval, and physical access controls before proceeding.

Local emergency access is unavailable

Console access must be planned. Maintain documented console and out-of-band access procedures, test authorized emergency access during approved exercises, and protect console access with physical and administrative controls.

Limitations and complementary controls

IOS Resilient Configuration does not prevent every compromise scenario. A privileged attacker may still change the active configuration, alter other device settings, disrupt services, or compromise the device through means not addressed by local protected copies.

ControlWhat it protectsWhat it does not replace
IOS Resilient ConfigurationLocal protected copies of the IOS image and startup configurationOff-device backups, access control, image integrity validation, logging, and physical security
Off-device configuration backupIndependent copies that remain available if the device or its flash storage is lostLocal recovery copies or secure administrative access
AAA and privileged access controlAuthentication, authorization, and accounting for administratorsRecovery copies and physical protection
SSH-based managementEncrypted network-based administrative sessionsProtection from every privileged misuse or storage failure
Physical securityDevice, console, and local storage accessOff-device backup, software integrity validation, and administrative authorization

Use encrypted management protocols, role-based administrative access, centralized logging, time synchronization, image integrity validation, independent configuration backups, and appropriate physical security. Test recovery procedures during approved maintenance windows so that the team knows how to use the protected copies and external backups when needed.

Exam-relevant notes

  • The IOS image is the software currently used to boot and operate the device; the running image is the image currently loaded and executing.
  • Running-config is active in memory, while startup-config is the saved configuration used at startup.
  • The primary bootset consists of protected copies of the IOS image and startup configuration.
  • secure boot-image and secure boot-config are entered from global configuration mode.
  • show secure bootset verifies protected image and configuration entries.
  • Remote sessions cannot remove protected bootset files or disable the feature; disabling requires local console access.
  • Resiliency is not a replacement for off-device backups, AAA, SSH, logging, image validation, or physical security.
  • Feature support and behavior must be confirmed for the particular Cisco platform and IOS release.

Key takeaway

Enable IOS Resilient Configuration only after identifying a known-good running image and saving the intended startup configuration. Then verify that show secure bootset displays both protected components, document the baseline, and maintain independent recovery and access controls.

Related lesson: Secure IOS images and files.