Security Overview
This page is an architectural overview — it is not a threat model, security assessment, or certification statement. It describes how VaultPAM is designed and does not constitute a guarantee of security outcomes.
This page describes the principal security properties built into VaultPAM. It is intended for administrators, security reviewers, and evaluators who need to understand how VaultPAM handles access, credentials, encryption, and audit trails.
Zero-Trust Connector Model
VaultPAM connectors establish outbound-only encrypted tunnels to the VaultPAM control plane. No inbound firewall rules or open ports are required on the network where the connector is deployed.
Key properties:
- Connectors initiate all connections to the control plane — the control plane never reaches inward.
- Each connector authenticates to the control plane using a provisioned identity token.
- Session traffic flows through the established tunnel; the control plane acts as the session broker.
- A compromised or deregistered connector cannot be used to re-enter the network — its tunnel credentials are revoked on deregistration.
This model eliminates the need to expose internal resources to inbound internet traffic, reducing the attack surface for the networks where connectors are deployed.
Credential Isolation
VaultPAM stores privileged credentials (passwords, SSH keys, API tokens) encrypted at rest using Vault/OpenBao-managed encryption. Credentials are:
- Never exposed to the end-user browser — the web application and session interface do not transmit plaintext credentials to clients.
- Injected just-in-time into sessions at the point of use — the control plane retrieves and injects credentials into the session channel without surfacing them to the user.
- Scoped by Safe — each credential is associated with a Safe, and access requires an active session policy grant.
Credential access events are logged to the audit trail. Administrators can review which credential was accessed, by whom, and in which session.
Encryption
In Transit
All communication between clients, connectors, and the VaultPAM control plane uses TLS 1.3. TLS 1.2 fallback is disabled by default on control-plane endpoints. Certificate validation is enforced; connectors do not accept self-signed certificates from the control plane unless explicitly configured in isolated/air-gapped deployments.
At Rest
Privileged credentials stored in VaultPAM are encrypted using AES-256-GCM via the Vault/OpenBao encryption layer. Encryption keys are managed by the secrets backend and are not stored alongside the ciphertext. Session recording data stored in object storage is also encrypted at rest using the configured storage-layer encryption (AES-256-GCM where provider-managed encryption is active).
Network Isolation
VaultPAM is designed to minimize lateral movement risk:
- Connector-to-control-plane only — connectors communicate exclusively with the VaultPAM control plane. They do not establish peer-to-peer connections with other connectors or external services.
- No direct user-to-resource connectivity — users do not receive network-level access to the resources behind a connector. All traffic is proxied through the session channel.
- Kubernetes network policy enforcement — in VaultPAM Cloud, Kubernetes network policies enforce default-deny posture between components; explicit allow policies cover only the required communication paths.
These properties prevent a compromised session or connector from being used as a pivot point into adjacent systems beyond what the session itself authorizes.
Session Recording Integrity
VaultPAM session recordings are stored with an integrity hash computed at the point of write. This hash allows administrators and auditors to verify that a recording has not been modified after capture.
- Recordings are written to append-only object storage paths — overwrites to completed recording objects are not permitted by the storage policy.
- Each recording object is accompanied by a metadata record containing the integrity hash.
- The integrity hash is verified during replay and export; a mismatch is flagged and the recording is marked as potentially tampered.
This design supports audit trail integrity requirements without relying on proprietary storage primitives.
Authentication Model
Identity Provider
VaultPAM uses Keycloak as its OIDC identity provider. All user authentication flows go through Keycloak; VaultPAM does not store passwords. OIDC tokens are short-lived and validated on each API request.
Multi-Factor Authentication (MFA)
MFA enforcement is configurable at the realm, group, and policy level in Keycloak. VaultPAM supports:
- TOTP (time-based one-time passwords via authenticator apps)
- WebAuthn / passkey authentication
MFA requirements can be scoped to specific actions (e.g., session launch, credential reveal, administrative operations) via step-up authentication policies.
Break-Glass Access
VaultPAM supports a break-glass policy for emergency access when normal approval workflows are unavailable. Break-glass sessions:
- Require a separate break-glass credential with elevated justification logging.
- Generate an alert to configured notification channels on use.
- Are recorded and flagged in the audit trail for post-incident review.
Break-glass access is designed for exceptional circumstances and is subject to the same recording and audit trail requirements as standard sessions.
Compliance Framework References
VaultPAM's architecture is designed to support regulated environments. VaultPAM is in scope for the following compliance frameworks:
| Framework | Status |
|---|---|
| SOC 2 Type II | In scope |
| ISO 27001 | In scope |
| NIS2 | In scope |
| DORA | In scope |
For framework-specific control mappings, audit reports, or attestation packages, contact your VaultPAM account team.
For questions about VaultPAM security architecture or to request a security review package, contact your VaultPAM account team.