Credential Vaulting
Checking access...
Credential vaulting is the foundational capability of any PAM program. A credential vault securely stores privileged passwords, SSH keys, API tokens, and other secrets in an encrypted repository, then manages their lifecycle — checking credentials out on demand, rotating them after use, and maintaining a complete audit trail of every access.
Without credential vaulting, privileged credentials are stored in spreadsheets, shared via email, hardcoded in scripts, or memorised by administrators — all of which create unacceptable security risk.
Vault Architecture
Core Components
┌──────────────────────────────────────────────────────┐│ CREDENTIAL VAULT │├──────────────────────────────────────────────────────┤│ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ ││ │ Encrypted │ │ Access │ │ Rotation Engine │ ││ │ Storage │ │ Control │ │ │ ││ │ (HSM) │ │ Engine │ │ - Scheduled │ ││ └──────────┘ │ ┌─────┐ │ │ - On-checkout │ ││ │ │PEP │ │ │ - On-demand │ ││ ┌──────────┐ │ │PDP │ │ └──────────────────┘ ││ │ Audit │ │ └─────┘ │ ││ │ Engine │ └──────────┘ ┌──────────────────┐ ││ └──────────┘ │ Session Proxy │ ││ │ (optional) │ ││ ┌──────────┐ └──────────────────┘ ││ │ API & │ ││ │ CLI │ ││ └──────────┘ │└──────────────────────────────────────────────────────┘| Component | Function | Examples |
|---|---|---|
| Encrypted Storage | Stores credentials at rest using AES-256 or stronger | HSM-backed database, encrypted filesystem |
| Access Control Engine | Enforces who can access which credentials and under what conditions | RBAC, approval workflows, time-based access |
| Rotation Engine | Automatically changes passwords/keys according to policy | Scheduled rotation, post-checkout rotation |
| Audit Engine | Logs every credential access, rotation, and management action | SIEM integration, immutable audit log |
| Session Proxy | Optionally proxies privileged sessions through the vault | No direct network connectivity to targets |
| API & CLI | Programmatic access for automation and integration | REST API, SDK, CLI tools |
Vault Deployment Models
On-Premises Vault
The vault is deployed within the organisation’s data centre.
| Pros | Cons |
|---|---|
| Full control over security and compliance | Requires infrastructure management |
| Air-gapped deployment possible (no external connectivity) | Scaling requires additional hardware |
| Complete data sovereignty | Higher operational overhead |
Cloud-Hosted Vault (SaaS)
The vault is provided as a managed service by a PAM vendor.
| Pros | Cons |
|---|---|
| No infrastructure management | Data stored in vendor’s cloud |
| Automatic scaling and high availability | Requires network connectivity to cloud |
| Vendor handles patching and compliance | Potential vendor lock-in |
| Built-in HA/DR | Data sovereignty considerations |
Hybrid Vault
Credentials are distributed across on-premises and cloud vaults with synchronisation.
Best for: Large enterprises with both on-premises and cloud infrastructure that need unified credential management across environments.
Tip
Most enterprises should start with a cloud-hosted PAM solution for their primary internet-facing infrastructure and add on-premises vaults for legacy systems that cannot connect to cloud services. Avoid managing the vault infrastructure yourself unless you have dedicated PAM operations staff.
Password Rotation Policies
Rotation Triggers
| Trigger | Description | When to Use |
|---|---|---|
| Scheduled rotation | Password changed on a regular cadence (e.g., every 30, 60, 90 days) | Service accounts, standard admin accounts |
| On-checkout rotation | Password rotated immediately after each checkout | High-risk accounts, shared admin accounts |
| On-demand rotation | Password rotated when manually requested | Emergency rotation, suspected compromise |
| Event-based rotation | Password rotated in response to a specific event (HR termination, security incident) | User-specific privileged accounts |
Rotation by Account Type
| Account Type | Recommended Rotation | Notes |
|---|---|---|
| Local admin | On-checkout or every 30 days | LAPs manages unique password per machine |
| Domain admin | Every 30 days + on-checkout | Critical accounts — most aggressive rotation |
| Service account | Every 90 days or managed by gMSA | Verify no service interruption before rotation |
| Application account | Every 90 days or per compliance requirement | Coordinate with application owners |
| SSH key | Every 180 days or key replacement | Rotate public key + deploy new key |
| Cloud IAM access key | Every 90 days | Cloud provider key rotation |
| Break-glass account | Immediately after each use | Emergency accounts must be rotated after every access |
SSH Key Management
SSH keys present unique management challenges because they are not centrally managed by design — each key pair is generated independently by the administrator.
SSH Key Lifecycle
SSH Key Discovery
Scan all systems for authorized_keys files, known_hosts files, and key pairs in user home directories. Identify orphaned keys (no corresponding user), shared keys (same key on multiple systems), and keys with no expiry.
SSH Key Inventory
Create a central registry of all authorised SSH keys with metadata: owner, purpose, creation date, expiry date, systems accessed, and last-used timestamp.
SSH Key Rotation
For each key pair: generate new key, deploy public key to authorised systems, verify connectivity, remove old public key, and archive old key pair for audit purposes.
SSH Key Monitoring
Continuously monitor for:
- New unauthorized key pairs appearing on systems
- Key pairs used from unexpected locations or at unusual times
- Keys not present in the central registry (rogue keys)
- Key pairs associated with terminated employees
SSH Key Management Best Practices
| Practice | Implementation |
|---|---|
| Centralised key management | Vault-like solution for SSH keys with automated rotation |
| Remove key-based root access | Require vault checkout for root access — no standing SSH keys for root |
| Short-lived certificates | Use SSH certificates (signed by a CA) instead of raw key pairs for automation |
| Key usage monitoring | Log every SSH key authentication with source IP, timestamp, and target system |
| Orphaned key cleanup | Quarterly scan for keys without corresponding active users |
| Key expiry enforcement | Set maximum key lifetime (180 days recommended) |
Secrets Management
Secrets management extends vaulting beyond passwords to include API tokens, database connection strings, certificates, and other sensitive configuration data used by applications and automation.
Secrets Management vs PAM Vaulting
| Characteristic | PAM Vault | Secrets Manager |
|---|---|---|
| Primary users | Human administrators | Applications and automation |
| Access pattern | Interactive checkout | Programmatic API call |
| Credential types | Passwords, SSH keys | API keys, connection strings, certificates |
| Rotation trigger | Scheduled, on-checkout | Scheduled, dynamic (pre-rotation) |
| Cache/buffer | Minimal | Client-side caching for performance |
| Integration | RDP, SSH, web portals | CI/CD, Kubernetes, application code |
Vault Operational Best Practices
| Practice | Rationale | Priority |
|---|---|---|
| Defense in depth | Vault encryption + HSM + access controls — any single control can fail | Critical |
| Zero-standing credentials | No user should have permanent knowledge of a privileged password | Critical |
| Approval workflows | Require at least one approver for high-risk credential access | High |
| Justification required | Users must provide a ticket or reason for each credential checkout | High |
| Automatic rotation after checkout | Ensures each checkout gets a fresh credential | High |
| Session proxy | Prevent direct network connectivity to managed systems | High |
| Vault health monitoring | Monitor vault availability, sync status, and capacity | Medium |
| Disaster recovery | Replicate vault to secondary site with failover capability | Medium |
| Regular DR testing | Test failover, restore, and break-glass procedures at least annually | Medium |
Danger
The vault is a single point of failure for privileged access management. If the vault goes down, administrators cannot access credentials to manage systems. Deploy the vault in a highly available configuration with geographic redundancy, and maintain an offline break-glass procedure as the ultimate fallback.
Key Takeaways
- Credential vaulting is the foundational PAM capability — it securely stores privileged credentials, manages their lifecycle, and provides a complete audit trail
- Vault deployment models include on-premises (full control but high overhead), cloud/SaaS (managed but data sovereignty considerations), and hybrid (best for mixed environments)
- Password rotation should be triggered by schedule, checkout, on-demand, or events — with rotation frequency determined by account type and risk level
- SSH keys require dedicated management (discovery, inventory, rotation, monitoring) because they are decentralised by design and easily orphaned
- Secrets management extends vaulting to application credentials (API keys, connection strings, certificates) with programmatic access patterns suited for CI/CD and automation
- Operational best practices include zero-standing credentials, approval workflows, automatic rotation, session proxying, and regular DR testing — treat the vault as a critical system requiring high availability