Regulatory Guide · India BFSI
RBI Q-SAFE & CBOM Planning Guide
Indian banks, NBFCs, and fintech platforms are being asked to plan for quantum-safe cryptography under RBI Q-SAFE direction and national strategy. The first deliverable is not a new HSM — it is a Cryptographic Bill of Materials (CBOM): a complete inventory of where classical crypto lives in your stack.
What is a Cryptographic Bill of Materials (CBOM)?
A CBOM is a structured inventory of every cryptographic algorithm, key length, protocol version, library, and hardware security module (HSM) path used across your organization. It answers: where is RSA, ECC, AES, SHA, and TLS — and what breaks when we migrate to NIST PQC standards like ML-KEM-768 and ML-DSA?
CBOMs follow the same principle as software bills of materials (SBOMs) but focus on crypto exposure for compliance, vendor evaluation, and migration sequencing. CycloneDX and SPDX extensions now support cryptographic component metadata for automated tooling.
What is RBI Q-SAFE and why does it matter?
RBI Q-SAFE is the Reserve Bank of India's quantum-safe cryptography direction for regulated entities (May 2026). It emphasizes crypto agility, CBOM-based inventory, and phased migration planning — not an immediate rip-and-replace of every algorithm. Banks should treat 2026–2028 as the inventory and prioritization window before production cutovers accelerate.
Q-SAFE aligns with:
- NPCI ML-KEM-768 TLS pilots and late-2027 production targets for payment rails
- National PQC strategy phased adoption timeline (2028–2033)
- NIST FIPS 203 / 204 — ML-KEM and ML-DSA as standardized replacements
What should a bank include in its first CBOM?
Start with systems that combine external exposure and long data retention: internet-facing TLS, payment APIs, mobile app backends, HSM/KMS paths, document signing, and archival encrypted stores. For each system, record algorithm, key size, protocol version, and owner team.
| Layer | What to inventory | Red flags |
|---|---|---|
| TLS / API | Cipher suites, cert algorithms, TLS version | TLS 1.0/1.1, RSA-1024, weak curves |
| Application | JWT signing, payload encryption libraries | MD5, SHA-1, RC4, custom crypto |
| Key management | HSM, KMS, vault, key wrap algorithms | RSA-only wrap, no agility plan |
| Data at rest | DB TDE, backup encryption, object storage | 10+ year retention + classical keys |
| Dependencies | OpenSSL, BoringSSL, Java JCE, Node crypto | Pinned old versions without PQC roadmap |
How do you prioritize quantum risk?
Rank systems on two axes: harvest-now-decrypt-later (HNDL) exposure (data or channels an adversary can capture today) and operational cutover difficulty (HSM dependencies, vendor lag, third-party APIs). High HNDL + feasible migration = pilot first. High HNDL + hard cutover = design partner / staging project.
Sample prioritization matrix
| System | HNDL risk | Cutover effort | Priority |
|---|---|---|---|
| Payment gateway TLS | High | Medium | Pilot in 2026 |
| Internal admin portal | Low | Low | Wave 2 |
| Legacy HSM signing | High | High | Vendor roadmap + hybrid |
| Archived transaction DB | High | High | Re-encryption planning |
How can you automate CBOM discovery?
Combine static codebase scanning (find RSA, MD5, SHA-1, weak TLS configs in repos) with architecture interviews for HSM and network paths scanners cannot see. VajraShield's CBOM scanner analyzes source exports and lockfiles, producing an engineer report pack with NIST PQC migration guidance — a starting point for triage, not a full organizational audit.
What are realistic next steps after the CBOM?
After inventory: (1) publish a 90-day action plan, (2) run one staging pilot with hybrid ML-KEM-768 TLS or API encryption, (3) evaluate HSM/KMS vendor PQC roadmaps, and (4) brief risk committee with a phased timeline through 2030. Production mass migration is a separate program — planning starts now.
- Week 1–2: Kickoff, regulatory landscape, architecture interviews
- Week 3–4: Populate exposure map, dependency scan, risk matrix v1
- Month 2: Sandbox validation, staging design, 90-day plan sign-off
Frequently asked questions
Does CBOM replace a full security audit?
No. A CBOM is a crypto-specific inventory artifact. It complements — not replaces — penetration testing, SOC 2, and RBI supervisory reviews.
Do we need production keys in the CBOM phase?
No. Planning-phase CBOMs use architecture diagrams, config exports, and code scans. Production key material should never leave HSM boundaries during inventory.
How does CBOM relate to CERT-In directions?
Both emphasize crypto hygiene and documented controls. CBOM feeds into broader cyber resilience reporting by making algorithm exposure visible to leadership.