Secrets management is the practice and tooling for storing, controlling, delivering, rotating and auditing the credentials that software uses to reach other systems, such as database passwords, API keys, cloud access keys, tokens, SSH keys and certificates. Instead of writing these secrets into code or configuration files, applications request them at run time from a protected service, often called a vault, which controls who and what can access each one and records every request.
At a glance
- Secrets are credentials used by software rather than people, and they often grant broad, long-lived access.
- A secrets manager stores them encrypted, releases them only to authorized applications and logs each access.
- Rotation, changing secrets regularly or replacing them with short-lived ones, limits the damage if one leaks.
- Secret scanning in code repositories and pipelines catches credentials committed by mistake.
- It is a core control for non-human identities and is often linked to PAM, PKI and DevSecOps work.
What problem it solves
Software needs credentials to work: an application needs a database password, a script needs a cloud key, a pipeline needs a token to deploy. The easy path is to paste them into code, configuration files, environment settings or a shared chat, and many organizations end up with secrets scattered across repositories, servers, laptops and wikis. They are rarely changed because nobody knows what will break, and when someone leaves or a repository is exposed, there is no quick way to find and revoke them.
Leaked secrets are a common starting point for breaches, especially cloud keys in public code. Secrets management puts credentials in one controlled place, makes them easier to rotate, and gives security teams visibility into which systems use which secrets.
How it works
Central vault. Secrets are stored encrypted in a dedicated service. The encryption keys are often protected by a key management service or a hardware security module (HSM).
Authentication and policy. Applications, servers and pipelines authenticate to the vault using their own identity, such as a cloud workload identity or a certificate, and policies decide which secrets each one may read. This applies least privilege to machines.
Delivery at run time. Applications fetch secrets through an API or have them injected at startup, so secrets don’t sit in code or images. Platforms such as container orchestrators commonly integrate with vaults.
Rotation and dynamic secrets. The vault can change secrets on a schedule and update the systems that use them. Some tools issue dynamic secrets: short-lived credentials created on request and expiring automatically, which limits the value of anything stolen.
Certificates. Many teams manage certificates and their private keys with similar tooling, often tied to public key infrastructure (PKI), to track expiry and automate renewal.
Scanning and audit. Secret scanning tools check repositories, pipelines and logs for exposed credentials, and vault audit logs show who accessed what and when.
When it matters for buyers
- When adopting cloud, containers or automation. The number of machine credentials grows quickly, often faster than people accounts.
- After a leaked key or a code exposure. Finding and rotating every affected secret is far easier with a vault.
- When building a DevSecOps or infrastructure as code (IaC) program. Pipelines need a safe way to get credentials.
- When auditors or customers ask about credential handling. Frameworks commonly expect secrets to be protected, limited and rotated.
- When staff with production access leave. Knowing what they could reach helps you revoke the right credentials.
For tools that also protect administrator accounts, see our privileged access management overview.
Questions to ask vendors
- Which platforms, clouds, CI/CD tools and container systems do you integrate with?
- How do applications authenticate to the vault, and can we avoid a “secret zero” stored in plain text?
- Can you rotate secrets automatically for our databases and cloud accounts, and do you support dynamic secrets?
- How are vault encryption keys protected, and can we hold them in our own HSM or key service?
- What happens to applications if the vault is unavailable?
- What audit logs are available, and can they feed our SIEM?
- Is the product self-hosted, a cloud service or both, and how is it priced?
How it differs from privileged access management
Privileged access management (PAM) traditionally controls powerful accounts used by people, such as administrators, with credential vaulting, session approval and session recording. Secrets management focuses on credentials used by software, delivered through APIs at scale, often within development pipelines. The two overlap: many PAM products now manage some application secrets, and some secrets managers handle human access. A password manager is different again, built for people storing their own logins. Many organizations use a PAM tool for administrators and a secrets manager for applications, so check which use cases a product was designed for.