Traditional vs Modern Secrets Management

Two ways to hand out a secret

Every team has secrets: the password to a database, the API key to a payment provider, the token one service uses to call another. A secrets manager is the locked drawer they live in. It keeps them in one encrypted place and hands them to the machines that need them, instead of scattering copies across config files and chat messages.

The interesting question is not where the drawer is. It is how the drawer decides who is allowed to open it. There are two very different answers, and the gap between them is the whole difference between traditional and modern secrets management. The idea is simple enough to explain without any code, so we will do that first, then look at how SikkerKey actually implements the modern one.

How traditional secrets managers work

You, the human, sign in with something strong: a password, a second factor on your phone, maybe a hardware key. That part is genuinely hard to fake.

But your servers and scripts cannot stop to tap a hardware key every time they need a database password. So a traditional secrets manager does something that sounds reasonable and quietly weakens everything: it trades your strong sign-in for a token. A token is just a long string of characters. Your machine stores that string and presents it whenever it wants a secret. The drawer checks the string, sees that it is valid, and hands the secret over.

Think of a hotel. At the front desk they check your passport once, carefully. Then they give you a plastic keycard. From that moment on, the door does not care about you at all. It only checks the card. Anyone who finds that card in the parking lot can open your room.

That is what a token is: a bearer credential. Whoever bears it, gets in. It behaves like cash or a movie ticket, where there is no second check of who is holding it.

A strong login is used only to mint a weaker, copyable token. From then on the secret is guarded by the weaker thing.

The strong login never opens the drawer directly. It mints a weaker key, and that weaker key is what stands between an attacker and your secrets.

The crutches bolted on around the token

Everyone who builds these systems knows the token is the soft spot. So traditional secrets management spends most of its effort on machinery to limit the damage for when a token leaks, because tokens do leak: into log files, crash reports, environment variables, a screenshot in a support ticket.

The usual crutches:

• Short expiry. The token is set to stop working after a few minutes or hours, so a stolen one is useful for a smaller window. The window is smaller. It is never zero.
• Constant rotation. New tokens are issued on a schedule and old ones retired, which means a permanent treadmill of credentials to mint, distribute, and clean up.
• Revocation lists. A blocklist of tokens known to be stolen, which only helps once you already know a token was stolen.
• The secret-zero problem. To fetch secrets, a machine needs its first token. Getting that one to the machine safely means you need a secret to get your secrets, and that bootstrap secret carries the same weakness as the rest.

Picture leaving a copy of your house key under the doormat, then trying to make the copy expire on its own and changing the lock every week to stay ahead of anyone who found it. It is better than doing nothing. But all of it is work you only have to do because there is a copyable key sitting out there in the first place.

This is also why running a secrets manager so often feels like a second job. A large share of the moving parts exists to babysit a credential that was weak by design.

How a modern secrets manager works

Modern secrets managers start from a different question. Instead of giving a machine a token to hold, they give the machine an identity to prove.

Here is the everyday version. Rather than a keycard that anyone can copy, each machine has a signature that only it can produce, like a handwritten signature or a wax seal that cannot be forged. Every time the machine asks for a secret, it signs that specific request. The secrets manager checks the signature. If it matches, the request is genuine.

The crucial part is what travels and what does not. The thing that creates the signature, the machine's private key, never leaves the machine. The secrets manager only keeps the public half of the pair. A public key can check a signature, but it cannot create one. So there is nothing stored on SikkerKey, and nothing sent over the network, that an attacker could pick up and reuse.

The machine proves its identity by signing each request. The private key never leaves it; SikkerKey keeps only the public key, which can verify a signature but never produce one.

This is the model SikkerKey is built on, so let us look at exactly how it works. None of it asks you to trust a hand-wave.

How SikkerKey does it

When you add a machine to SikkerKey, the machine creates its own key pair locally, on that machine. Only the public key is sent to SikkerKey and saved. The private key stays on the host and never travels, not during setup and not on any request afterward. There is no shared API key to copy into a config file or paste into a build pipeline.

From then on, every secret read is a signed request. For readers who want to see under the hood, here is exactly what the machine signs and what SikkerKey checks when the request arrives.

Every field of the request is folded into one Ed25519 signature and sent as four headers. Change any field and the signature no longer matches.

The machine signs a short description of the precise request it is making: the method, the path, the current time, a one-time number called a nonce, and a fingerprint of the request body. SikkerKey rebuilds that same description from the request it actually received and verifies the signature against the machine's public key on file. Two checks make replaying an old request pointless: the timestamp has to land within about five minutes of the server's clock, and each nonce can be used only once, so a captured request cannot be sent a second time.

There is no token anywhere in this exchange. The machine proves who it is on every request, and it never hands over anything that keeps working later. If you want the deeper engineering view, we wrote a separate piece on why we sign every request instead of handing out bearer tokens. You can also require that requests only come from approved networks, so even a correctly signed request from an unexpected place is turned away.

The real test: what happens in a break-in

Any secrets system sounds fine on a good day. The honest way to compare two of them is to ask what an attacker walks away with after they get in.

With the traditional model the stolen token is functionally equal to the secrets behind it. With the modern model there is nothing reusable to take.

With the traditional model, stealing the token is the whole game. It is a working key for everything that token could read, from anywhere, until it happens to expire or someone notices and rotates it.

With the modern model, the attacker comes up empty on the authentication side:

• A captured past request is useless. Its one-time nonce is already spent and its short time window has closed.
• The public key is, by design, public. It cannot be used to forge a signature.
• There is no token in the first place, so there is nothing to lift from a log, an environment variable, or a config file.

This even holds for SikkerKey's own database. Because it stores only public keys for authentication, there is nothing in it that would let someone impersonate one of your machines. To be precise about that claim: it is about how machines prove who they are. The secret values themselves are encrypted at rest with AES-256 and are only ever served to a machine that has proven its identity.

Simpler and safer from the same decision

Notice that almost all the crutches from the traditional model simply stop being necessary. There is no authentication token to rotate, no first-token bootstrap to protect, no race to revoke a leaked string before it gets used. To take a machine offline you disable it, and its key stops being accepted. That is the whole step.

So moving from traditional to modern secrets management is not a trade where you buy more security with more complexity. Both improvements come from the same decision to stop handing out a copyable credential. Take away the bearer token and a large amount of fragile machinery goes with it, and so does the thing an attacker most wanted to steal.

If you are new to the category, our explainer on what a secrets manager is covers the basics, and the machine authentication page goes deeper on the identity model described here.

FAQ

What is a traditional secrets manager? One that authenticates a machine by giving it a token, a reusable string, and then trusting whoever presents that token. Because the token can be copied, these systems add short expiry, rotation, and revocation lists to limit the damage when one leaks.

What is a modern secrets manager? One that authenticates a machine by its identity rather than by a token. The machine signs each request with a private key that never leaves it, and SikkerKey verifies the signature against a stored public key. There is no reusable credential to steal.

Are bearer tokens insecure? A bearer token proves only that the sender holds the token, not who the sender is. That is fine until the string leaks, and strings leak in ordinary ways. The crutches around tokens shrink the leak window; they do not remove the underlying weakness.

What is machine identity? It is giving each machine its own cryptographic key pair so it can prove who it is, the same way a signature shows that a particular person signed something. SikkerKey gives every enrolled machine an Ed25519 key pair and verifies a fresh signature on every secret request.

Does removing tokens make the system simpler to run? Yes. Much of the day-to-day work in traditional secrets management exists to manage tokens. When identity replaces tokens, the rotation schedules, bootstrap secrets, and revocation races on the authentication path go away.