The argument is no longer whether to encrypt

The win that created the blind spot

For most of the last decade the security profession campaigned, correctly, for encryption everywhere. Certificates became free and automatic, browsers began marking plain connections as unsafe, and search rankings rewarded the change. It worked. Over ninety-five per cent of web traffic is now encrypted, and the class of attack that depended on reading traffic in transit has largely stopped being worth writing about.

The same change removed the defender's oldest source of information. A network that could once be watched for a file arriving, a credential leaving or a machine reporting to somewhere it should not, now sees an opaque flow and the fact that it happened. Reporting puts more than eighty per cent of attack traffic inside encrypted tunnels. A callback to an attacker's server and a request for a news article are, without decryption, the same event: two scrambled payloads of similar size. The archive noticed this early — Malware Authors Making a Payday Off Encryption argued it while the campaign was still being won.

This is worth stating carefully, because it is regularly misused. It is not an argument against encryption, and the people making it in bad faith usually want something else. Encryption is neutral about whom it protects; making it universal was correct precisely because the alternative protected nobody. What follows is narrower and duller: the visibility that used to arrive for free now has to be bought, and the price is a decision about interception that organisations are entitled to weigh rather than assume.

The part that decides whom you are talking to

Scrambling a conversation is worthless if you are scrambling it with an impostor. The half of the system that establishes identity is the certificate, and it depends on a chain of trust that almost nobody examines: a browser ships with a list of authorities it will believe, any one of them can vouch for any name, and a certificate issued in error by a single authority anywhere in the world is accepted everywhere.

That arrangement has been repaired in ways worth knowing about. Certificate transparency requires issuance to be logged publicly, so a domain owner can discover that somebody obtained a certificate for their name — a mechanism that has caught real misissuance and that costs nothing to monitor. Automated issuance made certificates free and short-lived, which removed both the commercial argument for going without and the long window during which a stolen private key stayed useful. Lifetimes have been shortening steadily since, on the reasoning that revocation has never worked reliably and expiry always does.

Short lifetimes bring their own hazard, and it is the one that actually takes sites down. An expired certificate is among the most common causes of self-inflicted outage in this field, it happens overwhelmingly to internal systems and appliances that automation never reached, and it tends to occur at whatever hour the renewal was originally performed years earlier by somebody who has left. An inventory of certificates with expiry dates is a mundane document that prevents a recurring and entirely predictable failure.

Inside an organisation the trust question reappears in a different form. Every machine with an inspection proxy has been given an extra authority it will believe, which means whoever controls that authority can impersonate any site to any of those machines. That is the intended behaviour and it is also a standing capability that deserves the same protection as any other master key — a point that tends to be missed because the proxy is filed as a network appliance rather than as a certificate authority, which is what it is.

What happens when the mathematics changes?

The archive mentions quantum computing 24 times, almost all of it speculative. The situation in 2026 is considerably more concrete, and the concrete part is not a machine — it is a set of deadlines.

The first post-quantum standards were finalised in August 2024. The deprecation timeline that accompanies them calls for today's public-key algorithms to be disallowed across those standards by 2035, and national security systems in the United States are required to have moved by 2030. Estimates for a large organisation migrating everything it runs range from five to fifteen years, which means the deadlines and the effort are the same size — a rare and uncomfortable alignment.

The threat that makes the schedule urgent is passive. Harvest now, decrypt later means copying encrypted traffic today and keeping it until it can be read. It leaves no trace, cannot be detected, and is presumed to be under way against anything worth the storage. The consequence is that a decision about secrecy is being made now for data whose confidentiality requirement is measured in decades: medical records, state material, industrial designs, anything whose worth outlives the cipher protecting it.

The encouraging half of the story is how much has already happened without anyone doing anything. Hybrid key agreement went from roughly two per cent of connections in early 2024 to the majority of web traffic in under two years, delivered through browser and content network defaults. Most engineers did not notice, which is what a successful migration looks like. The work that remains is everything an organisation operates itself — its own servers, its own applications, its own long-lived certificates, and the embedded equipment whose firmware nobody can change — and none of that migrates through somebody else's default.

What does encrypting stored data protect against?

Everything above concerns data in motion. Data sitting still is a separate problem with a separate answer, and conflating the two is the most common confusion in this subject — including in the sentence "the data was encrypted", which is offered after breaches to mean anything from a great deal to almost nothing.

Full-disk encryption protects against a specific and narrow event: somebody taking the physical machine while it is switched off. It is genuinely valuable, it should be on everywhere, and it does nothing whatsoever once the machine is running and the volume is mounted — which is the state a laptop is in when malware is stealing from it. A stolen laptop is protected. A compromised laptop is not.

Database encryption at rest works the same way and is oversold in the same way. The storage layer is encrypted so that somebody obtaining the underlying disks or a raw backup file learns nothing. An application with valid credentials reads plaintext, because that is the entire purpose of the arrangement, and almost every breach of a database happens through the application rather than through the disks. Attackers rarely steal drives from data centres. They log in.

Field-level encryption is where the protection starts biting, because the data stays unreadable until something with the right key decrypts a specific value. That narrows what an intruder gains and it costs real functionality: you cannot easily search, sort or index what you cannot read, which is why it tends to be applied to a handful of fields rather than everywhere. The design question is which values would cause harm if they escaped, and it is a business question rather than a technical one.

The practical test cuts through most of the marketing. Ask where the key is. If the key lives on the same machine, in the same account, or in the same cloud project as the data it protects, then whoever reaches the data reaches the key, and the encryption is protecting against theft of the hardware and nothing else. That is a legitimate thing to protect against and it is not what the phrase "encrypted at rest" is usually taken to mean when it appears in a breach notification.