Cryptagion

Cryptagion addresses the part of cryptographic modernisation that comes before cryptography: knowing what is deployed. It is concerned with cryptographic discovery across an estate, the construction and maintenance of a cryptographic inventory, and the mapping of cryptographic dependencies between components that were never designed to be examined together.

Cryptographic discovery

Locating cryptographic usage wherever it occurs — code paths, linked libraries, negotiated protocols, issued certificates, configuration files and inherited third-party components.

Cryptographic inventory

A maintained record of those uses, with enough context to answer which systems depend on which primitives, and through which intermediaries.

Cryptographic risk

The exposure implied by that inventory: deprecated algorithms still in use, short keys, obsolete protocol versions, and long-lived data protected by primitives with a limited remaining horizon.

Crypto agility

The architectural property of being able to change cryptographic primitives without redesigning the systems that use them — largely absent in estates where algorithms are hard-coded or buried in dependencies.

CBOM

A Cryptographic Bill of Materials: the inventory expressed in a structured, machine-readable form, so it can be diffed, tracked and consumed by other tooling.

Post-quantum readiness

The degree to which an organisation is able to plan and execute a migration to post-quantum primitives, measured by what it knows about its own estate rather than by intent.

The end point of that work is migration planning: an ordered, dependency-aware programme rather than a list of algorithms to replace. Readiness is treated as a measurable property of the inventory, not a statement of position.

Organisations cannot migrate cryptography they cannot identify. This is the central argument. Every discussion of post-quantum transition presumes a known starting state, and in most estates that starting state does not exist in any consolidated form.

Cryptography is not deployed in one place. It is spread across application code, linked and transitively linked libraries, transport and messaging protocols, certificates and their issuance chains, configuration and platform defaults, and third-party dependencies whose internals are not visible to the organisation that runs them. Each of those layers is owned by a different team, changes on a different cadence, and is documented — if at all — in a different system.

• Cryptographic use is rarely inventoried as an asset class, unlike software components or network exposure.
• Choices made years ago persist in dependencies that no current owner selected.
• Configuration and negotiated protocol behaviour can differ from what the code appears to specify.
• Third-party components can constrain migration regardless of internal engineering capacity.

Post-quantum migration turns that gap into a planning problem before it becomes a cryptography problem. The primitives are being standardised; the difficulty for most organisations is not choosing an algorithm but establishing scope, ownership, sequencing and dependency order across an estate whose cryptographic composition has never been written down. Discovery and inventory are therefore not preliminaries to the migration — they are the first phase of it.