{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/prove-network-device-rebuild-known-good-configuration/", "item": { "id": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/", "slug": "prove-network-device-rebuild-known-good-configuration", "url": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration.md", "json": "https://update.dsesecurity.com/api/v1/posts/prove-network-device-rebuild-known-good-configuration/" }, "title": "Prove a network device can be rebuilt from a known-good configuration", "summary": "A copied running configuration is not yet a recovery capability. Prove that hardware, firmware, licensing, identity, certificates, secrets, dependencies, telemetry, and business traffic can be restored together.", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/", "type": "Person" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-17T13:19:00+00:00", "modified_at": "2026-08-17T19:22:09+00:00", "reviewed_on": "2026-08-17", "reading_minutes": 3, "word_count": 646, "potentially_affected": "Routers; switches; firewalls; wireless controllers; load balancers; configuration archives; firmware images; licenses; certificates; secrets; AAA; routing; monitoring; and network recovery plans.", "dse_recommendation": "Define a complete recovery package for each device class, protect and version it, rebuild representative equipment in isolation, validate management and business traffic, record timing and gaps, and repeat after material change.", "primary_source": { "name": "CISA Disable Cisco Smart Install Feature (CM0014)", "url": "https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0014", "published_on": "2025-03-14", "authority": "Cybersecurity and Infrastructure Security Agency" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Source facts: known-good material supports secure device restoration

\n

CISA’s Disable Cisco Smart Install Feature (CM0014) is a countermeasure for a specific legacy Cisco provisioning feature, not a general network-backup standard. CISA says Smart Install can be abused to access, copy, or poison startup configuration files or modify Cisco IOS. When administrators determine that a device was abused, the guidance says to isolate it and restore its image and configuration to a secure state; that may include a known-good configuration backup, a factory reset, and current vendor patches. It also says to preserve a tampered configuration or other evidence during investigation.

\n

NIST SP 800-128 describes baselines, change control, configuration monitoring, and the preservation of approved configuration information. CISA’s communications-infrastructure hardening guidance emphasizes secure management, centralized logging, visibility, backups, and preparation for recovery from unauthorized change.

\n

A text export alone may not recreate the device. Recovery can depend on compatible hardware, bootloader and firmware, feature licenses, certificates and private keys, secret values omitted from exports, identity services, routing neighbors, controller state, cloud entitlements, cabling, upstream configuration, time, DNS, and vendor-specific restore behavior. A successful command import also does not prove that production services or security controls work.

\n\n

DSE recommendation: test a full device recovery package

\n

Choose representative critical devices and prove the rebuild in an isolated environment or approved maintenance exercise. Treat every discovered dependency as a corrective action, not an informal note.

\n
    \n
  1. Define the recovery target. Record device role, critical services, site, hardware and module identifiers, software train, desired recovery time, acceptable data loss, configuration owner, support status, and approved replacement models. Prioritize devices that are single points of failure or trust boundaries.
    2. \n
  2. Assemble the package. Preserve startup and running configuration, firmware and hashes, boot variables, licenses or entitlement steps, certificates and renewal details, secrets through an approved vault, inventory, diagrams, port mapping, dependencies, console settings, recovery contacts, and a dated known-good reference.
    3. \n
  3. Protect the evidence. Encrypt sensitive backups, separate backup administration from device administration, use immutable or offline copies where appropriate, log access, restrict exports, and verify integrity. Keep recovery material available when normal identity, DNS, network, or cloud control planes are down.
    4. \n
  4. Start from a clean state. Use spare or lab hardware that represents the production class, or a vendor-supported virtual equivalent when it can test the required behavior. Follow the documented initialization path, install the intended firmware, restore entitlement, and import configuration without hidden technician shortcuts.
    5. \n
  5. Validate management. Test console access, named administrator authentication, AAA fallback, role authorization, time, DNS, certificate trust, management routing, configuration archive, logging, monitoring, backups, and alert delivery. Confirm default accounts and unexpected services are not left active.
    6. \n
  6. Validate forwarding and policy. Exercise representative VLANs, routes, redundancy, VPNs, NAT, access policy, inspection, quality of service, multicast, wireless, or load-balancing functions relevant to the device. Confirm failover and recovery rather than testing only a ping to the management address.
    7. \n
  7. Record and repeat. Capture elapsed time, manual decisions, failed steps, unavailable files, incompatible commands, missing secrets, vendor dependencies, and business tests. Update the package and runbook, retest unresolved gaps, and schedule another exercise after material hardware, firmware, identity, licensing, or topology change.
    8. \n
\n

Factual boundary: A lab rebuild reduces uncertainty but cannot reproduce every production dependency, traffic pattern, carrier condition, or latent hardware fault. Vendor procedures differ, and some backups are not portable across models or software versions. Confirm support and change requirements for the exact platform.

\n

Measure configuration-backup success, integrity verification, recovery-package completeness, tested device classes, rebuild time, manual steps, missing dependencies, business-test pass rate, and age of the last exercise. The meaningful claim is not “we back up the switches.” It is “we have recently rebuilt this class of device from protected material and verified the services it must restore.”

\n\n

Official references

\n", "content_text": "Source facts: known-good material supports secure device restoration\nCISA’s Disable Cisco Smart Install Feature (CM0014) is a countermeasure for a specific legacy Cisco provisioning feature, not a general network-backup standard. CISA says Smart Install can be abused to access, copy, or poison startup configuration files or modify Cisco IOS. When administrators determine that a device was abused, the guidance says to isolate it and restore its image and configuration to a secure state; that may include a known-good configuration backup, a factory reset, and current vendor patches. It also says to preserve a tampered configuration or other evidence during investigation.\nNIST SP 800-128 describes baselines, change control, configuration monitoring, and the preservation of approved configuration information. CISA’s communications-infrastructure hardening guidance emphasizes secure management, centralized logging, visibility, backups, and preparation for recovery from unauthorized change.\nA text export alone may not recreate the device. Recovery can depend on compatible hardware, bootloader and firmware, feature licenses, certificates and private keys, secret values omitted from exports, identity services, routing neighbors, controller state, cloud entitlements, cabling, upstream configuration, time, DNS, and vendor-specific restore behavior. A successful command import also does not prove that production services or security controls work.\n\nDSE recommendation: test a full device recovery package\nChoose representative critical devices and prove the rebuild in an isolated environment or approved maintenance exercise. Treat every discovered dependency as a corrective action, not an informal note.\n\nDefine the recovery target. Record device role, critical services, site, hardware and module identifiers, software train, desired recovery time, acceptable data loss, configuration owner, support status, and approved replacement models. Prioritize devices that are single points of failure or trust boundaries.\nAssemble the package. Preserve startup and running configuration, firmware and hashes, boot variables, licenses or entitlement steps, certificates and renewal details, secrets through an approved vault, inventory, diagrams, port mapping, dependencies, console settings, recovery contacts, and a dated known-good reference.\nProtect the evidence. Encrypt sensitive backups, separate backup administration from device administration, use immutable or offline copies where appropriate, log access, restrict exports, and verify integrity. Keep recovery material available when normal identity, DNS, network, or cloud control planes are down.\nStart from a clean state. Use spare or lab hardware that represents the production class, or a vendor-supported virtual equivalent when it can test the required behavior. Follow the documented initialization path, install the intended firmware, restore entitlement, and import configuration without hidden technician shortcuts.\nValidate management. Test console access, named administrator authentication, AAA fallback, role authorization, time, DNS, certificate trust, management routing, configuration archive, logging, monitoring, backups, and alert delivery. Confirm default accounts and unexpected services are not left active.\nValidate forwarding and policy. Exercise representative VLANs, routes, redundancy, VPNs, NAT, access policy, inspection, quality of service, multicast, wireless, or load-balancing functions relevant to the device. Confirm failover and recovery rather than testing only a ping to the management address.\nRecord and repeat. Capture elapsed time, manual decisions, failed steps, unavailable files, incompatible commands, missing secrets, vendor dependencies, and business tests. Update the package and runbook, retest unresolved gaps, and schedule another exercise after material hardware, firmware, identity, licensing, or topology change.\n\nFactual boundary: A lab rebuild reduces uncertainty but cannot reproduce every production dependency, traffic pattern, carrier condition, or latent hardware fault. Vendor procedures differ, and some backups are not portable across models or software versions. Confirm support and change requirements for the exact platform.\nMeasure configuration-backup success, integrity verification, recovery-package completeness, tested device classes, rebuild time, manual steps, missing dependencies, business-test pass rate, and age of the last exercise. The meaningful claim is not “we back up the switches.” It is “we have recently rebuilt this class of device from protected material and verified the services it must restore.”\n\nOfficial references\n\nCISA, Disable Cisco Smart Install Feature, Countermeasure CM0014.\nNIST, Guide for Security-Focused Configuration Management of Information Systems, SP 800-128 Update 1.\nCISA, Enhanced Visibility and Hardening Guidance for Communications Infrastructure.", "content_markdown": "## Source facts: known-good material supports secure device restoration\n\nCISA’s [Disable Cisco Smart Install Feature (CM0014)](https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0014) is a countermeasure for a specific legacy Cisco provisioning feature, not a general network-backup standard. CISA says Smart Install can be abused to access, copy, or poison startup configuration files or modify Cisco IOS. When administrators determine that a device was abused, the guidance says to isolate it and restore its image and configuration to a secure state; that may include a known-good configuration backup, a factory reset, and current vendor patches. It also says to preserve a tampered configuration or other evidence during investigation.\n\nNIST SP 800-128 describes baselines, change control, configuration monitoring, and the preservation of approved configuration information. CISA’s communications-infrastructure hardening guidance emphasizes secure management, centralized logging, visibility, backups, and preparation for recovery from unauthorized change.\n\nA text export alone may not recreate the device. Recovery can depend on compatible hardware, bootloader and firmware, feature licenses, certificates and private keys, secret values omitted from exports, identity services, routing neighbors, controller state, cloud entitlements, cabling, upstream configuration, time, DNS, and vendor-specific restore behavior. A successful command import also does not prove that production services or security controls work.\n\n## DSE recommendation: test a full device recovery package\n\nChoose representative critical devices and prove the rebuild in an isolated environment or approved maintenance exercise. Treat every discovered dependency as a corrective action, not an informal note.\n\n- Define the recovery target. Record device role, critical services, site, hardware and module identifiers, software train, desired recovery time, acceptable data loss, configuration owner, support status, and approved replacement models. Prioritize devices that are single points of failure or trust boundaries.\n\n- Assemble the package. Preserve startup and running configuration, firmware and hashes, boot variables, licenses or entitlement steps, certificates and renewal details, secrets through an approved vault, inventory, diagrams, port mapping, dependencies, console settings, recovery contacts, and a dated known-good reference.\n\n- Protect the evidence. Encrypt sensitive backups, separate backup administration from device administration, use immutable or offline copies where appropriate, log access, restrict exports, and verify integrity. Keep recovery material available when normal identity, DNS, network, or cloud control planes are down.\n\n- Start from a clean state. Use spare or lab hardware that represents the production class, or a vendor-supported virtual equivalent when it can test the required behavior. Follow the documented initialization path, install the intended firmware, restore entitlement, and import configuration without hidden technician shortcuts.\n\n- Validate management. Test console access, named administrator authentication, AAA fallback, role authorization, time, DNS, certificate trust, management routing, configuration archive, logging, monitoring, backups, and alert delivery. Confirm default accounts and unexpected services are not left active.\n\n- Validate forwarding and policy. Exercise representative VLANs, routes, redundancy, VPNs, NAT, access policy, inspection, quality of service, multicast, wireless, or load-balancing functions relevant to the device. Confirm failover and recovery rather than testing only a ping to the management address.\n\n- Record and repeat. Capture elapsed time, manual decisions, failed steps, unavailable files, incompatible commands, missing secrets, vendor dependencies, and business tests. Update the package and runbook, retest unresolved gaps, and schedule another exercise after material hardware, firmware, identity, licensing, or topology change.\n\nFactual boundary: A lab rebuild reduces uncertainty but cannot reproduce every production dependency, traffic pattern, carrier condition, or latent hardware fault. Vendor procedures differ, and some backups are not portable across models or software versions. Confirm support and change requirements for the exact platform.\n\nMeasure configuration-backup success, integrity verification, recovery-package completeness, tested device classes, rebuild time, manual steps, missing dependencies, business-test pass rate, and age of the last exercise. The meaningful claim is not “we back up the switches.” It is “we have recently rebuilt this class of device from protected material and verified the services it must restore.”\n\n## Official references\n\n- CISA, [Disable Cisco Smart Install Feature](https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0014), Countermeasure CM0014.\n\n- NIST, [Guide for Security-Focused Configuration Management of Information Systems](https://csrc.nist.gov/pubs/sp/800/128/upd1/final), SP 800-128 Update 1.\n\n- CISA, [Enhanced Visibility and Hardening Guidance for Communications Infrastructure](https://www.cisa.gov/resources-tools/resources/enhanced-visibility-and-hardening-guidance-communications-infrastructure)." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/", "url": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-17" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Prove a network device can be rebuilt from a known-good configuration", "item": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/#article", "identifier": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/", "url": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/", "headline": "Prove a network device can be rebuilt from a known-good configuration", "description": "A copied running configuration is not yet a recovery capability. Prove that hardware, firmware, licensing, identity, certificates, secrets…", "abstract": "A copied running configuration is not yet a recovery capability. Prove that hardware, firmware, licensing, identity, certificates, secrets, dependencies, telemetry, and business traffic can be restored together.", "articleBody": "Source facts: known-good material supports secure device restoration\nCISA’s Disable Cisco Smart Install Feature (CM0014) is a countermeasure for a specific legacy Cisco provisioning feature, not a general network-backup standard. CISA says Smart Install can be abused to access, copy, or poison startup configuration files or modify Cisco IOS. When administrators determine that a device was abused, the guidance says to isolate it and restore its image and configuration to a secure state; that may include a known-good configuration backup, a factory reset, and current vendor patches. It also says to preserve a tampered configuration or other evidence during investigation.\nNIST SP 800-128 describes baselines, change control, configuration monitoring, and the preservation of approved configuration information. CISA’s communications-infrastructure hardening guidance emphasizes secure management, centralized logging, visibility, backups, and preparation for recovery from unauthorized change.\nA text export alone may not recreate the device. Recovery can depend on compatible hardware, bootloader and firmware, feature licenses, certificates and private keys, secret values omitted from exports, identity services, routing neighbors, controller state, cloud entitlements, cabling, upstream configuration, time, DNS, and vendor-specific restore behavior. A successful command import also does not prove that production services or security controls work.\n\nDSE recommendation: test a full device recovery package\nChoose representative critical devices and prove the rebuild in an isolated environment or approved maintenance exercise. Treat every discovered dependency as a corrective action, not an informal note.\n\nDefine the recovery target. Record device role, critical services, site, hardware and module identifiers, software train, desired recovery time, acceptable data loss, configuration owner, support status, and approved replacement models. Prioritize devices that are single points of failure or trust boundaries.\nAssemble the package. Preserve startup and running configuration, firmware and hashes, boot variables, licenses or entitlement steps, certificates and renewal details, secrets through an approved vault, inventory, diagrams, port mapping, dependencies, console settings, recovery contacts, and a dated known-good reference.\nProtect the evidence. Encrypt sensitive backups, separate backup administration from device administration, use immutable or offline copies where appropriate, log access, restrict exports, and verify integrity. Keep recovery material available when normal identity, DNS, network, or cloud control planes are down.\nStart from a clean state. Use spare or lab hardware that represents the production class, or a vendor-supported virtual equivalent when it can test the required behavior. Follow the documented initialization path, install the intended firmware, restore entitlement, and import configuration without hidden technician shortcuts.\nValidate management. Test console access, named administrator authentication, AAA fallback, role authorization, time, DNS, certificate trust, management routing, configuration archive, logging, monitoring, backups, and alert delivery. Confirm default accounts and unexpected services are not left active.\nValidate forwarding and policy. Exercise representative VLANs, routes, redundancy, VPNs, NAT, access policy, inspection, quality of service, multicast, wireless, or load-balancing functions relevant to the device. Confirm failover and recovery rather than testing only a ping to the management address.\nRecord and repeat. Capture elapsed time, manual decisions, failed steps, unavailable files, incompatible commands, missing secrets, vendor dependencies, and business tests. Update the package and runbook, retest unresolved gaps, and schedule another exercise after material hardware, firmware, identity, licensing, or topology change.\n\nFactual boundary: A lab rebuild reduces uncertainty but cannot reproduce every production dependency, traffic pattern, carrier condition, or latent hardware fault. Vendor procedures differ, and some backups are not portable across models or software versions. Confirm support and change requirements for the exact platform.\nMeasure configuration-backup success, integrity verification, recovery-package completeness, tested device classes, rebuild time, manual steps, missing dependencies, business-test pass rate, and age of the last exercise. The meaningful claim is not “we back up the switches.” It is “we have recently rebuilt this class of device from protected material and verified the services it must restore.”\n\nOfficial references\n\nCISA, Disable Cisco Smart Install Feature, Countermeasure CM0014.\nNIST, Guide for Security-Focused Configuration Management of Information Systems, SP 800-128 Update 1.\nCISA, Enhanced Visibility and Hardening Guidance for Communications Infrastructure.", "datePublished": "2026-08-17T13:19:00+00:00", "dateModified": "2026-08-17T19:22:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Person", "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/prove-network-device-rebuild-known-good-configuration/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Prove a network device can be rebuilt from a known-good configuration" }, "articleSection": [ "Business Continuity", "Cybersecurity", "IT", "Networks & Infrastructure" ], "keywords": [ "Business Continuity", "Cybersecurity", "IT", "Networks & Infrastructure", "Checklist", "Important priority" ], "genre": "Checklist", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 646, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "CISA Disable Cisco Smart Install Feature (CM0014)", "url": "https://www.cisa.gov/eviction-strategies-tool/info-countermeasures/CM0014", "datePublished": "2025-03-14" } } ] } }