Preparing Your Edge Fleet for the Post-Quantum Era

There is a specific shape of threat that most infrastructure teams are not yet taking seriously, and that every team running long-lived edge devices should be.

It’s called “harvest now, decrypt later,” and it goes like this. An adversary records encrypted traffic today. Bulk, indiscriminately, patiently. They store it. They cannot decrypt it. That’s fine. They wait. In five years, or ten, or fifteen, a sufficiently capable quantum computer exists, and they go back through the archive and decrypt everything retrospectively.

Everything you sent over TLS. Every API call. Every device credential exchange. Every firmware update. Every signed manifest that told a screen what to display.

For most cloud traffic, this is a moderate concern. Session data from a decade ago is usually irrelevant by the time it can be decrypted.

For digital signage, it’s existential. And we should talk about why.

What an adversary actually does once they’re in

Let’s skip past the abstract and get concrete. Imagine an adversary has, through patience and arithmetic, recovered the credentials your signage platform was using in 2026. It is now 2034. What can they do?

Quite a lot, depending on how the platform was built.

If those credentials still work, they can authenticate as you against your own fleet and tell every screen in the country to show something else. A competitor’s logo. A political message. A QR code pointing at a phishing site. Pornography. The choice is theirs, and the screens will obey, because as far as the screens are concerned the instructions came from you.

If those credentials let them push firmware, they can lock devices. Push an image with a hardcoded root password they control, or with the network stack disabled, or simply with a kernel that won’t boot. Now every screen in the fleet is a brick that can only be recovered by physically driving to it. For a national QSR chain or a transit network, that’s not a recovery plan. That’s a corporate event.

If those credentials let them disable updates, they can hold the fleet hostage. Lock the devices in a state of their choosing and then let you pay them to unlock it.

This is not theoretical. This is the standard playbook, today, for any attacker who gets meaningful credentials into a fleet management platform. The only thing that’s hypothetical is the delivery mechanism. Most platforms rely on adversaries failing to compromise credentials in real time. The post-quantum threat is the observation that they don’t have to compromise them in real time anymore. They can record the encrypted handshakes today, decrypt them in a decade, and then walk through the front door.

If your devices are still in service when that decryption happens, you have a problem. And signage devices are very often still in service.

Why signage is uniquely exposed

Three properties of signage deployments combine badly here.

The first is that screens live a long time. A digital menu board installed in 2026 will, realistically, still be running in 2036 or later. Capital expenditure on signage hardware is depreciated over many years, and operators are not in a rush to replace working hardware. If the device is still in the field when quantum decryption becomes feasible, traffic captured during its lifetime is in scope.

The second is that the network path is uncontrolled. Your screens are on the venue’s Wi-Fi, on a 4G modem, on a guest network at a shopping centre, behind a firewall managed by a landlord’s IT contractor. You have no idea who’s in a position to tap the link, and no way to know what’s being recorded. You have to assume somebody, somewhere, is writing it all to disk.

The third is that the content matters in a way most edge data doesn’t. A compromised industrial sensor leaks data. A compromised signage screen broadcasts whatever the attacker wants to a public audience. The blast radius is reputational, immediate, and visible to your customers and theirs.

If you ship a screen today with only classical cryptography protecting the link, you are making a bet that quantum computers capable of breaking 2048-bit RSA will not exist for the entire operational life of that device. That’s a bet we are not comfortable making, and neither should you be.

What the standards bodies have actually landed on

The good news is that the cryptographic community has been working on this for a decade, and the standards are now real.

In 2024, NIST finalised the first round of post-quantum cryptographic standards. The key exchange primitive, the one that matters most for TLS, is ML-KEM (Module-Lattice-based Key Encapsulation Mechanism), formerly known as Kyber. It’s based on the mathematical hardness of problems in structured lattices, which, as far as anyone currently knows, are not meaningfully easier for quantum computers than classical ones.

ML-KEM is fast. It’s well-studied. Its key sizes are manageable, around 1-2KB depending on the security level. It is, by the standards of new cryptographic primitives, remarkably practical.

The other thing the standards bodies settled on, sensibly, is hybrid mode. You don’t deploy ML-KEM by itself. You deploy it alongside a classical algorithm, typically X25519, and combine the two shared secrets. The session is safe if either algorithm holds. If ML-KEM turns out to have an unexpected flaw, X25519 still protects you. If quantum computers break X25519, ML-KEM still protects you. You need both to fail simultaneously for the session to be exposed.

This is the model that has been working its way through TLS 1.3 implementations throughout 2024 and 2025. Chrome, Cloudflare, AWS, and a growing list of others now offer hybrid post-quantum key exchange by default. The ecosystem is real.

Why the handshake isn’t the only thing that matters

Here’s the part that’s easy to miss, and that we think a lot of competing platforms are going to get wrong.

Hybrid post-quantum TLS protects the transport. It means that traffic recorded today cannot be decrypted in the future. Excellent. Necessary. But not sufficient.

Once an adversary is past the transport, they hit your authentication model. And if your authentication model is “the device holds a long-lived API key,” then an adversary who decrypts ten-year-old traffic finds the key, and the key still works in 2034 because nobody rotated it, and now they’re in.

Post-quantum cryptography is one layer. It buys you nothing if the layer underneath is rotten.

A coherent post-quantum posture for edge has to include four things together. Hybrid post-quantum key exchange on every connection, so the transport is safe. Hardware-rooted device identity, so credentials cannot be copied off a device into an adversary’s hands. Short-lived per-device credentials, so even a successfully recovered credential is useless by the time it’s recovered. And per-device authorisation scoping, so a single compromised device cannot be levered into control of the fleet.

Miss any one of these, and the others are window dressing.

What Admiral ships today

Every connection between an Admiral device and the control plane uses hybrid X25519 + ML-KEM-768 key exchange over TLS 1.3. Every connection. No exceptions, no configuration, no opt-in. Traffic recorded today between an Admiral device and the control plane will not be decrypted by a future quantum computer, because there is no classical-only path through the key exchange to attack.

Device identity is rooted in hardware. The private key is generated on a secure element, never leaves it, and is bound to that specific piece of silicon. An adversary who somehow recovers a decade-old credential off the wire still cannot impersonate the device, because the credential alone is not what authenticates the device. The device proves possession of a hardware-bound key on every connection. There is nothing on the wire to record that would let you forge that proof later.

Credentials are short-lived. Minutes, not months. Even in the worst case where an adversary captures a fresh token, it expires before they can do anything useful with it.

Authorisation is per-device. A compromised device, in the hypothetical scenario where everything else fails, has authority over itself and nothing else. It cannot push content to other screens. It cannot deploy firmware to the fleet. It cannot read another device’s credentials. The blast radius is one screen.

The combined effect is that the harvest-now-decrypt-later attack, as it applies to digital signage, is removed from the threat model entirely. Not mitigated. Not made harder. Removed. There is no recording an adversary can make today that becomes useful when quantum computers arrive, because nothing on the wire is the actual credential.

This is the bar. We think it should be the bar industry-wide, and we expect regulators to agree before the end of the decade.

What you should be asking your current vendor

If you’re running signage on a platform that isn’t Admiral, here are the questions worth asking.

What key exchange algorithms do my devices negotiate with your control plane today? If the answer is anything classical-only, that traffic is in the harvest pile right now.

How are device credentials stored and what’s their lifetime? If credentials are long-lived API keys sitting in a config file, the post-quantum threat compounds with normal credential leakage. Both problems share a solution: hardware-rooted identity and short-lived tokens.

If a single device is fully compromised, what authority does the attacker gain over the rest of the fleet? If the answer involves any phrase resembling “shared credentials” or “fleet-wide tokens,” the architecture is wrong regardless of the cryptography.

What’s your migration plan to post-quantum, and when do my devices benefit from it? “We’re looking into it” is not an answer that protects a screen with a fifteen-year service life.

These are not unreasonable questions. If your vendor cannot answer them clearly, that itself is the answer.

The awkward conversation about timelines

Nobody knows exactly when a cryptographically relevant quantum computer will exist. Estimates from serious researchers range from “ten years” to “never.” The median expert opinion sits somewhere around 2035-2040, with very wide error bars.

This is, obviously, not a helpful planning horizon. But the decision framework is clear. If there is a non-trivial probability that the capability exists before your current devices reach end-of-life, and if the cost of pre-migrating is modest, the expected value of migrating now is strongly positive.

Our take is that the cost of pre-migrating is indeed modest. Hybrid TLS adds a few kilobytes per handshake and a few milliseconds of CPU, on devices that have plenty of both. And the cost of not pre-migrating, if the capability does arrive in a plausible timeframe, is every screen in your fleet showing whatever an adversary chooses, on the day they choose it.

So we did the work. It’s on. It’s the default. You don’t have to think about it.

That’s the whole point.