Retirement changes the security system
Decommissioning removes a service or component from operation and from the trust relationships around it. It includes routes, DNS, load balancers, firewall rules, identity clients, service accounts, credentials, certificates, keys, policy, federation, monitoring, backups, data, artifacts, vendor access, support processes, documentation, and ownership.
Turning off compute is only one step. A forgotten hostname, callback, key, account, direct origin, backup, or automation path can remain reachable or become available for reuse by another party.
Map dependencies and authority
Start from current inventory and observed use. Identify producers and consumers, inbound and outbound connections, identities, credentials, policy references, DNS aliases, certificate names, telemetry, recovery paths, and data copies. Find dependencies that use a shared key, trust anchor, policy bundle, network rule, or support account.
Define the required final state. Requests to the old route fail safely. Names cannot be re-registered by an attacker. Old credentials, sessions, assertions, certificates, and federation records are rejected. Required records move to an owned archive. Expired personal data and unnecessary copies are sanitized. Other services keep their needed security controls.
Controlled removal
Stop new issuance and new dependency creation. Announce a measurable removal window to owners. Reduce traffic and authority in stages where continuity matters. Capture final configuration, ownership, evidence, retention decisions, and unresolved dependencies. Revoke trust and close direct paths before releasing names or infrastructure.
Sanitize media and provider copies with a method suitable for the data and storage technology. Verify deletion, key destruction, backup expiry, and restore behavior. Remove monitoring only after it can show that no old path or credential remains in use.
Failure and residual risk
Usage logs can miss dormant disaster-recovery clients. Immediate revocation is safer against reuse and can break unknown consumers. Long archives preserve investigation evidence and increase confidentiality and retention risk. Cryptographic erasure fails when keys or plaintext exist elsewhere.
A retired domain, bucket, package name, identity client, or cloud resource can be claimed again. Restoring an old backup can reintroduce removed accounts, policy, credentials, and data.
Pomerium boundary
Pomerium routes and policy can be removed from the configured deployment. Operators own DNS, public and private origins, identity-provider clients, certificates, infrastructure, application data, backups, monitoring, and third-party integrations. Removing a Pomerium route does not remove the upstream or prevent direct access to it.
Evaluation checklist
- Are every owner, consumer, route, name, identity, credential, key, policy, data copy, backup, and recovery path inventoried?
- Does the final state reject the old route, direct origin, session, credential, assertion, certificate, and federation trust?
- Can another party reclaim a released name or resource and receive trusted traffic or credentials?
- Are retained evidence and data owned, access-controlled, time-bounded, restorable, and sanitizable?
- Does a restore test prove that retired authority and expired data do not return?
