What Post-Quantum Encryption Means for Business
Post-quantum encryption is a business planning topic because a sufficiently capable quantum computer could defeat encryption used today. The practical question for a business is how the technology it relies on will adapt. Understanding the standards can help you ask clearer questions about systems and suppliers, without treating an algorithm name as a complete security plan.
Why Quantum Computing Changes the Question
NIST explains that encryption tools depend on difficult mathematical problems. Conventional computers find those problems hard or impossible to solve, while a sufficiently capable quantum computer could examine possible solutions very quickly and defeat current encryption. The threat concerns that computing capability; it does not mean every device described as a quantum computer can already break today's protections.
In its August 13, 2024 announcement, the National Institute of Standards and Technology finalized its first three post-quantum cryptography standards. It described their algorithms as designed to withstand attacks from a quantum computer and ready for immediate use. The selection effort began in 2015 and assessed 82 algorithms from 25 countries.
For a business reader, separate the purpose of these standards from the details of a particular product. A standard gives you something specific to discuss with the people responsible for a system. It does not, by itself, describe how that system has been configured or what work a supplier has completed.
The Three Standards Cover Different Tasks
NIST identifies two essential tasks: general encryption to protect information exchanged over a public network, and digital signatures for identity authentication. Its three finalized standards divide those roles. When you encounter a claim about post-quantum support, ask which task and which standard the claim covers.
- FIPS 203: ML-KEM - The primary standard for general encryption, based on CRYSTALS-Kyber. NIST describes comparatively small keys and speed of operation as advantages.
- FIPS 204: ML-DSA - The primary standard for digital signatures, based on CRYSTALS-Dilithium.
- FIPS 205: SLH-DSA - A digital signature standard based on Sphincs+, using a different mathematical approach from ML-DSA. NIST intended it as a backup if ML-DSA proved vulnerable.
The names matter because encryption and identity authentication are distinct jobs. A discussion that mentions only ML-KEM leaves the signature question unanswered. Equally, a signature algorithm does not answer every question about how exchanged information is protected. Ask for the relevant role as well as the algorithm name.
Why NIST Selected HQC as a Backup
On March 11, 2025, NIST announced its selection of HQC as a backup for ML-KEM. HQC uses different mathematics, which NIST said could matter if a weakness were discovered in ML-KEM. This backup concerns general encryption, while SLH-DSA fills the backup role for digital signatures in the 2024 standards.
NIST said in March 2025 that it planned to issue a draft HQC standard in about a year, with a finalized standard expected in 2027. Those dates describe the timetable NIST gave in that announcement. They should be read as that stated plan rather than confirmation of what has happened since. HQC was the only algorithm selected for standardization from the fourth round of candidates.
Turn Standards into System Questions
NIST's description of the 2024 standards as ready for immediate use provides a concrete starting point for discussion. A useful next step is to ask your technology team to identify where encryption and signatures are used, who owns those systems, and which suppliers can explain their plans. Frame this as information gathering before committing to a change.
An inventory need not begin with every mathematical detail. Ask for a clear description of the function involved, the person responsible, and the evidence behind any statement about post-quantum support. If a system's status is unclear, record that uncertainty explicitly so it can be investigated.
Questions to Raise with Technology Suppliers
- Scope: Which parts of the service use encryption, and which rely on digital signatures? Which of those parts does the proposed change cover?
- Standards: Does the supplier identify ML-KEM, ML-DSA or SLH-DSA, and explain the role of each one it supports?
- Roadmap: What work is complete, what is planned, and what evidence supports those descriptions? Ask for the supplier's own timetable.
- Testing: What compatibility checks would your team need before changing a system, and who would decide whether to proceed?
These questions turn a broad security claim into a discussion you can assess. Keep the record specific to the system and the task being protected. The standards explain the algorithms' intended roles; your technology team and suppliers still need to explain the proposed implementation.