Learning outcomes
- Establish ownership, requirements, trust, dependencies, tests, and recovery before service activation.
- Prove that every public and private path enforces the intended identity and authorization boundary.
- Retire routes, names, credentials, policy, infrastructure, data, and monitoring without leaving shadow authority.
- Verify that restored environments cannot reintroduce the retired system or its authority.
Operating objective
Commissioning establishes that a specific deployed system is ready to enforce a stated protection need. Retirement establishes that the system and its authority no longer exist outside the approved archive. Both transitions need an owner, inventory, acceptance criteria, evidence, rollback or recovery plan, and independent negative tests.
Define the service, environments, routes, identities, resources, actions, data, dependencies, administrators, emergency authority, support model, and lifecycle end condition before activation.
Signals and evidence
For commissioning, preserve the approved design, threat model, requirements, source revision, artifact identity and provenance, dependency state, configuration, policy version, issuer and key metadata, routes, DNS, certificates, direct-path controls, owner acceptance, positive and negative tests, monitoring, retention, and recovery exercise.
For retirement, use configuration, identity, DNS, network, certificate, cloud, application, telemetry, billing, and backup inventories to find current and dormant dependencies. Observe use for an approved period, but do not treat no log record as proof that no recovery client or direct path exists.
Response and recovery
- Assign owners for the protected service, identity, network, policy, application, evidence, data, and recovery.
- Commission from a reviewed immutable artifact and exact configuration. Verify provenance and administrative authority.
- Test approved access, unauthorized identity, wrong action, wrong tenant, direct origin, stale context, dependency failure, revocation, rollback, and recovery.
- Record the accepted residual risks and the evidence that starts monitoring them.
- Before retirement, stop new clients, credentials, data, and dependencies. Notify every recorded consumer and service owner.
- Reduce traffic and authority in bounded stages. Preserve required evidence and final configuration.
- Remove route and policy, revoke identity clients and credentials, close network and direct paths, remove DNS and certificates, and retire infrastructure.
- Archive only required records. Apply access, retention, deletion, key, and sanitization decisions to every copy and backup.
- Keep monitoring until old use, name reuse, credential use, and unexpected traffic remain absent for the stated period.
- Restore a representative backup in isolation and prove that retired authority and expired data do not return.
Design tradeoffs and residual risk
Gradual activation and retirement reduce outage risk and extend coexistence with old paths. Immediate removal limits exposure and can break unknown consumers. Keeping names reserved prevents takeover and costs ownership and maintenance. Rich archives improve investigation and preserve sensitive data.
Residual risk includes dormant clients, external caches, third-party integrations, unknown direct origins, copied credentials, provider-retained data, released names, and backups that predate retirement.
Pomerium boundary
Pomerium can activate and remove configured routes, policy, and deployment components. Operators own the surrounding DNS, network, identity-provider client, certificates, upstream, application data, monitoring, backups, and recovery paths. A removed route does not prove that the upstream is gone or unreachable.
Exercise
Commission one staging administration route from an immutable artifact. Capture every acceptance item and run the complete negative test set. Then retire the route as if its hostname, identity client, certificate, service account, and application data were real production assets.
Restore a pre-retirement backup in isolation. Confirm that automation detects or removes the old route, credential, identity client, policy, and data before any network exposure. Record one dependency that inventory alone did not reveal.
Evaluation checklist
- Are service ownership, protection need, lifecycle boundary, dependencies, authority, and acceptance criteria explicit?
- Does commissioning evidence identify the exact source, artifact, configuration, policy, trust, route, and environment?
- Do tests cover approved, unauthorized, bypass, stale, failure, revocation, rollback, and recovery behavior?
- Does retirement remove every route, name, identity, credential, key, policy, data copy, backup effect, and direct path?
- Can monitoring and an isolated restore prove that retired authority does not return?
Next learning unit
Security Assurance and Evidence
Distinguish a control claim, verification, validation, assurance argument, and the evidence that supports each conclusion.
