5.3 Object Versioning, Retention Policies & Storage Quotas

5.3 Object Versioning, Retention Policies & Storage Quotas

Quick Answer: The CyberArk Digital Vault preserves an immutable history of every credential change and file modification through Safe Object Versioning. Safes can be configured under two primary retention policies: Retention by Days (e.g., retain all versions created within the past 30 days) or Retention by Versions (e.g., retain the last 5 versions regardless of age). Deleted objects enter a soft-deleted state and can be restored using the Undelete action until the Vault's nightly background maintenance process (PurgeSafeHistory) permanently expunges them. Enforcing Storage Quotas on Safes prevents disk exhaustion on the Vault host, which is particularly critical for high-volume PSM recording Safes.

---

The Mechanics of Safe Object Versioning

Within the Digital Vault, credentials and files are stored as structured objects on the NTFS volume under the Vault's encrypted Safe directory structure. When a password is changed—whether through automated CPM rotation, administrative reconciliation, or manual user input—the Vault does not overwrite the existing data. Instead, it generates a new, sequentially numbered, immutable version of that object ($V_1, V_2, V_3, \dots, V_n$).

Architectural Purpose of Versioning

• Operational Rollback: If a target service fails after a password change (e.g., an application fails to ingest a new database password), administrators can inspect previous versions to identify the prior working credential and restore service connectivity.
• Forensic Auditing: Security investigators can determine the exact password that was active on any target system at any historical timestamp, correlating Vault access logs with target system events.
• Tamper Evidence: Historical versions are cryptographically encrypted under the Safe Key and cataloged in the Vault database, preventing retroactive modification.

---

Safe Retention Models: Days vs. Versions

When configuring Safe Properties in the PVWA or PrivateArk Client, administrators select one of two primary retention models governing how long historical versions are preserved:

Model 1: Retention by Days ("Save account versions for X days")

• Mechanism: The Vault retains all versions created within the last X days (default: 7 days; enterprise standard: 30 to 90 days). Once a version's creation timestamp falls outside this sliding window, it becomes eligible for purging.
• High-Churn Risk: If an enterprise implements One-Time Passwords (OTP) or check-in/check-out policies where an account rotates several times per day, a 30-day retention policy will cause hundreds of versions to accumulate for a single account, leading to significant database and disk bloat.

Model 2: Retention by Versions ("Save the last X versions of each account")

• Mechanism: The Vault retains a fixed number of historical versions (e.g., the last 5 versions) for each object. When version 6 is generated, the oldest version (version 1) is immediately flagged for purging, regardless of whether it was created yesterday or two years ago.
• Operational Benefit: Provides a predictable, capped storage ceiling per account object, making it the ideal retention model for frequently rotated service accounts and high-churn OTP environments.

---

Soft Deletion, Undeleting Objects & The Purge Process

When an account or file object is deleted from a Safe in PVWA, the Vault executes a soft deletion rather than an immediate physical wipe from the storage volume.

The Soft Deletion Lifecycle

1. Active Deletion: A user with the "Delete accounts" permission deletes an account in PVWA. The object disappears from standard inventory views.
2. Retention Staging: The Vault marks the object header as deleted and records the deletion timestamp. The object remains physically on disk within the encrypted Safe folder and continues to occupy storage against the Safe quota.
3. Undelete Capability: During the retention window (e.g., 30 days), an authorized administrator can open the Safe in the PrivateArk Client or PVWA, select "View Deleted Objects", and execute the Undelete command. The object, its full version history, and its associated metadata are restored instantly without requiring backup media.
4. The Purge Process (PurgeSafeHistory):
   • The Digital Vault executes scheduled background maintenance daily (configured in DBParm.ini, typically running at 01:00 AM).
   • The maintenance engine scans every Safe and identifies all soft-deleted objects and historical versions whose age exceeds the Safe retention policy.
   • These objects are permanently expunged from the database catalog and their encrypted files are wiped from the NTFS disk volume.
   • Irreversibility: Once an object is purged by the maintenance engine, it cannot be undeleted. It can only be recovered by restoring the entire Vault database and storage volume from external backup media (PAReplicate).

---

Safe Storage Quotas & Vault Capacity Planning

Every Safe can be configured with an explicit Storage Quota (measured in Megabytes or Gigabytes) or set to unlimited capacity. Enforcing quotas is an essential operational safeguard on production Vaults.

Quota Exhaustion Failure Mode

When a Safe reaches 100% of its assigned storage quota:

• Existing credentials can still be retrieved and used for PSM connections.
• All write operations are blocked. Any attempt to onboard new accounts, modify account properties, or upload files will fail.
• CPM Rotation Failure: Central Policy Manager password changes will fail with a "Safe is full" error because the CPM cannot write the newly generated credential version to the Safe.

Monitoring and Event Notification Engine (ENE)

Administrators configure threshold alerts via the Event Notification Engine (ENE). When a Safe reaches warning thresholds (typically 85% and 95% capacity), the Vault issues automated notifications to PAM administrators, prompting proactive quota expansion or version cleanup.

---

Managing High-Capacity Safes: The PSM Recordings Challenge

In CyberArk architecture, the most significant threat to Vault storage volume capacity comes from Privileged Session Manager (PSM) recordings.

Architectural Best Practices for PSM Recording Safes

1. Never Retain Recordings Indefinitely in the Vault: Storing years of session recordings on the Vault storage volume degrades database indexing, slows disaster recovery replication (PADR), and risks catastrophic storage exhaustion on the Vault host.
2. Partitioning Recording Safes: Modern deployments automatically rotate recording Safes on a monthly or quarterly basis (e.g., PSMRecordings_2026_01) to prevent individual Safe sizes from exceeding optimal limits.
3. External Archiving & Offloading: Organizations requiring multi-year compliance retention (such as PCI-DSS 7-year mandates) must deploy automated archiving solutions that extract completed session recordings from the Vault and transfer them to hardened external cold storage (e.g., AWS S3 Glacier, Azure Archive, or enterprise SAN/NAS storage).

---

Time-of-Use Restrictions on Safe Access

Retention controls how long data survives; time-of-use restrictions control when a Safe may be opened at all. They are configured in the PrivateArk Administrative Client rather than the PVWA, on the Safe's Restrictions tab, and they are the reason a Safe that worked perfectly at 3 p.m. can be inaccessible at 3 a.m.

The tab offers two settings:

A second control on the same tab defines whether there is a delay between when a Safe is opened and when it can be accessed, specified in minutes. This is a deliberate friction control for extremely sensitive Safes: it removes the possibility of an attacker who has just compromised a session grabbing a credential instantly, and it gives monitoring a window in which to alert.

Time restrictions also exist at the user level, set on the Vault user object, and the two stack. A user restricted to business hours cannot reach a Safe open around the clock, and a user available around the clock cannot reach a Safe restricted to business hours. The error message distinguishes them: ITATS102E — "User is unable to logon due to preset time restrictions" points at the user object, while a Safe-level block reports that the Safe is unavailable. Diagnosing "access denied outside working hours" tickets starts with deciding which of the two produced the message.

Because these restrictions are enforced by the Vault itself rather than by the PVWA, they apply uniformly to every access path — PVWA, PrivateArk Client, PACLI, and REST — which is what makes them a genuine control rather than a UI convenience. The corollary is that a service identity such as the CPM user must never be scoped by a restrictive window, or scheduled rotation will fail silently outside the permitted hours.