Vault-based authentication: an honest look at what it cannot do

Vault-based authentication, in the broad sense — HashiCorp Vault, AWS KMS, GCP CloudHSM, Azure Key Vault, and the family of dynamic-secret patterns that grew up around them — has been one of the genuine wins of the cloud-microservice era. It centralised what should be centralised. It put a sane authority in front of a hundred services that used to ship long-lived credentials in environment variables.

We are not here to argue against it. In its envelope — services in a single cloud, with reliable network reachability to a credential authority, where the per-request latency to fetch or refresh a credential is amortised against a request that will then make four database calls anyway — vault-based authentication is the right tool. It will continue to be the right tool there.

The honest thing to say, though, is that the operational envelope of vault-based authentication does not stretch as far as the cloud-native conversation often pretends.

Take a drone fleet under jamming. The vault is in some terrestrial datacentre. The drone, by definition, cannot reach it for the duration of the jamming. What does the drone authenticate against? In practice: nothing. The drone is either operating on a stale credential it should not still have, or it has degraded gracefully into an unauthenticated mode, or it has lost the mission. None of these are good answers.

Take an inter-satellite link in a constellation between ground-station passes. The latency to a ground key-management station is in seconds, when there is one in view, and infinity when there is not. The constellation either depends on a satellite-resident vault (which becomes the new central authority and so reproduces the problem at orbital scale), or it gives up on per-pair authentication and trusts the constellation as a whole. Neither is what the security review wanted.

Take an industrial sensor with a twenty-five-year operational lifetime. The vault that authenticates it today may not exist in 2045. The certificate authority chain it depends on may have rotated through three new roots. The post-quantum migration may have happened twice. None of these are events the sensor's firmware is going to sit through gracefully if its authentication architecture assumes phone-home.

What these cases share is not that vault-based authentication is bad. It is that vault-based authentication assumes a particular operational envelope — reliable reach-back to an authority, latency budget that admits a round-trip, time horizon shorter than the authority's lifecycle — and outside that envelope, it cannot do the job.

The architecture that does the job outside that envelope looks different. It bootstraps once, post-quantum, and then runs without an authority. It carries no persistent secret on disk. Its state advances through one-way functions on a schedule. Its verification path is branch-free and fits in cache. That is not a vault. That is EdSSA Nano.

We are happy to debate the boundary. We do not think the boundary moves much, though, because the operational realities — jamming, orbits, twenty-five-year horizons — do not move much. The vault is the right tool inside the cloud envelope. Outside it, the right tool looks like EdSSA.