Getting ready for post-quantum cryptography
A quantum computer threatens key exchange and signatures, not vault content. Every encrypted record on Essence names its algorithm, and in September we added a post-quantum signature for long-lived evidence.
Some records have to outlast the cryptography that protects them. An organisation may need to keep a record confidential, or prove it has not changed, for decades. Over that span the algorithms will change, and a large quantum computer is the change many now plan for.
"Quantum-ready" is becoming a label used loosely. The useful questions are narrower: where is the cryptography a quantum computer would threaten, and how will it be replaced? We have been answering both in code.
Where the risk is
Not all cryptography is equally exposed. Content in an Essence vault is encrypted with AES-256, a symmetric cipher. A large quantum computer weakens symmetric ciphers but is not expected to break them, and our security documentation treats AES-256 as adequate, with no migration planned. The same holds for SHA-256 hashing in its current uses.
The exposure is in asymmetric cryptography: the public-key exchange used when a person shares something with another person or an organisation, and the classical signatures used across the platform.
That is also where "harvest now, decrypt later" comes in: someone records encrypted traffic today and waits until they can open it. For Essence, that risk sits on the sharing path, not on the bulk content held in vaults. Knowing exactly where the exposure is tells us where the work belongs.
Records that say how they were protected
Changing an algorithm is hard when nobody knows which data used the old one. On Essence, nothing has to be guessed. Every encrypted record carries the version of the algorithm that produced it and the key generation in force. A new algorithm is designed to arrive as a provider added in an ordinary release: new data adopts it, and existing data stays readable.
In our September release we applied the same idea to hashes. Stored digests across the platform's databases gained a field recording which hash algorithm produced them, set to SHA-256 by default. When a hash algorithm needs replacing, those stored digests will already say what they are.
A key exchange with room for both
The platform has a hybrid key-exchange interface with two slots, one classical and one post-quantum. Hybrid means the shared secret is built from both, so it is at least as strong as the stronger of the two. If a flaw is later found in a young post-quantum scheme, security does not fall below the classical baseline. Our security documentation notes that this approach matches NIST, NCSC and BSI transition guidance.
On the device, Essence uses the cryptographic primitives the device platform provides, rather than shipping its own implementations of new standards into the encryption path.
A signature for evidence that has to last
Some records exist to be checked years later: evidence that a document existed, unchanged, at a point in time. They depend on signatures, and classical signatures will not last for ever. This is where we started with post-quantum signatures.
Also in our September release, we added a composite witness to these preserved-evidence records. It is a signature made with two algorithms together: ECDSA P-256, which is classical, and ML-DSA-65, the post-quantum signature standard NIST published as FIPS 204.
The witness is due on a record once a classical signature algorithm on it reaches its renew-by date, which is set ahead of that algorithm's deprecation. The renewal is planned, not a scramble.
It also fails safe. When the witness is in use, the service reports itself not ready if the post-quantum signer or its key custody is unavailable, so a record is never quietly renewed with a classical signature alone. The ML-DSA-65 code we use is checked against a subset of the test vectors NIST publishes for the standard.
What this means for you
If you hold data that must stay confidential or verifiable for decades, ask any provider two questions: where is your asymmetric cryptography, and how will you replace it? Our answers are specific, and they are a position you can check rather than a label you have to trust. If long-term confidentiality or evidence is part of your requirements, we would be glad to take you through the design.
Published 30 September 2026