Operate the credential and key lifecycle

Operating objective

Every credential and cryptographic key has one defined purpose, owner, issuer, subject, audience, permitted operation, custody boundary, creation method, activation time, expiry, rotation method, revocation path, recovery rule, destruction rule, and evidence trail. No credential remains valid because nobody knows who owns it.

Distinguish human authenticators, sessions, refresh and access tokens, client credentials, service-account tokens, API keys, symmetric secrets, private signing and encryption keys, TLS certificates and keys, trust anchors, and recovery credentials. They have different compromise effects and invalidation mechanisms.

Signals and evidence

Maintain a relationship inventory that maps each item to its producer, storage, distributors, consumers, target, environments, backups, replicas, and derived credentials. Record safe identifiers and fingerprints, not secret values. Monitor age, expiry, use after replacement, unknown consumers, issuance spikes, failed validation, weak or obsolete algorithms, unapproved export, and inventory drift.

For a rotation, record generation context, entropy or hardware boundary where applicable, approvers, activation and overlap, consumer update, old-value rejection, revocation status, destruction, and rollback. For exposure, assume routine overlap can aid an attacker. Replace dependent trust and investigate derived authority.

Response and recovery

1. Classify purpose, impact, and every system that can issue, store, copy, use, or derive authority from the item.
2. Generate new material with an approved mechanism and protect it before activation.
3. Distribute it only to named consumers through authenticated channels. Avoid command lines, source, logs, images, and general backups.
4. Activate in a bounded sequence. Verify issuer, audience, algorithm, key identifier, certificate name, and target acceptance.
5. Use a short planned overlap only when the protocol and availability need justify it.
6. Stop new issuance from the old authority. Revoke or remove the old item and all exposed derivatives.
7. Test old-value rejection at each target, including offline validators, caches, replicas, and recovery systems.
8. Destroy remaining copies according to the storage boundary. Preserve non-secret evidence.
9. For recovery, restore authority through a separately protected path. Do not copy an exposed private key back into service.

Design tradeoffs and residual risk

Short lifetimes reduce replay windows and increase issuer, clock, and renewal dependency. Overlap protects availability and extends the time that two credentials work. Hardware-backed non-exportable keys improve custody and can complicate disaster recovery.

Central brokers reduce secret distribution and become high-authority targets. Per-service credentials limit blast radius and increase inventory and rotation work. Automatic rotation reduces age and can fail silently if consumers do not reload.

Residual risk includes live use by a compromised workload, forgotten replicas, backup copies, derived sessions, offline validation, and targets that have no effective revocation mechanism.

Pomerium boundary

Pomerium supports documented certificate and service-account configurations and validates trust as configured. Operators own generation, custody, delivery, inventory, rotation, revocation, consumer reload, backup, and destruction. Pomerium cannot invalidate a credential at an external issuer or target, and replacing configured material does not prove all copies or derived authority stopped.

Exercise

Choose one TLS private key and one non-human access credential in staging. Map every producer, copy, consumer, target, backup, derivative, and recovery path. Rotate both without displaying their values.

Verify the new material works. Verify the old key or credential fails at every target after the stated bound, including a restarted consumer and an offline or cached validator. Simulate suspected exposure and compare that procedure with routine rotation.

Evaluation checklist

• Does every item have one purpose, owner, audience, custody boundary, lifetime, and revocation path?
• Are all copies, consumers, targets, derivatives, backups, and recovery paths known?
• Does rotation verify consumer reload and old-value rejection?
• Does compromise response remove derived authority instead of only replacing one value?
• Can recovery restore service without restoring exposed private material?