What is a secrets manager?
A secrets manager, often called a vault, is a central service that holds the credentials applications and automation need: database passwords, API keys, cloud access keys, tokens, and certificates with their private keys. Instead of being written into source code, configuration files or pipeline definitions, each secret lives in the manager, encrypted, and an application requests it at runtime after proving its own identity. Common examples include HashiCorp Vault, AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager.
What a secrets manager provides
- Encrypted storage: secrets are encrypted at rest, typically under keys held by a key management service or an HSM.
- Fine-grained access: each application or pipeline can read only the secrets it needs, ideally scoped to one environment.
- Audit logging: every read and change is recorded, so investigators can see which identity retrieved a credential and when.
- Rotation: the manager can change a password or key on a schedule, updating the target system and the stored value together.
- Dynamic secrets: some managers generate short-lived credentials on request, such as a database login that expires after an hour, so there is no standing password to leak.
- Versions and revocation: earlier values are kept for rollback, and a leaked secret can be revoked from one place.
How applications prove who they are
A vault only helps if getting into it does not require yet another hardcoded secret, a bootstrap problem sometimes called secret zero. Platforms solve it with an identity the environment already provides: a cloud instance role or managed identity, a Kubernetes service account, or OpenID Connect federation for a CI/CD job, which lets the job receive short-lived cloud credentials with no stored key at all. Policies in the manager then map each of those identities to the specific secrets it may read.
Example: removing a hardcoded password
A billing service's source contains DB_PASSWORD = "Winter2026!", and the same password works in development and production. The team stores the production password in the manager under prod/billing/db and grants the production service's cloud role permission to read that one secret and nothing else. The code now fetches it at startup, for example with aws secretsmanager get-secret-value --secret-id prod/billing/db or the matching SDK call. They turn on automatic rotation every 30 days and change the database password immediately, because the old value still sits in the repository history. Development gets its own secret with a different value. A leak of the source code now exposes no working credential, and the audit log shows exactly which service read the secret and when.
Secrets manager vs. KMS, password manager and PAM
- Key management system (KMS): creates and guards encryption keys and performs cryptographic operations, often without ever releasing the key itself. A secrets manager stores and hands out credentials, and usually relies on a KMS to encrypt them.
- Password manager: stores passwords for people to use when signing in to websites and apps. A secrets manager serves machines and code.
- Privileged access management (PAM): vaults administrator credentials for humans and adds approval workflows, checkout and session recording. Some products cover both jobs.
Secrets manager on the CompTIA Security+ exam
On SY0-801, secrets managers are taught as the long-term fix that pairs with secrets scanning among the mitigating controls in objective 4.1, and as the remedy for hardcoded secrets among the application weaknesses in objective 2.4. Wording such as applications need database passwords without storing them in code, rotate service credentials automatically or keep API keys out of the repository points to a secrets manager or vault. Distractors include environment variables kept in a committed file, Base64 encoding, which is not encryption, a password manager for staff, and an HSM on its own, which protects keys but does not hand application credentials to code.