Documentation

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.

Password Vault

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:

  1. The vault generates a new secret meeting the policy's complexity requirements
  2. The proxy engine connects to the target with the current credential
  3. The target's password is changed
  4. The new secret is encrypted and versioned in the vault
  5. 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

LevelKeyLocationPurpose
L1Master key (KEK)HSM / KMS (never exported)Wraps tenant keys
L2Tenant keyKMS, encrypted by KEKWraps credential DEKs
L3Credential DEKVault store, wrapped by tenant keyEncrypts 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:

EventRecorded fields
Credential created / importedactor, target, source, timestamp
Checkout (use)actor, session ID, target, timestamp, source IP
Rotationactor (system or user), version IDs, success, timestamp
Policy change on credentialactor, before/after values, timestamp
Retirementactor, reason, timestamp
Failed access attemptactor, 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

  1. Enable automatic rotation on every credential; treat manual-only credentials as exceptions to review quarterly
  2. Require MFA on the adapter that fronts the vault — vault access is only as strong as its authentication gate
  3. Use generated secrets wherever the target allows — stronger than any human-chosen password
  4. Review failed access attempts weekly — they are the leading indicator of credential stuffing against target systems
  5. Retire, don't delete — tombstoned credentials keep the audit chain complete