Post-Quantum Cryptography Readiness: Mapping the Cryptography That a Scanner Can't See

Industry Financial Services / Banking

Key
Technologies Post-quantum cryptography, Cryptographic Bill of Materials (CBOM), CycloneDX, network topology assessment, risk assessment and scoring

Services Advisory / Security

At a Glance

Post-quantum cryptography readiness is the question every regulated institution is starting to ask: will the encryption protecting our data survive quantum computing? For a regional financial institution we advise, the honest answer depended on a harder question first — where does cryptography actually live across the estate? Most transition plans stall there, because nobody can see it all.

The market conversation is about algorithms. The real blocker is inventory. An adversary can capture encrypted traffic today and decrypt it once the hardware matures, so data with a long sensitivity life — mortgage and records data carrying ten-plus-year retention is the clearest example — is already exposed. You can't sequence a migration you can't see, and most cryptographic inventories fail on exactly the assets a code scanner can't reach: firewalls, load balancers terminating TLS, storage arrays, replication appliances, and private cloud interconnects.

We could see those already. Six months earlier, we'd mapped this same bank's network estate end to end — so when the post-quantum question arrived, the hardest part of the inventory was already done.

Two Assessments, One Compounding Asset

Callibrity mapped the bank's network first, then reused that map for the cryptographic inventory. The devices a code scanner can't see were already documented, so the second engagement started with an advantage the bank had already paid for.

An Inventory the Bank Owns

Built to open standards — the CycloneDX CBOM schema, visualized in an Apache 2.0 Linux Foundation project — so the bank keeps the tooling and isn't locked into a proprietary product. No new software was needed to deliver.

Governance Fixed, not Just Findings

Cryptographic policy had been unowned, split across three groups. The most consequential recommendation wasn't technical — it was simply to name an owner.

The Challenge

You can't transition what you can't see

Quantum computing will eventually break the public-key cryptography that protects financial data, and "harvest now, decrypt later" means the risk isn't only in the future — long-retention data is already exposed. NIST finalized its post-quantum standards in 2024, and the bank wanted to understand its position before an auditor or a board member asked.

But most institutions can't answer the prior question: where is cryptography actually used across our systems, and which of it is at risk? Without that inventory, a transition plan is guesswork. And the inventory itself is deceptively hard — cryptography turns up in code, but also in network appliances, storage, replication, and cloud interconnects that no source-code scanner will ever surface. Miss those, and the map has holes exactly where the risk concentrates.

Our Approach

Start with the map, then inventory everything the map can't.

The work began with an advantage. Months earlier we'd inventoried the bank's network — devices, protocols, and configurations across on-premises sites and Azure — and built a validated topology it didn't previously have. That engagement documented the non-application layer where cryptography hides: the firewalls, load balancers, storage, replication appliances, and private cloud circuits. For the post-quantum assessment, we pulled those assets forward rather than rediscovering them.

On the application side, we ran a source-code sweep across roughly 285 repositories spanning 15 business domains, surfacing the discrete places cryptography is actually implemented. The expensive part was the breadth of the hunt, not the depth on any one system — which is precisely why a wide, structured approach matters more than a deep one here. We paired the sweep with stakeholder interviews across eight functions, from enterprise architecture and information security to records management and the housing-programs group, because cryptography lives in places a security team doesn't own.

Open standards, so the bank keeps the tooling.

We built the inventory to the CycloneDX CBOM schema and visualized it in CBOMKit, an Apache 2.0 project under the Post-Quantum Cryptography Alliance at the Linux Foundation. The reference scanner covers Java and Python; the bank's estate is C#. Rather than sell a workaround, we built an interim generator that produced CycloneDX-compatible output from the bank's own repositories, and we found that the bank's existing software-composition-analysis tooling could already emit CycloneDX 1.6 — so no new scanner had to be introduced. The bank bought no additional tooling, and it owns everything we left behind.

Risk scored on the bank's terms, traceable end to end.

We scored risk on the bank's own likelihood and severity scales rather than importing a vendor framework, then ran an independent second pass and reconciled the differences. Every risk traces back to the interview or inventory entry that produced it, and the register carries the bank's own control columns. At the bank's request, we mapped every item across the risk register, the inventory, and the recommendations by ID, so the three documents read as a single artifact.

We delivered a machine-readable Cryptographic Bill of Materials in CycloneDX plus a working spreadsheet, a risk assessment and scored register, a recommendations report with a one-year and three-year roadmap sequenced by quarter and written for the bank to revise as budgets firm up, an executive summary and leadership playback, and a secure CBOMKit trial design for the bank's own cloud tenant.

The Results

Our executive assessment — the finding we delivered, paraphrased from the report — was that the bank maintains a strong and proactive security posture, measurably more mature than most peer institutions:

Core controls are well established, teams show real operational discipline, and the organization has invested thoughtfully in identity, network security, monitoring, and cloud governance. Across interviews, code review, and infrastructure analysis, we found no systemic failures and no critical deficiencies. The opportunities ahead are maturing cryptographic governance, completing the retirement of legacy algorithms, and formalizing post-quantum readiness — not urgent exposures, but the next steps that keep a strong posture strong as standards evolve.

That's what a bank pays an advisor for: we told it the truth about a program that was working, and gave it a sequenced way to stay ahead.

The bank accepted the findings and recommendations, and leadership praised the work. It assigned ownership of cryptographic policy — previously unowned and fragmented across three groups — which is the clearest before-and-after of the engagement. It approved the readiness framework for reuse across other systems and for vendor engagement, moved to trial the inventory tooling in its own cloud environment, and scoped follow-on work to complete the inventory and automate its refresh. The assessment anchors to the standards a regulated institution will be measured against — NIST FIPS 203, 204, and 205, the NCCoE migration practice guide (NIST SP 1800-38), CISA's Quantum-Readiness guidance, OMB M-23-02, and NSA CNSA 2.0, which targets completing the post-quantum transition by 2035.