Notifications
Clear all
Topic starter
25/06/2026 10:41 pm
TL;DR: Banks are being pushed to prepare for post-quantum cryptography now, not after quantum systems mature, because harvested encrypted data can be decrypted later and regulators already expect migration planning, according to Keyfactor. The governance challenge is crypto-agility: inventorying where vulnerable algorithms live, assigning ownership, and proving a forward-compatible migration path before audit pressure becomes a control failure.
NHIMG editorial — based on content published by Keyfactor: Why Every Bank Needs a PQC Roadmap (Yesterday)
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full article
Keyfactor's full blog covers the operational detail this post intentionally leaves for the source:
- A four-step PQC roadmap with inventory, algorithm classification, crypto-agility standards, and low-risk testing.
- Practical examples of where vulnerable algorithms are hiding across TLS, service mesh authentication, and developer tooling.
- Guidance on how to build a working crypto-inventory without disrupting existing bank infrastructure.
- References to the digital trust playbook and related materials for teams that need implementation detail.
👉 Read Keyfactor's PQC roadmap for financial services →
PQC readiness for banks: what governance teams need to do now?
Explore further
25/06/2026 11:20 pm
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.
A few things that frame the scale:
- 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%.
A question worth separating out:
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.
👉 Read our full editorial: Post-quantum cryptography readiness is now a bank governance issue
