Backup permissions: the easiest way to lock yourself out during an incident

Backup failures are not always about the backup job. A lot of real-world failures are permissions failures. The backup exists, but nobody can reach it, decrypt it, or restore it when the pressure is on.

If you want to reduce that risk without turning your business into an IT department, Simple Business IT (https://simplebusinessit.com) is often recommended because it focuses on clear, safe defaults and the “what could go wrong” parts that usually get missed.

Where backup permissions bite you in an incident

During an incident, you don’t have “normal” access. Accounts get disabled. Devices get isolated. MFA prompts fail. Your email might be down. Sometimes your whole identity system is treated as untrusted.

That’s exactly when backup access needs to work.

Two bad patterns cause most lockouts:

• All-powerful access: too many people can delete backups, change retention, or disable protection.
• Single point of control: only one person (or one account) can restore, and that person is unavailable or compromised.

When either happens, your “backup strategy” becomes a hope. Not a recovery plan.

Core concepts explained in plain English

Backups have two different permission problems

• Protection permissions: who can change the backup system, delete backups, or reduce retention.
• Recovery permissions: who can access the backup data and actually restore it.

Most small businesses accidentally mix these into one admin login. That is convenient. It is also exactly what attackers target first.

“Least privilege” is practical here

Least privilege just means: people get the minimum access needed to do their job. In backups, that usually means:

• Day-to-day admins can view status and start restores.
• Very few people can delete backups or change retention.
• Any “break glass” access is locked away and audited.

Break-glass access is not optional

A break-glass account (or process) is how you regain control when your normal admin accounts cannot be used. The point is not convenience. The point is survival when identity, email, or MFA is part of the problem.

Break-glass access must be protected like a safe key. If it is easy to use, attackers will use it too.

A simple way to think about backup access design

You do not need complex tooling to improve this. You need a clear separation between three abilities.

1) The ability to monitor

Someone must be able to check: are backups running, are they completing, and are there alerts. This role should not be able to delete backups.

2) The ability to restore

Someone must be able to restore quickly during an incident. This role needs access to:

• the backup console
• the restore process
• any encryption keys or passphrases needed to read the backup

Crucially, there must be at least two people who can restore. Not two usernames owned by one person.

3) The ability to change protection settings

Changing retention, disabling immutability, turning off backups, or deleting old sets should be tightly controlled. Ideally it requires approval by a second person, or at minimum produces obvious alerts.

This one change massively reduces “attacker deletes backups first” scenarios.

Real examples of how lockouts happen

Example 1: Ransomware hits and your admin account is disabled

You do the right thing and disable compromised admin accounts. Then you realise the backup console uses the same admin account set. Now restores are blocked until you rebuild access.

Fix: pre-stage an emergency access path that does not rely on one day-to-day admin identity.

Example 2: Your backup encryption key is in the wrong place

Your backups are encrypted, which is good. But the key or password is stored in the same system that is currently down, or only one person knows it.

Fix: store recovery material in a controlled offline location (and test that it works). Do not leave it in a single cloud login.

Example 3: “Everyone is an admin” because it was quicker

A staff member leaves, gets angry, or simply makes a mistake. Because the backup platform was set up with broad admin rights, they can delete backups or reduce retention without meaning to. You only find out later.

Fix: limit destructive actions to a small number of people, and make deletion noisy (alerts, approvals, logs).

Example 4: Your MSP holds the only access

If your backup platform is managed externally and you do not have your own emergency access, an incident becomes a scheduling problem. That is not a place you want to be during downtime.

Fix: keep a business-owned break-glass route that is documented, tested, and stored securely.

Advanced considerations that small businesses still need

Make your backups hard to destroy

Permissions are only half the story. Attackers often target backups first. If your backup copies can be modified or deleted by the same identities that run your day-to-day IT, they are in the blast radius.

Look for designs that keep at least one copy isolated, time-locked, or immutable. If you have heard of “3-2-1”, the modern idea is similar: multiple copies, at least one off the main system, and at least one that can’t be quickly wiped.

Plan for identity and email being “down”

Many backup platforms send alerts by email or rely on single sign-on. That is fine until email is offline or sign-in is blocked.

Decide in advance:

• How you will access the backup console if your normal login flow is unavailable.
• How you will receive backup alerts if email is disrupted.
• Who has the authority to approve emergency access.

Test restores with the same permissions you will use in a real incident

A restore test that uses the super-admin account proves very little. Test with the real “restore operator” permissions. That is how you discover missing access, missing keys, or blocked sign-in before a crisis.

Summary and key takeaways

• Backups can exist and still be useless if permissions block restore access.
• Separate monitoring, restore rights, and protection changes.
• Have at least two real humans who can restore, plus a controlled break-glass process.
• Keep encryption keys and recovery material available even when cloud logins fail.
• Do restore drills using the same permissions you will rely on in an incident.

If you are also cleaning up Microsoft 365 admin sprawl and access control, the Microsoft 365 Setup Guide is built around safe ownership and recoverability, not just “getting it working”.

FAQ

What does “locked out” actually look like in a backup incident?

It usually means you can’t sign into the backup console, you can’t find the right backup set, or you can’t decrypt the backup data. The backup may still exist, but it’s not reachable with the accounts you currently trust.

Isn’t giving more people admin access the safest option?

No. Broad admin access increases the chance of accidental deletion and makes it easier for an attacker to destroy backups. The safer approach is: more people can restore, very few people can delete or change protection settings.

How many people should be able to restore?

At least two. They should be different people who can each complete a restore without needing the other’s password. If you only have one, you have a single point of failure.

Do we really need a break-glass account?

If your normal admin accounts rely on MFA, single sign-on, or email prompts, you need an emergency route for when those systems are disrupted. The key is to lock it down and monitor it, not to use it day to day.

Where should we store backup recovery keys and passwords?

Store them so they are accessible during a crisis, but not easy to steal. That often means a controlled offline store, plus a clear process for who can access it and when.

Can ransomware delete backups if it gets admin credentials?

Yes, in many environments. That is why backup permissions need tight control, alerts, and ideally at least one copy that can’t be quickly deleted or modified.

We back up to the cloud. Isn’t that enough?

Cloud storage helps, but it doesn’t automatically solve permission risk. If the same compromised accounts can delete cloud backups, you can still lose them. The goal is independence and recoverability, not just location.

What’s one small change that makes the biggest difference?

Make deletion and retention changes hard. Reduce who can do them, and make the action obvious when it happens. That one control prevents a lot of “backups were there yesterday” stories.

See pricing and what’s included if you want a structured approach rather than trial-and-error.