Lifecycle, EOL, EOS, Decommissioning, and Configuration Management
Key Takeaways
- Lifecycle management tracks an asset from planning and procurement through deployment, operation, support renewal, replacement, and disposal — N10-009 objective 3.5 ties this to configuration management.
- End-of-Life (EOL) and End-of-Support/End-of-Sale (EOS) dates drive patch availability, vendor support, replacement budgeting, and whether you need compensating controls or formal risk acceptance.
- Decommissioning is more than powering off: remove ports/routes/firewall rules/VPNs/NAT/DNS, delete credentials and SNMP/API access, sanitize data, and update IPAM, inventory, monitoring, and backups.
- Configuration management preserves intended state via golden configs, version control, automated backups, drift detection, and rollback.
- Configuration backups can expose SNMP communities, pre-shared keys, AAA secrets, and topology — store them securely and tie them to change records.
Governing an Asset Across Its Life
Network assets need governance for their entire life. A device that is installed, forgotten, and left unsupported becomes a reliability, security, and compliance liability. N10-009 objective 3.5 pairs lifecycle management with configuration management, and the exam tests whether you understand the operational consequences of EOL/EOS dates and the difference between unplugging a device and properly decommissioning it.
Asset Lifecycle Stages
| Stage | Operational focus |
|---|---|
| Plan | Requirements, standards, budget, capacity, support model |
| Procure | Approved vendor, licensing, support contract, lead time |
| Deploy | Baseline config, documentation, monitoring, acceptance testing |
| Operate | Patching, backups, change control, performance review |
| Renew/replace | Support status, capacity, risk, cost, compatibility |
| Decommission | Remove service, sanitize data, update records, dispose properly |
Lifecycle planning prevents surprises. If a firewall's support expires next month, waiting for it to fail can leave the organization with no patches, no replacement hardware on hand, and no vendor TAC case option.
EOL and EOS
Vendors use these terms slightly differently, but Network+ focuses on the operational effect.
| Term | Meaning | Operational risk |
|---|---|---|
| EOL (End of Life) | Product retired from the vendor portfolio | Replacement planning required |
| EOS (End of Support / End of Sale) | Support or new sales stop, per vendor context | Patches, vendor TAC, or new purchases may end |
| Maintenance expiration | Support contract ends | Hardware RMA or escalation may be delayed |
| Software support end | Firmware/OS updates stop | Vulnerabilities may remain unpatched |
Track these dates in inventory and review them during budget cycles. An unsupported but still-running device usually requires one of three responses: replace it, wrap it in compensating controls (tighter segmentation, monitoring), or document a formal risk acceptance. Doing nothing silently is the wrong answer on the exam.
Decommissioning Properly
Decommissioning is a process, not a power switch. A complete process prevents abandoned paths, stale records, and exposed data.
| Step | Example |
|---|---|
| Confirm ownership/dependency | Verify the device or service is truly unused |
| Remove traffic paths | Disable ports, routes, firewall rules, VPNs, NAT, DNS records |
| Remove access | Delete local accounts, API tokens, SNMP communities, certificates |
| Preserve required records | Keep change tickets, diagrams, and audit evidence per policy |
| Sanitize data | Wipe storage, clear configs, remove secrets, or destroy media |
| Update systems | IPAM, inventory, monitoring, logging, backup, support contracts |
| Dispose or repurpose | Follow environmental, legal, and organizational rules |
Configuration Management
Configuration management keeps the network aligned with approved intent through templates, version control, automated backups, comparison tools, and drift detection.
| Practice | Why it matters |
|---|---|
| Golden configuration | Approved settings for a device class |
| Version control | Shows who changed what and when |
| Configuration backup | Recovery after hardware failure or a bad change |
| Drift detection | Finds unauthorized or accidental differences |
| Rollback plan | Restores a known-good state when a change fails |
Configuration files often contain sensitive data: SNMP communities, pre-shared keys, local usernames, TACACS+ or RADIUS secrets, IP addressing, and management paths. Store backups encrypted and access-controlled, and tie each backup to a change record so you can recover the exact pre-change state.
Drift, Golden Configs, and Recovery in Practice
Configuration drift is the gap between a device's running state and its approved intent. Drift creeps in through manual hotfixes, undocumented troubleshooting edits, or a replacement device built from memory instead of a template. Drift detection compares each live config against the golden configuration and flags differences — an unexpected open SNMP community or a missing syslog destination, for example. The cure is to reconcile: either approve the difference (update the golden config through change management) or revert the device to the standard.
A device that drifts silently is the one that behaves differently during an incident, which is why the exam treats undetected drift as an operational risk, not a cosmetic issue.
Backups close the loop. The fastest recovery from a failed router is not rebuilding by hand; it is restoring the last known-good configuration backup, then replaying any approved changes since. This is why backups must be current, protected, and versioned — a six-month-old backup omits half a year of legitimate change, and an unprotected backup hands an attacker your topology and secrets.
Practical Scenario
A wireless controller is approaching end of support. A solid lifecycle plan identifies affected AP models, licensing, support expiration, replacement compatibility, migration steps, the maintenance window, a configuration backup, rollback options, documentation updates, and the decommissioning tasks for the old controller — including pulling its DNS, IPAM, and monitoring entries.
Common Exam Traps
| Trap | Better exam reasoning |
|---|---|
| "EOL is only a purchasing issue." | EOL/EOS affect patching, support, risk, and operations. |
| "Decommissioning means unplugging it." | Records, access, configs, routes, DNS, IPAM, and data also need handling. |
| "Config backups are public-safe text." | They expose topology and secrets and need protection. |
| "Manual changes need no version history." | Configuration management depends on traceability and rollback. |
Quick Drill
- Support expires next quarter: plan replacement or formal risk treatment.
- Retired VPN gateway still has DNS and firewall entries: complete decommissioning cleanup.
- New switch config differs from the template: investigate configuration drift.
- Router fails and must be rebuilt fast: restore from a protected configuration backup.
- Prove when a route changed: version history and change record.
A retired firewall was powered off, but its DNS records, IPAM entries, VPN account, and monitoring object still exist. Which process was incomplete?
Which pairing best supports configuration management by keeping devices aligned with approved intent?
Why should End-of-Life and End-of-Support dates be tracked in the asset inventory?