Keys are authority
A cryptographic key grants an operation: decrypt, encrypt, sign, verify within a trust policy, authenticate a message, derive another key, or establish a shared secret. Key management controls this authority through its complete lifecycle.
Every key needs a purpose, algorithm, strength, owner, generating component, custody boundary, permitted operations, users and services, activation time, cryptoperiod, distribution path, backup rule, rotation method, compromise response, recovery requirement, and destruction evidence.
Generation and custody
Generate keys with an approved cryptographic mechanism and suitable entropy. Keep key type and purpose explicit. Do not reuse a signing key for encryption or a data key for message authentication. Prefer non-exportable use through a cryptographic module or service when the threat and operational needs justify it.
Limit human and workload access. Distinguish permission to administer metadata from permission to invoke a key and permission to export key material. Use dual control or split knowledge for exceptional high-impact operations where appropriate.
Distribution, use, and rotation
Distribute keys only through authenticated, protected channels to named consumers. Avoid source code, container images, command lines, logs, general configuration, and unrestricted environment variables. Bind every operation to an authenticated workload and an authorization policy.
Version keys and encrypted records. Plan overlap from protocol and availability needs. Verify that new consumers use the new key and that old keys stop creating new authority. Retain an old decryption key only while required data remains and protect it according to the remaining sensitivity.
Failure and residual risk
Rotation does not repair unknown copies, derived keys, cached sessions, backups, or a compromised issuer. A non-exportable key can still be abused through an authorized cryptographic API. Losing an encryption key can destroy data availability. Backing up a signing key can expand forgery risk. Destroying one storage copy does not prove that memory, replicas, logs, and snapshots are clear.
Pomerium boundary
Pomerium accepts documented certificate, signing, shared-secret, and service-account configuration. Operators own generation, custody, access, distribution, inventory, rotation, revocation, recovery, and destruction. Pomerium cannot invalidate an external key or find copies outside its configured deployment.
Evaluation checklist
- Does every key have one purpose, algorithm, owner, custody boundary, and permitted operation?
- Who can administer, invoke, read, export, back up, rotate, and destroy it?
- Are all consumers, copies, derived keys, records, backups, and recovery paths inventoried?
- Does rotation prove new-key use and old-key rejection at every consumer?
- Does compromise response remove derived authority and rebuild trust where needed?
- Are availability needs for encryption keys distinct from non-repudiation or forgery risks for signing keys?
