A scorecard, not a sales pitch
The Ten Golden Rules of Credential Management
These are the rules a credential system should be built on — technical, testable, pass/fail. Hold any tool against them, including ours, and count how many it keeps. Most of the industry keeps fewer than half, because the way secrets have been stored for twenty years was designed for humans who had to read and remember them. Remove that assumption and the bar moves. Here is where it should sit.
Ten rules. Each one Clavitor keeps.
Every rule is a universal principle of good credential management. Underneath each, in plain terms, is exactly how Clavitor holds to it.
01 — Random key
The key is random, and no human ever sees it.
A secret a person can read can be phished, guessed, reused, or coerced out of them. The key should be random material the machine generates — never displayed, never typed, never recoverable from anything a human knows.
02 — No master password
There is no master password. A hardware key is the only key.
A master password is a door, and a door can be picked. A recovery phrase for the owner is a recovery phrase for the attacker. The root of trust should be a physical key that must be present.
03 — Operator blind
The operator cannot decrypt the data it stores.
If the company running the servers can read your secrets, so can a rogue employee, a subpoena, or whoever breaches that company. Confidentiality should rest on math, not on the operator's good behavior.
04 — Nothing at rest where code runs
A secret exists only for the instant it is used, never sitting on the machine that runs the code.
A credential in a .env file, an environment variable, a local cache, or plain memory on the box is waiting for whatever runs next to grab it, and it is exactly as exposed on a client device as on a server. An encrypted local copy is still a copy, with its key on the same machine. Code should get the use of a secret, never custody of it.
05 — No enumeration
An agent cannot enumerate. It reaches only what it was named.
If an actor can list, search, or browse the store, a single compromise becomes a map of everything you own. The inability to enumerate is stronger than any limit placed on enumeration.
06 — Machine-bound
A credential is bound to the machine it was issued to.
Assume a credential will eventually be stolen. What matters is whether it is worth anything off the machine it belongs to. A key that works from anywhere works from the attacker's laptop.
07 — No mass drain
No single actor can drain the vault.
Normal use touches a handful of secrets. A theft tries to take everything, fast. The system should tell those two apart and stop the second one without the owner having to watch.
08 — Logged and attributed
Every action is logged and attributed.
Shared accounts and silent reads destroy accountability. When something goes wrong you need to know exactly who, or what, did it, and every credential it touched. A record with gaps is not a record.
09 — Validated crypto
The cryptography is validated, not invented.
Home-grown crypto is how smart teams lose. The primitives protecting a secret should be ones independent reviewers have already validated, and the build should make it impossible to ship without them. Boring and audited beats clever.
10 — Two-party recovery
No vault is recovered without the owner, and none by the owner alone.
Recovery is where most systems quietly reopen every door they closed: an email reset, an SMS code, a security question, a support desk that can be talked into an override. The way back into a vault should take the owner and more than the owner, so that neither a stolen recovery secret nor a compromised provider is ever enough by itself.
Run the list.
Run your current tool down the ten. Then run ours. We wrote these down because most of the industry quietly fails several — and we built Clavitor to fail none.