Post-quantum cryptography readiness is now a bank governance issue

At a glance

What this is: This is a PQC readiness analysis for financial services, and its key finding is that delayed migration planning creates a governance gap now, not a future technical issue.

Why it matters: It matters because IAM, PKI, and identity platform teams must treat cryptographic inventory and algorithm agility as part of identity trust governance across machine, service, and customer-facing systems.

By the numbers:

• 25% of FinServ organizations could accurately inventory where, tory where vulnerable algorithms like RSA and ECC are used across TLS connections, app-level signing mechanisms, service mesh authentication, customer APIs, and developer toolchain.

👉 Read Keyfactor's PQC roadmap for financial services

Context

Post-quantum cryptography, or PQC, is the shift from cryptographic algorithms vulnerable to quantum attack to algorithms designed to resist it. In financial services, the problem is not only future decryption, but the current inability to inventory where legacy algorithms protect identity trust across systems, services, and customer interactions.

That makes PQC a governance issue as much as a cryptography issue. If teams cannot identify which certificates, signing processes, and machine-to-machine trust paths depend on RSA or ECC today, they cannot prove resilience, ownership, or migration readiness when regulators or auditors ask.

For identity and access teams, the lesson is direct: cryptographic agility sits alongside lifecycle governance, secrets management, and workload identity as part of the trust fabric. The organizations most exposed are usually the ones that treat cryptography as an infrastructure detail instead of an identity control surface.

Key questions

Q: How should banks prioritise post-quantum cryptography work?

A: Banks should start with an inventory of cryptographic dependencies, then rank systems by data lifespan, regulatory exposure, and operational criticality. Long-lived customer data, identity packets, signing services, and externally exposed APIs should move first because they are hardest to protect retroactively once quantum risk becomes operational.

Q: Why does PQC readiness affect IAM and identity teams?

A: Because cryptography is part of the trust fabric that authenticates systems, signs transactions, and protects machine-to-machine communication. IAM and identity teams often own certificates, service authentication, and lifecycle controls, so they are central to proving where vulnerable algorithms exist and how trust can be migrated safely.

Q: What breaks when organisations cannot map vulnerable algorithms?

A: Migration becomes reactive, ownership becomes unclear, and hidden dependencies remain in production until an audit, incident, or procurement change exposes them. Without a clear map, banks cannot prove that they know where RSA or ECC still protects sensitive communications or identity flows.

Q: Who is accountable when quantum-readiness gaps become a compliance issue?

A: Accountability usually sits across security architecture, IAM, platform engineering, and risk leadership, because no single team owns the full cryptographic estate. For regulated firms, the governance obligation is to show that ownership, prioritisation, and migration oversight are explicit before auditors ask for evidence.

Technical breakdown

Cryptographic inventory is the first control plane

PQC readiness begins with knowing where cryptography exists, who owns it, and how long it will remain in use. In practice, that means certificates, signing keys, TLS endpoints, service mesh authentication, APIs, and developer pipelines all need to be mapped into one inventory. Without that baseline, migration planning becomes guesswork and hidden dependencies survive until a regulator, outage, or audit forces discovery.

Practical implication: build a cryptographic asset inventory that includes ownership, lifecycle state, and algorithm dependency for every trust boundary.

Crypto-agility is about replacing algorithms without breaking trust

Crypto-agility means an organisation can swap cryptographic primitives with minimal disruption to systems, users, and service-to-service trust. The hard part is not the replacement itself, but the operational coupling: hardcoded algorithms, certificate renewal chains, vendor integrations, and legacy services all create friction. Banks that lack abstraction between policy and implementation will find migration expensive, slow, and brittle.

Practical implication: separate cryptographic policy from application code so algorithm changes do not require a full platform redesign.

Harvest-now, decrypt-later changes the risk timeline

Harvest-now, decrypt-later attacks are built on the fact that encrypted data can be stolen long before it can be read. That extends the threat horizon from immediate compromise to delayed exposure, which is especially serious for financial records, identity packets, and long-lived confidential communications. The control question becomes how long sensitive data must remain protected, and whether current algorithms will still be defensible at that horizon.

Practical implication: prioritise the systems holding long-lived or regulated data first, because their cryptographic shelf life matters most.

Threat narrative

Attacker objective: The attacker aims to store encrypted data now and decrypt it later when quantum capability makes the stolen material usable.

1. entry via long-term harvesting of encrypted cloud backups and system communications, while current encryption still appears intact.
2. credential or cryptographic exposure persists because the organisation has no complete inventory of vulnerable algorithms or trust dependencies.
3. impact arrives later when quantum capability crosses the threshold and previously stolen data becomes readable, including transaction logs and identity packets.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Crypto-agility is now a trust governance requirement, not a future optimisation. Financial institutions cannot treat post-quantum planning as a pure cryptography exercise because the real problem is ownership, inventory, and change control across identity trust paths. A bank that cannot show where RSA or ECC is embedded cannot credibly claim readiness, regardless of how advanced its migration intentions are. The practitioner conclusion is that crypto-agility belongs in governance reporting, not only in security architecture.

Harvest-now, decrypt-later creates a compliance problem before it creates a breach problem. The organisation may pass today’s audit while still accumulating unreadable but exfiltratable data that will become sensitive later. That means retention, classification, and algorithm lifespan must be assessed together, especially for customer identity packets and long-lived transaction records. The practitioner conclusion is that data protection horizons have to be aligned to cryptographic shelf life, not just current controls.

Crypto inventory is the named concept banks keep underestimating. In practice, this is the difference between knowing that PQC matters and being able to prove where migration work must start. The article shows that fewer than a quarter of FinServ organisations can accurately inventory vulnerable algorithms across core systems, which means most migration plans begin with blind spots. The practitioner conclusion is that inventory quality is the deciding control for PQC readiness.

Identity trust now depends on algorithm portability across machine and application layers. Banking environments do not fail at a single certificate point, they fail when one algorithm choice is embedded across APIs, developer tooling, and service authentication. That makes migration a cross-domain issue spanning PKI, IAM, and platform engineering. The practitioner conclusion is that PQC planning must be integrated into identity and workload trust programmes, not isolated in cryptography teams alone.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
• That governance gap is why practitioners should also look at Ultimate Guide to NHIs , Key Challenges and Risks when they are mapping machine trust, identity ownership, and rotation policy.

What this signals

PQC readiness will increasingly be judged through the same lens used for machine identity governance: can the organisation inventory, rotate, and prove control over the trust mechanisms that keep systems speaking securely. As crypto-agility becomes a board-level topic, banks that cannot trace certificate and algorithm ownership will struggle to defend their migration plans. For a broader identity control view, see Ultimate Guide to NHIs , Key Challenges and Risks.

Cryptographic shelf-life risk: the practical question is how long protected data must remain protected before current algorithms become a liability. That means financial services teams should align retention, classification, and migration priorities rather than treating quantum readiness as a standalone project.

With only 1.5 out of 10 organisations highly confident in securing NHIs, the broader message is that identity trust programmes already have a confidence gap before PQC pressure fully lands. Banks should treat algorithm migration, machine identity governance, and lifecycle ownership as one operating model rather than separate workstreams.

For practitioners

• Inventory cryptographic dependencies across trust paths Map every certificate, key, signing mechanism, TLS endpoint, service mesh dependency, customer API, and developer toolchain that relies on RSA or ECC, and assign ownership for each dependency.
• Classify assets by cryptographic shelf life Prioritise systems holding regulated, long-lived, or identity-rich data so the migration order reflects how long the data must remain protected.
• Separate cryptographic policy from application code Use abstraction layers and hybrid-ready standards so algorithm changes can be executed without rewriting every dependent service or control.
• Build audit evidence for crypto-agility now Document tested migration pathways, renewal processes, and fallback procedures so regulators can see a credible readiness plan before enforcement pressure rises.

Key takeaways

• PQC readiness is a governance problem because banks must prove where vulnerable algorithms exist before they can migrate them.
• Harvest-now, decrypt-later risk turns today’s encryption decisions into tomorrow’s exposure if long-lived data is not prioritised.
• Crypto inventory, ownership, and policy abstraction are the controls that determine whether a bank can adapt without breaking trust.

Key terms

• Post-quantum cryptography: Cryptographic algorithms designed to resist attacks from quantum computers. In practice, PQC is a migration problem as much as a technology problem, because organisations must replace vulnerable algorithms without breaking authentication, signing, or data protection workflows.
• Crypto-agility: The ability to change cryptographic algorithms quickly and safely without redesigning the surrounding system. It depends on abstraction, inventory, and ownership so that certificates, keys, and signing processes can be swapped before old algorithms become unacceptable.
• Harvest-now, decrypt-later: A threat pattern where attackers steal encrypted data now and wait to decrypt it later when stronger computing makes old protections obsolete. The risk is especially serious for long-lived records, regulated communications, and identity data with a long confidentiality horizon.
• Cryptographic inventory: A complete record of where cryptographic controls exist, what algorithms they use, who owns them, and how long they are intended to last. Without this baseline, migration planning is blind and audit evidence is weak.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and workload identity alongside broader identity lifecycle topics. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Keyfactor: Why Every Bank Needs a PQC Roadmap (Yesterday). Read the original.