Table of Contents
Revoking a leaked credential is the easy part. Knowing what breaks when you do is the part nobody can answer.
A scanner flags a credential in a repository. It’s the data lake key - read access to most of what the company has ever collected.
Nothing reads it from there. It was mistakenly committed two years ago and went unnoticed. But it is out, so it has to be rotated. Nobody argues about that.
Then someone asks which systems are using it.
Nobody can answer. You build a list from memory and from asking around. Twelve services, you think. Four teams.
You rotate on a Tuesday evening and watch. Nothing happens for forty minutes.
Then the reporting view goes blank. For customers.
That team keeps its workload secrets in a different secret manager. You updated the source of truth. You did not update theirs, because yours was never the only one.
Nobody did anything wrong. Two teams standardized at different times. That is how most estates end up.
The next rotation waits for a complete list of consumers. Nobody can produce one. It is still waiting.
The system you’re protecting can’t tell you who’s using it
A safe rotation needs two facts. Which services authenticate with the credential. And where each of them reads it from.
The first sounds like it should come from the data lake. It doesn’t. The lake records that the credential was used. It does not record which service used it. One credential handed to twelve services arrives as one caller, twelve times. The audit trail is fine. It is answering a different question.
The second assumes there is one place the credential is kept. Most estates have several, and one credential can sit in more than one. So a rotation is not one write. It is a write to every place the value is kept, and you have to know how many places that is.
What gets tried first
- Ask the teams. Tribal knowledge, and the people who set it up have moved on.
- Last-used data. The best of the existing answers, and still not enough. It tells you the key was used, not which service used it or where it read it from. And only some systems offer it at all.
- Run two keys and phase it. Genuinely good, where the system supports it. You still need the consumer list to know when the old key has gone quiet.
- Rotate and see what breaks. This is the one that created the problem.
The answer only exists on one side
Both missing facts are facts about the consumer, not the provider. So any answer has to be built from the authentication itself. Two things follow.
- It has to work the same for a database password, for a cloud key, and for the API token a SaaS vendor issued you.
- It cannot carry the secret. What gets recorded has to identify a value without holding it – enough to match two copies of the same value, not enough to reconstruct it.
Get both right and everything you know about one credential collapses into one picture: every place it is kept, and every service observed using it.
The sensor is already watching
Hush deploys a sensor across your clusters and hosts. It observes at the operating system level, so applications are not modified and nothing needs an SDK added to it. It watches; nothing routes through it.
It sees each authentication: which workload made it (a service, a job, a container), what it reached, and where that workload read the credential from an environment variable, a mounted secret, a vault, a cloud secret manager.
The secret value never leaves the machine. Only the fingerprint does.
So the rotation starts with both facts in hand, including the source of truth nobody remembered.
Why runtime matters
A scan can tell you a credential exists somewhere. Almost everything you decide afterwards depends on use.
A match in a repository is a guess. An authentication is proof.
That is why secret-scanning queues fill with findings nobody triages: expired keys, test values, strings that only look like credentials. When the same value turns up authenticating, the guess resolves. When it never does, it can wait.
Use is also what makes a finding rankable. Ranking needs three things: how serious the finding is, how important the system it reaches, and whether the workload using it runs in production. A scan gives you the first, and can often infer the second. But permissions say what a credential could reach. Runtime says what it did reach, and from where.
And what the sensor doesn’t see matters as much as what it does. A credential sitting in a secret manager that nothing has authenticated with is one nobody has needed lately. A credential authenticating from a workload with no secret manager behind it is one nobody owns, and something in production depends on it. Neither of those is visible to anything but a sensor watching the authentications.
What it still won’t tell you
Seeing a credential authenticate is proof it is in use. Not seeing it for thirty days is weaker evidence, because some jobs run once a quarter. An unused credential is a candidate for retirement, not a verdict.
So the output is a list of what breaks, not a promise that nothing will: it covers the workloads on machines the sensor runs on. That is still the difference between planning a rotation and hoping.
The deeper fix is not a better rotation. It is having nothing long-lived to rotate in the first place. Hush Access Manager gets rid of the stored credential. What grants access is a rule about the workload’s identity, the way an IAM role does: the workload gets access because of what it is, not because of what it holds. A short-lived key is minted for it when it runs. The idea is not new. Extending it to a database password and a vendor’s API token is, and that deserves its own post.
Until then, the key still has to be rotated. The difference is that the list already exists, so the rotation stops waiting. Nobody finds out from a customer.