Backups That Survive Your Own Admins

The most valuable credential in a 200-seat company is not the domain administrator's. It belongs to whoever administers the backup platform. That account can make every copy of the business unrecoverable in a single afternoon — no malware deployed, no files encrypted, no endpoint alert raised.

Something shifted in the ransomware economy while most recovery plans stayed where they were. Encryption used to be the attack. Now encryption is the invoice. The work that actually decides the outcome happens earlier and quieter: get in, find the backup console, and remove the thing that would have let the company say no.

Encryption is loud. Deletion is patient.

Detection tooling has become genuinely good at spotting encryption. Mass file rewrites, shadow copy deletion, unusual process behavior — that is precisely the signal EDR and MDR platforms are tuned to catch. An intruder who intends to be paid has every reason to delay that stage as long as possible.

Consider an alternative path that requires no exploit at all. This is an illustrative scenario, not an incident report. A credential with rights to the backup platform is phished. Nothing is visibly deleted. Retention is simply reduced from ninety days to three. Jobs keep running. Dashboards stay green. The nightly success email arrives on time. Recovery capability then expires on schedule, by design, through the platform's own normal operation. Nobody deleted a backup — the system did exactly what an authorized administrator instructed it to do.

There is a more mundane version of the same weakness. Backup agents need broad read access, and their service accounts are frequently exempted from Conditional Access policies because enforcing modern authentication on them breaks the job. That exemption tends to live in the backup product's configuration rather than in the identity console, so it rarely surfaces during a security review. Our opinion, stated as opinion: machine identities carrying standing privilege with no adaptive controls are among the least examined risks in mid-market environments, and the backup service account is often the most powerful identity in the building.

One question decides whether a backup is actually immutable

"Immutable" has become a datasheet checkbox, which means it now describes several materially different things. The distinction that matters is not where copies live, how many exist, or whether the storage is described as write-once. It is this: who can shorten retention before the clock runs out?

If the answer includes any human being — an internal administrator with sufficient privilege, a vendor support engineer acting on a ticket, a cloud account owner with a policy override — then the data is durable, not immutable. Durable survives hardware failure and accident. Immutable survives an adversary holding legitimate credentials. Those are different products solving different problems, and the second is what a credential-driven threat model requires.

Backup platforms commonly offer more than one style of retention lock: a mode a sufficiently privileged administrator can override, and a mode nobody can override until the retention period expires. Convenience argues for the first. Only the second deserves the word immutable. Whoever manages your data backup should be able to say, without hedging, which mode is configured and who holds the authority to change it.

Four questions produce an honest answer in about ten minutes:

• Can any single administrator in our organization reduce retention or delete a locked recovery point? If so, name them.
• Can the vendor's support team override the lock at our request — and therefore at an attacker's request, if that attacker sounds like us on the phone?
• Is the backup platform's authentication separate from the production directory, with its own privileged access controls?
• When was a restore last performed and documented — not a job status check, an actual restore?

The fourth question tends to be the uncomfortable one.

Microsoft 365 retention is one blast radius, not two

A common and expensive misunderstanding holds that native retention features constitute a backup. Recycle bins, retention policies, litigation hold, and versioning are all genuinely useful. They are also administered from inside the same tenant, by the same privileged roles, under the same identity plane an attacker has just compromised. A Global Administrator can modify retention. That is not a flaw in the platform — it is what administration means.

Which is why Microsoft 365 deserves an independent, separately authenticated copy of mail, files, Teams content, and increasingly the configuration state of the tenant itself. As business processes migrate into SaaS and AI agents begin acting on that data under delegated permissions, the volume of business-critical information governed by a single administrative boundary keeps expanding. Analysis rather than fact: most mid-market companies have accumulated single-blast-radius data considerably faster than they have redrawn their recovery architecture to match.

Clean data restored into a compromised directory is not recovery

Assume the immutable copies held and everything is recoverable. Here is where recovery plans written before identity became the perimeter start to fail: restore into what?

If the intrusion touched the directory — and in credential-driven attacks it usually does — then restoring servers and mailboxes into that same directory reintroduces the attacker's persistence alongside the data. Recovery order becomes the entire problem. A clean identity plane has to exist before restored workloads can safely attach to it, which makes the rebuild path for identity a recovery asset in its own right: documented, tested, and stored somewhere the incident cannot reach.

Two failure modes are easy to predict and easy to prevent. First, the runbook lives in the SharePoint site that is currently unavailable. Second, break-glass credentials live in a password manager that authenticates through the compromised directory. Both are trivial to fix in advance and nearly impossible to fix mid-incident. Treating the recovery procedure as a protected artifact rather than as documentation is a cybersecurity decision, not a filing decision.

The number to put in front of your board

Storage cost is the wrong axis for this decision. Immutable capacity costs somewhat more than ordinary capacity, and that delta is not the figure that matters. The figure that matters is time-to-first-clean-login: how long from the declaration of an incident until employees are working in a directory nobody else controls, with their data intact. That number is measurable only by rehearsal, and in our experience of how these plans are built, it is almost always longer than executives assume.

So the budget question is not whether backups exist. It is whether the deletion path has been closed against a credentialed adversary, whether the identity rebuild is written down somewhere reachable, and whether anyone has proven a restore recently with evidence a cyber insurer or an auditor would accept. Whether that work sits with internal staff or an outside managed IT partner matters far less than whether a named person owns it. Three honest answers describe an organization's resilience better than any dashboard, because the dashboard's job is to report that the system did what it was told.

Pro Link Systems has supported Los Angeles businesses from Woodland Hills since 1999. In our view, the companies that recover quickly are the ones that decided in advance who is not allowed to delete their history. If you want a second opinion on where your recovery architecture would break, our team will walk through it with you at prolinksystems.com/backup-disaster-recovery.