Where secrets hide
Ask an engineering team where their passwords and keys live and the honest answer is: everywhere. A database password in a deployment script. An API key in a configuration file committed to a repository years ago. A cloud credential pasted into a chat to unblock a colleague. A shared spreadsheet of service accounts that three people can edit and nobody owns.
Each of these began as a reasonable shortcut. Together they mean that nobody can say with confidence who has access to what, and that rotating a single credential requires a search across systems nobody fully knows. When someone leaves, their access often stays behind in the copies they made.
What a vault changes
A secrets vault is a dedicated service for storing, issuing and auditing credentials. Applications and people request a secret when they need it, prove who they are, and receive only what they are entitled to. The secret is never written into the code or the configuration; the code holds a reference, and the vault holds the value.
That one change has several consequences. Access becomes a policy rather than a habit. Every read is logged, so you can answer who used which credential and when. Rotation becomes a change in one place rather than a hunt. And repositories can be shared, reviewed and handed over without exposing anything sensitive.
Open-source options
Several mature open-source projects fill this role. Infisical, for example, offers a developer-friendly vault with secret versioning, environment separation and integrations for common deployment tools. Whichever vault you choose, it should integrate with your identity provider, such as Keycloak, so access follows the same single sign-on and role model as everything else, and leavers lose access everywhere at once.
As with any core service, choose software you can run yourself, back up and restore, and replace if you must. A vault you cannot export from is simply a new place to be locked in.
A practical migration
Moving secrets into a vault is a project, not a switch. A sensible order of work looks like this:
Expect this to surface surprises: credentials nobody can identify, service accounts with far more rights than they need, and keys shared between environments. Each surprise is a risk you have just removed, so treat the findings as progress rather than embarrassment.
- Scan repositories and their history for committed secrets, and treat every finding as compromised.
- Stand up the vault with identity integration, backup and an audit log before migrating anything.
- Move the highest-risk credentials first: production databases, cloud accounts and administrative keys.
- Replace each secret in code with a reference, then rotate the original value.
- Add a check to the build that fails when a new secret appears in code.
- Set rotation schedules and review access policies regularly.
Secrets and handover
Vaults matter especially when a platform changes hands. When we hand a platform to the team that will run it, every credential, certificate and key moves into the client's own vault, under the client's own identity provider, and every temporary access used during the build is revoked. The client should be able to confirm that no one outside their organisation still holds a working credential. That is part of what owning a platform means.
The same discipline applies inside an organisation when teams change or suppliers rotate. With a vault, the question who still has access has an answer you can check rather than a guess you hope is right.
Secrets management rarely appears in a strategy deck, but it underpins almost every other security control. Getting secrets out of scripts is one of the most valuable, least glamorous improvements any estate can make.