Are backups secured with different access credentials from administrator credentials?
This question is asking whether a single compromised administrator can both cause the disaster and remove the recovery from it.
What the carrier is actually asking
The carrier is asking about credential separation between the production environment and the backup environment. Not merely different passwords, but different accounts, held by different identities, ideally in a different trust boundary, so that compromise of one does not grant the other.
Why it is underwritten
Shared domain credentials between production and backup is the configuration that produced many of the worst ransomware recoveries on record. The attacker escalates once, and both the systems and their backups are inside the same blast radius. Carriers ask because it is the difference between a recoverable event and a total loss.
Where the answer lives in Microsoft 365, Entra ID, and Azure
The cloud half of the separation is measurable through role assignments and tenancy. The on-premises half is attested.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Azure | Role assignments on the backup subscription or resource group | Identities that administer backup are distinct from those that administer production workloads |
| Entra ID | Group membership behind the backup roles | No nesting that quietly reunites the two populations through a shared parent group |
| Azure | Resource locks and management group placement of the backup scope | Backup resources sit under a scope that production owners do not inherit rights over |
| Entra ID | Whether backup administration is performed with dedicated accounts | Dedicated privileged accounts rather than daily-use accounts with an extra role |
| Backup product | Local service accounts, domain join state, and repository credentials | The backup repository does not authenticate with domain administrator credentials. Attested |
Backup storage in a separate subscription, under a separate management group, administered by accounts that hold no production rights, with a locked immutability policy. Each layer is independently defensible, and together they mean no single credential compromise removes recovery.
What a defensible yes requires
- Backup administration uses accounts that hold no production privilege.
- The backup repository does not authenticate to production directories with privileged credentials.
- Group nesting has been checked, since inherited membership is how separation quietly disappears.
- Backup storage sits in a scope production owners do not inherit.
- The separation is tested rather than designed, by confirming a production administrator cannot reach the backup scope.
How this answer goes wrong
The classic failure is convenience during deployment. The backup server is domain-joined and its service runs as a domain administrator because that made the installation work. Every subsequent control in the backup block is then downstream of a single credential. The second failure is nesting: two separate groups that both belong to an infrastructure group nobody has looked at in years.
Frequently asked
Is a different password on the same account enough?
No. The question is about separate credentials in the sense of separate identities with separate privilege. One account with a strong password is still one account.
Should the backup system be domain-joined?
Preferably not, for the on-premises case. A backup server outside the production domain removes the most direct escalation path, at the cost of some operational convenience.
How does this apply to cloud-only estates?
Through subscription and management group separation, and through distinct role assignments. The principle is identical and the mechanism is easier.
What if our provider manages backups?
Then their access is the credential in question. Ask how it is scoped and authenticated, and treat the answer as part of your third-party access position.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture