TL;DR: Post-quantum readiness is less about selecting replacement algorithms than about assigning ownership across certificates, libraries, suppliers and platforms, according to AppViewX. NIST’s transition timeline makes cryptographic posture management the practical control that exposes where trust dependencies live and whether they can actually be changed safely.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on AppViewX's blog post: Cryptographic posture management is the control that turns post-quantum readiness into accountable ownership across certificates, libraries and services.
Why it matters: This matters because identity and infrastructure teams will have to prove which cryptographic dependencies exist, who owns them and whether they can be replaced without breaking production.
By the numbers:
- RSA and elliptic-curve cryptography will be deprecated after 2030 and disallowed after 2035, according to AppViewX.
Context
Post-quantum readiness exposes a governance problem before it exposes a technical one: cryptographic trust is spread across applications, devices, suppliers and cloud services, while ownership is often split across different teams. When the underlying algorithms change, organisations need to know not only what uses cryptography, but who can change it without causing outage or breaking a dependency.
The operational challenge is that certificate inventories and scan results are point-in-time evidence, while cryptographic dependency chains change continuously. Lifecycle governance for NHIs becomes relevant because the same discipline of ownership, rotation and offboarding now applies to certificates, signed tokens and the systems that rely on them.
Key questions
Q: Why does post-quantum cryptography change certificate management operations?
A: Post-quantum cryptography changes certificate management because the new signatures are much larger, so handshake overhead, logging, and validation design all become operational concerns. That pushes PKI teams toward compact proof models, hybrid transition paths, and more explicit lifecycle governance.
Q: Why do cryptographic inventories become unreliable so quickly?
A: Cryptographic inventories become unreliable quickly because keys, certificates, algorithms, usages and owners change faster than manual records do. Expired certificates, rotated API keys, duplicated secrets and shadow tokens quickly make spreadsheets stale. A dependable inventory needs automated discovery, asset ownership, business impact tagging, lifecycle status and regular reconciliation against certificate stores, secret managers and code repositories.
Q: What is the difference between a cryptographic bill of materials and posture management?
A: A cryptographic bill of materials is a catalogue of the cryptographic components used by an application or service, such as algorithms, libraries, keys, certificates and protocols. Cryptographic posture management is an ongoing control process that finds weak, expired, misused or non-compliant cryptography across systems and checks exposure, policy and remediation status.
Q: How should security teams prioritise cryptographic changes as quantum computing risk increases?
A: Security teams should start with the controls that protect communications first, especially key exchange, because those algorithms create the encrypted channel. Then they should plan for quantum-safe signatures and staged migration across systems that depend on SSH keys and certificates. A practical crypto-agility journey uses evaluation, adoption, and migration so organisations can reduce exposure without breaking connectivity.
Technical breakdown
Why cryptographic inventories go stale fast
A certificate inventory or endpoint scan only captures the state at the moment it runs. In modern estates, that is quickly outdated because code, configurations, libraries and infrastructure change continuously. A cryptographic bill of materials helps, but it is only useful when it is tied to live discovery and operational context. The core problem is not knowing that RSA exists somewhere in the estate, but knowing which service, application and owner depend on it, and whether that dependency is production-critical or merely present in a non-production path.
Practical implication: Treat cryptographic inventory as a live governance feed, not a compliance snapshot.
Exposure clocks versus change clocks
Post-quantum migration has two different time horizons. The exposure clock measures how long the protected data or signature must remain trustworthy. The change clock measures how long it will take to replace the cryptography without breaking the system. Those clocks are rarely aligned, which is why a short-lived connection can still protect data that must remain confidential for years, while firmware or root-of-trust changes may require major hardware replacement. A sound readiness model separates those timelines instead of assuming one migration date fits all assets. See the Machine Identity, PKI and Certificate Lifecycle Guide.
Practical implication: Prioritise the cryptographic assets with the longest confidentiality horizon and the hardest replacement path.
How crypto-agility becomes verifiable
Crypto-agility is only meaningful when an organisation can show that a new cryptographic choice works in production-like conditions. A lab success that fails in client compatibility, certificate handling or deployment automation does not count as readiness. The useful sequence is discover, assess, pilot and verify, with policy enforcement attached to deployment rather than left as a manual promise. That is also where AI agent identities matter, because signed tokens, keys and certificates underpin their delegated authority just as they do for services and workloads.
Practical implication: Require a tested change path before declaring any cryptographic dependency migration complete.
Threat narrative
Attacker objective: The practical objective is to keep trust paths exploitable until defenders are forced into rushed, error-prone cryptographic replacement.
- Entry occurs when organisations continue to rely on deployed cryptographic dependencies that are already embedded across certificates, libraries and signed connections.
- Escalation happens when ownership is fragmented, because no single team can safely change the affected dependency before the deprecation window closes.
- Impact is a forced migration under time pressure, where broken trust chains or unsupported algorithms can disrupt services and expose long-lived data.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cryptographic posture management is the ownership model post-quantum programmes need. The hard part is not replacing an algorithm in isolation, but assigning accountability for every dependency that uses it across infrastructure, applications and suppliers. That makes posture management a governance discipline, not a tooling feature. The implication is that readiness must be measured by ownership clarity as much as by technical migration progress.
Post-quantum transition exposes a broken assumption about cryptographic change windows. The assumption that trust foundations can be updated on a single, centrally managed schedule was designed for slower infrastructure cycles. That assumption fails when cryptographic dependencies are scattered across systems with different refresh cadences, vendor timelines and operational constraints. The implication is that programmes must stop treating cryptographic migration as one event and start governing it as a persistent dependency state.
Exposure time and replacement effort are the two variables that should drive prioritisation. Some systems protect data that must remain confidential for decades, while others take months or years to replace because the underlying hardware or protocol path is fixed. A posture-led approach keeps that distinction visible and prevents teams from ranking work by inventory size alone. Practitioners should prioritise by business lifetime of trust and difficulty of change, not by scan volume.
AI agent identity inherits the same cryptographic dependency problem. The article's strongest implication is that delegated machine authority is only as trustworthy as the certificates, keys and signed tokens behind it. If those foundations are not governed, agent identity becomes another unmanaged trust layer rather than a controlled identity plane. Practitioners should treat cryptographic readiness as part of identity governance, not as a separate infrastructure project.
From our research library:
- According to the 2023 State of Machine Identity Management report, only 47% of companies have enough staff dedicated to their PKI.
- Read next: Identity Security Posture Management (ISPM) Guide
What this signals
Cryptographic readiness becomes an identity problem when machine authority depends on keys and certificates. The governance question is no longer only whether a vulnerable algorithm exists, but whether the organisation can discover every system that relies on it before the trust chain becomes unsustainable. That makes cryptographic posture part of the same operating model that governs workloads, services and delegated identity.
The practical signal for programmes is that inventory alone will not deliver resilience. Readiness now depends on whether teams can move from discovery to tested replacement without losing control of the dependency chain, especially where certificates, signed tokens and supplier-managed components are involved.
For practitioners
- Establish a live cryptographic dependency inventory Map certificates, libraries, signed connections and code-level cryptographic use to the service, data and owner they affect, then keep the inventory updated as deployments change.
- Separate exposure horizon from replacement effort Rank cryptographic dependencies by how long the protected data must stay trustworthy and how difficult the replacement path will be, then sequence work accordingly.
- Require pilot evidence before declaring crypto-agility Verify that new certificates, chains or algorithms work through discovery, test deployment and production-like validation before rollout is marked complete. See the Machine Identity, PKI and Certificate Lifecycle Guide.
- Assign a named owner to every cryptographic dependency Use CMDB context or equivalent service ownership records so each finding becomes an accountable change request rather than an orphaned technical issue.
Key takeaways
- Post-quantum readiness is fundamentally an ownership and dependency problem, not just an algorithm migration problem.
- The clearest evidence of readiness is whether an organisation can discover, prioritise and verify cryptographic change across live systems.
- Teams should sequence quantum remediation by trust lifetime and replacement difficulty so critical dependencies are not left until the deprecation window closes.
Related NHI Mgmt Group resources: Ultimate Guide to NHIs: Lifecycle Processes for Managing NHIs · Identity Security Posture Management (ISPM) Guide · Machine Identity, PKI and Certificate Lifecycle Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-57, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Long-lived cryptographic dependencies create the same persistence problem as long-lived secrets in identity estates. |
| Recommendation — Inventory and shorten the lifespan of cryptographic dependencies that cannot be retired before the quantum transition window closes. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The article centres on cryptographic dependency lifecycle and controlled replacement. |
| Recommendation — Govern key generation, rotation and retirement as a lifecycle, not as isolated technical events. | ||
| NIST CSF 2.0 | PR.DS-10 — Data-in-Transit is Protected | The post focuses on protecting data in transit as encryption foundations change. |
| Recommendation — Track whether transit protections remain effective as cryptographic algorithms and certificate chains are replaced. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Ownership and accountability for cryptographic dependencies require disciplined control of who can change them. |
| Recommendation — Assign and review ownership for cryptographic dependencies so changes are made by the right teams. | ||
Key terms
- Post-Quantum Cryptography: Cryptographic algorithms designed to remain secure against attacks from sufficiently powerful quantum computers. In practice, PQC is a migration problem as much as an algorithm problem because organisations must replace trust anchors, certificates, and secrets without breaking identity-dependent systems.
- Signed Token: A signed token is a token whose contents are protected by a digital signature so the recipient can verify they were issued by a trusted party and not altered. It is used in authentication and authorisation flows, often as a bearer token or assertion, and validity depends on the signing key, claims and expiry.
- Cryptographic Bill of Materials: A cryptographic bill of materials lists the cryptographic capabilities built into software components, such as supported algorithms and libraries. It is useful for component visibility, but it does not show live configuration, deployment context or actual runtime usage. That makes it a partial input, not the full governance record.
- Crypto-Agility: Crypto-agility is the ability to change cryptographic algorithms, certificates, and trust dependencies without redesigning production systems. It matters because cryptographic standards evolve, and organisations need accurate inventories and automated lifecycle controls before they can migrate safely.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org