Are backups protected by MFA?
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 |
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.
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
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