Storage Account Hardening
BYOVault writes your backed-up content into a storage account you own and control. The account itself is outside BYOVault's ability to secure — but two things about how BYOVault uses it are worth understanding before you touch the credentials protecting it: where those credentials actually live, and what happens to backup efficiency when you rotate them.
Your credentials are not sitting in BYOVault’s database
When you save a storage configuration on a tenant’s Storage tab, the access key or key pair itself is written to a dedicated managed secret store. BYOVault’s own application database holds only a reference to that secret, alongside non-sensitive configuration such as which container or bucket to use — never the credential value.
A database compromise on BYOVault’s side does not, by itself, hand over working access to your storage account. The full detail of this split is covered in Storage Credentials.
This has a practical consequence for access-key hygiene on the provider side: the account key or IAM secret you generate in Azure or AWS is the actual boundary, so it should be scoped as tightly as the provider allows.
- AWS — use an IAM user restricted to
PutObject,GetObject,ListBucket, andDeleteObjecton the specific bucket ARN, rather than a broad S3 policy. BYOVault’s setup guide for AWS S3 walks through this. - Azure — keep the storage account’s access key itself confidential, since that key — not a separately scoped role — is what authorizes every write BYOVault makes, as described in Azure Storage Account.
Rotation is safe for existing data, but not free
Regenerating an access key or replacing an IAM secret does not affect any content already written to your storage account. The credential only authorizes reads and writes against your account; it plays no role in deriving or wrapping the encryption applied to backed-up content. Updating BYOVault’s Storage tab with a new key is, from a data-integrity standpoint, uneventful.
What does change is how the next backup run behaves. Every time a tenant’s storage configuration is saved, BYOVault treats it as a new storage destination — even if you re-enter the exact same account and container details rather than genuinely changing account.
The next backup after any storage save therefore re-downloads, re-encrypts, and re-uploads every item: in effect a full copy of the tenant’s content into the same account, rather than an incremental run. This is covered in more detail in Incremental Backup & Change Detection.
Plan credential rotation with that cost in mind.
- Rotating immediately before a scheduled backup window, or rotating repeatedly within a short period, means paying the full re-upload cost — bandwidth, time, and provider transaction charges — more often than the credential rotation itself requires.
- Rotating on a deliberate, infrequent cadence instead (for example, aligned with a suspected exposure or a fixed organizational policy) keeps that cost proportionate to the actual security benefit.