How VaultPAM Secures Session Recordings

A recording you cannot trust is not evidence. It may show activity, but it cannot answer the harder questions: was this the recording from this session, has it changed, who has viewed it, and did its handling follow the rules? That is why protecting a recording is more than placing a file in storage. It is an engineering chain that begins at controlled capture and continues through encryption, integrity verification, access decisions, retention, and audit history. This article explains how VaultPAM builds that chain so a recording can be used as accountable evidence rather than treated as an unverified artifact.

For the audit and investigation perspective—the questions a reviewer asks of the finished record—read Session Recording as Audit Evidence. This is the companion view: how the recording is handled so that evidence can be trusted.

Start with the controlled access path

Trust cannot be added only after a session ends. VaultPAM captures recordings through its controlled, browser-based and agentless access path, brokering RDP, SSH, VNC, and HTTP sessions. That path provides the point at which a recording is captured as part of the privileged session.

This matters because evidence has to remain connected to the access activity it represents. The recording is not simply a convenient file to keep; it is a protected record of a session that passed through the controlled path. Everything that follows is designed around the same question: can a reviewer rely on this particular artifact in this particular context?

Encrypt every artifact, and bind it to its context

At rest, each recording artifact is encrypted with AES-256-GCM using its own per-artifact data key. That is envelope encryption: the data key protects the artifact, while a dedicated key-management service wraps the data key. Key material never sits alongside the data it protects.

The separation is deliberate. A recording contains privileged activity, so the protection of its contents should not depend on treating the recording and the key as one package. Envelope encryption separates the encrypted artifact from the key material while allowing each artifact to have its own data key. In plain terms, the artifact is protected with a key made for that artifact, and that key is protected separately.

Encryption alone is not enough if ciphertext can be moved between contexts and accepted as though it belonged there. VaultPAM also authenticates contextual metadata as additional authenticated data: the organization, recording, artifact, and chunk. This is context binding. If ciphertext is moved or re-labeled for another context, decryption fails.

That choice protects the meaning around the bytes as well as the bytes themselves. A reviewer should not have to assume that an encrypted chunk still belongs to the recording, artifact, organization, and chunk context printed next to it. The encryption checks that relationship during decryption.

Remove plaintext only after the protected copy is proven

Secure handling has an important write-path detail: locally captured plaintext is not removed merely because an upload was initiated. It is removed only after the encrypted upload has been persisted and a byte-for-byte decrypt/readback verification has succeeded.

The order is intentional. It avoids treating a request to upload as proof that the protected artifact is available and readable. The persistence condition confirms that the encrypted upload has been stored; the decrypt/readback check confirms the encrypted artifact can be verified byte for byte. Only after both conditions succeed is the locally captured plaintext removed.

This is a small sequencing rule with a large evidentiary consequence. The protected record must be established and checked before the local plaintext is cleared. Otherwise, a failure between capture and verified encrypted persistence could leave an organization unable to rely on the intended recording artifact.

When recording metadata and evidence move between internal services, those calls are mutually authenticated with mTLS. Mutual authentication ensures that the internal parties carrying that recording context authenticate one another.

Make changes detectable, then make verification repeatable

Confidentiality and integrity answer different questions. Encryption protects recording content at rest. Integrity asks whether the recording content still holds together as the recorded session.

VaultPAM protects recording content with a SHA-256 hash chain over recording chunks. It keeps durable integrity manifests, and an offline verification tool can re-check any recording. Together, those elements give a verifier a repeatable way to test recording integrity rather than relying on an assertion that a recording has not changed.

The hash chain makes individual recording chunks part of an ordered integrity check. The durable manifest preserves the information needed for verification, and the offline tool provides a way to perform that check again when evidence is needed. This is useful during routine review, an investigation, or an audit: the integrity question can be answered by verification, not by confidence alone.

Native RDP recording has an additional condition. A frame-integrity sidecar is required, and ingest fails if its verification is not clean. That makes frame integrity a required part of accepting a native RDP recording rather than an optional check performed later.

Control who can see the evidence—and record that access

A protected recording can still create risk if too many people can view or export it. VaultPAM separates the permissions for viewing or replaying a recording from the permissions for exporting or downloading it. Those are distinct actions with distinct authorization decisions.

All recording operations are tenant-scoped. This applies to the operations around recordings, including access to the evidence. The boundary is important because a recording is meaningful only within the organization and recording context it belongs to.

VaultPAM records both successful access and authorization denials in the audit log. The result is a simple but important principle: access to the evidence is itself evidence. A successful replay or export leaves a record, and so does an attempt that is not authorized. This makes the review of recordings accountable without claiming that every person should be allowed to access them.

Retain recordings with operational guardrails

Retention needs to balance evidence availability with a defined lifecycle. VaultPAM offers configurable retention periods of 30, 90, 180, or 365 days. The default is 90 days, with a 7-day grace period.

Reducing a retention period receives additional safeguards. It requires fresh step-up authentication and typed confirmation by a platform admin. The resulting deletions are audited, and deletion honors legal-hold safeguards.

These guardrails focus attention on the change that can shorten the availability of recording evidence. A retention reduction is not handled as an ordinary configuration edit: it requires a fresh authentication step, an explicit typed confirmation, and the platform-admin role. The resulting deletion activity becomes part of the audit history, while legal holds remain a safeguard in the deletion process.

What this means for NIS2 and SOC 2 readers

For NIS2 readers, VaultPAM’s compliance mapping links Article 21(2)(a) to audit trail and session recording for all privileged access, and Article 21(2)(b) to real-time alerting on suspicious privileged sessions and full session replay for incident investigation. The engineering details in this article help explain why a session recording can support that mapping: the record is captured through the controlled path, protected at rest, bound to its context, and capable of integrity verification.

For SOC 2, the current status is precise: Type II audit in progress, report pending 2026. Recording protection should be assessed by the controls that can be demonstrated, including encryption, verification, authorization boundaries, retention guardrails, and audit history—not by a report that has not yet been issued.

For the broader security context around the recording protections described here, see VaultPAM’s security page.

Evidence should be testable, not merely stored

The result is not a promise that a stored recording is trustworthy simply because it exists. It is a set of checks and boundaries: controlled capture, per-artifact envelope encryption, authenticated context, verified encrypted persistence before local plaintext removal, hash-chain verification, distinct access permissions, tenant-scoped operations, and governed retention.

That is the engineering standard behind a recording that can carry evidentiary weight. When the question is what happened in a privileged session, the answer should rest on a record whose content, context, access, and lifecycle can all be examined. That is how session recording becomes evidence an organization can rely on.