--- title: "Are backups protected by MFA?" url: https://insuranceposture.com/questions/backup-and-recovery/backups-protected-by-mfa category: "Backup and recovery" canonical_key: q_bak_004 evidence_state: partial updated: 2026-08-24 --- # Are backups protected by MFA? URL: https://insuranceposture.com/questions/backup-and-recovery/backups-protected-by-mfa Section: Backup and recovery Evidence state: Partly verifiable from your tenant The backup console is the first thing a competent attacker opens. A password alone on that console makes the rest of the backup block irrelevant. ## What the carrier is actually asking The carrier is asking whether administrative access to the backup system requires a second factor: the backup vendor's console, the storage account holding the copies, and the recovery process itself. It is asking about the control plane of recovery rather than about the data. ## Why it is underwritten Ransomware operators delete or encrypt backups before triggering the payload, and the fastest way to do that is to log into the backup product with credentials harvested from an administrator's workstation. An insured with immutable copies and a single-factor backup console has bought a lock and left the key in it. ## Where the answer lives in Microsoft 365, Entra ID, and Azure Where the backup console federates to Entra ID, this is measurable in the same way as any other application. Where it uses local accounts, the evidence comes from the product. | Platform | Where the setting lives | What has to be true | | --- | --- | --- | | Entra ID | Conditional Access covering the backup application, where it federates | An enforced policy requiring a strong authentication strength, with no convenience exclusions | | Azure | Role assignments on the subscription and resource group holding backup storage | A short list of identities, covered by the multi-factor requirement for Azure management | | Azure | Storage account access keys and shared access signatures | Account keys disabled or tightly controlled, since a key bypasses identity entirely and therefore bypasses multi-factor | | Entra ID | Separation between production administrators and backup administrators | Different accounts, ideally different privilege paths, so one compromised session does not reach both | | Backup product | Local console accounts and their authentication settings | Every local account enforces a second factor, including vendor support accounts. Attested | **Storage keys are the bypass** A storage account key or a long-lived shared access signature authenticates without any identity, so no Conditional Access policy applies. If backup storage still has account key access enabled, the multi-factor answer describes only one of the two doors. ## What a defensible yes requires - Every path into the backup console requires a second factor, including local and vendor accounts. - Backup storage is reachable only through identity, with account keys disabled or rotated and tightly held. - Backup administration is separated from production administration. - Deletion of backup data requires an additional step, such as a locked immutability policy or a separate approval. - The separation has been tested by confirming that a production administrator alone cannot destroy the protected copy. ## How this answer goes wrong The gap is usually the service account. Human administrators authenticate with a second factor while a service account with full backup rights runs the jobs and authenticates with a stored password that has not changed since deployment. That account is the one an attacker will find on the backup server itself. ## 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 ### Does this include the storage where backups land? Yes. Protecting the console and leaving the storage reachable by key is a common and complete failure of the control. ### Should backup admins be separate people? Separate accounts at minimum. Separate people is stronger and not always practical. What carriers want is that one compromised session cannot both encrypt production and destroy recovery. ### What about the vendor support account? Ask the vendor how it authenticates and whether it can be disabled between support cases. Standing vendor access to your backup console is an exposure you did not create and still own. ### Is immutability a substitute for this? They are complementary. Immutability protects the data; multi-factor protects the console. An attacker in the console without immutability deletes everything, and with immutability can still disrupt operations. ## Related questions - [Are backups kept offline (disconnected) or immutable / air-gapped?](https://insuranceposture.com/questions/backup-and-recovery/backups-kept-offline-immutable-air-gapped) - [Are backups secured with different access credentials from administrator credentials?](https://insuranceposture.com/questions/backup-and-recovery/backups-secured-different-access-credentials-from-administrator-credentials) - [Is MFA enforced on all privileged / administrative user accounts?](https://insuranceposture.com/questions/multi-factor-authentication/mfa-enforced-privileged-administrative-user-accounts) - [Where are backups stored (on-prem / offsite / offline / MSSP / cloud)?](https://insuranceposture.com/questions/backup-and-recovery/where-backups-stored) --- 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.