How the Vault Is Provisioned & Locked

A second, genuinely separate storage account

The vault is not a folder or container carved out of a tenant’s existing primary storage. It is configured as its own storage account or bucket, with its own container name, and its own credentials — stored separately from the tenant’s primary storage credentials.

A tenant can point the vault at a different storage account within the same cloud provider, or at the other provider entirely. The only constraint: the vault provider must support a real storage-layer lock, which today means Azure Blob Storage or AWS S3. Google Cloud Storage has no equivalent lock and is not accepted as a vault target.

The three-step provisioning flow

Provisioning happens as three separate steps, each guarded so that the irreversible action can never be a side effect of an earlier one:

1. Consent. An operator explicitly acknowledges, in BYOVault’s own plain-English explanation, that locking is irreversible. This is recorded with a timestamp and the acknowledging operator’s email. No later step will run without it.
2. Configure vault storage. The vault’s storage account, container, and credentials are saved.
   • For Azure, this step also requires a separate management-level credential — distinct from the account name and key used for everyday blob reads and writes — because creating and locking an immutability policy is a management-plane operation, not a data-plane one.
   • Before anything is written, each credential is validated with a read-only check against the storage account or bucket, catching a mistyped key or secret immediately rather than letting it surface only when the irreversible lock step is attempted.
   • This step can be repeated to correct a mistake, right up until the vault is locked.
3. Provision and lock. A single action that creates the provider-side immutability configuration and locks it, back to back. Until this step runs, no lock exists in the cloud provider at all; once it succeeds, the vault’s status becomes Locked and stays that way permanently.

How the lock actually works, per provider

Both mechanisms are the provider’s own native retention-lock feature — not a BYOVault application-level restriction layered on top of ordinary storage.

• AWS S3: a single call enables Object Lock on the bucket (which also enables Versioning, a prerequisite Object Lock brings along automatically) and sets a bucket-default retention rule in Compliance mode, for the chosen number of retention days.
  • Governance mode is never used, because it can be overridden by a sufficiently privileged principal holding s3:BypassGovernanceRetention — that does not meet the requirement that the guarantee hold even against BYOVault or a compromised administrator account.
  • Object Lock can be enabled on an existing bucket (a capability AWS added after Object Lock originally shipped as creation-time-only), so an existing bucket can become a vault without being recreated.
• Azure Blob Storage: a container-level time-based retention policy is created, then locked in a second, immediately following call using the policy’s own ETag.
  • Both calls happen together deliberately: an unlocked policy provides no real guarantee (Microsoft’s own guidance recommends the unlocked state only for short-term testing, since it can be freely shortened or deleted by anyone with sufficient RBAC).
  • So a vault is only ever left in one of two states — no policy, or a fully locked one.

Irreversible in two independent places, not one

Once a vault reaches the Locked status, the guarantee that it cannot be undone is enforced twice, independently:

• At the storage provider. AWS documents plainly that once Object Lock is enabled on a bucket, it cannot be disabled and Versioning cannot be suspended for that bucket. Azure’s locked policy cannot be deleted or shortened by any caller, regardless of permissions — only extended to a longer period.
• Inside BYOVault. Once a vault is locked, BYOVault permits exactly one change to its configuration: extending the retention period further into the future. No operator action, support request, or administrative path shortens or removes a lock that has already been committed.

Vault generations

A tenant can have more than one vault generation over its lifetime, though exactly one is ever active for new writes at a time.

Starting a new generation is only permitted once the current one is fully locked. It cannot be used to abandon a vault that failed or is still mid-provisioning — that generation’s storage configuration can simply be corrected and reused instead.

Starting a new generation deactivates the current one for new writes without touching its lock in any way: it remains locked, remains extendable, and continues to enforce its own already-committed retention period independently for as long as that period requires.

For what happens after locking — extending a locked vault’s retention period — see Extending a Retention Period. For how files actually move into a locked vault, see Archiving. For the wizard-level walkthrough of these same steps, see Provisioning a Retention Vault.