Password Vault
Technical reference for the PDAccess Password Vault — the credential lifecycle, envelope encryption with a KMS-backed key hierarchy, zero-knowledge injection, and the immutable audit trail around every credential operation.
Overview
The Password Vault is the single source of truth for every privileged credential PDAccess brokers. Credentials live in the vault, are checked out by the proxy engine at session start, and are injected at target authentication — the user never sees the secret. Every operation on every credential is written to an immutable audit trail.
Credential Lifecycle
A credential moves through defined states; every transition is logged with actor, timestamp, and reason.
Created
A credential enters the vault by:
- Manual entry — an administrator adds the current username/password (or key)
- Import — batch import via CSV or API
- Auto-generation — the vault generates a strong secret and pushes it to the target during onboarding
Active
The credential is encrypted at rest and available for checkout by the proxy engine under the target's access policy.
In Use (Checked Out)
At session start the proxy engine checks out the credential. The checkout is scoped to one session: the secret is decrypted in the proxy engine's memory, injected at target authentication, and discarded on session end. A checkout event is written to the audit log with the session ID.
Rotated
Rotation replaces the secret at both the target and in the vault atomically:
- The vault generates a new secret meeting the policy's complexity requirements
- The proxy engine connects to the target with the current credential
- The target's password is changed
- The new secret is encrypted and versioned in the vault
- The previous version is retained as a history entry — restoring it is itself a logged event
Rotation runs on a schedule (daily, weekly, monthly, quarterly) or on an event: breach notice, user departure, or compliance trigger.
Retired
Retirement revokes the credential at the target (password change or key removal) and tombstones it in the vault: the entry remains for audit correlation but can no longer be checked out. Retirement events record the actor and the reason.
Secure Storage
Envelope Encryption
Every credential is encrypted with its own data encryption key (DEK) using AES-256-GCM — authenticated encryption, so tampering is detected, not just possible. DEKs are never stored in plaintext: each is wrapped (encrypted) by a tenant master key held in the KMS/HSM.
The result is envelope encryption:
- Compromise of the vault database alone exposes only ciphertext and wrapped keys
- Decryption requires the KMS — key material never leaves the HSM boundary
Key Hierarchy
| Level | Key | Location | Purpose |
|---|---|---|---|
| L1 | Master key (KEK) | HSM / KMS (never exported) | Wraps tenant keys |
| L2 | Tenant key | KMS, encrypted by KEK | Wraps credential DEKs |
| L3 | Credential DEK | Vault store, wrapped by tenant key | Encrypts the credential (AES-256-GCM) |
Key-hierarchy rotation re-wraps DEKs without re-encrypting credential data. Split knowledge applies: no single operator can extract a plaintext secret without KMS access.
In Transit and In Memory
- Client-to-proxy and proxy-to-target legs are TLS 1.2+ (mTLS where client certificates are provisioned)
- Decrypted secrets exist only in proxy-engine memory for the duration of a session checkout
- Secrets are never written to disk, never returned to API clients, and never appear in logs
Zero-Knowledge Injection
The defining property of the vault: the user never learns the secret.
- The user authenticates to PDAccess with their own identity
- The proxy engine checks out the target credential and performs target authentication server-side
- The session is carried by the proxy; the user's client only ever sees its own authenticated connection to PDAccess
- Shared, standing credentials are eliminated — every session is attributed to a named user
Audit and Activity Logging
Every vault operation is written to an immutable, append-only audit log:
| Event | Recorded fields |
|---|---|
| Credential created / imported | actor, target, source, timestamp |
| Checkout (use) | actor, session ID, target, timestamp, source IP |
| Rotation | actor (system or user), version IDs, success, timestamp |
| Policy change on credential | actor, before/after values, timestamp |
| Retirement | actor, reason, timestamp |
| Failed access attempt | actor, target, denial reason, timestamp |
Log properties:
- Immutable — entries are append-only; deletion is not an operation
- Tamper-evident — the log is hash-chained; a modified entry breaks the chain
- Correlated — checkout events carry the session ID, linking a credential use to its recorded session
- Retained per your data-retention policy, independently of session recordings
Best Practices
- Enable automatic rotation on every credential; treat manual-only credentials as exceptions to review quarterly
- Require MFA on the adapter that fronts the vault — vault access is only as strong as its authentication gate
- Use generated secrets wherever the target allows — stronger than any human-chosen password
- Review failed access attempts weekly — they are the leading indicator of credential stuffing against target systems
- Retire, don't delete — tombstoned credentials keep the audit chain complete