Backup credential security means controlling the passwords, access keys and identities used to create, manage and restore backups. Its purpose is to prevent a compromised account from gaining control of both production systems and the copies needed to recover them. That requires separating access to the backup application, backup storage and recovery environment, including the ways those credentials can be reset.
Different usernames alone do not establish that separation. A production administrator might still be able to reset the backup administrator’s password, retrieve storage keys from a shared vault or take control of the server running the backup software. Each connection can give one compromised identity more reach than the account list suggests.
For backup administrators and infrastructure teams, the useful question is: if this credential is stolen, what else can the attacker reach, change or unlock? Answering it requires following access paths through the environment, beyond the backup console.
What is a backup access path?
An access path is the sequence of permissions and systems that lets someone reach a backup resource. It includes the initial login, any credentials or privileges available after that login, and the controls governing the destination. A path might lead to backup data, storage administration, encryption keys or a restore target.
Consider a backup service account with permission to access one repository. Its direct authority may be limited, but an administrator of the machine using that account may be able to run the backup software under its existing identity. The attacker does not necessarily need to extract the secret as readable text to use its permissions.
Password reset and account recovery create additional paths. If the same corporate identity can unlock every privileged account, unique passwords offer less separation than they appear to provide. An access review therefore needs to cover who can use a credential, who can replace it and who controls the system where it is used.
Separate the jobs that require access
Start by distinguishing the work each identity performs. Reading production data, scheduling backups, managing a storage platform and restoring an application require different authority. The exact permissions depend on the products involved, but those responsibilities should be visible before deciding which accounts can share access.
The following table is a review model, rather than a universal permission policy.
| Access path | Required purpose | Boundary to check |
|---|---|---|
| Production access | Read protected workloads and perform required backup integration tasks | Does this identity also administer backup servers or storage? |
| Backup application administration | Configure jobs, repositories and recovery operations | Can this administrator obtain storage administration or emergency credentials? |
| Repository access | Perform the application’s supported backup and restore operations | Is the credential scoped to the intended storage resources? |
| Storage administration | Manage storage accounts, policies and infrastructure | Is this authority available from the backup server or ordinary workstation? |
| Recovery access | Retrieve protected copies and restore into an approved destination | Can it work when production identities and routine credentials are unavailable? |
| Encryption key administration | Govern keys or passwords needed to decrypt backups | Can the same compromised identity deny both data access and decryption? |
One person may perform several of these jobs in a small IT team. Separate accounts, protected administrative sessions and controlled elevation can still reduce the authority exposed during routine work. However, they provide limited protection if all the credentials remain accessible from the same compromised session.
Keep production identity from controlling backup administration
A dedicated backup administrator account is a useful starting point. Check whether production administrators can reset it, change its group membership or administer the machine where it signs in. Those capabilities may reconnect environments that look separate on a network diagram.
Veeam’s infrastructure guidance illustrates this distinction: it recommends a management domain in a separate Active Directory forest for larger environments, with a separate workgroup as an option for smaller deployments. It also recommends network separation where applicable. The appropriate implementation depends on the environment and supported product features.
The design review should then consider dependencies outside the directory. Who administers the privileged access system? Can endpoint management software push commands to the backup server? Who controls the virtualization platform hosting it? A separate login does not remove authority held through those systems.
Document any shared administration that remains. It may be operationally necessary, but it should be an explicit risk with a recovery plan. Calling the backup environment “separate” without identifying these exceptions makes an incident harder to assess.
Give repository credentials a defined scope
The credential a backup application uses to access storage should have a clear owner, purpose and resource scope. Avoid reusing it for unrelated applications or general storage administration. If it is exposed, the team should be able to identify the affected repositories without tracing an unknown number of shared integrations.
Least privilege must also account for how the backup product actually works. A repository credential may need to read data, manage retention information and delete expired content. Replacing the supported permissions with a generic “write only” policy can break restores or repository maintenance.
Scality’s ARTESCA integration documentation provides a concrete example. Its Veeam configuration uses an IAM user and policy for repository access, and the documented immutable-bucket policy includes object deletion and retention operations. The presence of a delete permission does not, by itself, establish that a protected object version can be deleted before its retention expires. Storage enforcement and the applicable retention mode also matter.
Use the documented policy for the deployed integration, then inspect its resource scope and any additional permissions. Validate backup creation, restore, retention handling and cleanup after changes. A successful connection test establishes much less than a complete operating cycle.
Protect human logins and application secrets differently
Multi-factor authentication helps protect interactive administrator access. An unattended backup job typically uses a service identity, access key or another machine authentication mechanism. Enabling MFA on the console does not automatically add a second factor to every request made with that application credential.
This creates two related tasks: protect how administrators sign in, and control where application secrets can be used. Review secret storage, configuration exports, deployment scripts and support bundles. Avoid copying repository keys into general documentation or leaving them available in ordinary administrator sessions.
The backup server itself deserves particular attention. Veeam documents that an administrator of its backup server can decrypt passwords stored in its configuration database. Encryption of stored credentials therefore does not establish independence from the machine authorized to use them.
A credential inventory should record its owner, authorized resources, consuming systems and replacement procedure. Include certificates and tokens where applicable. The inventory needs to support a practical decision during an incident: which access should be revoked, and what will stop working when it is?
Keep storage administration outside routine backup access
Writing objects to a repository and administering the storage platform are different responsibilities. A backup application needs the operations required by its integration. It should not acquire unrelated authority to create administrators, broaden access policies or manage the underlying infrastructure.
ARTESCA exposes storage management roles alongside IAM users, groups, roles and policies for access to storage resources. That gives teams distinct controls to review. The relevant question is whether the application’s configured identity remains appropriately scoped and whether someone controlling the backup server can obtain broader authority elsewhere.
For example, a storage administrator credential saved in a script on the backup server creates an additional access path even if the repository policy is narrow. The same applies to a vault session that can retrieve both application keys and platform administrator passwords. Evaluate the complete chain from the initial compromise to the highest privilege available.
Network access should support the intended boundary. Permit required backup traffic while restricting management interfaces to approved administration paths. Also examine who can change those network rules; an isolated interface is less useful if the compromised identity can immediately make it reachable.
Understand what immutability protects
Immutability can preserve protected backup data after an application credential is compromised. Its behavior depends on the storage implementation, retention mode and permissions. In Amazon S3, for example, governance retention can be bypassed with the appropriate authorization and request, while compliance retention prevents users, including the account root user, from shortening the retention period or deleting the protected version during that period.
That distinction makes the bypass path part of the credential review. Check both who currently holds the relevant permission and who can grant it. Validate the corresponding behavior on the actual backup storage platform.
Immutability also leaves other recovery dependencies to address. An attacker may stop new backups, interfere with configuration or deny access to a required encryption key. Existing protected data can survive while recovery becomes slower or temporarily unavailable.
Evaluate retention enforcement and recovery access together. The team needs a surviving copy, a way to locate it, the ability to decrypt it and an approved destination for the restore. Each dependency deserves its own access check.
A worked example: three accounts with one failure point
Consider an illustrative IT team using separate accounts for production administration, backup administration and storage management. All three passwords are stored in one vault, and the same corporate sign-in can retrieve them. The team has separated account names, but a compromise of that vault session exposes all three roles.
Moving the backup password into a different vault folder will not resolve the issue if the same session can open both folders. Adding MFA helps protect authentication, but the review must still consider an already authenticated session and the authority available within it. The problem is the reach of that access.
A stronger design could restrict ordinary vault access to routine credentials, require separate controlled elevation for storage administration, and maintain an emergency recovery route outside the production identity dependency. The backup application would use its own scoped repository identity. These are proposed design changes, not evidence of a completed security test.
The team should then test the intended outcome: losing the production administrator account does not grant storage management access, and disabling routine backup credentials does not prevent an authorized recovery operator from restoring a protected test copy. Those results demonstrate more than an inventory containing three different passwords.
Test recovery after credentials are revoked
A normal restore test often uses the existing backup server, saved repository credentials and a working directory service. It verifies that recovery works under those conditions. A credential security exercise should deliberately change the identity assumptions.
In an isolated test environment, use disposable backup data and an agreed recovery procedure:
- Remove routine access. Disable the test identities and repository credentials assumed compromised.
- Open the emergency route. Obtain recovery access without relying on the production sign-in being tested as unavailable.
- Reconnect to the protected copy. Use the vendor-supported recovery process, including required configuration and decryption material.
- Restore and validate. Recover into an isolated destination and confirm that the application or data is usable.
- Close temporary access. Revoke exercise credentials and preserve the audit record.
Record the time needed to obtain access separately from the time spent transferring data. A restore that reads data quickly can still miss its recovery objective because nobody can unlock the required account. Note every dependency that delayed the exercise, including approvals, unavailable staff and missing configuration information.
Credential rotation should receive similar operational attention. Identify consumers before changing a secret, update them through the supported process, verify backup and restore operations, then revoke the previous credential. During a suspected compromise, containment may require immediate revocation and an interruption to jobs; the runbook should make that tradeoff clear.
Make access separation an observable result
Begin with one critical workload and trace its production, backup, storage and recovery identities. Include password resets, vault access, host administration and encryption dependencies. For every shared path, decide whether to remove it, restrict it or document why it remains.
The strongest evidence is a tested boundary: a compromised production identity cannot take over backup administration, a repository key cannot become a storage administrator, and recovery can proceed after routine access is revoked. Those outcomes give the team a concrete basis for trusting its backup design. They also make the next review easier, because there is a recorded behavior to verify after infrastructure or permission changes.