A practical guide to post quantum cryptography for non engineers

[CyberRider56]

TL;DR

• Post quantum cryptography (PQC) is ordinary software that resists attacks from future quantum computers, it does not need quantum hardware
• The new NIST standards are ML-KEM for key exchange and ML-DSA and SLH-DSA for digital signatures, published in August 2024
• Managers, buyers, lawyers and policy people all have a role, because migration is mostly about inventory, priorities, contracts and timelines
• Ask suppliers about their PQC roadmap, hybrid support and crypto agility now, while it is a friendly question rather than an urgent one
• Start with data that must stay secret for a long time, because harvest now, decrypt later puts it at risk today

Why non engineers belong in this conversation

Most writing about post quantum cryptography assumes the reader can follow equations or configure a server. That leaves out the people who make many of the decisions that matter. Budget holders decide when migration work gets funded. Procurement teams choose which products enter the organisation, and legal teams write the contracts that bind suppliers to security commitments

This guide is written for those people. It avoids mathematics entirely and focuses on what you need to know to ask good questions, make sensible decisions and support the technical teams who do the hands on work. If you can follow a project plan, you can follow post quantum migration. The concepts are much friendlier than the name suggests

There is also a simple practical reason to read on. Post quantum migration will touch nearly every technology contract, product roadmap and risk register over the next decade. Organisations whose non technical leaders understand the basics will move faster and spend less. Those whose leaders treat it as a niche IT topic will find it arriving later as an expensive surprise

What PQC is, in plain language

Cryptography is the set of techniques that keeps digital information private and proves who sent it. A small family of those techniques, called public key cryptography, lets two parties who have never met agree on a secret and verify each other's identity. It is what makes the padlock in your browser meaningful and what makes signed software updates trustworthy. Today it relies mostly on systems called RSA and elliptic curve cryptography

A sufficiently large quantum computer, which does not yet exist, could break RSA and elliptic curve cryptography using a method called Shor's algorithm. Post quantum cryptography is simply a new set of public key techniques built on mathematical problems that quantum computers are not known to solve efficiently. Crucially, it runs on the computers and phones we already have. It is a software upgrade, not a hardware revolution

A useful analogy is replacing the locks on a building. The doors, corridors and rooms stay the same, but the lock mechanism changes to one that a newly invented tool cannot pick. Staff still use keys, visitors still sign in, and daily life carries on. The hard part is finding every door, especially the ones in basements and storerooms that nobody has opened in years

The standards in one minute

In August 2024, the US National Institute of Standards and Technology, known as NIST, published three standards that most of the world is adopting. ML-KEM, defined in FIPS 203, handles the step where two systems agree on a shared secret key. ML-DSA, defined in FIPS 204, and SLH-DSA, defined in FIPS 205, handle digital signatures, which prove identity and integrity. Those three names will appear in vendor documents, audit questionnaires and regulatory guidance for years

Two more are on the way. NIST selected an algorithm called HQC in March 2025 as a backup for ML-KEM, and a compact signature scheme called FN-DSA is being standardised as FIPS 206. You do not need to wait for these before acting, and NIST itself has said organisations should begin with the published standards. Knowing the backups exist is mainly reassurance that the system has spare parts

You will also hear the word hybrid. A hybrid approach uses an established algorithm and a post quantum algorithm together, so an attacker has to defeat both. Most early deployments, including those in web browsers, use hybrids. For a non engineer, the key point is that hybrids are a cautious, widely recommended way to make the transition

Why the clock is already running

The most common question from leadership is why act now when the quantum computer does not exist yet. The answer is harvest now, decrypt later. Adversaries can record encrypted communications today and store them until a quantum computer can unlock them. Anything that must stay confidential for many years is therefore exposed already if it travels under old style encryption

Think about which information in your organisation has a long shelf life. Patient records, trade secrets, merger plans, legal correspondence, government data and personal identity information often need protection for ten, twenty or more years. If that information is intercepted today, the protection it needs must outlast the arrival of a quantum computer. That is why many security leaders see this as a present day risk rather than a future one

There is a second reason for urgency, and it is about time rather than technology. Large organisations take years to change cryptography because it is embedded everywhere, from websites to badge readers to supplier connections. The UK NCSC has suggested completing discovery and planning by 2028, priority migration by 2031 and full migration by 2035. Working backwards from those dates, the planning window for most organisations is open right now

Your role if you manage people or budgets

If you lead a team or control a budget, your most valuable contribution is sponsorship. Ask your technology or security lead whether a cryptographic inventory exists, and if not, what it would take to create one. An inventory lists where cryptography is used, which algorithms protect which systems, and who owns each one. Almost every migration programme starts there

Next, ask for a prioritised plan. Not everything needs to move at once, and a good plan will rank systems by data sensitivity, exposure to the internet and difficulty of change. Systems handling long lived secrets and those facing the public usually go first. A plan with phases and milestones is far easier to fund and track than a vague intention to become quantum safe

Finally, build PQC into normal cycles rather than treating it as a separate crusade. Hardware refreshes, software upgrades, certificate renewals and contract renewals are natural moments to require post quantum support. Folding the work into routine change keeps costs down and avoids disruption. Over a few years, the organisation moves forward almost without noticing

Your role if you buy technology

Procurement teams have enormous leverage, because every new product either helps or hinders migration. Adding a few questions to supplier assessments can shape the market. Ask whether the product supports ML-KEM and ML-DSA today, and if not, when. Ask whether it supports hybrid modes and whether algorithms can be changed by configuration rather than by replacing the product

Ask suppliers to describe their own migration roadmap in writing. A credible roadmap names specific standards, gives realistic dates and explains how customers will receive updates. Be wary of vague phrases such as quantum ready with no detail behind them. Equally, be wary of products claiming to be unbreakable or quantum proof forever, because serious cryptographers never make such promises

Validation matters too. In the United States and many allied markets, cryptographic modules are tested under the FIPS 140-3 programme, and individual algorithm implementations can be validated through NIST's testing programmes. Asking whether a product's PQC implementation has been or will be validated is a sensible, non technical way to separate mature offerings from early experiments. Your technical colleagues can help interpret the answers

Your role if you work in legal, risk or compliance

Contracts written today will still be in force when many migration deadlines arrive. Legal teams can add clauses requiring suppliers to support recognised post quantum standards within a defined period, to notify customers of their cryptographic roadmap and to cooperate with migration. These clauses cost little now and can save a great deal of negotiation later. They also signal to suppliers that customers are paying attention

Risk teams can add quantum risk to the register with sensible framing. The risk is not that a quantum computer will appear next week, but that long lived data is exposed now and that migration takes years. Rating it with that nuance avoids both panic and neglect. Linking it to existing controls on data classification and encryption makes it easier to manage

Compliance teams should watch for regulatory signals. Financial regulators, healthcare bodies and national cyber security agencies are increasingly referencing post quantum readiness. NIST's draft transition report IR 8547 proposed deprecating vulnerable algorithms after 2030 and disallowing them after 2035, and several governments have published similar timelines. Tracking these dates helps the organisation stay ahead of formal requirements

Common myths, kindly corrected

One myth is that all encryption will break. In reality, the main risk is to public key cryptography, while symmetric encryption such as AES-256 remains strong. Another myth is that you need a quantum computer to defend against a quantum computer. PQC runs on ordinary hardware, and quantum key distribution, which does require special equipment, is not the primary recommendation of agencies such as the UK NCSC and the US NSA

A third myth is that this is purely an IT problem. Migration involves suppliers, contracts, budgets, risk appetite and sometimes customers, so it is an organisational project with technical components. A final myth is that it is too early to act. With standards published and major platforms already deploying them, the early adopter phase is well underway



A simple first month plan

• Week 1: Ask your security lead for a short briefing on post quantum readiness and whether a cryptographic inventory exists
• Week 2: Identify the three kinds of data your organisation holds with the longest confidentiality needs
• Week 3: Add two or three PQC questions to supplier assessments and upcoming contract renewals
• Week 4: Agree an owner and a first milestone, such as completing discovery for internet facing systems

Closing thoughts

Post quantum cryptography sounds intimidating, but for non engineers it comes down to familiar skills. Asking clear questions, setting priorities, writing good contracts and funding sensible plans are exactly what this transition needs. The technology teams will handle the algorithms, and they will do it far more effectively with informed support. Your involvement can turn a technical upgrade into a smooth organisational change

There is plenty of reason for optimism. The standards are published, the software is shipping, and the world has years of warning before the threat matures. Organisations that start calmly now will finish comfortably. That is a rare and welcome position to be in when it comes to security


Key references for citation

• NIST FIPS 203, 204 and 205, August 2024
• NIST status report on the fourth round of PQC standardisation and HQC selection, March 2025
• NIST IR 8547 initial public draft, November 2024
• UK NCSC, Timelines for migration to post-quantum cryptography, March 2025
• NIST Cryptographic Module Validation Program (FIPS 140-3)

[ForumPhantom25]

Great introduction. I'd stress one distinction for beginners: quantum computers don't automatically break all encryption. RSA and elliptic curve cryptography are vulnerable to sufficiently capable quantum computers because of specific mathematical algorithms. Symmetric encryption, such as AES, is affected differently and can generally be strengthened by using larger keys. It's not the end of cryptography; it's a change in which tools we trust.

[Delulu]

One question I keep coming back to is performance. If the replacement algorithms produce larger keys and signatures, surely that creates additional costs for businesses? Particularly for older devices, embedded systems and services handling millions of transactions. It would be useful to see a real-world comparison rather than just theoretical assurances.

[Puma22]

Disagreeing strongly with the notion that this is just "ordinary software". The key sizes are massive. CRYSTALS-Kyber ciphertexts are hundreds of bytes, and signatures can be several kilobytes. If your API bandwidth is tight or you're storing millions of small records, this bloat can push your costs up significantly. I recently audited a client who thought they moved to PQC, but their storage bills jumped 30% because they didn't normalize the public keys in the database schema.

[Bussin]

Tangents aside, the biggest hurdle isn't the math, it's the transition latency. If you're running a legacy system with hard-coded ECC keys, imagine swapping out the engine of a car while it's still on the highway. You need a hybrid approach that supports both algorithms simultaneously for a few years, otherwise your handshake protocols will just fail with a confusing error code that sales teams will blame on the internet being down.

[Neuer]

Good myth busting section. The belief that all encryption breaks causes a lot of unnecessary fear among staff

Explaining that AES-256 remains strong helps people focus. The problem becomes manageable when it is correctly sized. Panic tends to produce either paralysis or wasted spending. Neither helps anyone

I also appreciated the QKD clarification, since some vendors blur the two technologies together. Calm explanations like this one make a real difference. Staff stop worrying once they see the shape of the problem. Clear scope is calming. That matters for any change programme

[QuarkStorm]

Quick question for anyone in finance. Have regulators in your region asked about post quantum readiness yet? Ours has mentioned it in speeches but nothing formal so far. I am trying to judge whether to prepare now or wait

My instinct says prepare, given the long timelines everyone mentions. But I need something concrete to show the budget committee. The committee likes dates and published sources. Vague warnings rarely survive their questions. Anything from a recognised agency carries weight

The NCSC and NIST dates in this article might be enough to anchor the case. Any experience from others would help

[CoherentSonnet]

A practical example might help people understand the urgency. Imagine a hospital encrypting patient records today. Those records could still be sensitive 15 years from now. Even if nobody can decrypt them today, someone could intercept and retain copies for future attacks. That's why organisations handling long-lived confidential information shouldn't treat PQC as a distant IT upgrade.