Ability to change cryptography
Cryptographic agility is the ability to discover, evaluate, replace, and retire cryptographic algorithms, protocols, parameters, implementations, keys, certificates, and data formats without losing security or service continuity. It is an engineering and operations property, not a runtime setting that accepts any algorithm.
Cryptographic inventory
Inventory every use with owner, purpose, data lifetime, algorithm, parameter, protocol, library, provider, key, certificate, format, producer, consumer, environment, hardware dependency, and migration constraint. Include code, configuration, network appliances, identities, build systems, backups, archives, firmware, partner integrations, and offline validators.
Measure actual negotiation and stored formats. Source search alone misses managed services and deployed configuration. Traffic observation alone misses dormant recovery paths and old data.
Versioned migration
Separate policy from implementation. Use a narrow approved suite selected by controlled configuration. Version ciphertext, signatures, keys, certificates, and protocol messages so readers know how to verify old material while writers produce the new format.
Plan phased support: inventory, test vectors, dual-read or hybrid compatibility where justified, new-write, migration of stored data, consumer adoption, old-write disablement, old-read retirement, key destruction, and evidence. Reject downgrade to a weaker choice outside the bounded transition.
Failure and residual risk
Accepting many algorithms can create algorithm confusion and downgrade. A generic interface can hide incompatible nonce, key, and failure rules. Old backups can require retired code and keys. Partners and hardware can block migration. Dual operation increases complexity and the time that old weaknesses remain usable.
Pomerium boundary
Pomerium supports documented cryptographic protocols and certificate configuration. Operators must track supported versions, libraries, certificates, upstream and downstream peers, and upgrade paths. Application ciphertext and signing formats remain the application owner's responsibility. Do not add unsupported algorithm negotiation around a Pomerium assertion.
Evaluation checklist
- Does the inventory include code, configuration, traffic, stored data, backups, hardware, and external partners?
- Can every use name its owner, purpose, data lifetime, key, implementation, producer, and consumer?
- Are formats and protocols versioned without allowing attacker-selected downgrade?
- Can the system read old and write new material during a bounded migration?
- Is retirement defined for algorithms, keys, libraries, stored records, recovery code, and partner support?
- Has the migration been tested for rollback, mixed versions, failure, and final old-path rejection?
