Somewhere right now, encrypted traffic is being captured and quietly warehoused. Not because anyone can read it today, but because someone is betting they’ll be able to read it later. That is the “harvest now, decrypt later” attack, and it has already inverted the way security leaders have to think about the quantum threat: the question is not when will a quantum computer break RSA, but which of my data is being collected today in anticipation of that day.
If your organization runs M&A deals, licenses semiconductor IP, or handles defense program data, there’s a good chance the most concentrated collection of your long-lived secrets sits in a virtual data room. And if that data room is a traditional third-party VDR, your crown jewels are sitting on someone else’s infrastructure, protected by someone else’s cryptography, on a quantum migration timeline you cannot see and do not control.
This post lays out why post-quantum cryptography (PQC) is now a data room problem, why the regulatory clock is shorter than it looks, and why the architectural decision that matters most is one you can make today – without buying a single quantum product.
The Quantum Threat Isn’t Arriving in 2035. It’s Operating Today.
A cryptographically relevant quantum computer – one capable of running Shor’s algorithm against the RSA and elliptic-curve encryption that protects nearly all data in transit today – does not yet exist. That fact lulls a lot of organizations into treating PQC as a next-decade problem.
Harvest now, decrypt later breaks that logic. Adversaries with long planning horizons – state actors chief among them – are intercepting and storing encrypted data now, to decrypt once quantum capability arrives. For data that stops mattering in a year, that’s a non-event. But for data with a long confidentiality horizon, the math is brutal:
- Semiconductor process and design IP stays sensitive for decades.
- Defense program data carries classification and export-control obligations that outlive any single program.
- M&A deal rooms concentrate valuations, board deliberations, customer contracts, IP schedules, and litigation exposure – the densest collection of long-lived secrets a company ever assembles in one place.
If your data must stay confidential for ten or more years, and a cryptographically relevant quantum computer is plausible within that window, then data captured today is already exposed. The migration deadline isn’t Q-Day. It’s the day your data was harvested – which may be today.
Regulators Have Already Set the Clock
This is no longer a research conversation. The U.S. government has published dates.
NIST IR 8547, the federal roadmap for transitioning to post-quantum cryptography, sets out a schedule under which quantum-vulnerable public-key algorithms – RSA, ECDSA, ECDH – are deprecated after 2030 and disallowed after 2035. NIST has already finalized the replacement standards: ML-KEM (FIPS 203) for key encapsulation and ML-DSA (FIPS 204) for digital signatures.
NSA’s CNSA 2.0 goes further for national security systems, mandating ML-KEM-1024 and ML-DSA-87 and phasing in requirements years ahead of the civilian timeline. Critically, CNSA 2.0 doesn’t stop at federal agencies: it reaches the defense industrial base through acquisition requirements, DFARS clauses, and CMMC expectations. If you sell into the defense supply chain, this is your timeline too – whether or not you ever touch a classified network.
Here is the part that most organizations miss: for long-lived data, 2030 and 2035 are not the deadlines – they’re the backstop. If your confidentiality horizon is fifteen years, the harvest-now-decrypt-later window opened before the regulation was even drafted.
The Second-Copy Problem: Every Third-Party VDR Is a Harvest Target
Now look at what a traditional virtual data room actually does with your data.
The operating model of a conventional VDR – the model behind essentially every standalone data room product on the market — is to copy your most sensitive documents out of your environment and onto the vendor’s infrastructure. That second copy is encrypted with the vendor’s cryptographic stack, managed under the vendor’s key management, and secured on the vendor’s timeline.
In a post-quantum world, that second copy carries three compounding liabilities:
- It’s a harvestable target outside your boundary. Every transfer to and from the VDR, and every copy at rest in the vendor’s cloud, is an additional interception and exfiltration surface – one your security team doesn’t monitor and can’t instrument.
- Its quantum migration is a black box. When does your VDR vendor move to ML-KEM for data in transit? When does their key management go quantum-safe? What about their backups, their DR replicas, their deleted-but-retained copies? You don’t know, and in most cases you can’t audit it.
- You’re hostage to their crypto-agility. Cryptographic migration at cloud scale is one of the most expensive engineering programs in the industry. Hyperscalers are resourced for it. A mid-market VDR vendor is not – and their roadmap will follow their economics, not your risk model.
Put simply: every copy of your deal room that lives on a VDR vendor’s servers is a harvest-now-decrypt-later target on a migration timeline you’ll never see.
Quantum-Safe by Architecture: The Tenant-Native Answer
There is a different architecture – and it changes the quantum question entirely.
A tenant-native virtual data room like Govern 365 runs inside your own Microsoft 365 tenant. Your documents never leave your environment. There is no second copy on a vendor’s infrastructure, which means there is no second cryptographic stack, no second key management regime, and no second migration timeline. Your data room’s post-quantum readiness is Microsoft’s post-quantum readiness.
And Microsoft is running one of the most aggressive, best-resourced PQC migrations in the industry:
- ML-KEM and ML-DSA are generally available in SymCrypt, Microsoft’s core cryptographic library, exposed through Windows CNG and certificate APIs and through SymCrypt-OpenSSL on Linux.
- Post-quantum key exchange has come to the Windows TLS stack, with ML-KEM hybrid groups now configurable.
- Microsoft has publicly committed to early adoption of quantum-safe capabilities by 2029 and completion of its transition by 2033 – two years ahead of the government’s 2035 deadline – across Windows, Azure, and Microsoft 365.
Here’s the strategic payoff for a tenant-native data room: as Microsoft flips post-quantum protection on across M365 service encryption, TLS, and key management, Govern 365 customers inherit it automatically. Zero re-platforming. Zero data migration. No waiting for a VDR vendor to catch up, and no diligence exercise to find out whether they ever will.
You don’t buy your way to quantum-safe by adding another product. You architect your way there – by never letting the data leave your tenant in the first place. That is the Secure by Design thesis, restated for the quantum era.
You Can’t Protect What You Can’t Find: The Governance Half of PQC
There’s a second half to every post-quantum migration, and it has nothing to do with algorithms.
Ask anyone who has scoped a PQC program: the dominant task is cryptographic and data inventory – finding every system, every data store, and every dependency that touches quantum-vulnerable cryptography. For large organizations, industry estimates commonly put the inventory phase alone at 12 to 24 months. You cannot migrate what you cannot find.
This is where data room architecture quietly becomes a governance decision. Deal documents scattered across third-party VDR silos are, by definition, outside your inventory scope – outside your classification regime, outside your audit trail, outside the boundary you’re about to spend two years mapping. Deal documents inside your governed tenant – classified with Microsoft Purview, covered by your existing sensitivity labels, logged in your existing audit infrastructure – are already inside the boundary you’re going to secure.
A tenant-native data room doesn’t just reduce your harvest surface. It keeps your crown jewels inside the one perimeter your PQC migration will actually cover.
What Post-Quantum Readiness Actually Means (and What It Doesn’t)
A note on honesty, because this topic attracts overclaiming and your diligence teams will see through it.
No collaboration platform – Govern 365 included – can truthfully claim your data-at-rest is “quantum-safe today.” Service-side post-quantum encryption across the Microsoft cloud is rolling out on the roadmap above; it is not finished. Any vendor telling you their data room is “already quantum-encrypted” is selling you a claim you should test in diligence.
What a tenant-native architecture can truthfully claim is this:
- It eliminates the second-copy exposure that every third-party VDR creates – fewer harvestable copies, on fewer cryptographic stacks, today.
- It puts you in the only architecturally correct position to inherit quantum-safe protection automatically, on the industry’s best-resourced migration timeline, with no re-platforming.
- It keeps your most sensitive data inside the governance and inventory boundary your PQC program will secure.
Readiness and attack-surface reduction now; inheritance when the cryptography lands. That’s the defensible frame – and it happens to be the strongest one.
The Bottom Line
The harvest-now-decrypt-later clock is running fastest exactly where data rooms live: long-horizon IP, defense program data, and M&A secrets. Regulators have set the backstop at 2030–2035, but for your data, the real deadline is the day it gets harvested.
Every third-party VDR copy of your deal room is a target you don’t control on a timeline you can’t see. A tenant-native data room keeps that data where it inherits Microsoft’s quantum-safe roadmap automatically.
You don’t patch your way to quantum-safe. You architect your way there – by never letting the data leave your tenant.
Govern 365 delivers virtual data rooms, external collaboration governance, and compliance controls natively inside your Microsoft 365 tenant. See how tenant-native architecture changes your quantum risk posture – request a demo.
Frequently Asked Questions
Post-quantum cryptography refers to encryption algorithms designed to resist attack by quantum computers. NIST finalized the first PQC standards in 2024, including ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) for digital signatures, which replace quantum-vulnerable algorithms like RSA and ECDH.
It’s an attack in which adversaries capture and store encrypted data today, planning to decrypt it once a cryptographically relevant quantum computer exists. It means data with a long confidentiality horizon – deal documents, design IP, defense data – is at risk now, years before any quantum computer arrives.
No one knows precisely, but government timelines assume the risk becomes unacceptable in the 2030s: NIST IR 8547 deprecates RSA, ECDSA, and ECDH after 2030 and disallows them after 2035. For data that must stay confidential beyond that window, the exposure has effectively already begun.
If it’s a third-party VDR, your data is a second copy on the vendor’s infrastructure, and its quantum migration depends entirely on that vendor’s roadmap – which you generally cannot audit. A tenant-native data room keeps data inside your Microsoft 365 tenant, where it inherits Microsoft’s post-quantum migration (targeted for completion by 2033) automatically.
Start with inventory: identify where long-lived sensitive data lives and what cryptography protects it. Reduce the number of external copies of your most sensitive data. Classify and govern what remains (e.g., with Microsoft Purview). Then align with your platform vendors’ PQC roadmaps rather than building your own cryptographic migration.
