Zero Trust for Edge: Rethinking the Perimeter

For about thirty years, enterprise security was organised around a fence.

Inside the fence, things were trusted. The corporate network, the datacentre, the VPN. Outside the fence, things were hostile. The entire job of a security team was to guard the fence. You authenticated people at the gate, and once they were inside, they could largely talk to whatever they needed to.

This was never a great model, but it was a workable one when “infrastructure” meant “servers in a room we own.”

Infrastructure does not mean that anymore. It hasn’t for a long time. And for edge fleets in particular, the perimeter model isn’t just imperfect, it’s incoherent. There is no fence to draw.

This post is about what replaces it.

The perimeter was never about trust, it was about convenience

The dirty secret of the perimeter model is that it wasn’t really a security model. It was a key management model. Distributing credentials to every service and authenticating every call between them was operationally painful in 1998, so we drew a line and said “inside this line, we’ll skip that step.” The perimeter was an excuse not to do the hard work.

Zero trust, fundamentally, is the observation that modern infrastructure makes it possible to do the hard work. Every request authenticated. Every connection encrypted. Every identity cryptographic, not positional. You don’t trust a service because of where it is. You trust it because of what it can prove about itself.

For cloud workloads this is now fairly well understood. mTLS everywhere, service meshes, SPIFFE identities, short-lived tokens. The tooling is mature. The cultural shift has mostly happened.

For edge fleets, the same ideas apply, but the environment is harder, and the stakes are different.

Why edge breaks the perimeter harder than cloud does

When a cloud workload sits outside your datacentre, it’s usually still in some trusted environment. A VPC you own, a cloud account you control, a region with audited physical security.

An edge device sits in a shop. A field. A vending machine. A bus. A mine.

There are three things that make edge security uniquely hard.

The first is that physical access is not controllable. Anyone can unplug, open, or tamper with an edge device. The threat model has to assume someone, at some point, will pull a device out of a wall and take it home.

The second is that the network is hostile by default. Your devices are on the customer’s Wi-Fi, on a 4G modem, on a guest network, behind a captive portal, behind a firewall you can’t configure. You cannot assume anything about what’s on the same network segment.

The third is that the scale inverts the math. One compromised device in a fleet of 50,000 is 0.002% of your fleet, but it’s 100% of the access needed to pivot into your control plane if you’ve designed the trust model wrong. Static shared credentials, “the device API key”, are a loaded gun pointed at your entire business.

A proper zero-trust model for edge has to answer three questions. How does a device prove who it is, how does it prove the current moment is legitimate, and how do we contain the blast radius when something goes wrong.

Identity, bound to hardware, not to a config file

The first thing to get right, and the thing most platforms get wrong, is identity. A device’s identity must be rooted in something that cannot be copied to another device.

This means a hardware secure element. A TPM, a dedicated security chip, or at minimum a hardware-backed key store. The device’s private key is generated on the chip, never leaves the chip, and is bound to that specific piece of silicon. The public key is enrolled with the control plane at manufacturing or first boot.

An attacker who pulls the SD card out of an Admiral device, reads every byte, and writes those bytes to a different device gets nothing. The new device cannot sign its way into the control plane because it doesn’t have the original’s key, and the original’s key cannot be extracted.

This is the foundation. Everything else, authentication, authorisation, audit, is only as strong as the identity underneath it.

Credentials, short-lived, scoped, proof-of-possession

Long-lived API keys are the weed in the garden of zero-trust. They persist. They leak. They end up in screenshots, in Git history, in support tickets. They are, structurally, the wrong shape.

Admiral devices don’t have long-lived credentials. They have a hardware identity, and they use it to obtain short-lived tokens, minutes not months, that are cryptographically bound to that specific identity. Every token is proof-of-possession. Presenting the token without being able to sign with the matching key proves nothing. Copying a token off a device gets you nothing, because the token expires before you can use it, and even if you caught it fresh you can’t sign a challenge with it.

The control plane issues these tokens only over a connection that’s already authenticated with the device’s hardware identity. There’s no bootstrapping moment where a weaker credential unlocks a stronger one. The hardware identity is the only thing that ever gets you in.

Network, outbound, encrypted, unassuming

The network model flips the traditional direction. Devices do not listen. Devices dial out.

Every Admiral device maintains a persistent outbound connection to the control plane. This connection is the only way anything reaches the device. SSH, telemetry, remote commands, workload deployment, all of it flows through that single authenticated tunnel.

This has several compounding benefits. No inbound firewall rules needed on the customer’s network, so deployments stop requiring arguments with IT departments. No exposed services on the device means nothing for an attacker on the same network to probe. The connection is mutually authenticated with post-quantum hybrid TLS 1.3, so even a future quantum attacker replaying captured traffic learns nothing. Every session through the tunnel is logged at the control plane, giving a complete audit trail without relying on the device to self-report honestly.

The device, effectively, has a network presence of exactly one socket. The one it opened itself. Nothing else is reachable.

Blast radius, assume compromise, contain it

The last piece, and the one most easily overlooked, is containment. A good zero-trust model doesn’t just make compromise harder, it makes compromise smaller when it happens.

Every Admiral device has credentials scoped only to itself. A device cannot impersonate another device. A device cannot read another device’s telemetry. A device cannot deploy workloads to other devices. If an attacker fully compromises a device, extracts the secure element somehow, owns the hardware outright, they have one device. They do not have the fleet.

The control plane enforces this at every level. Authorisation decisions are per-device. Tenant isolation is per-customer. The architecture assumes every device could, in principle, be hostile, and refuses to grant any device more authority than it strictly needs.

This is the quiet, boring part of zero-trust. Not cryptography, not protocols, just the discipline of giving every component the least authority it can function with. It’s also the part that decides whether a future incident is a contained nuisance or a front-page story.

Zero trust isn’t a product, it’s a posture

There is a marketing tendency to sell “zero trust” as a thing you buy. A box, a dashboard, a subscription. It is not. It is a way of designing systems so that trust is earned continuously rather than granted positionally.

What a platform like Admiral can do is make that posture the default. Hardware identity out of the box. Short-lived credentials out of the box. Outbound-only networking out of the box. Per-device scoping out of the box. So that the right model is the easy model, and your engineers don’t have to rebuild it from first principles on every project.

The fence is gone. It was always imaginary. What matters now is what each individual component can prove about itself, every time, from scratch.

That’s the whole idea.