Credential vaulting
Also called password vaulting, secrets vaulting, privileged credential vault, secrets management
Credential vaulting is the practice of storing privileged passwords, SSH keys, API tokens and other secrets in an encrypted, access-controlled vault that releases or injects them only under policy, rotates them, and logs every use.
Credential vaulting takes privileged secrets out of spreadsheets, scripts and people’s heads and puts them in one encrypted store. Users and workloads ask the vault for access instead of keeping their own copy; the vault decides, records the request and, ideally, supplies the secret straight into the session so the person never sees it. After use, the credential can be changed so any copy stops working.
How it works
A privileged credential vault usually provides:
- Encrypted storage of passwords, SSH keys, cloud access keys, certificates and API tokens, with the master key kept apart from the data.
- Access policy deciding who may use which secret, for how long, and with whose approval.
- Checkout or injection. A user checks a credential out for a fixed period, or a proxy injects it into the session without revealing it.
- Rotation on a schedule and after each checkout, changed on the target system.
- Audit of every reveal, checkout, rotation and failure.
The OWASP Secrets Management Cheat Sheet recommends centralising and standardising secrets management, applying least privilege so engineers cannot read every secret, automating rotation, using dynamic secrets where possible, and making audit logs resistant to tampering.
Why it matters
Hard-coded and shared credentials are easy to leak and hard to revoke. NIST SP 800-53 Rev. 5 control IA-5 covers authenticator management, including changing default credentials before first use and refreshing them on a schedule, and IA-5(7) forbids embedding unencrypted static authenticators in applications. OWASP’s Non-Human Identities Top 10 lists secret leakage and long-lived secrets among the main risks for machine identities.
Credential vaulting vs short-lived credentials
| Vaulted static credential | Short-lived credential | |
|---|---|---|
| Lifetime | Until rotated | Minutes to hours, then invalid |
| Main control | Vault policy and rotation | Issuing service and expiry |
| Typical use | Servers, databases, network devices, legacy apps | Cloud roles, federated access |
AWS recommends temporary credentials over long-term access keys where possible. Many estates need both: vaulting for systems that only accept static passwords or keys, and short-lived credentials where the platform supports them.
Examples
- A production root password is checked out for 30 minutes and rotated on check-in.
- An engineer opens an SSH session through a proxy that injects the key; the key never reaches the laptop.
- An automation server stores host passwords and
.pemfiles encrypted at rest instead of in scripts.
How SWOT supports it
The Central Vault in SWOT PAM holds passwords, SSH keys, cloud keys and API tokens with AES-256-GCM encryption and the master key kept outside the database. Credentials are checked out for a set time and can be rotated on schedule or on check-in, with a second approver for the most sensitive systems. SWOT Cloud PAM keeps provider credentials encrypted and strips them from proxied calls, and FlowForge encrypts stored host credentials with AES-256-GCM. See DevOps pipelines.
Questions
- Is a credential vault the same as a password manager?
- They overlap but serve different goals. A personal password manager helps one person store their own logins. A privileged credential vault holds shared and system credentials for servers, databases and cloud accounts, controls who may check them out and when, rotates them on the target system, and keeps an audit trail of every reveal and session.
- How often should vaulted credentials be rotated?
- It depends on the credential. System and service credentials are commonly rotated on a fixed schedule and immediately after each checkout, so a revealed password stops working. OWASP notes that user passwords are an exception and should mainly change on suspected compromise. Where a platform supports short-lived credentials, those can replace rotation altogether.
In SWOT
Sources
Related terms
- Privileged access management (PAM)Privileged access management (PAM) is the set of controls and tools that decide who may use administrative access to critical systems, for how long and under what conditions, while keeping the credentials protected and every privileged session on record.
- Non-human identity (NHI)A non-human identity (NHI) is an account or credential used by software rather than a person, such as a service account, API key, workload role, bot or certificate, that lets applications, scripts and services authenticate to other systems.
- Zero standing privileges (ZSP)Zero standing privileges (ZSP) is a security model in which no human or machine identity holds privileged rights by default; elevated access is created for a specific task when requested and approved, then removed when the task or time window ends.
- Session recordingSession recording is the capture of everything that happens during a privileged session, such as keystrokes, commands, queries, screen activity and API calls, in a tamper-evident form that can be searched, replayed and used as audit evidence.


