--- title: "Are backups secured with different access credentials from administrator credentials?" url: https://insuranceposture.com/questions/backup-and-recovery/backups-secured-different-access-credentials-from-administrator-credentials category: "Backup and recovery" canonical_key: q_bak_005 evidence_state: partial updated: 2026-08-24 --- # Are backups secured with different access credentials from administrator credentials? URL: https://insuranceposture.com/questions/backup-and-recovery/backups-secured-different-access-credentials-from-administrator-credentials Section: Backup and recovery Evidence state: Partly verifiable from your tenant 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 | **The strongest version of this answer** 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. ## If this answer turns out to be wrong Backup immutability and restore testing are trivially checkable after a ransomware loss, which is why an overstated answer here is one of the few that regularly turns into a coverage argument. Whether anything follows from an inaccuracy depends on materiality, on the policy wording, and on the law of the governing state: [what counts as misrepresentation on a cyber application](https://insuranceposture.com/glossary/misrepresentation). The other consequence terms are collected in the [glossary](https://insuranceposture.com/glossary). ## 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 - [Are backups protected by MFA?](https://insuranceposture.com/questions/backup-and-recovery/backups-protected-by-mfa) - [Are backups kept offline (disconnected) or immutable / air-gapped?](https://insuranceposture.com/questions/backup-and-recovery/backups-kept-offline-immutable-air-gapped) - [Is MFA enforced on all privileged / administrative user accounts?](https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-privileged-administrative-user-accounts) - [Is service provider access to network/data restricted on least-privilege basis, reviewed periodically?](https://insuranceposture.com/questions/third-parties/service-provider-access-network-data-restricted-least-privilege-basis) --- Insurance Posture by SecValley. https://insuranceposture.com The question library is written in our own wording to reflect the control topics that recur across US cyber application and ransomware supplemental forms. No carrier form is republished. SecValley is not a law firm, an insurance broker, an agent, or a carrier, and holds no producer licence. Nothing here is insurance advice, legal advice, or a coverage determination, and no attorney-client relationship arises from reading it. Statements about what a party to a cited case did, knew, or intended are allegations drawn from court filings and contemporaneous reporting, not findings of fact. Your organization's authorized signer remains responsible for the accuracy of any application. Consult a licensed broker and qualified counsel before binding.