Post-Quantum Readiness: What Exactly Are You Protecting?

When a provider says a product is post-quantum-ready, ask what it has protected. The answer might concern signed software, confidential network traffic, archived documents, or an evidence record. Those are different protection paths, with different dependencies and different tests of success.

This paper explains three jobs: encryption protects confidentiality; digital signatures support integrity and authentication; key establishment gives systems shared key material for subsequent cryptographic operations. Replacing the algorithm in one job does not automatically upgrade the others. The practical objective is a protection plan that follows information through its useful life.

This educational synthesis brings published cryptographic standards and migration guidance into business decisions: what to protect, which dependencies matter, and how to verify the result.

In 1994, Peter Shor presented quantum algorithms for integer factoring and discrete logarithms. On a sufficiently capable quantum computer, those algorithms would undermine the mathematical problems on which widely used public-key systems rely. RSA and elliptic-curve systems are among the affected families. The result was a change in the long-term security assumptions behind digital trust, not a demonstration that ordinary computers could suddenly read everyone's messages. [1]

A quantum computer capable of carrying out these attacks at useful scale is a much stronger requirement than a machine described simply as a quantum computer. A research breakthrough, a qubit count, and a demonstrated attack against deployed cryptography are not interchangeable milestones. Businesses should plan for the risk without treating a forecast as an established deadline.

The term post-quantum describes the threat an algorithm is designed to resist. Organizations do not need quantum hardware to use post-quantum cryptography. The algorithms run on conventional computers and networks. Their purpose is to preserve useful protection as an attacker's capabilities change. [2]

Imagine sending a confidential package. Encryption is the lock: it makes the contents unreadable without the required key. A digital signature is a tamper-evident seal associated with a signing key: it lets a recipient check whether the signed content has changed and whether the signature matches the public key they trust. Key establishment addresses how the participants obtain the shared secret needed for protection.

The analogy has a limit worth preserving. A valid signature does not prove that the statement inside the package is true. A false measurement can be signed correctly. Nor does a signature, by itself, hide the package's contents, establish the real-world identity behind an untrusted key, or prove when the contents were created.

For a business record, these questions remain distinct: Is it confidential? Has it changed? Which trusted key signed it? Was the signer authorized? Is the underlying observation accurate? A sound evidence process makes each answer inspectable. Cryptography supports that process; it cannot substitute for reliable observation or accountable authority.

Ed25519 is a digital-signature scheme specified in RFC 8032. Its compact keys and signatures make it useful in many conventional systems. Its security depends on elliptic-curve mathematics that is vulnerable to sufficiently capable quantum attacks. That quantum threat changes the long-term protection requirements for signed records. [3]

ML-DSA uses module-lattice mathematics and is standardized in NIST FIPS 204, published in August 2024. ML-DSA-65 is one of that standard's parameter sets. It provides a post-quantum approach to the signature job: checking authenticity and detecting unauthorized changes to signed data. The number 65 identifies the algorithm’s parameter set. [4]

Choosing a standardized algorithm is only part of deployment. The implementation, private-key protection, message encoding, verifier behavior, and handling of rejected signatures all matter. A provider should distinguish use of a NIST-standardized algorithm from a separately established claim of cryptographic-module validation. Cryptographic-module validation requires its own supporting certification.

Security evidence can outlive the system state it describes. An incident timeline, a control observation, or a record of an authorized action may matter months or years later. Its usefulness depends on preserving both the evidence and a defensible way to check its origin and integrity.

VitalSec's hosted evidence-signing approach pairs ML-DSA-65 with Ed25519 for evidence batches. The architectural purpose is to add a post-quantum signature layer while retaining the classical signature path. This illustrates a specific application of post-quantum cryptography: protecting the integrity and authenticity of signed evidence. The protection described here applies to hosted evidence batches; transport, endpoints, and storage each have their own protection requirements.

Two signatures are not automatically a complete assurance policy. A receiving system needs explicit rules for which signatures it checks, which keys it trusts, and what it does if a required check fails. If it silently accepts a weaker path when the stronger one fails, the algorithm list can look better than the actual protection.

Long-term evidence also needs the signed material, algorithm identifiers, public-key history, and relevant trust context. Re-signing a historical record can preserve an attestation about the record now held; it does not retroactively prove every earlier event or establish an original creation time. These are evidence-design questions as much as algorithm choices.

ML-KEM, standardized in NIST FIPS 203, is a key-encapsulation mechanism. It enables participants to establish a shared secret over a public channel. A protocol can then derive encryption keys from that secret and use an appropriate encryption scheme to protect the information itself. ML-KEM is neither a digital signature nor a bulk-data encryption algorithm. [5]

That distinction matters when assessing a vendor. Post-quantum signing of an evidence package says nothing by itself about how the package was transported or how stored copies are encrypted. Conversely, a quantum-resistant key-establishment path does not, on its own, establish the authenticity of a business record.

The complete protocol must address authentication as well as confidentiality. Ask which connection is protected, which peers support the mechanism, how the negotiated mode is checked, and what happens when a peer cannot support it. A feature advertised by one component does not establish coverage across the entire path.

Harvest now, decrypt later describes an attacker collecting encrypted information today in the hope of decrypting it when stronger capabilities become available. Joint CISA, NSA, and NIST guidance identifies this risk as a reason to begin preparing for migration. A future upgrade cannot retrieve copies an attacker already captured. [6]

Consider a medical record, a trade secret, or confidential business information that must remain private for many years. The planning question is how long disclosure would matter, how long migration will take, and which vulnerable protection paths expose the information. A short-lived record and a long-lived record may justify different priorities.

Signatures raise a related but separate problem: future forgery and the continuing trustworthiness of signed records. Treat confidentiality lifetime and authenticity lifetime as separate requirements. Encrypting an archive does not settle its provenance, and signing it does not make it private.

NIST recommends beginning the transition to its post-quantum standards. Begin by inventorying dependencies and planning migration around information lifetime, deployment effort, and business consequence. [2]

What is protected? Ask for the specific object or path: an evidence batch, software update, API connection, backup, or archive. A clear answer names both the security purpose and the boundary of coverage.

Which algorithm and parameters are used? Ask for the standard, parameter set, implementation, and version. Distinguish a signature algorithm from key establishment and encryption rather than accepting a list of cryptographic names.

How does the recipient verify protection? Ask how the relevant key is trusted, what is actually checked, and how invalid, absent, or unsupported protection is handled. Verification policy determines whether a capability affects acceptance.

What happens during migration? Ask about compatibility, downgrade prevention, key rotation, recovery, and the intended behavior when a required component is unavailable. These decisions should be explicit before a critical workflow depends on them.

What evidence supports the claim? Ask for reproducible verification of representative artifacts or negotiated connections, interoperability results, and negative tests showing that altered data or unacceptable protection is rejected. Algorithm support and independently inspectable behavior are different kinds of evidence.

What remains dependent on other systems? Ask about identity, transport, endpoints, storage, signing services, and downstream consumers. A useful answer provides an understandable scope, not an absolute promise.

First, inventory where public-key cryptography is used and who owns each dependency. Include purchased services as well as software your organization controls. Then rank those uses by information lifetime, business consequence, and migration difficulty. The NCCoE migration project treats discovery and interoperability as central parts of this work. [7]

Next, select a bounded pilot with clear success and failure criteria. Test compatibility, artifact size, latency, verification, and failure handling in the workflow that matters. Preserve the ability to investigate errors without silently accepting a protection mode the policy forbids.

Finally, build cryptographic agility into procurement and operations. Assign owners, document replacement paths, retain the information needed to verify historical records, and revisit assumptions as standards and implementations evolve. Treat the inventory as something maintained, not a spreadsheet completed once.

Shor's result began with mathematics. The business response is practical: understand what must remain confidential, what must remain authentic, and for how long. You do not have to understand the quantum algorithm to ask a precise question about the protection your organization relies on.