Cryptographic Posture Management: The Layer Your Security Stack Forgot

Every security program has a discipline for scanning vulnerabilities, hardening cloud configurations, and governing identities. Almost none of them have one for cryptography, even though cryptography is the thing protecting every other layer on that list. Cryptographic Posture Management, or CPM, is the practice built to close that gap, and it is becoming urgent for a very specific, dateable reason: the quantum threat to today’s encryption and the collapsing lifespan of public TLS certificates are both accelerating at the same time.

Key Takeaways

• CPM is the continuous practice of discovering, assessing, and improving an organization’s cryptography against a defined policy, the same way vulnerability management treats CVEs.
• It builds on the CBOM (Cryptography Bill of Materials), a CycloneDX-formatted inventory of algorithms, keys, certificates, and libraries. The CBOM is the map; CPM is the navigation.
• CPM does not replace certificate lifecycle management (CLM). CLM tracks certificate validity and expiry. CPM validates whether the underlying cryptography is actually strong, across certificates, keys, algorithms, libraries, and protocols.
• Two deadlines make this urgent in 2026: NIST’s draft post-quantum transition timeline (deprecation after 2030, disallowance after 2035) and the CA/Browser Forum’s Ballot SC-081v3, which cuts public TLS certificate validity to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029.
• The operating model is a six-stage loop: discover, normalize, assess, prioritize, remediate, monitor, run continuously across code, network, runtime, and storage.

The Gap Nobody Named

Look at how the security stack matured over the last two decades. Every layer earned its own posture discipline: a dedicated practice for continuously measuring and improving it.

Security Layer	Posture Discipline
Vulnerabilities	Vulnerability Management
Cloud configuration	CSPM
Data	DSPM
Identities	Identity governance
Cryptography	Nothing, until now

That gap survived this long because most cryptographic failures are invisible to the tools built for everything else. A deprecated TLS version still negotiating, a weak cipher still enabled, an RSA key that is too short: none of these produce a CVE with an identifier a vulnerability scanner can catch. CLM does not validate algorithm strength either; its job is expiry, not cryptographic quality. So a control protecting every other layer of the stack has been, until recently, the one layer nobody was actually measuring. The discipline built to measure it is Cryptographic Posture Management (CPM).

What Cryptographic Posture Management Actually Is

CPM is the continuous practice of discovering, assessing, and improving the cryptography an organization uses, measured against policy, driving remediation over time. Three verbs carry the definition:

• Discover means finding every cryptographic asset in use, continuously, not as a one-time audit. Algorithms, keys, certificates, libraries, and protocols change daily across a live estate.
• Assess means measuring each of those assets against a defined policy: approved algorithms, minimum key lengths, current protocol versions.
• Improve means ranking the gaps by risk, driving remediation in priority order, and tracking whether posture is actually getting better over time.

The closest existing analogy is vulnerability management. No security team scans for CVEs once and declares victory; it is accepted as a permanent, cyclical program. Cryptography has never received that same treatment for most organizations, and CPM is the shift from treating cryptography as something you configure once and forget to something you continuously measure. But continuous management requires more than a definition. It needs a reliable view of the cryptographic estate, which is where the CBOM comes in.

CPM Builds on the CBOM

CPM has two halves that are easy to conflate. The simplest way to hold the distinction: the CBOM is the map, CPM is the navigation. A CBOM with no program around it is a report nobody acts on. A program with no CBOM underneath it is flying blind. You need both.

The CBOM: The Map

The CBOM, or Cryptography Bill of Materials, is a structured, point-in-time inventory of an organization’s cryptographic assets. It is data. It tells you what you have. It does not tell you what to do about it.

• Structured inventory of algorithms, keys, certificates, libraries, and dependencies
• A point-in-time snapshot of the estate
• Machine-readable, expressed in the CycloneDX standard so tools and auditors can consume it directly

CPM: The Navigation

CPM is the continuous program built on top of that inventory.

• Continuous program built on the CBOM
• Measures assets against cryptographic policy
• Prioritizes weaknesses and drives remediation
• Keeps the map current as the estate changes

With that distinction established, it is equally important to understand where CPM fits alongside the certificate management tools organizations already use.

CPM and CLM Are Scope, Not Competition

If your organization already runs a certificate lifecycle management (CLM) tool, a fair question follows: isn’t this the same thing? It is not, but it is not a competitor either. CLM stays essential inside a CPM program; it is one control among several, and certificates are a fraction of the full posture that keys, algorithms, libraries, and protocols make up the rest of.

Laid side by side, the scope difference is the whole story:

Dimension	CLM	CPM
Asset scope	Certificates only	Certificates, keys, algorithms, libraries, protocols
What it checks	Validity and expiry	Cryptographic strength and policy compliance
Core action	Automates issuance, renewal, revocation	Ranks and remediates cryptographic risk
Goal	Prevent expiry outages, pass audits	A measurable, improving posture

A certificate can be perfectly valid, with an intact chain and no expiry in sight, and still be signed with an algorithm that should have been retired years ago. CLM will not flag that. It is not built to. That is the gap CPM closes.

Why CPM Is Urgent Now

Harvest Now, Decrypt Later

The quantum threat to today’s cryptography is already active, not hypothetical. An adversary does not need a working quantum computer today to attack data today. They can record encrypted traffic now, store it, and decrypt it later once a cryptographically relevant quantum computer exists. This is called harvest now, decrypt later, and it changes the math on migration timing in a way that past algorithm transitions did not.

• Exposed Now – Any data captured in transit under RSA or elliptic-curve key exchange is already collectible by anyone willing to store it.
• Long-Lived Data – Health records, financial data, government secrets, and intellectual property often need to stay confidential for ten to twenty-five years or more, which means the “decrypt later” half of the attack lands well inside that secrecy window.
• The Asymmetry – When the industry moved from RSA to elliptic curve, moving late meant running with a reduced security margin for a while. Late PQC migration is not a margin problem, it is a total-loss problem: Shor’s algorithm, run on a sufficiently large quantum computer, does not weaken RSA and elliptic curve, it breaks both completely, because it solves the exact factoring and discrete-logarithm problems their security depends on in polynomial time.

The downside of moving early is some wasted effort. The downside of moving late is total exposure of anything an adversary already recorded.

The 47-Day Certificate Mandate

The CA/Browser Forum passed Ballot SC-081v3 in April 2025, compressing the maximum validity period for publicly trusted TLS certificates from 398 days in three steps:

• 200 days – starting March 15, 2026 (already in effect)
• 100 days – starting March 15, 2027
• 47 days – starting March 15, 2029

This is a distinct threat from harvest-now-decrypt-later: the quantum threat is about confidentiality, someone reading recorded data later, while the certificate mandate is about authentication, shrinking how long a compromised key or stale validation data stays trusted. A certificate renewed once a year today will, by 2029, renew roughly eight times a year, and manual tracking with a spreadsheet reminder does not survive that arithmetic.

What renews every 47 days is the certificate and its signature, and in 2026 that signature cannot simply be flipped to a post-quantum algorithm, because no browser yet trusts a post-quantum certificate and the CA/Browser Forum has not opened its rules to them. What organizations can already switch on today is post-quantum hybrid key exchange, the confidentiality protection, ahead of when the Web PKI eventually allows post-quantum signatures. That is where continuous discovery earns its keep:

• Discover the certificates automation does not yet know about, across code, network, runtime, and storage, because the forgotten ones are what cause outages.
• Assess lifetime and algorithm together, so every renewal also becomes a step toward a quantum-safe posture.
• Automate renewal on the assets that matter most first, ranked by exposure.
• Monitor for drift as renewal volume multiplies.

The automation built to survive a 47-day renewal cadence is the same automation that will carry the eventual certificate transition.

Together, these pressures point to the same conclusion: cryptographic management cannot remain a periodic exercise. It needs an operating model that runs continuously.

The Policy Baseline, and Why Meeting It Is Not a Simple Swap

NIST finalized three post-quantum standards in August 2024:

Standard	Function	Replaces
FIPS 203 (ML-KEM)	Key encapsulation	RSA and ECDH key exchange in TLS and VPNs
FIPS 204 (ML-DSA)	Primary post-quantum signature	Certificates, code signing, authentication
FIPS 205 (SLH-DSA)	Conservative, stateless hash-based signature	Serves as a backup to ML-DSA. It relies on a different mathematical foundation (hash functions instead of lattices) and is intended for cases where algorithm diversity is wanted, in case a future weakness is found in lattice-based cryptography.

NIST‘s draft transition roadmap, IR 8547, sets the dates that matter for planning:

• 2024 – Standards finalized, so migration can start immediately.
• After 2030 – 112-bit-security algorithms such as RSA-2048 are deprecated, meaning they should not go into new systems. ECDSA P-256, at 128-bit security, is not in this 2030 tier; it falls under the 128-bit-and-above disallowance that takes effect after 2035
• After 2035 – Quantum-vulnerable public-key algorithms are disallowed entirely.

One honest caveat worth keeping in front of any audience: IR 8547 remains an initial public draft as of mid-2026 and has not been finalized as a binding standard. Treat “deprecated after 2030” and “disallowed after 2035” as the planning horizon the industry is aligning to, not dates locked to the calendar.

Those dates would be comfortable if PQC were a drop-in replacement. It is not, because the new keys and signatures are substantially larger, and that size ripples through everything downstream:

• A post-quantum public key is roughly 4 to 4.6 times larger, depending on encoding, than what it replaces: ML-KEM-768 runs about 1,184 bytes against roughly 270 bytes for an RSA-2048 public key in PKCS#1 DER encoding (closer to 294 bytes in the full X.509 SubjectPublicKeyInfo form used in TLS certificates).
• A post-quantum signature is far larger still, on the order of 47 times: the final FIPS 204 ML-DSA-65 signature is 3,309 bytes against 70 to 72 bytes for a DER-encoded ECDSA P-256 signature.

Size is an operational problem, not a cosmetic one:

• Bigger keys and signatures produce bigger TLS handshakes, which can fragment across packets and interact badly with older network gear.
• Constrained devices with limited memory may struggle to handle the new sizes at all.
• Certificate chains multiply the overhead at every hop, because every certificate in the chain now carries a larger signature.

Meeting the baseline is a genuine engineering migration touching protocols, hardware, and certificate chains, which is exactly why it needs to start from an accurate inventory rather than discovering these constraints one painful surprise at a time.

You Cannot Migrate What You Cannot See

Only about 35 percent of organizations maintain a centralized inventory of their cryptographic assets. The other roughly two-thirds are approaching a hard migration essentially blind.

That blindness is not carelessness; it is genuinely hard to see:

• Operating systems ship thousands of cryptographic components out of the box that nobody enumerated.
• Embedded libraries such as OpenSSL and Bouncy Castle sit buried as dependencies of dependencies.
• Third-party binaries arrive as vendor software whose source code cannot be inspected.
• Developer environments accumulate orphaned keystores and hardcoded keys living outside formal PKI.
• Legacy protocols, old TLS and SSH versions, keep running because nobody switched them off after the upgrade that was supposed to replace them.

Every one of these is cryptography an organization depends on and currently cannot see, and it is exactly the gap discovery is built to close.

Inventory Is Becoming a Regulatory Requirement

If the security case does not move leadership, the compliance case increasingly will. 15 countries plus the EU now recommend or require some form of cryptographic inventorying for at least some organizations, according to Microsoft’s Security Blog from April 2026.

Framework	What It Requires
DORA (EU)	The Level 1 regulation (EU 2022/2554) requires financial entities to manage ICT risk; the cryptographic-controls specificity comes from its Level 2 Regulatory Technical Standard (EU 2024/1774), Article 6.
OMB M-23-02 / M-26-15 (US)	M-23-02 (2022) first required agencies to inventory quantum-vulnerable systems. Its 2026 successor, M-26-15, replaces that with a five-phase migration timeline through 2035 and a 120-day deadline for a PQC migration plan built on an automated inventory.
PCI DSS 4.0	Requires a documented inventory of cryptographic cipher suites and protocols for anyone handling payment card data.

Every one of these presupposes an inventory exists. You cannot manage crypto risk you have not catalogued, and the inventory the security case already argued for is the same inventory regulators are beginning to demand. Encryption Consulting’s breakdown of NIST IR 8547 and SP 800-131A covers the federal algorithm-transition rules in more detail.

How to Actually Run CPM

Microsoft’s Security Blog outlined this operating model in April 2026 as a six-stage loop, where each stage feeds the next and the last feeds back into the first. We apply that same lifecycle here:

1. Discover – collect cryptographic signals from across the environment.
2. Normalize – unify those signals into one inventory, one schema.
3. Assess – evaluate assets against policy baselines and standards.
4. Prioritize – rank by criticality, exposure, and compliance need.
5. Remediate – rotate keys, update libraries, replace weak algorithms.
6. Monitor – track drift, new commits, and renewals, then loop back to discovery.

Normalize is the stage most programs skip, and it is the most common way CPM quietly fails. Signals arrive from dozens of tools, each with its own format and its own idea of what a finding looks like. Without unifying that into one schema first, what exists is a pile of data, not an inventory, and a pile of data cannot be assessed consistently. It produces duplicate entries, contradictory naming, and gaps that look like coverage.

Point the Loop at Four Domains

Cryptography lives in four distinct places, and each needs its own discovery method. Missing a domain creates a permanent blind spot regardless of how good the tooling is elsewhere:

Domains	Description
Code	Primitives and libraries referenced in source, found through static analysis of repositories and dependencies.
Network	Encryption live on the wire, the TLS and SSH handshakes and cipher suites actually negotiated.
Runtime	Cryptography active in memory, the library calls in running processes and live key material.
Storage	Assets at rest: certificates, keys, and secrets on disk, in databases, in key vaults, and in configuration files.

The four domains cross-check each other. A library sitting in code but never called at runtime is low urgency, it is potential rather than active risk. A protocol that appears nowhere in configuration files but shows up live on the wire is a real finding, something running that nobody declared. Catching that contradiction requires looking across domains at once; a single-domain scan cannot see it.

The Design Goal for CPM: Crypto Agility

The loop finds and ranks the problems. How fast you can fix them depends on one design property. NIST’s Cybersecurity White Paper 39, finalized in its full version on December 19, 2025, defines crypto agility as the ability to replace or adapt cryptography without disrupting operations. Anyone can change an algorithm if they are allowed to take the system down; agility means changing it while the lights stay on.

CSWP 39 does not package this into a single named framework, but its discussion groups into four practical lever:

• Modularity – Separate algorithms from application logic so implementations swap like components.
• API abstraction – Applications request a cryptographic service, not a specific algorithm; the library decides.
• Policy, not code – Algorithm choices live in machine-readable policy profiles, so a disallowed algorithm is a config change, not a rewrite.
• Hybrid mechanisms – Run classical and post-quantum algorithms together during the transition, protecting against both threat models at once.

CSWP 39 is direct about the stakes: the PQC migration will not be the last cryptographic transition, and systems retrofitted rigidly today will fail the same way again next time.

Begin With Discovery

The instinct in a lot of security programs is to treat 2030 or 2035 as the trigger and plan backward from there. We would push back on that. The deadline that actually matters is whichever one an auditor, a regulator, or an adversary hits first, and right now that is more likely to be a certificate renewal automation failure or a PCI DSS inventory finding than a quantum computer.

The organizations we see handle this well are the ones that treat discovery as the immediate, low-cost first move rather than the last step before a migration project, because the six-stage loop only produces a trustworthy ranked list once normalization and cross-domain discovery are actually in place. Waiting for budget season to start an inventory is the single most common way we see this stall.

Getting Started

Six practical first moves, none of which require waiting for a budget cycle:

1. Assign Ownership – name an accountable owner spanning security, infrastructure, and development.
2. Start Collecting and Normalize – pull cryptographic signals from tools already deployed across Code, Network, Runtime, and Storage, and unify them into one inventory schema.
3. Set the Policy Baseline – document approved algorithms, key lengths, validity periods, and protocol versions.
4. Prioritize Exposures – rank findings by asset criticality, internet exposure, and compliance mandate.
5. Plan Remediation – build runbooks and automation for library updates, key rotations, and reconfigurations.
6. Bring in Specialists – where coverage or speed falls short, add dedicated discovery tooling and outside advisory.

Ownership and policy are decisions your team makes once. Collection, prioritization, and remediation are where the work becomes continuous, and where our tooling and advisory work come in.

How Encryption Consulting Fits

CPM is achievable but doing it well across a large, heterogeneous environment is where most organizations want a partner. Encryption Consulting provides the means designed exactly for that journey, from CBOM through assessment to implementation.

CBOM Secure is Encryption Consulting’s answer to both the map and the continuous stages of the loop: it builds the CBOM and runs discover, normalize, assess, and prioritize, plus the monitoring that feeds back into discovery.

• Production sensors – Discovery runs in live environments, not just repositories, which matters because runtime is one of the four domains static scanning misses.
• Code-path reachability – Shows which cryptography actually runs rather than what is merely installed, separating real findings from noise.
• Risk scoring, low to critical – Every asset gets a ranked severity score rather than a flat list of raw numbers.
• CycloneDX 1.6 / 1.7 export – A standards-based CBOM output for tooling and auditors, mapping to compliance frameworks including CMMC, CNSA 2.0, NIST IR 8547, PCI DSS, ISO 27001, and SOC 2.
• Asset relationship mapping – Links every certificate, key, and library to the application and dependency chain it belongs to, so a single weak algorithm shows every downstream system it touches instead of appearing as an isolated finding.

CBOM Secure or any CBOM tool for that matter, doesn’t cover the remediation stage. Remediation needs human judgment: sequencing a migration, deciding rotation order, and executing changes without breaking dependencies. That is where Encryption Consulting’s PQC Advisory Services take over, translating a ranked CBOM finding list into an executable plan.

• PQC Impact Assessment: Assess vulnerabilities across RSA, ECC, PKI, HSMs, and applications to identify quantum risks and prioritize migration needs.
• PQC Strategy & Roadmap: Develop a phased, tailored migration strategy aligned with business, compliance, and technical goals, including policy updates and crypto-agility.
• Vendor Evaluation & PoC: Evaluate PQC-ready solutions, manage RFI/RFPs, conduct PoCs, and compare technologies to identify the right fit.
• Pilot Testing & Scaling: Validate PQC deployments for interoperability and performance, using pilot feedback to optimize enterprise-wide rollout.
• PQC Implementation: Integrate PQC across PKI, infrastructure, and applications while maintaining compliance, continuity, and hybrid algorithm support. Provide training, monitoring, and lifecycle management for long-term security.

For the certificate side of the loop specifically, CertSecure Manager handles the automated discovery and renewal that a 47-day validity cadence requires. Together, the product owns the continuous stages and advisory owns the hands-on one, and monitor feeds back into discover so the program runs continuously rather than closing out as a one-time project.

FAQ

What Is the Difference Between a CBOM and CPM?

A CBOM (Cryptography Bill of Materials) is a point-in-time, machine-readable inventory of an organization’s cryptographic assets in the CycloneDX format. CPM (Cryptographic Posture Management) is the continuous program built on top of that inventory: it measures assets against policy, prioritizes weaknesses, and drives remediation over time. The CBOM is data; CPM is the process.

Does CPM Replace Certificate Lifecycle Management (CLM)?

No. CLM remains essential for automating certificate issuance, renewal, and revocation. CPM widens the scope beyond certificates to cover keys, algorithms, libraries, and protocols, and it validates cryptographic strength rather than just certificate validity.

When Do Quantum-Vulnerable Algorithms Like RSA and ECDSA Get Retired?

Per NIST’s draft IR 8547 transition roadmap, 112-bit-security algorithms such as RSA-2048 are planned for deprecation after 2030 and full disallowance after 2035. ECDSA P-256 provides 128-bit security (per NIST SP 800-131A Rev 2) and is not in that 2030 tier; it falls under the 128-bit-and-above disallowance after 2035. IR 8547 remains a draft as of mid-2026, so treat these as the industry’s planning horizon rather than finalized regulatory dates.

Why Are Public TLS Certificates Dropping to 47-Day Validity?

The CA/Browser Forum’s Ballot SC-081v3, approved in April 2025, reduces maximum public TLS certificate validity from 398 days to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029, primarily to limit the window that stale validation data or a compromised key stays trusted.

What Are the Four Domains Where Cryptography Needs to Be Discovered?

Code (static analysis of repositories and dependencies), network (live TLS/SSH handshakes and cipher suites), runtime (active library calls and key material in running processes), and storage (certificates, keys, and secrets at rest in databases, key vaults, and config files).

Conclusion

Cryptography has quietly become the one layer of the security stack nobody measures, and two independent forces are closing that window at the same time: the quantum threat is already collecting today’s data for tomorrow’s decryption, and public TLS certificates are heading toward a 47-day renewal cycle that no manual process survives. Cryptographic Posture Management gives security teams a way to treat cryptography the way they already treat vulnerabilities: discovered continuously, measured against policy, and improved on a running loop rather than configured once and forgotten. The organizations that come out ahead won’t be the ones that wait for 2030 or 2035 as a trigger. They’ll be the ones that start with an accurate inventory now, while there’s still runway to act on what it finds.