Veteran Forge Strategies Deck Log article graphic — Harvested. Encrypted today, readable later. Status cards show FIPS 140-3 as the requirement that applies now, the 2030 post-quantum date as proposed and not final, and a ten-year data shelf life for contracts, IP and CUI. Post-quantum cryptography feature by John Farmer.
| |

Somebody Is Already Saving Your Encrypted Data

ByJohn Farmer

The quantum computer that breaks your encryption does not exist yet. That turns out to be a much weaker comfort than it sounds like.

The one part of this that is not hypothetical

Almost every conversation about quantum computing and security gets stuck on the same question — when? When does a machine exist that can break RSA. Five years, fifteen, never.

It is a reasonable question and nobody can answer it honestly. Every serious source declines to give a date, and the ones that do give a date are selling something.

But there is a second question that does not depend on the first, and it is the one that actually matters to a small business:

How long does your data need to stay secret?

Because an adversary does not have to wait for a quantum computer to start. They can copy your encrypted traffic, your encrypted backups, your exfiltrated archive today, store it, and decrypt it whenever the capability arrives. The industry calls this harvest now, decrypt later. Nothing about it is speculative — bulk collection of encrypted data is cheap, storage is cheap, and patience is free.

So the risk calculation is not “will quantum happen before 2035.” It is subtraction:

Does anything I encrypt today still need to be secret when that capability exists?

For a lot of data the answer is genuinely no. Today’s pricing sheet, this week’s scheduling traffic, a password that gets rotated in ninety days — none of that survives long enough to matter. But some of it does. Contracts with ten-year tails. Engineering drawings and source code. Financial and personnel records you are legally required to retain. Anything covered as Controlled Unclassified Information. For that category, a copy taken this afternoon is a disclosure later, and you will never know it happened.

That is the honest version of the urgency. Not “quantum is coming.” Rather: some of your data has a shelf life longer than your encryption does.

First, an honest correction about the deadlines

Here is where most writing on this subject — including a fair amount aimed squarely at defense contractors — goes wrong, and it goes wrong in a way that happens to sell product.

You will see three dates thrown around as if they were all the same kind of thing. They are not.

2030 and 2035. These come from NIST IR 8547, which proposes that RSA and elliptic-curve algorithms be deprecated after 2030 and disallowed after 2035. Those are the right numbers to plan against. But IR 8547 was released as an initial public draft in November 2024 and, as of the middle of this year, has not been finalized. The dates are proposed, not settled. Industry has broadly adopted them as a planning baseline, which is sensible — but quoting a draft as though it were binding federal rule is not the same as being right, and you should know which one you are looking at before you build a budget on it.

January 1, 2027. This one comes from CNSA 2.0, the NSA’s post-quantum algorithm suite, after which new deployments are expected to comply. It is real and it is close. It also very probably does not apply to you. CNSA 2.0 governs National Security Systems and NSA-governed deployments. If you are a small contractor handling CUI on a commercial network, you are not inside that boundary, and a vendor presenting 2027 to you as a universal compliance cliff is either confused or counting on you being confused.

What actually binds a CUI contractor today is none of the above. It is NIST SP 800-171 3.13.11 — CMMC practice SC.L2-3.13.11 — which requires you to “employ FIPS-validated cryptography when used to protect the confidentiality of CUI.” That is a question about whether the cryptographic modules in your stack carry a current FIPS 140-3 validation. It is not a post-quantum question at all, and it is the one an assessor will actually ask you about.

I want to be clear about why this distinction is worth three paragraphs rather than a footnote. The gap between “there is a 2027 deadline” and “there is a 2027 deadline for National Security Systems” is exactly the gap that turns a sensible planning exercise into a rushed purchase. If a rep cannot tell you which of these three things they are invoking, that tells you what the call is about.

None of this means do nothing. It means do the useful thing rather than the urgent-sounding one — and, as it happens, the useful thing is the same in all three cases. The same exercise — separating the loud industry deadline from the requirement you actually carry — applies to AI-powered attacks, where the alarming headline statistic and the thing that genuinely changed turn out to be two different stories.

What NIST actually finalized

The genuinely settled part is the algorithms, and this is good news that arrived quietly.

In August 2024 NIST finalized three post-quantum standards:

  • FIPS 203 (ML-KEM) — key encapsulation. This is the one that replaces the key exchange protecting your TLS sessions and VPN tunnels.
  • FIPS 204 (ML-DSA) — the primary digital signature standard. Certificates, code signing, firmware signing.
  • FIPS 205 (SLH-DSA) — a second, hash-based signature scheme, deliberately built on different mathematics so that a break in one family does not take everything down with it.

The practical consequence for a small business is better than people expect: you are mostly not the one who implements these. They land in your browser, your operating system, your VPN concentrator, your cloud provider’s TLS termination, your backup vendor’s encryption. Your job is not to implement ML-KEM. Your job is to be running things that will receive it, and to know which things those are.

Which brings us to the only piece of homework in this article.

The crypto inventory is the whole assignment

If you do one thing after reading this, make it this one, because it is the thing every version of the future requires.

Write down where your organization uses encryption, and what is protecting what.

Not a formal program. A list. For a small organization it is an afternoon, and it looks like:

  • TLS certificates — every one you own, what issued it, when it expires, and who renews it. Most organizations discover at least one certificate nobody owns.
  • VPN and remote access — what the tunnel actually negotiates, and whether the appliance is still getting firmware updates. This is the same review I have argued for when looking honestly at what is running at your edge — the crypto question is one more column on a list you should already have.
  • Backups — what encrypts them, where the keys live, and how long you retain them. Retention length is exactly the variable that decides whether harvest-now-decrypt-later applies to your backups, which makes this a direct extension of the recovery questions most organizations have not answered either.
  • SaaS and cloud — which vendors hold data that matters, and what they say about encryption in transit and at rest.
  • Code signing, firmware, and any PKI you run — internal certificate authorities are the classic thing that one person set up years ago and nobody has looked at since.
  • Anything embedded — building systems, cameras, printers, industrial gear. These are the devices that will still be running the old algorithms in 2035 because no update will ever exist for them, and the honest answer for that category is usually replacement or isolation, not migration.

You will notice this is an inventory problem before it is a cryptography problem. That is not a coincidence — it is the same argument I have made about knowing what you own, pointed at a narrower target. You cannot migrate an algorithm off a system you have forgotten you run.

And the inventory is the piece that pays off regardless of how the quantum timeline plays out. It is what a FIPS-validation question gets answered from. It is what tells you which vendor conversations matter. It is what turns “we should probably look at post-quantum” into a list with names next to it.

Crypto-agility, in plain terms

The second concept worth carrying out of this is crypto-agility — the ability to change cryptographic algorithms without re-architecting the system around them.

This sounds abstract until you have lived through it. Anyone who dealt with the migration off SHA-1, or watched TLS 1.0 and 1.1 get switched off, knows the shape: the problem was never the new algorithm. The problem was the handful of systems where the algorithm was welded in — hardcoded in an application nobody maintains, baked into an appliance past end-of-support, assumed by an integration written in 2011.

Post-quantum migration will be that, at larger scale, and the systems that hurt will be the same ones: the oldest, the most custom, the least documented.

So the design question to start asking now, on every purchase and every build, is simply: can this thing’s cryptography be changed later without replacing the thing? If a vendor cannot answer that, you have learned something useful about the vendor.

Two questions worth putting to your vendors this year, in writing:

  • “What is your post-quantum roadmap, and will it reach my version?” The second half matters more than the first. A roadmap that only lands on a platform you are not licensed for is not your roadmap.
  • “Which cryptographic modules in your product carry FIPS 140-3 validation today?” This is the question with a present-tense answer, and for a CUI handler it is the one with contractual teeth.

You are not trying to force a migration in 2026. You are trying to make sure that when the migration is ready, it does not run into a wall you could have seen coming.

The federal and contractor angle

For anyone working federal, the sequencing matters more than the deadline.

  • Get FIPS-validated cryptography right first. SC.L2-3.13.11 is the requirement in front of you, with an assessment attached. Post-quantum is a planning horizon. Doing the second while the first is unresolved is backwards.
  • The FIPS pipeline is the delivery mechanism. This is the part that makes the work compound: PQC will reach regulated environments as FIPS 140-3-validated modules. The vendor relationships and the module inventory you build to satisfy today’s requirement are the same ones that will carry tomorrow’s. It is one effort, not two.
  • Mandates cascade down, but on contract timelines. Agency requirements tend to reach contractors through clauses and system security requirements rather than through the standard itself. Read the clause. That is where your actual obligation lives — the same lesson that applies to almost every framework question a small contractor faces.
  • Long-retention CUI is where the harvest argument bites hardest. If you are contractually required to retain data for years, you have already conceded the shelf-life argument. That is the data to prioritize.
  • Being able to discuss this coherently is a differentiator. Most small contractors cannot. If you are still working toward a first subcontract, being the vendor who has a crypto inventory and a straight answer about FIPS validation is cheap credibility that larger competitors often cannot produce quickly either.

Where this usually goes wrong

  • Treating it as urgent and buying something. The near-term deliverable is a list, not a purchase order.
  • Treating it as science fiction and doing nothing. The inventory is an afternoon and it is useful immediately for unrelated reasons.
  • Quoting a draft as a rule. IR 8547’s 2030 and 2035 are proposed dates. Plan to them; do not cite them as settled.
  • Adopting somebody else’s deadline. CNSA 2.0’s 2027 belongs to National Security Systems. Confirm scope before you inherit a date.
  • Ignoring retention. Long retention plus long-lived secrets is the actual exposure, and it is a policy decision you already control.
  • Forgetting the embedded gear. The devices that will never get a PQC update are the ones nobody inventories.
  • Assuming your vendors have it handled. Possibly they do. Get it in writing, with a version number.
  • Confusing a FIPS question with a PQC question. They are different requirements on different clocks, and only one of them is being assessed this year.

Start with the list

There is no emergency here, and I would be suspicious of anyone telling you there is. But there is a slow, quiet problem that gets more expensive the longer it goes unmeasured, and the measurement is genuinely cheap.

Open a spreadsheet. Write down every place your organization uses encryption, what it protects, and how long that thing has to stay secret. Mark the rows where the answer is “longer than five years.” Those rows are your priority list, and you now have something to take to your vendors that is specific enough to get a real answer.

The businesses that handle this well will not be the ones who moved first. They will be the ones who knew what they had when it was time to move — which, as usual, is the same advantage that shows up in every other part of security where the work has to be done before you need it.

Veteran Forge Strategies is an SBA-Certified Service-Disabled Veteran-Owned Small Business providing IT infrastructure, operations, and cybersecurity support to small businesses and federal clients from Northern Virginia. If you cannot currently produce a list of where your organization uses encryption and what it protects, that is the engagement — get in touch. You can also read about how a fractional IT engagement works, or browse the rest of the Deck Log.

Similar Posts