Glossary

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.

Rudratic glossary

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 .pem files 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

  1. OWASP Cheat Sheet Series: Secrets Management Cheat Sheet
  2. NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations
  3. AWS IAM User Guide: Security best practices in IAM
  4. OWASP: Non-Human Identities Top 10

Related terms