Network Configuration Backup and Change Control Guide

The configuration archive for your routers, switches and firewalls is a copy of every device's credentials, keys and topology in one place, and it is often protected less carefully than the devices themselves. Teams back up device configurations so they can roll back a bad change or rebuild a failed box, which is the right instinct. The same archive is what an attacker collects first, because a configuration dump hands over local account hashes, SNMP community strings, TACACS+ and RADIUS keys, VPN pre-shared keys and a map of the network. This guide covers how to build a configuration archive that is safe to keep: what to capture, how to transfer and store it, how to scrub or protect the secrets inside, how to diff configurations against approved changes, and how to restore with a safety net. It is written for network engineers, network automation teams and the security architects who review them. Management plane hardening and syslog detection have their own guides, linked below; this page focuses on the archive and the change loop around it.

Key takeaways

A config archive is a credential store. Treat the repository, the backup server and the collector's login as privileged assets with the same controls as a vault.
The device is not the source of truth. CISA's communications infrastructure guidance says to store configurations centrally, push them to devices and compare regularly, so the archive becomes the baseline you enforce.
Weak password types turn a leaked file into a breach. Hashes and reversible types in the file decide how much damage a stolen copy does; CISA and NSA recommend Type 8 for Cisco local passwords.
Every diff should match a ticket. A nightly comparison that reconciles each change against an approved change record is one of the cheapest detections for a compromised device.
Restore with a timer. Use confirmed-commit or revert timers so a bad restore or change rolls itself back if the engineer loses access.

Why configuration archives are a target

MITRE ATT&CK describes adversaries collecting device configurations as Network Device Configuration Dump (T1602.002), a sub-technique of Data from Configuration Repository (T1602). Stolen files are then mined for credentials, which ATT&CK tracks under Credentials In Files (T1552.001). NSA's guidance on Cisco password types notes that every device has plaintext configuration files holding pre-shared keys and user authentication information, and that those credentials can be compromised if strong password types are not used. CISA's August 2024 alert on Cisco device configuration reported attackers obtaining configuration files through existing protocols and the legacy Smart Install feature, and continued use of weak password types that make cracking easier.

The Salt Typhoon telecom intrusions show both halves of the problem: Cisco Talos reported that the group pulled device configurations, often over TFTP or FTP, that held SNMP read and write community strings and local accounts with weak password encryption, and it later modified configurations, changing AAA and TACACS+ server addresses and altering ACLs. A protected archive limits the first; a diff against approved change catches the second. See the Salt Typhoon Threat Actor Profile.

Secret in a typical config	What exposure gives an attacker	Archive-side control
Local user and enable passwords	Direct device login if the hash is weak or reversible	Type 8 hashing on Cisco (CISA, NSA); local accounts only for break-glass; rotate after any archive exposure
SNMP v1/v2c community strings	Read, and with read-write strings change, device configuration	Move to SNMPv3 with authentication and encryption; treat v3 user keys as secrets
TACACS+ and RADIUS shared keys	Impersonation of the AAA server or decryption of AAA traffic	Type 6 encryption where supported (CISA); unique key per device group
VPN pre-shared keys and certificates	Rogue tunnel endpoints	Certificate-based authentication where possible; keys stored in a vault, not the archive
Routing protocol authentication keys	Route injection	Rotate on exposure; restrict archive read access
Interface addressing, ACLs and topology	Reconnaissance and a map of the management plane	Need-to-know access; encryption at rest

What to capture and how often

Running and startup configuration: Capture both. A difference between them shows unsaved changes, which is either work in progress or someone hoping a reload hides their edit.
Trigger on change, plus a schedule: Capture after every commit or save event and on a fixed interval as a backstop. Junos supports both: transfer-on-commit sends the active configuration to an archive site after each commit, and transfer-interval sends it periodically, between 15 and 2,880 minutes, under [edit system archival configuration].
Software version and image hash: Record the running version and image hash with each capture so the archive also answers what was running, not only how it was configured. See the Vulnerability Management for Network Devices Guide.
Cloud and controller-managed networks: For SD-WAN, wireless controllers and cloud network services, back up the controller or API state, because the devices may hold only pushed fragments.
Metadata: Device name, collector identity, timestamp in UTC (Junos archive filenames use UTC by default), and the change ticket if the capture was triggered by a change.

Transfer and storage: making the archive safe to keep

Decision	Do this	Avoid
Transfer protocol	SCP, SFTP or HTTPS, or pull over SSH by the collector	TFTP and FTP, which CISA lists among plaintext services to disable
Direction	Collector pulls from devices on the management network	Devices pushing to a general file server reachable from user networks
Collector credentials	A dedicated read-only account per collector, held in a vault, authenticated through central AAA	Reusing a shared admin account or embedding `user:password@host` in an archive URL on every device
Storage	Version control or a backup system with encryption at rest, access logging and immutable or retained copies	A share on a jump host, an engineer's laptop or a ticket attachment
Access	Read limited to network engineering and named automation identities; write limited to the collector	Organisation-wide read on the repository "because it is only configs"
Copies	An offline or separately administered copy for rebuild after a compromise	Only one copy, on infrastructure the attacker can also reach

The Junos archival documentation shows a password inside the archive site URL in one syntax example, and a separate password keyword in another. Whichever form your platform uses, that credential sits in every device configuration, so it must be scoped to write-only access to one drop location and rotated like any other device secret.

Handling the secrets inside the files

Fix the source first: Move Cisco local passwords to Type 8 and avoid Type 5 and Type 7, as CISA's communications infrastructure guidance recommends, and use Type 6 for keys that must be reversible. A stolen file with strong hashes is far less useful.
Scrub a working copy: Keep a sanitised copy, with secrets replaced by placeholders, for diffing, review and sharing with vendors or auditors. Keep the full copy, needed for bare-metal restore, in a tighter store.
Template secrets out: Where configurations are generated from templates, hold secrets in a secrets manager and inject them at deploy time, so the source repository never holds them. See the Infrastructure as Code Security Guide.
Scan the archive: Run secret scanning over the repository history to find keys committed before the scrubbing rule existed, then rotate them.

Diffing changes against approved change

CISA says to monitor configuration and, if feasible, test and override on a frequent basis, and to scrutinise any modification made outside change management. In practice that means a nightly (or per-change) comparison of each device's live configuration with its last approved version.

Normalise: Strip volatile lines such as timestamps, uptime counters and certificate refresh fields so the diff shows only meaningful change.
Classify: Mark high-risk stanzas: AAA servers, local users, SNMP, logging targets, ACLs on management interfaces, routing authentication and NTP. These are the changes an attacker makes.
Reconcile: Match each diff to a change record by device, time window and implementer. The Change Management Security guide covers the change process itself.
Alert or revert: Unmatched high-risk changes go to the SOC as a potential incident. For devices under full automation, the pipeline can push the approved version back, but only after triage, so evidence is not overwritten.
Record: Keep the diff, the ticket reference and the outcome as audit evidence.

Log-based detection of configuration change events complements the diff: the log says who changed it and when, the diff says exactly what changed. See the Network Device Syslog and Configuration Change Detection Guide and the Configuration Drift and Baseline Enforcement Guide.

Restoring safely

Use a revert timer: On Junos, commit confirmed applies a change and reverts automatically to the prior configuration if it is not confirmed, by default after 10 minutes, and broadcasts a message to logged-in users. Cisco IOS and IOS XE offer configuration archive, configuration replace and rollback features with a confirmation option; check the configuration guide for your release, as syntax varies.
Verify integrity before use: NIST CSF 2.0 RC.RP-03 asks that the integrity of backups is verified before they are used for restoration. Check the stored hash and the source of the file, and diff it against the last known-good version before applying it.
Restore from before the compromise: After a suspected device compromise, the most recent backup may contain the attacker's changes. Pick a version from before the first unexplained diff, then re-apply legitimate later changes deliberately. See the Network Rebuild After Compromise Playbook.
Rotate after restore: A restored configuration brings back old secrets. If the archive or the device was exposed, rotate local passwords, SNMP and AAA keys after the restore, not before.
Test restores: Restore a sample of device configurations into a lab or virtual device each quarter, so the first test is not during an outage.

Where identity fits

The configuration collector is a non-human identity with read access to every network device and write access to the most sensitive file store in the network team. Give it its own account per collector instance, authenticate it through TACACS+ or RADIUS with command authorisation limited to show and copy operations, hold its credential in a vault with rotation, and alert on any interactive login with it. The automation identity that pushes approved configurations is more powerful still and should be separate from the collector. See the Network Device Management Plane Hardening Guide for AAA design and the Ansible and AWX Security Guide where Ansible is the push tool.

Rolling it out

Inventory (weeks 1 to 2): List every device, where its configuration is backed up today, by what account and over what protocol. Expect to find TFTP jobs, personal scripts and copies in tickets.
Secure the store (weeks 2 to 4): Move the archive to an encrypted, access-logged repository with named access. Remove copies from shares and mailboxes.
Fix transport and credentials (weeks 3 to 8): Switch to SCP, SFTP or SSH pull, issue dedicated collector accounts, and disable TFTP where it is no longer needed. Pilot on a small device group, then extend by site.
Strengthen secrets in configs (ongoing): Migrate password types and SNMP versions per device class through normal change, starting with internet-facing and core devices.
Turn on diff and reconcile (weeks 6 to 10): Start in report-only mode, tune normalisation, then route unmatched high-risk diffs to the SOC.
Prove restore (quarterly): Run restore tests and record results. Roll back any step by keeping the old collector running in parallel until the new one has a full cycle of clean captures.

Small and large estates: A small organisation with a few firewalls and switches can meet most of this with vendor-native scheduled backup to SCP and a weekly manual diff. A large estate needs a dedicated collection platform, a source-of-truth model and automated reconciliation with the ITSM change record, because manual comparison does not scale beyond a few dozen devices.

Detection and measurement

Metric	What it shows	Target direction
Devices with a successful capture in the last 24 hours	Archive coverage	Close to 100%
Devices still backed up over TFTP or FTP	Plaintext exposure	Zero
High-risk diffs not matched to a change record	Unauthorised or undocumented change	Zero open beyond one working day
Devices with deprecated password types or SNMP v1/v2c	Damage a leaked file would do	Falling each quarter
Successful test restores in the last quarter	Recoverability	All device classes covered
Named identities with read access to the full archive	Blast radius of one compromised account	Small and reviewed

Monitor the archive itself: alert on bulk reads, reads by identities outside the network team, and interactive logins by collector accounts.

Framework mapping

Framework	Reference	How this guide applies it
NIST SP 800-53 Rev. 5	CM-2 Baseline Configuration, CM-3 Configuration Change Control, CM-5 Access Restrictions for Change	Archived approved version as baseline; diff reconciled to change; restricted push identities
NIST SP 800-53 Rev. 5	CP-9 System Backup, CP-10 System Recovery and Reconstitution, SC-28 Protection of Information at Rest	Protected, tested configuration backups and restore
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management	Password types and secrets in configurations; collector credentials
NIST CSF 2.0	PR.PS-01, PR.DS-11, RC.RP-03	Configuration management; protected backups; integrity check before restore
CIS Critical Security Controls	Control 12 Network Infrastructure Management	Network infrastructure management
MITRE ATT&CK	T1602.002, T1552.001	Threats the archive controls and diff address

Common failure patterns

TFTP backups that never went away: A job set up years ago still copies every configuration in clear text across the network.
Archive on a general file share: The configs sit where any domain user, or any attacker with a domain user, can read them.
Diffs nobody reconciles: The tool emails a nightly diff to a shared mailbox; changes to AAA servers or ACLs pass unnoticed, the pattern seen in the Salt Typhoon intrusions.
Restoring the attacker's version: The latest backup is restored after an incident, reinstating rogue accounts or AAA servers.
One shared admin account for collection: The collector uses an engineer's or a shared privileged account, so its credential grants full device control and its activity is indistinguishable from people.
Secrets left in after the hash upgrade: Password types were improved on devices, but old archive versions with weak hashes remain readable in repository history.

Practitioner checklist

Capture running and startup configurations on every change and on a schedule.
Use SCP, SFTP or SSH pull; disable TFTP and FTP for configuration transfer.
Give each collector its own least-privilege account through central AAA, held in a vault.
Store the archive encrypted, access-logged and restricted to named identities, with a separately administered copy.
Move Cisco local passwords to Type 8 and move SNMP to v3 with authentication and encryption.
Keep a scrubbed copy for diffing and sharing, and scan repository history for secrets.
Reconcile every high-risk diff against a change record and send unmatched ones to the SOC.
Restore with revert timers, verify file integrity first and rotate secrets after a restore following compromise.
Test restores quarterly and report the six metrics above.

Network Configuration Backup and Change Control: Archive, Diff and Restore Device Configs Safely