They should treat them as complementary, but if one comes first it should be phishing-resistant MFA on the highest-risk access paths. Immutable backups limit damage after compromise, but they do not stop initial entry. Strong identity controls reduce the chance that ransomware affiliates can reach the recovery layer in the first place.
How MFA and immutable backups actually divide ransomware risk
Phishing-resistant MFA protects the door, while immutable backups protect the exit. Ransomware crews usually need some combination of valid access, privilege, and persistence before they can encrypt production systems or sabotage recovery. If you can reduce account compromise on the highest-risk paths, you make it harder for them to reach backup consoles, admin tools, and recovery workflows in the first place.
Immutable backups still matter because ransomware is a destruction and extortion problem, not just an access problem. They shorten recovery time and reduce the leverage of backup deletion or encryption, but they do not stop initial intrusion, lateral movement, or credential abuse. That is why the right order is usually identity first on exposed access paths, then durable recovery controls.
Why identity controls usually deserve the first move
Most ransomware incidents that become operationally severe begin with weak authentication, stolen credentials, or abused remote access rather than a direct assault on backups. High-risk paths include VPNs, remote desktop, privileged admin portals, help desk resets, and any account that can touch backup infrastructure or virtualization layers. A strong MFA rollout on those paths reduces the chance that an attacker can get to the controls that would let them disable recovery.
That is especially true when MFA is phishing-resistant, because adversaries do not just guess passwords anymore, they replay tokens, coerce push approvals, or steal session material. A simple second factor helps, but it is weaker than passkeys or hardware-backed methods against modern ransomware entry chains. If the question is “which first”, the practical answer is to harden the identities that can open the recovery path before assuming backups will absorb the damage.
For a practitioner view of why phishing-resistant sign-in and recovery matter, Workforce Identity Security Guide and Passwordless and Passkeys Guide are the most direct references in the supplied corpus.
What immutable backups do well, and where they stop
Immutable backups are a resilience control. They help if ransomware encrypts servers, wipes snapshots, or attempts to destroy restore points, because the backup copy cannot be easily altered during its retention window. That makes them essential for recovery planning, especially where downtime is expensive or systems are too large to rebuild quickly.
The limit is that immutability is only useful after you still control the backup environment and know what to restore. If the same credentials or admin paths can access both production and backup systems, the backup layer can become part of the blast radius. In practice, the backup strategy only works as designed when access to backup administration is tightly separated, monitored, and difficult to abuse.
That separation is why backup resilience should be paired with account hardening, not used as a substitute for it. The recovery plan should assume some percentage of user and admin accounts will be probed, phished, or stolen during a campaign.
What ransomware teams should prioritise in sequence
Start with the accounts that can change identity settings, remote access policy, backup policy, or hypervisor and storage administration. Those are the paths most likely to convert a single compromised credential into a full recovery failure. Then harden the backup plane itself, including immutable retention, offline or logically isolated copies, and restore testing from clean credentials.
Next, reduce the chance of credential replay and account takeover on common entry points such as VPN, SSO, privileged portals, and help desk workflows. If an environment still relies on legacy authentication or push-based approvals for sensitive access, treat that as a near-term exposure rather than a deferred improvement. The control order should follow the likely attack path, not the order in which tools are easiest to buy.
In the context of access path hardening, MFA Guide and NIST SP 800-63 Digital Identity Guidelines support the case for phishing-resistant authentication on the highest-risk paths first.
Risk and Threat Considerations
Ransomware is dangerous here because the same access that lets an attacker encrypt systems can often be reused to damage backups, disable alerts, or lock out administrators. If identity paths are weak, immutable backups may still survive technically, but the organisation can lose the clean credentials or time needed to reach them during an incident.
Failure mechanism: Attackers gain valid access through phishing, password reuse, token theft, or weak remote access, then pivot into backup administration or recovery infrastructure before defenders can respond.
Impact: Recovery slows, restoration points may be lost or delayed, and the business can face longer outage windows, higher extortion pressure, and a larger blast radius than backup immutability alone would suggest.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 provides the primary governance reference for this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Ransomware commonly abuses external or third-party access paths. |
| IA-5 — Authenticator Management | The answer depends on preventing stolen or replayed credentials from opening recovery paths. | |
| AC-6 — Least Privilege | Backup and admin access should be separated to limit ransomware blast radius. | |
| Recommendation — Require strong authentication for all non-organizational access paths. Rotate, protect, and retire authenticators that can reach backup or admin systems. Limit backup and recovery privileges to the smallest necessary set of accounts. | ||
Practitioner Guidance
What to prioritise: Put phishing-resistant MFA on privileged remote access, administrative portals, and any path that can alter backup or recovery settings before you treat backup immutability as sufficient protection.
What to verify: Confirm that backup administration is not reachable with the same standing credentials used for day-to-day IT work, and that restore tests can be executed from a clean administrative context.
Decision rule: If one access path can both reach production and disable recovery, secure that path first. If the environment already has strong sign-in controls, move faster on immutable retention and recovery testing so the backup layer is not just theoretical.
Practitioner takeaway: Backups reduce the cost of compromise, but identity controls reduce the chance of compromise reaching the recovery layer, so the first investment should usually be the control that closes the attacker’s shortest path to backup administration.
Related resources from NHI Mgmt Group
- Should organisations prioritise external exposure or internal credential governance first?
- Should organisations prioritise HTTPS, MFA, or certificate management first against MITM?
- Should organisations prioritise MFA or compromised-credential screening first?
- Should organisations prioritise phishing-resistant MFA or SaaS audit logging first?