Post-quantum cryptography for Indian enterprises: what to do before the DST milestones

Today's public-key algorithms, such as RSA and elliptic-curve Diffie-Hellman, can be broken by a large enough quantum computer. Nobody knows exactly when one will exist. The risk starts earlier: an adversary can record your encrypted traffic today and decrypt it later. This is "harvest now, decrypt later".

If your data must stay confidential for 5, 10 or 20 years, such as customer financial records, health data, identity data, trade secrets or government communications, it is exposed now. That is why banks, insurers, government bodies and critical infrastructure appear in the DST roadmap's early track.

The fix for this specific risk is well understood. The IETF draft for ML-KEM in IKEv2 says that by adding ML-KEM, "IKEv2/IPsec tunnels become resistant to harvest-now-decrypt-later attacks" (IETF).

The DST roadmap, developed under the National Quantum Mission, sets out:

• Phased migration for critical information infrastructure (CII) and for other enterprises, with CII going first.
• Cryptographic bills of materials (CBOMs) from vendors: requested from FY 2026-27, mandatory in procurement from FY 2027-28.
• Crypto-agility: systems that can change algorithms without redesign.
• NIST algorithms as the baseline: ML-KEM, ML-DSA and SLH-DSA.
• Testing and certification: a TEC-led framework, four assurance levels (L1–L4), and Tier-1/Tier-2 labs targeted for December 2026.
• Preference for indigenous quantum-safe products in procurement.

What it does not do: create a legal obligation. It "does not constitute a legal or regulatory mandate". Enforcement depends on sector regulators such as RBI, SEBI, TRAI and CERC, none of which had issued binding post-quantum directions as of mid-2026 (PostQuantum.com). Because the certification labs are not yet running, no product can yet hold an Indian post-quantum certificate. Treat any such claim with caution.

• TEC published a technical report on migration to post-quantum cryptography on 28 March 2025 (TEC).
• CERT-In issued technical guidelines on SBOM, QBOM and CBOM (v2, 9 July 2025). A CBOM lists the algorithms, keys, certificates and TLS settings a product uses (AZB & Partners).
• RBI's Directions of 31 July 2026 require strong, non-deprecated cryptography. In September 2026 an RBI Deputy Governor said it is time for payment system providers "to begin work moving towards quantum proofing", and RBI has formed an expert committee (Q-Safe). No date or standard has been set (MediaNama).

• FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures, all final since August 2024.
• IKEv2: RFC 9370 and RFC 9242 allow extra key exchanges; the ML-KEM-for-IKEv2 draft (-09, July 2026) is with the IESG for publication and is not yet approved.
• TLS 1.3: the hybrid X25519MLKEM768 key exchange is standardised in RFC 10024 (August 2026).
• NIST IR 8547 (draft) proposes deprecating quantum-vulnerable public-key algorithms after 2030 and disallowing them after 2035 (NIST). It is a draft, not a rule.

"Hybrid" means combining a classical algorithm with ML-KEM, so the connection stays secure as long as either one holds.

1. Build a cryptographic inventory. List every place you use public-key cryptography: VPN tunnels, TLS on portals and APIs, device firmware signing, PKI, HSMs and partner links. Ask each vendor for a CBOM. This also supports RBI's requirement for strong, non-deprecated cryptography.
2. Rank by data lifetime. Protect links that carry long-lived confidential data before anything else: branch and ATM WAN, data-centre interconnects, remote access and partner connections.
3. Retire IKEv1. IKEv1 has no post-quantum key-exchange mechanism. Move every IPsec tunnel to IKEv2.
4. Turn on hybrid ML-KEM key exchange on IPsec and TLS 1.3 where your equipment supports it. This addresses harvest now, decrypt later directly.
5. Plan authentication and firmware signing. Key exchange protects confidentiality; ML-DSA certificates and post-quantum-signed firmware protect against future forgery. PKI changes take longer, so start the plan now.
6. Require crypto-agility and CBOMs in procurement. Add clauses asking vendors to name algorithms (FIPS 203/204/205), provide a CBOM, and switch algorithms by policy.
7. Test and document. Run interoperability tests with partners and keep evidence for auditors and, later, for the DST assurance labs.

• Which FIPS 203/204/205 algorithms and parameter sets do you use, on which layers?
• Is post-quantum key exchange hybrid? On IKEv2, TLS 1.3, or both?
• Is authentication post-quantum, or still classical?
• Is firmware signed with a post-quantum scheme?
• Can you provide a CBOM, and in what format?
• Which firmware versions are required, and is post-quantum on by default?
• Which IETF code points do you implement, and with which peers have you tested interoperability?

Nexapp provides full post-quantum cryptography, generally available across SD-WAN tunnels, Instaroute routers, Nexapp SSE and the management plane:

• Hybrid classical + ML-KEM key exchange (FIPS 203) on every IKEv2 tunnel.
• ML-DSA (FIPS 204) authentication for IKEv2 and TLS peers.
• Post-quantum-signed NexappOS firmware and configuration.
• Post-quantum TLS 1.3 (X25519MLKEM768) on consoles, APIs and SSE inspection.
• Crypto-agility by policy, and a CBOM available today.

This coverage runs from a single 4G router to SSE, from one Indian vendor, aligned to the DST roadmap. Post-quantum mode is on by default.

DST, Quantum-Safe Ecosystem in India: Roadmap to Quantum Resiliency (May 2026); PostQuantum.com (DST final roadmap, May 2026); The Quantum Insider (Feb 2026 draft); DST task force report (4 Feb 2026); TEC PQC technical report (28 Mar 2025); AZB & Partners on CERT-In BOM guidelines (Jul 2025); MediaNama on RBI (Sep 2026); IETF ML-KEM for IKEv2 draft; IETF RFC 10024; NIST FIPS 203/204/205; NIST IR 8547 ipd.