Contemporary office building facade

Every organisation relies on cryptography to secure data, identities, applications and communications. Yet very few organisations can confidently answer where cryptography is used, which algorithms protect their critical systems, which certificates and keys are nearing end of life, which systems rely on quantum-vulnerable cryptography, or which business services should be prioritised first.

Without these answers, quantum readiness becomes guesswork. That gap has a name: Enterprise Cryptographic Exposure Management (ECEM).

A working definition

Enterprise Cryptographic Exposure Management (ECEM) is the discipline of discovering, understanding, and reducing cryptographic exposure — the business risk created by unknown, weak, outdated, or quantum-vulnerable cryptography across an organisation.

The word “exposure” is doing deliberate work here. ECEM is not just an inventory exercise. Knowing that a certificate exists is not the same as knowing whether it protects something that matters, whether it is about to expire, or whether the algorithm behind it will still be trustworthy in five years. Exposure means understanding cryptography in terms of business risk, not just technical presence.

Why “just like Vulnerability Management” is the right analogy

Vulnerability Management became a mature discipline by moving organisations from “we patch when something breaks” to “we continuously discover, assess, prioritise and remediate, based on business risk.” Exposure Management extended that same discipline from individual vulnerabilities to entire attack paths across infrastructure.

ECEM applies the same maturity curve to cryptography specifically:

  • Yesterday: Vulnerability Management — applications, CVEs, patch systems.
  • Today: Exposure Management — infrastructure, attack paths, reduce exposure.
  • Tomorrow: Enterprise Cryptographic Exposure Management — cryptography, cryptographic exposure, prepare for the quantum era.

Just as Vulnerability Management helps organisations identify and prioritise software vulnerabilities, ECEM helps organisations identify, measure and reduce cryptographic exposure — using the same underlying operational discipline, applied to a domain most organisations have never systematically inventoried at all.

The five questions ECEM answers

In practice, ECEM exists to make five questions answerable with evidence rather than assumption:

  • Where is cryptography being used?
  • Which algorithms protect our critical systems?
  • Which certificates and keys are nearing end of life?
  • Which systems rely on quantum-vulnerable cryptography?
  • Which business services should be prioritised first?

Most security teams cannot currently answer these with confidence — not because the information doesn’t exist, but because it is scattered across endpoints, servers, applications, databases, PKI, HSMs, cloud environments and source code repositories, with no continuously updated inventory tying it together.

Why now, specifically

Quantum computing capable of breaking current public-key cryptography may still be years away. That timeline is not really the point. Encrypted data intercepted and stored today can potentially be decrypted once sufficiently capable quantum computers exist — a risk often called “harvest now, decrypt later.” For any organisation handling data with a multi-year sensitivity window — financial records, health data, government or defence information, long-lived intellectual property — that risk is already active, regardless of exactly when large-scale quantum computers arrive.

The longer cryptography remains invisible, the harder and more expensive the eventual transition to post-quantum cryptography becomes. Discovery today is what makes migration tomorrow tractable rather than chaotic.

Where this fits with what you already run

ECEM is not a replacement for Vulnerability Management or Exposure Management — it is the missing layer alongside them. Most vulnerability and exposure tooling was never built to reason about cryptographic algorithms, certificate lifecycles, or key management systems as first-class objects. ECEM fills that gap with the same operational rigour applied to a domain that has, until now, largely been managed informally, if at all.

The next post in this series looks at why cryptographic discovery — knowing where cryptography exists — is necessary but not sufficient, and what has to happen after discovery for exposure to actually go down.

Scroll to Top