Quantum Secure Email Smime

What quantum computing means for secure email

Encrypted email is among the most exposed applications of public key cryptography. S/MIME provides no forward secrecy, messages are retained for years or decades, and the private keys needed to read archives must be kept for as long as the archive exists. Anything encrypted to an RSA key today can be read once that key becomes derivable.

How email cryptography works today

Email protection operates at two independent layers, and confusing them is the most common source of misplaced confidence.

Transport protection is widely deployed and largely invisible. Its weakness is that the message is decrypted at every hop, so it protects the wire and not the mailbox.

S/MIME protects the message itself. It uses X.509 certificates, with RSA or ECDSA for signatures and RSA key transport or elliptic curve key agreement to protect the content encryption key. The structure is defined in the Cryptographic Message Syntax, and both the signature and the key protection are quantum-vulnerable.

Why email cryptography is a harvest now, decrypt later problem

Three properties combine to make encrypted email an unusually poor case.

There is no forward secrecy. TLS negotiates ephemeral keys, so compromising a server's long-term key does not expose past sessions. S/MIME does the opposite: the content encryption key is protected under the recipient's long-lived public key, and recovering the corresponding private key exposes every message ever sent to that recipient.

Messages persist. Email archives routinely run to seven, ten or twenty years under regulatory and legal hold obligations. The confidentiality requirement of the content, particularly legal advice, clinical correspondence, HR matters and commercial negotiation, frequently extends further still.

Private keys must be retained. To read an encrypted archive, the recipient must keep the decryption key for as long as the archive exists. Key history and escrow are therefore deliberate features of enterprise S/MIME deployments, which means the estate holds a store of long-lived, quantum-vulnerable private keys by design rather than by neglect.

The consequence is direct. An organisation that has used S/MIME for a decade holds an archive whose confidentiality depends entirely on RSA or elliptic curve keys that are already published in the certificates attached to every message sent.

What happens to signed email

Signed email fails differently. The signature does not become invalid, but the basis for non-repudiation does, because a verifier cannot distinguish a genuine historic signature from one produced later using a derived key.

For most internal correspondence this is of limited consequence. Where signed email carries evidential weight, in regulated instruction, authorisation workflows, legal correspondence or anything that may be relied upon in dispute, the same preservation measures apply as to any other signature: trusted timestamping at the point of signing and long-term validation, as covered in what quantum computing does to digital signature validity.

Where the standards have reached

Work is under way and is less mature than the equivalent work for TLS.

The IETF has published RFC 9629, which defines how key encapsulation mechanisms are used within the Cryptographic Message Syntax. This is the structural prerequisite for ML-KEM in S/MIME, because CMS was designed around key transport and key agreement rather than encapsulation. Further work in the LAMPS working group covers post-quantum and composite signature algorithms in certificates and CMS.

The practical position is that the specifications are arriving and client support is not. Mail clients update slowly, S/MIME implementations sit deep in mature codebases, and interoperability must hold not only within an organisation but with every external correspondent. Transport layer post-quantum support will be routine well before end-to-end email protection is.

Practical obstacles specific to email

Certificate size is more consequential here than elsewhere. S/MIME certificates travel with messages, so a post-quantum certificate chain is added to every signed message rather than negotiated once per connection. On a high-volume mail platform that is a measurable increase in storage and transmission.

Credential storage is a hard limit. Many government and regulated S/MIME deployments issue certificates onto smartcards or tokens, whose storage capacity was sized for elliptic curve credentials. A post-quantum credential may not fit, which converts a certificate migration into a hardware replacement programme.

Interoperability is bilateral. A post-quantum S/MIME message can only be read by a correspondent whose client supports the same algorithms. Unlike TLS, where server and client negotiate, email offers no fallback: a message encrypted to an algorithm the recipient cannot process is simply unreadable.

Key history complicates rotation. Migrating to a new algorithm does not permit retiring old keys, because the archive still requires them. Organisations end up maintaining both, which increases the surface rather than reducing it.

What to do about email cryptography now

Establish what actually flows through email

Inventory which categories of sensitive content are routinely sent by email and what their confidentiality lifetimes are. This frequently produces the most useful finding in the exercise, which is that material with thirty year confidentiality requirements is moving through a channel that was never designed to protect it for that long.

Reduce sensitive content in the channel

The cheapest post-quantum improvement available to most organisations is not cryptographic. Moving long-lived confidential material out of email and into a controlled repository with managed access, where encryption keys are under the organisation's control and can be rotated, removes the exposure rather than mitigating it.

Enforce transport protection

Confirm that outbound and inbound mail uses enforced TLS rather than opportunistic STARTTLS, using MTA-STS or DANE. Hybrid post-quantum key exchange arrives at this layer through normal platform updates, so enforcement now positions the organisation to benefit without further work.

Inventory S/MIME certificates and key history

Record where S/MIME certificates are issued from, which archives depend on which keys, and how long each must be retained. This is routinely absent, and it determines the scope of any future migration.

Timestamp signed mail that carries evidential weight

Where signed email is relied upon in regulated or contractual contexts, apply trusted timestamping at signing so that evidential value can be preserved as algorithms are withdrawn.

Raise credential capacity at the next token refresh

Where S/MIME certificates are issued to smartcards or tokens, specify capacity for post-quantum credentials in the next procurement, since retrofitting is not possible.

Common mistakes

The first is treating transport encryption as end-to-end protection. TLS between mail servers protects hops. The message sits decrypted at every intermediate point and in every mailbox and archive.

The second is assuming the archive is safe because it is behind access controls. Harvest now, decrypt later exposure arises from the message in transit, which was captured years before the archive controls became relevant.

The third is planning to migrate S/MIME on the same timeline as TLS. Client support, interoperability with external correspondents and credential capacity all make email slower, and the plan should reflect that rather than assume parity.

The fourth is deleting old keys after migration. The archive cannot be read without them, so key retention obligations continue and must be managed as a distinct risk.

How Unsung helps

Unsung is a UK-based, vendor-neutral consultancy specialising exclusively in public key infrastructure and cryptographic systems, working across central government, defence, healthcare, financial services, nuclear and transport.

We inventory S/MIME issuance, key history and archive dependency as part of our PKI health check and cryptographic bill of materials services, and design the issuance and certificate lifecycle management capability required to reissue user certificates at scale. Where credentials are held on smartcards or tokens, we assess capacity and support specification of replacement credentials, working with credential management platforms including MyID selected on requirement rather than partner preference.

For the endpoint layer that S/MIME depends on, see why endpoints are missing from most PQC programmes.