Ransomware crews do not need a novel exploit if they can log in as you. They phish a password, reuse it on email or VPN, turn off security tools, and encrypt what they can reach. If the backups sit on the same network, with the same credentials, they encrypt those too. The business then pays, or pretends it can rebuild from memory.
Two controls still change that math: multi-factor authentication on the accounts that matter, and backups you can restore without the attacker's permission. Neither is a security program. Both are why many incidents stay an inconvenience instead of an outage.
MFA is useful because most initial access is still identity. Email, VPN, remote desktop, cloud consoles, and privileged admin accounts are the doors. A second factor — a phishing-resistant passkey or hardware token where you can, an authenticator app where you cannot — stops a large share of password replay. That maps to identity-based access control in NIST SP 800-53 (IA-2 and related), to multi-factor requirements in NIST SP 800-171, and to HIPAA's technical safeguard expectation that access to electronic PHI is not password only in practice.
MFA does not stop ransomware that already has a foothold. It does not stop malware a user ran locally. It does not save you if session tokens are stolen and you never notice. It does not replace least privilege, patching, or logging. If MFA is only on webmail and the real path in is an exposed RDP box with a shared local admin password, you did not implement MFA. You implemented a checkbox.
Backups are the other half. Encryption is reversible if you have a clean copy and a way to bring it back. That is contingency planning, not heroics: NIST CP-9 and CP-10, HIPAA contingency and data backup plans, and the simple operational test — restore a file, then a system, on a calendar, with a name next to the result. A backup that has never been restored is a rumor.
Periodicity matters. Nightly is a starting point for files people change every day; less often is a decision you should be able to defend. Copies must exist in more than one place, and at least one copy must be offline, immutable, or on an account the domain admin cannot silently wipe. Mapped backup drives and the NAS everyone can see are not offsite. They are a second target.
Backups do not prevent the first encryption. They do not replace incident response. They do not help if the only restore path is a cloud console the attacker already controls. They do not satisfy a reviewer if you cannot show the last successful restore, what was in scope, and who owns the job when it fails at 2 a.m.
For federal, defense, and healthcare teams, this is table stakes. Put MFA on remote access and privileged roles first, then everyone else. Separate backup administration from day-to-day domain admin. Write the restore test into the program — frequency, owner, evidence — instead of a slide that says we backup. If you cannot name the last restore, you do not have a backup program. You have a hope.
Governance Guard Cyber does not run a SOC or a ransomware retainer. We help organizations write these controls into a program a reviewer can follow: who is covered, what is in scope, how often, and what evidence you keep. If that is the gap, request a consultation.