The Quantum Compliance Deadline Hiding in Your Clients' Procurement Contracts

A Nottingham engineering firm we work with lost a tender last spring. Not on price, not on capability, but on a single line in the supplier questionnaire: "Describe your roadmap for migrating to post-quantum cryptographic standards." They left it blank. The larger competitor didn't. The contract, worth roughly £400,000 over three years, went elsewhere.

That question is going to appear in more and more procurement documents, and the pace is picking up fast. If your clients supply the UK public sector, or sit anywhere in the supply chain for US federal contractors, a set of deadlines is closing in that most SMEs haven't heard of. One date in particular is worth circling: 21 September 2026.

What actually happens in September 2026

Let's be precise, because there's a lot of vague scaremongering around quantum computing.

Quantum computers capable of breaking today's encryption don't exist yet. The threat is real but not immediate in the "someone hacks you tomorrow" sense. The pressure that is immediate is regulatory and contractual, and it flows from two sources.

In the United States, the National Institute of Standards and Technology (NIST) finalised its first post-quantum cryptography standards in August 2024 — ML-KEM, ML-DSA and SLH-DSA, if you want the acronyms. Once a standard is published, federal agencies are required to plan migration, and that requirement cascades down through the supply chain via the Federal Acquisition Regulation and CMMC (Cybersecurity Maturity Model Certification). If your client sells to a US prime contractor, the prime is now obliged to ask its suppliers awkward questions.

Closer to home, the UK's National Cyber Security Centre published its own migration guidance in 2025, setting out a phased timeline that runs to 2035 for full migration, with the crucial first milestone being that organisations should have completed a discovery exercise and drafted a migration plan by 2028. Public sector buyers, following the lead of the NCSC, are already writing this expectation into framework agreements and Digital Marketplace requirements.

So where does 21 September 2026 come from? It's the point by which several major US federal supplier programmes expect a documented cryptographic inventory and migration roadmap from anyone bidding for renewed contracts. Some cyber-insurance underwriters have picked the same window for renewals, adding post-quantum readiness questions to their proposal forms. It isn't a single legal cliff-edge — it's a cluster of contractual and commercial deadlines landing in the same autumn. And the firms that treat it as a 2035 problem are going to be blindsided when it turns up in a tender in 2026.

Why "harvest now, decrypt later" changes the maths

There's one technical point worth understanding, because it explains why buyers are moving early rather than waiting for quantum computers to arrive.

An attacker doesn't need a working quantum computer today to cause damage. They can copy your encrypted data now — intercepted traffic, stolen backups, exfiltrated databases — and simply store it. When a capable quantum machine eventually exists, they decrypt the lot retrospectively. Security people call this "harvest now, decrypt later".

That matters for any data with a long shelf life. Medical records, legal case files, architectural drawings for critical infrastructure, personal data covered by retention obligations, intellectual property behind a product with a ten-year lifespan. If it needs to stay secret past roughly 2030, encrypting it with today's algorithms is already a gamble. This is precisely why defence and healthcare buyers aren't waiting. The data they handle outlives the encryption protecting it.

For a Nottingham SME that makes components for the aerospace sector, or a software house handling NHS data, this stops being abstract very quickly.

The problem nobody can answer off the top of their head

Here's the uncomfortable part. Ask most SMEs where they use encryption and you'll get a shrug. It's in the VPN. It's on the website. Probably in the email somewhere.

Cryptography is buried everywhere: in the TLS certificates on your websites, the VPN tunnels your remote staff use, the code-signing keys on your software releases, the disk encryption on laptops, the secure protocols talking to your suppliers' systems, the third-party libraries baked into products you shipped years ago. Much of it was configured once and forgotten.

You cannot migrate what you can't see. And a buyer asking about your post-quantum roadmap is really asking one simpler question first: do you even know what cryptography you're running?

The good news is that the first step costs almost nothing but time. It's a cryptographic inventory. Do it now and you're ahead of nearly everyone in your sector.

Your cryptographic inventory checklist

Work through this with your IT provider. It doesn't require buying anything, and the output — a documented inventory and a short migration statement — is exactly what procurement questionnaires are asking for.

1. Public-facing services

• List every website, portal and API you expose. Record the TLS version and cipher suites in use.
• Note the certificate authority and expiry dates for each.
• Flag anything still permitting TLS 1.1 or older.

2. Remote access and networking

• Document all VPNs, their protocols (IPsec, OpenVPN, WireGuard) and key exchange methods.
• List site-to-site tunnels connecting you to partners or suppliers.
• Record any hardware appliances (firewalls, load balancers) doing encryption, plus their firmware versions.

3. Data at rest

• Identify where full-disk encryption is enabled: laptops, servers, mobile devices.
• List encrypted databases, backup sets and cloud storage buckets, and the encryption each uses.
• Note the retention period for each data set. Anything kept beyond 2030 is a priority.

4. Identity, signing and secrets

• Catalogue code-signing certificates, document-signing keys and any PKI you run.
• List where SSH keys are used and how they're generated.
• Record secrets-management tools and the algorithms behind them.

5. Products and supply chain

• For any software or hardware you build and sell, list the cryptographic libraries embedded in it.
• Check which of your own suppliers' products handle your encryption, and whether they have a post-quantum roadmap.
• Identify anything with hard-coded or non-upgradable cryptography — these are your biggest headaches.

6. Classify and prioritise

• For each item, tag it: quantum-vulnerable, already agile, or unknown.
• Rank by data sensitivity and lifespan.
• Draft a one-page migration statement: what you'll change, roughly when, and who owns it.

What to do with the answers

Most of what you find won't need touching for years. The point of the inventory isn't to rip everything out — it's to know what you have and to be able to say so credibly when a buyer asks.

Where you'll want to act sooner: anything protecting long-lived sensitive data, and any product you ship that can't be updated. Where you can relax slightly: standard TLS on a marketing website will be handled by browser and server vendors rolling out hybrid post-quantum key exchange over the next couple of years, much of which is already shipping.

The firms that win the tenders in 2026 won't be the ones who've finished migrating. Nobody will have. They'll be the ones who can hand over a tidy inventory and a sensible plan instead of leaving that box blank.

If you're not sure where to start, that's a conversation worth having now rather than the week before a bid deadline. We're happy to run the discovery exercise with you and produce the documentation your clients are going to ask for.