> ## Content Index > Fetch the complete content index at: https://secdoc.tech/llms.txt > Use this file to discover other available public pages before exploring further. # Retiring a Security Platform Without Bringing It Back by Accident - URL: https://secdoc.tech/retiring-a-security-platform-without-bringing-it-back-by-accident/ - Published: 2026-09-28T10:41:58.000Z - Updated: 2026-09-28T10:41:58.000Z - Description: Decommissioning is the controlled removal of authority, dependencies, identities, and startup paths, not a power-off event. - Author: secdoc - Tags: security-architecture, decommissioning, siem, identity, disaster-recovery, open-source Turning off a server is easy. Retiring its authority is harder. I recently replaced several security platforms while preserving bounded recovery points. The old systems included log management, endpoint security, vulnerability management, SOAR, and DFIR services. Stopping the virtual machines removed their immediate compute load. It did not remove DNS records, collectors, webhook destinations, agent configurations, API credentials, firewall policies, backup jobs, dashboard links, scheduled tasks, or operator habits. Any one of those references could bring part of the old environment back into use. A collector can continue sending evidence to a retired destination. A restored virtual machine can boot with its old address and identity. An automation job can start a service because it still considers that service authoritative. An analyst can follow an old bookmark and make a decision using stale data. A backup can preserve the system perfectly while preserving its ability to collide with production. Decommissioning is therefore an authority-removal process. Power state is only one control. This follows [An Installed Agent Is Not Security Coverage](https://secdoc.tech/secdoc/docs/-/blob/main/blog/2026-09-06-an-installed-agent-is-not-security-coverage.md). Coverage asks whether a control has become authoritative. Retirement asks whether the old control has stopped being authoritative everywhere that matters. ## Define retirement states before taking action Words such as stopped, disabled, retired, archived, and deleted are often used as if they mean the same thing. They do not. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/define_retirement_states.png) Define retirement states before taking action | State | Meaning | | --------- | ------------------------------------------------------------------------------------------------ | | ACTIVE | The service is authoritative and receives production use or data | | DRAINING | New producers are moving away while bounded legacy traffic may remain | | QUIESCED | Writes and scheduled activity are stopped so final evidence or backup can be captured | | RETIRED | Authority and production references are removed; reactivation is prohibited without a new change | | ARCHIVED | Recovery material is retained but cannot start or connect automatically | | SANITIZED | Sensitive data and recoverable identity have been removed according to policy | | DISPOSED | The retained media or asset has completed its approved disposal process | A stopped system may still be active in the architecture if agents, DNS, and runbooks point to it. A deleted virtual machine may still be restorable with every old credential and network identity. An archived backup may still contain regulated data. I use a decommission record to make the transition explicit: ```yaml system_id: legacy-siem current_state: RETIRED former_authority: - endpoint-enrollment - log-search - alerting replacement_authority: enterprise-siem retirement_evidence: producer_migration: passed destination_readback: passed dns_withdrawal: passed credentials_revoked: passed schedules_disabled: passed startup_disabled: passed backup_retained: passed reactivation: automatic: prohibited requires: new-approved-recovery-change retained_data: classification: confidential-security-telemetry review_after: 2027-09-01 ``` The replacement needs to be named. "No longer used" is not enough for a service that performed a required control. ## Prove the replacement before removing the old path The first gate is not shutting down the legacy system. It is proving that the replacement is authoritative for the required workload. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/prove_the_replacement.png) Prove the replacement before removing the old path For a SIEM migration, I want evidence for each producer lane: - source identity and event type - old and new destination - transport and acknowledgement behavior - event count over a bounded interval - stable event identity or deduplication strategy - parsing and normalized field contract - retention and index placement - dashboard or query visibility - alert behavior - outage and retry behavior - rollback route Running both destinations temporarily can help compare results, but dual delivery has risks. It can duplicate downstream actions, double storage use, expose data to a system scheduled for retirement, and create two places analysts consider authoritative. If a SOAR workflow listens to both systems, one event can trigger two actions. If two endpoint managers share identity, an agent can flap or register unpredictably. If two vulnerability collectors produce findings with different IDs, the backlog can multiply. Dual operation needs a defined purpose, bounded duration, and one named decision authority. It is a test arrangement, not an acceptable permanent architecture. ## Retire producers before consumers when ordering requires it The safe shutdown order follows data flow and action authority. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/retire_producers_before_consumers.png) Retire producers before consumers when ordering requires it For a simple monitoring path: ```plaintext source -> collector -> transport -> parser -> index -> dashboard -> alert -> response ``` A practical retirement sequence is: 1. Disable automated response from the legacy path. 2. Move or stop producers and collectors. 3. Drain durable queues and record any intentional discard. 4. Prove the replacement receives the final expected events. 5. Disable legacy alerting and notifications. 6. Revoke integration credentials. 7. Remove routing, DNS, and firewall references. 8. Quiesce the legacy application and capture final evidence. 9. Stop services and disable automatic startup. 10. Capture the approved recovery point. 11. Delete active compute only after the retention decision is documented. The exact order changes by product. A message broker may need to remain available while producers drain. A secrets system cannot be retired until every consumer has moved and old leases or credentials are revoked. An identity provider must retain a tested break-glass path while applications migrate. The rule is to trace the real dependency graph. Do not use a generic server shutdown checklist for a control plane. ## Remove every kind of authority I use a retirement matrix because references hide in different layers. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/remove_evry_kind_of_authority.png) Remove every kind of authority | Layer | Questions | | --------------- | ---------------------------------------------------------------------------------------------------------- | | Name resolution | Do forward, reverse, service-discovery, and load-balancer records still resolve to the old system? | | Network | Do firewall rules, NAT, VIPs, routes, proxies, or health checks still permit or advertise it? | | Producers | Do agents, syslog senders, webhooks, exporters, collectors, or scanners still target it? | | Identity | Are API keys, service accounts, certificates, OAuth clients, local users, and trust relationships revoked? | | Automation | Can cron, systemd, CI, orchestration, HA, or infrastructure-as-code start or reconfigure it? | | Operations | Do dashboards, bookmarks, runbooks, inventories, monitors, alerts, and on-call procedures still name it? | | Recovery | Can a restore boot on the production network with the old address and identity? | | Data | What retained security, personal, credential, or regulated data remains? | The matrix should be completed with readback, not intention. After deleting a DNS record, query every authoritative resolver or replica that matters. After revoking an API credential, prove the old credential is rejected. After removing a firewall rule, run a negative reachability test from the former source. After changing a collector, inspect the old receiver for silence and the new receiver for acknowledged delivery. An API returning success only proves that the API accepted a request. ## DNS withdrawal needs timing DNS creates a common false finish. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/dns_withdrawl_needs_timing.png) DNS withdrawal needs timing Deleting a record from the primary server does not remove cached answers. The retirement plan should account for the existing TTL, secondary replication, local resolver caches, search domains, hosts files, and hard-coded addresses. A safe sequence can be: 1. Lower the TTL before the migration window when policy allows it. 2. Move producers to the replacement name. 3. Query authoritative and recursive resolvers for the new answer. 4. Monitor the legacy listener through at least the prior TTL. 5. Remove the old record. 6. Prove the old name returns the intended negative answer. 7. Search configuration repositories and live systems for the old name and address. Do not reuse the old name for an unrelated service immediately. Name reuse can route stale clients somewhere dangerous and make audit history ambiguous. ## Disable startup in more than one place A virtual machine marked off is not necessarily retired. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/disable_startup.png) Disable startup in more than one place For [Proxmox VE](https://pve.proxmox.com/pve-docs/qm.1.html?ref=secdoc.tech), `qm set --onboot 0` disables automatic startup for that guest. Also check HA resources, replication, startup ordering, backup hooks, scheduled tasks, and external automation. The guest operating system may have enabled services even when hypervisor startup is disabled. Inside a retained Linux guest, stop and disable application services if the retirement plan permits booting it for archival validation. Masking a unit creates a stronger local barrier, but it can complicate recovery and should be recorded. The better control for an archived guest is usually layered: ```yaml archived_guest_controls: power_state: stopped hypervisor_onboot: false ha_membership: absent virtual_nic_link: down production_vlan_attachment: absent guest_application_autostart: disabled dns_authority: absent credentials: revoked protection_flag: enabled ``` No single item is sufficient. A restore operation may create a new VM with default startup settings. A guest network configuration may still contain a production address. A service may start when an operator opens the NIC. ## Credentials survive the server Security platforms accumulate powerful identities: - agent enrollment keys - collector tokens - webhook secrets - database credentials - LDAP bind accounts - SAML or OIDC clients - TLS client certificates - API keys - backup tokens - SSH host and client keys - signing or encryption material ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/credentials_survive_the_server.png) Credentials survive the server Retirement needs a credential inventory tied to consumers. Revoke each identity after the replacement consumer passes acceptance. If several consumers share one token, first separate them or account for the coordinated rotation. A retained backup still contains old credentials. Revocation limits what those values can do if the backup is exposed or restored. Rotation is necessary when the same secret remains valid for another consumer. Do not copy secret values into the retirement report. Record the credential object, owner, scope, revocation evidence, and recovery implications. ## Backups are not standby systems I retained bounded backups of the old platforms after deleting active compute. The backups were labelled retired, not standby. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/backups_are_not_standby_systems.png) Backups are not standby systems That distinction establishes behavior: ```yaml backup_classification: retired-system-archive production_start: prohibited restore_purpose: - evidence-recovery - configuration-extraction - approved-forensic-review restore_network: isolated-recovery-only identity_regeneration_required: true retention_owner: security-platform-owner retention_review_after: 2027-09-01 ``` A standby system is expected to assume production authority. A retired archive is expected not to. If recovery requires examining old data, restore into an isolated network with virtual NIC link down by default. Confirm storage placement and startup settings before boot. Change or suppress cloned identity before permitting any network path. Use a distinct recovery hostname and address. Block production DNS, managers, identity services, notification services, and automation targets unless a specific test needs a narrowly approved connection. A recovered SIEM can send old alerts. A recovered SOAR platform can execute queued workflows. A recovered identity provider can issue tokens from historical state. A recovered secrets system can contain still-valid credentials. Isolation is not optional housekeeping. ## Data retention and sanitization are separate decisions Deleting a VM definition does not sanitize its storage or backups. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/data_retention_and_sanitization_are_separate.png) Data retention and sanitization are separate decisions [NIST SP 800-88 Revision 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final?ref=secdoc.tech) describes media sanitization as making access to target data infeasible for a given level of effort and places the decision in a program based on information sensitivity. The correct method depends on media type, storage architecture, encryption, reuse, disposal, and organizational requirements. A retirement plan should answer: - What data classes exist in application storage, logs, queues, snapshots, and backups? - Which legal, contractual, investigative, or operational retention requirements apply? - When does retained data expire? - Who can authorize access to the archive? - What sanitization method applies when retention ends? - How is sanitization verified and recorded? Crypto-erase can be effective when encryption keys are properly scoped and destroyed, but shared keys and copied plaintext undermine the claim. Thin-provisioned storage, deduplication, SSD wear leveling, snapshots, and remote replicas complicate overwrite assumptions. Use the storage vendor's supported mechanisms and the organization's sanitization policy. ## Search for ghosts after shutdown I treat post-retirement traffic as a defect. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/search_for_ghosts.png) Search for ghosts after the shutdown Monitor the old address, hostname, ports, API identity, and log destinations for a defined observation period. Useful detections include: - DNS queries for the retired name - denied connections to the old address or ports - authentication attempts using revoked identities - syslog or webhook traffic to the old listener - backup jobs naming the retired guest - automation runs referencing the old inventory object - dashboard links or health checks still requesting the old URL Do not keep the old service listening only to make those clients happy. A denial or sink that records metadata may help discovery, but it must not accept credentials or sensitive payloads. Where possible, detect at DNS, firewall, proxy, or sender configuration instead. The observation window should be longer than the slowest expected producer cadence. A weekly scanner will not reveal its stale target during a one-hour hold. ## Open-source options for controlled retirement | Need | Open-source options | Retirement use | | ------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------- | | Configuration discovery | Ansible, Salt, Puppet, Rudder | Search and read back service, package, schedule, and destination state across systems | | Network and service inventory | NetBox, phpIPAM | Mark lifecycle state, ownership, addresses, dependencies, and replacement authority | | DNS | Technitium DNS, BIND, PowerDNS | Withdraw records, inspect query logs, and verify negative answers | | Metrics and traffic observation | Prometheus, Grafana, Zabbix, Zeek, Suricata | Detect lingering health checks, connections, and producer traffic | | Secrets and PKI | OpenBao, step-ca | Revoke service identities, certificates, leases, and trust relationships. | | Backup and archive | Proxmox Backup Server, Restic, BorgBackup, Kopia | Preserve bounded recovery points with retention and verification. | | Evidence search | OpenSearch, Graylog | Confirm final delivery and detect references to retired destinations | ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/opensource_options.png) Open-source options for controlled retirement Open tooling makes configuration searchable and testable. It does not provide a universal retirement button. Product APIs, local files, identity stores, and network state still need a system-specific inventory. ## Restoration is not reactivation Rollback returns to a recent known state because the replacement change failed. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/restoration_is_not_reactivation-1.png) Restoration is not reactivation Restoration recovers data or service capability after loss. Reactivation returns a retired system to operational authority. Those are different approvals. A backup may support restoration without authorizing reactivation. If a retired platform must return to production, treat it as a new deployment. Reassess software support, vulnerabilities, credentials, certificates, data age, network policy, identity, capacity, integrations, and monitoring. Do not assume the archived state remains safe because it was safe on the day it was captured. ## The retirement acceptance test I consider a platform retired only when I can prove: 1. The replacement meets the required control objective. 2. Producers no longer send to the old system. 3. Durable queues are drained or their disposition is recorded. 4. Automated actions and notifications are disabled. 5. DNS, proxy, load-balancer, route, and firewall authority are removed. 6. Service identities and certificates are revoked or rotated. 7. Schedulers, CI jobs, infrastructure code, and HA cannot start it. 8. Operational documentation names the replacement. 9. Active compute is stopped or deleted under the approved retention decision. 10. Retained recovery material is protected, labelled retired, and isolated by default. 11. Post-retirement monitoring shows no unexplained legacy traffic. 12. Data retention and final sanitization have owners and dates. ![](https://storage.ghost.io/c/b9/e8/b9e8be96-d607-455c-b908-45c0663214eb/content/images/2026/09/retirement_acceptance.png) Retirement acceptance tests The final question is blunt: what would happen if someone restored this backup and clicked Start? If the answer is "it would come up on the production network with its old identity," the retirement is incomplete. The last post examined the recovery evidence behind that retained backup: [A Backup Is Not Recovery Evidence.](https://secdoc.tech/a-backup-is-not-recovery-evidence/)