Harvest Now, Decrypt Later Is a Data Classification Problem

In the first post in this series, one line in the DST Task Force report did more work than any of its deadlines: planning is to proceed on an assume-breach basis with respect to Harvest Now, Decrypt Later.

Take that line seriously and the first question of a quantum migration changes. Most programmes start with the algorithm ("replace RSA and ECC") or the inventory ("find every RSA key we have"). Both are necessary. Neither tells you where to start, because neither says anything about what an adversary recording your traffic today would actually gain.

That depends on the data. This post argues that HNDL exposure is a question of how long each class of your data stays valuable, and that answering it rearranges your migration order more than any cryptographic finding will.

The breach you will never detect

Picture a lending platform in March 2026. Somewhere on the network path to its document-upload endpoint (a transit provider, a mirrored cloud link, a well-resourced state actor) someone starts recording traffic. Customers are uploading PAN cards, Aadhaar, salary slips and bank statements. The connection is TLS 1.3 with ECDHE key exchange and AES-256-GCM. By every current standard, it is done right.

Nothing fires. There is no intrusion to detect, no exfiltration from your side, no anomaly in your logs. The attacker never touched your systems. They only kept a copy of what was already crossing the wire.

In 2034, the recording is decrypted. The customers' PAN numbers, dates of birth and Aadhaar numbers are exactly what they were in 2026. The breach happened in 2026, the damage lands in 2034, and the logs that might have explained it were rotated out in 2027.

Forward secrecy does not change this. Ephemeral key exchange protects past sessions from a stolen server key, but it does not protect a session whose key exchange can itself be broken. A cryptographically relevant quantum computer running Shor's algorithm breaks each ECDHE exchange on its own. Forward secrecy raises the cost per session. It does not close the door.

Stop asking when Q-Day arrives

Estimates of when a quantum computer will break RSA and ECC range from the three years claimed by IonQ's CEO at Davos in January 2026, which the DST report cites, to well over a decade. Nobody can settle that question, and a migration plan that depends on settling it will not get started.

Michele Mosca's framing is more useful because it replaces one unanswerable number with three, two of which you can estimate:

• X: how long the data must stay confidential
• Y: how long your migration will take
• Z: how long until a quantum computer can break today's key exchange

If X + Y is greater than Z, data you are sending today is already exposed. You cannot know Z. For Indian CII, the roadmap has effectively set Y: full PQC adoption by December 2029. That leaves X, the one number almost no organisation has written down.

The capture date is fixed. The decryption date is unknown. The only variable you control is which of these bars is still riding on classical key exchange.

In practice, X becomes two questions you can ask of any data set: Would disclosure still hurt in 2030? Would it still hurt in 2035? These are not predictions of Q-Day. They are the dates by which NIST's draft guidance (IR 8547) proposes to deprecate and then disallow quantum-vulnerable algorithms like RSA-2048 and P-256. In other words, they are the dates by which the standards world stops assuming classical key exchange is good enough.

What HNDL can and can't reach

Before classifying data, be clear about which cryptography the threat actually touches. Three distinctions matter.

Key establishment is harvestable. RSA key transport, ECDH and ECDHE, and finite-field Diffie-Hellman are what an attacker needs to break to read a recorded session. These appear in TLS, IPsec and IKE, SSH, and in file encryption formats like PGP and S/MIME. Recording is enough, and the attack can be deferred indefinitely.

Signatures are not harvestable backwards. A quantum computer in 2033 lets an attacker forge a signature in 2033. It does not let them tamper with a TLS session that completed in 2026. Signatures still have to migrate, but on a separate clock set by how long a signature must remain trustworthy. That clock matters for firmware roots of trust in devices with fifteen-year field lives, root CAs, and signed documents that must stay legally meaningful for years. Merging this into one "replace RSA" project is how teams spend 2027 reissuing internal certificates while the harvestable flows keep leaking.

Encryption at rest is mostly fine, but its keys may not be. AES-256 holds up against known quantum attacks. Grover's algorithm roughly halves effective key strength, which is why India's roadmap recommends moving long-lived data from AES-128 to AES-256. The weak point is how the data key got to where it is. Backups whose data keys are wrapped with RSA and shipped offsite are exposed. So are PGP-encrypted files sent over SFTP: the file body is symmetrically encrypted, but the session key travels inside the same file, encrypted with RSA or ECDH. Capture the file and you have everything you need to open it later. Indian BFSI runs on nightly PGP-over-SFTP batches, and each one is a self-contained harvest target delivered whole.

So HNDL is a confidentiality problem on data in motion, plus any at-rest data whose keys are wrapped classically. That scope is narrower than "all RSA", and it is exactly what makes prioritisation possible.

Shelf life: the classification nobody has done

Most enterprises already classify data, just not on this axis. Sensitivity labels like public, internal, confidential and restricted measure how bad a disclosure would be. Retention schedules measure how long you must, or may, keep a record. Neither measures how long the data stays valuable to someone who stole it. That is the number HNDL runs on.

Retention can also mislead in the other direction. Under DPDPA you may be obliged to erase a customer's data once its purpose is served. Erasing it in 2028 does nothing to the copy recorded in transit in 2026. Your retention period is a floor for this exercise, not the measure.

Classify by how long the data stays useful to an attacker, not by how long you keep it.

Three rules keep this classification honest.

Identity data is permanent, even inside a short-retention system. This is the tier Indian organisations underrate most. Almost every regulated business moves identity bundles: banks, NBFCs, insurers, telcos, brokers, fintechs. They tend to think of them as "KYC records" with a five-year retention window. But an Aadhaar number, PAN and date of birth never change. A capture from 2026 is as useful in 2036 as the day it was taken.

A data set takes the tier of its most durable field. A loan application is Long-tier because of the credit history, and Permanent-tier because of the PAN attached to it. Any flow carrying mixed data inherits the highest tier of anything it carries.

Secrets have the shelf life of their rotation period. API keys, service-account credentials and passwords sent over the wire stay useful until they are rotated. A partner API key unchanged since 2019 behaves like Long-tier data. Shortening rotation is one of the cheapest HNDL mitigations available, because it shrinks X directly.

From data to flows

HNDL needs interception, so the unit of migration is not a system or a server. It is a flow: a path along which classified data crosses a network someone else could record. For each Permanent and Long data set, trace where it travels:

• Customer-facing ingestion: onboarding apps, document uploads, customer portals and mobile APIs
• Ecosystem and partner APIs: credit bureaus, the CKYC registry, account aggregators, co-lending partners, TPAs, health-exchange integrations
• Batch file transfer: SFTP jobs, especially with PGP-encrypted payloads
• Site-to-site links: IPsec VPNs between branches, data centres and cloud
• Replication and backup: DR replication, offsite and cloud object-storage backups
• Administrative access: SSH and bastion sessions that touch production databases

For each flow, ask one technical question: what negotiates the key? Is it classical ECDHE or RSA, or a hybrid exchange that adds ML-KEM, such as X25519MLKEM768 in TLS?

Here is what that looks like for a mid-size NBFC.

Wave 1 contains four flows. The estate contains thousands of RSA and ECC instances. That ratio is the point.

Look at what did not decide this order: the number of certificates, the age of the servers, which team owns what. The marketing site probably has the most certificates in the estate. Migrating it first would feel like progress and change almost nothing.

Wave 1 also does not mean "all at once." The credit-bureau and co-lender flows depend on the other party supporting hybrid key exchange. That makes them the right place to start a conversation this quarter, even if the change lands later. It is the vendor question from the first post, pointed at your most sensitive flows.

What "migrate first" looks like in practice

For Wave 1 flows, the first moves are often smaller than a "quantum migration" sounds:

• Customer-facing TLS. Hybrid ML-KEM key exchange is already supported by current mainstream browsers, OpenSSL 3.5 and later, and a growing number of CDNs and load balancers. Where your edge supports it, enabling it can be a configuration change that closes the harvest window for modern clients. Check the whole path, though. The CDN may negotiate hybrid key exchange with the browser while the link from the CDN back to your origin stays classical.
• Batch files. PGP files sent over classical transport are the hardest harvest target to argue away. Move them onto a channel with hybrid key exchange, and track post-quantum support in your OpenPGP tooling and your partners' tooling.
• Site-to-site and replication links. IKEv2 now has a standard mechanism for adding extra key exchanges (RFC 9370), which is how hybrid PQC reaches IPsec. Vendor support is uneven, so ask your firewall and VPN vendors for dates, not roadmaps.
• Keys at rest. Move Permanent- and Long-tier data at rest to AES-256, and check how backup and replication keys are wrapped.
• Rotation. Shorten the lifetime of any long-lived secret that travels on a Wave 1 flow.

Hybrid key exchange is the pragmatic choice for now. An attacker has to break both the classical and the post-quantum component, so you are no worse off against today's adversaries while becoming resistant to tomorrow's.

What this ranking deliberately leaves out

Shelf life tells you what is worth protecting. It does not yet tell you two things, and both are the subject of the next posts.

It assumes your flow map is complete. It rarely is. Cryptography gets negotiated inside SDKs, pinned in transitive dependencies, configured in cloud consoles, and embedded in identity tokens. An integration added last sprint does not appear on a diagram drawn last quarter. The next post covers why cryptographic inventory defeats spreadsheets, and why a flow map that is not regenerated continuously describes an estate that no longer exists.

It treats every Permanent-tier flow as equally exposed. It isn't. A public endpoint can be recorded by anyone on the path. An internal flow behind segmentation needs a far more capable adversary to intercept. The fourth post in the series covers reachability-weighted migration, and why the same RSA-2048 can be a 2027 problem in one place and a 2031 problem in another.

A 30-day checklist

1. Name an owner for data shelf life. This usually sits between the DPO or data-governance function and security. It needs a name, not a committee.
2. Tier your top ten data sets using the two questions: sensitive in 2030, sensitive in 2035?
3. Apply the aggregation rule. Any data set carrying identity fields is Permanent-tier, whatever else it holds.
4. Trace the flows for every Permanent and Long data set, including partners, batches, replication and admin access.
5. Find your PGP-over-SFTP jobs. List what each one carries and who is on the other end.
6. Check how backup and replication keys are wrapped.
7. Test your edge. Check whether your public TLS termination points support hybrid ML-KEM, and whether the link behind them does too.
8. List long-lived secrets on Wave 1 flows and shorten their rotation.
9. Ask your critical partners (bureau, co-lender, TPA, cloud provider) for their hybrid key-exchange timeline.
10. Keep signature migration a separate workstream with its own clock, so it does not absorb the effort Wave 1 needs.

The work in this list is classification and mapping, not cryptography. That is the point. The organisations that meet the 2027 foundation milestone will not be the ones that bought a quantum-safe product first. They will be the ones that knew which four flows mattered.

Next in this series: you can't inventory cryptography with a spreadsheet. We look at where crypto actually hides across code, dependencies, cloud configuration, identity tokens and TLS endpoints, and why manual audits go stale within a sprint.

Xhield builds continuous attack surface intelligence for teams that need to know what changed before attackers do. If you're mapping which of your flows carry long-lived data, we'd like to hear how you're approaching it: contact@xhield.tech.