Post-Quantum Cryptography for CLM: Your Contracts Will Outlive Today’s Encryption
A while back, a security questionnaire came back to us with a question I hadn’t seen before: describe your post-quantum cryptography migration plan.
It has come up several times since. If it hasn’t reached your vendor reviews yet, it will. So I want to lay out what that question is actually asking, why it lands differently for contract software than for most enterprise tools, and where we stand at Malbek today.
Short version first, because I’d rather not bury it. Quantum computers cannot break encryption today. Your contracts are secure, and nothing you have already signed is affected. What makes the question worth a real answer rather than a shrug is that a large share of the agreements sitting in your CLM carry confidentiality obligations running twenty or thirty years, and that changes the arithmetic in a way most coverage of this topic skips right past.
What is Post-Quantum Cryptography (PQC)
Post-quantum cryptography is a set of new algorithms built to stay secure even against a future quantum computer. NIST finalized the first three in August 2024, after roughly eight years of open competition.
The part worth understanding, and the part that usually gets flattened in explainers, is that quantum computing does not break all encryption. It breaks a specific half of it.
Public-key cryptography is the half that needs to change. RSA and elliptic curve, the algorithms behind a TLS handshake and a digital certificate. A large enough quantum computer running Shor’s algorithm would eventually be able to derive the private keys behind them, which is precisely why the industry agreed on replacements well ahead of time.
Symmetric encryption is the other half, and it holds. AES-256, the algorithm protecting the actual contract document sitting in storage, faces only a quadratic speedup from Grover’s algorithm, which leaves a comfortable margin. NIST and the NSA both consider AES-256 fit for the post-quantum era with no change whatsoever.
So “quantum breaks encryption” is too broad. The accurate version is narrower: quantum breaks how keys get exchanged and identities get proven, and leaves the bulk encryption of stored data alone. Narrower, and a good deal more manageable.
Why You’re Hearing About 2030 Now
The transition to post-quantum cryptography is no longer just a long-term theoretical exercise.
In June 2026, the White House directed federal agencies to transition high-value and high-impact systems to post-quantum cryptography for key establishment by December 31, 2030, and for digital signatures by December 31, 2031. The guidance also calls for supporting critical infrastructure owners and operators in developing PQC migration plans. These dates don’t mean every enterprise application has the same deadline, but they help explain why PQC migration is becoming an active consideration in enterprise security planning and vendor assessments.
Why Contracts are a Special Case When it Comes to PQC
Here is the arithmetic that makes this worth attention now rather than a calendar reminder for 2031.
Security planners work from a scenario called harvest now, decrypt later. The premise is that someone could capture encrypted data today and hold onto it until quantum capability exists. Nobody has to be doing this for the planning to be sound, and it is the reason standards bodies and governments began moving years before any such computer was built.
Now put a contract into that model. Estimates for a cryptographically relevant quantum computer cluster somewhere in the next ten to fifteen years, with plenty of disagreement. Meanwhile a master services agreement, a commercial lease, an acquisition document, or a licensing deal routinely carries confidentiality obligations of twenty years or more.
Do the subtraction and the conclusion is simply that timing matters. If information needs to stay confidential for longer than the wait for quantum computing, the encryption used to store it is worth getting right early. That’s why serious vendors are working on this now rather than in 2031, and why stored contract data deserves closer attention than any other part of the stack. I’ll come back to how that plays out for us shortly.
That isn’t true of most software. A chat message from 2026 will be irrelevant by 2040. Your pricing structure, your IP assignments, and your negotiated indemnity caps will not be. Which is why I think CLM vendors ought to be further along in this conversation than most software categories, and why I’d be skeptical of one that waves the question off as premature.
Where Malbek Stands on PQC Readiness
So where does that leave Malbek CLM customers? In a good place, and I’ll explain why rather than just asserting it.
The encryption protecting your actual contracts, the documents themselves, the information about them, our databases, and our backups, is AES-256. That’s the same algorithm standard approved for protecting classified government information, and it is one of the methods that already holds up against quantum computing. NIST and the NSA have both confirmed it needs no replacement. So the thing that matters most here, your agreements sitting in Malbek for the long haul, rests on a foundation that is quantum-safe today. That was a deliberate design choice rather than a happy accident.
Several other layers are in the same position. The way we confirm data hasn’t been tampered with, the way we protect credentials, and the way we handle user sessions all rely on methods quantum computing doesn’t meaningfully weaken.
What’s left is a set of planned upgrades to a different category of cryptography: the kind that secures a connection while it’s being made and proves one system is who it claims to be. Think of it as the sealed envelope rather than the locked filing cabinet. Those protections are sound today and will remain sound for years. We’re upgrading them now because the industry has settled on better long-term replacements, and the right time to adopt a new standard is early and gradually rather than late and all at once.
The sequencing works out well, and it’s worth explaining why. The largest body of information that needs protecting for decades is your stored contract data, and that’s the part already on quantum-safe footing. The connection-level upgrades are being made well ahead of any machine capable of challenging them, which is the entire reason for moving now rather than later.
We keep a written record of every place cryptography appears in the platform, with the plan and the accountable owner for each upgrade. That sounds like paperwork, and it turned out to be the most useful thing we did, because you can’t upgrade cryptography you haven’t found. Most of the remaining work also arrives through Amazon Web Services as part of their own rollout, which means it reaches you through ordinary platform updates. Nothing to install, migrate, or approve.
Crypto agility, Minus the Buzzword
Crypto agility gets used loosely enough to mean nothing, so here is a concrete test for it.
Pick an algorithm your platform uses. Ask how many files someone would have to change to swap it out. If the answer is one configuration value, that’s agility. If the answer is grep for it and hope, it isn’t.
The design goal is that no part of the application names an algorithm directly. Code asks for an operation, sign this, encrypt that, and the algorithm gets resolved in a single place from configuration. Centralizing key management serves the same end, creating a small set of defined places where this behavior can change instead of a diffuse one.
There’s a second half people miss. Stored data has to record which algorithm encrypted it. Without that, you can start encrypting new records with something better, but you can never read the old ones under a new scheme. Agility isn’t only a property of the code. It’s the data leaving itself a note.
The Role of AWS in the Post-Quantum Transition for Malbek
We run on AWS, and a real share of our cryptographic surface, TLS termination, key management, storage encryption, is AWS-managed. That’s an advantage here rather than a dependency to apologize for.
AWS has published its post-quantum migration guidance and has begun rolling hybrid post-quantum key exchange into its service endpoints and SDKs. As those capabilities become production-ready we take them up, which means a good portion of our transport-layer work arrives with nothing for customers to do.
Hybrid deserves a sentence, because it’s the prudent way to run this transition. Rather than swapping today’s cryptography out for the new algorithms, you run both together. Nothing proven gets given up, and the connection stays protected even if a weakness is later found in one of them. Given how new the post-quantum algorithms are, keeping both is the careful choice.
One point worth being clear about: some of this sits with our partners. Electronic signature and identity providers hold cryptography we rely on and don’t control ourselves. Signatures are the piece we watch most closely, since an executed signature may need to stay verifiable for the full legal life of an agreement. Your existing signatures remain valid, and we track provider roadmaps as part of vendor management. Where we’re coordinating with someone else, we’ll say so plainly rather than blur the line.
5 Questions Worth Asking any CLM Vendor
If you’re evaluating software and want to know whether a PQC answer is real, these separate substance from vocabulary quickly.
- Which parts of your platform are already quantum-resistant, and which aren’t? A vendor who can’t split their own architecture that way hasn’t looked.
- Do you keep a cryptographic inventory? Ask what’s in it. This is the foundational step in every piece of government guidance on the subject.
- What’s your sequencing, and why that order? A good answer references how long data stays sensitive, not implementation convenience.
- Which parts depend on your own providers? Everyone has these. Vagueness here is the tell.
- What will we have to do? For SaaS, the answer should be close to nothing.
None of those require you to know anything about quantum computing.
Preparing Today for Tomorrow’s Security Requirements
The transition will take most of a decade and will be largely invisible, which is how infrastructure change usually goes.
You don’t need a prediction about when quantum computing arrives. You need vendors who know their own systems well enough to tell you what’s already covered, what’s being upgraded and in what order, and where they’re coordinating with their own providers.
