Commissioning a Post-Quantum Cryptography (PQC) risk assessment without knowing what to demand from the tools behind could lead you to end up with an incomplete inventory. And when a regulator asks for your cryptographic posture evidence, incomplete is the same as absent.
The usual method to evaluate PQC risk assessment tools is focused on price, brand and dashboard aesthetics. However, there are other important factors at play that determine whether an assessment will produce actionable output. This blog outlines those five criteria to apply before any engagement begins.
A PQC risk assessment is only as good as its discovery layer
Risk scoring requires a complete cryptographic inventory as input. There is no way around this sequencing.
A tool that applies quantum-risk scoring without first discovering all cryptographic assets across your environment is scoring against a partial picture. And a partial picture produces a partial risk register. What would this mean? It means your migration prioritisation is wrong before it starts.
Discovery must cover five surfaces:
- source code and dependency libraries
- network traffic and TLS configurations
- container images and compiled binary artifacts
- HSM and key management systems, and
- runtime configurations.
Miss any surface and you have gaps. Gaps at the discovery stage compound at every subsequent stage.
Criterion 1: Discovery surface coverage
The first question to ask any vendor is: which surfaces does your tool scan?
A tool covering only source code will miss cryptography negotiated at the network layer – TLS cipher suites, protocol versions, certificate chains across live endpoints. A tool covering only network traffic will miss cryptographic library usage embedded in application code. Neither will reach keys stored in your Hardware Security Modules (HSMs) or cloud Key Management Systems (KMS).
For a BFSI organisation with core banking systems, payment gateways, cloud infrastructure and third-party APIs, single-surface discovery is a compliance liability. Your assessment scope must match your actual cryptographic estate.
Criterion 2: Quantum risk scoring methodology
Not all cryptographic algorithms carry equal quantum risk. A credible assessment tool must distinguish between these tiers, not lump everything into a single “vulnerable” category.
The risk tiers look like this:
- RSA, Elliptic Curve Cryptography (ECC) and Diffie-Hellman are at critical risk – Shor’s algorithm running on a sufficiently large quantum computer breaks them directly.
- AES-128 is at medium risk – Grover’s algorithm halves effective key strength, reducing 128-bit security to roughly 64-bit. AES-256, SHA-384 and SHA-512 are currently considered safe under known quantum attack models.
If a tool scores your entire cryptographic estate at the same risk level, it is not a risk assessment tool. It is an inventory tool with a threat label applied uniformly. The output will not support meaningful migration prioritisation.
Criterion 3: Data shelf-life weighting
Algorithm type alone does not determine migration urgency. Data sensitivity and longevity do.
A payment session token that expires in 24 hours carries negligible Harvest Now, Decrypt Later (HNDL) risk. An adversary collecting that ciphertext today gains nothing useful when quantum capability arrives. A mortgage record, board communication or regulatory filing requiring 20 years of confidentiality is an active HNDL target right now.
The Government of India Task Force report is explicit on this: for organisations where data longevity exceeds ten years, the HNDL threat is active today not when Q-Day arrives.
Your assessment tool must allow prioritisation by data sensitivity and shelf-life, not just algorithm type. Without this weighting, your migration order will not reflect actual risk exposure.
Criterion 4: Regulatory output alignment
India’s regulatory landscape for cryptography creates three distinct evidence requirements that do not map to a single generic report.
CERT-In expects CycloneDX-format CBOM output aligned to its Technical Guidelines Version 2.0. SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF) requires a structured cryptographic asset register with risk scoring tied to data sensitivity. RBI master directions require key management control documentation mapped to specific framework requirements.
Running one generic assessment and expecting it to serve all three is the most common scoping error we see. Ask every vendor directly:
- Does your output format map to CERT-In’s CycloneDX requirements?
- Does it produce SEBI CSCRF-ready registers?
- Does it document key management controls for RBI review?
If the answer to any of these is “we can export a report and you can map it manually,” factor that translation effort into your assessment timeline and budget.
Criterion 5: Deployment model for data residency
This criterion is non-negotiable for Indian BFSI organisations. Your cryptographic inventories such as keys, certificates, algorithm usage, HSM configurations cannot be processed in foreign cloud instances. That data is itself sensitive.
Air-gapped Virtual Private Cloud (VPC) deployment or Indian-region hosting on AWS Mumbai or Azure India is a compliance requirement, not a preference. Evaluate this before shortlisting any tool. A platform with excellent discovery coverage and regulatory output that cannot meet Indian data residency requirements is not an option for your organisation.
CyberNX PQC readiness solutions support fully air-gapped VPC deployments and local Indian hosting, specifically to meet BFSI data residency obligations under RBI and SEBI frameworks.
Conclusion
Run every platform through these five criteria before any conversation about features or pricing. The criteria are sequential: if a tool fails on discovery coverage, risk scoring methodology is irrelevant. If it fails on data residency, everything else is moot.
A partial inventory becomes significantly more expensive when discovered during a regulatory audit.
Evaluating PQC risk assessment tools on the right criteria changes what you ask for and what you get back. Discovery coverage, risk scoring methodology, data shelf-life weighting, regulatory output alignment and data residency – these five criteria determine whether your assessment leads to an actionable migration programme or sits in a shared drive.
CyberNX CBOM solutions cover all four discovery surfaces, produce CycloneDX output mapped to Indian regulatory requirements and deploy on fully air-gapped Indian infrastructure. If your organisation is approaching a PQC risk assessment, speak to our team before you scope it.
PQC risk assessment tools FAQs
What is the difference between a PQC risk assessment and a CBOM?
A CBOM is the structured inventory of your cryptographic assets – algorithms, keys, certificates and protocols. A PQC risk assessment uses that inventory as its starting point and layers quantum-risk scoring on top: identifying which assets protect long-lived data, which algorithms are quantum-vulnerable, and which systems need to migrate first. You need a complete CBOM before a meaningful PQC risk assessment can begin.
Why does data shelf-life matter for PQC risk scoring?
Because the HNDL threat is active now. Adversaries are collecting encrypted data today with the intent to decrypt it once quantum computing capability arrives. Data that needs to stay confidential for a decade or more is already at risk – regardless of when a cryptographically relevant quantum computer appears.
Does CyberNX support CERT-In compliant CBOM output?
Yes. CyberNX CBOM solutions produce CycloneDX-format output aligned to CERT-In’s Technical Guidelines Version 2.0, with risk scoring mapped to SEBI CSCRF and RBI master direction requirements.
