There is a pattern in the conversations I have been having with CISOs over the past year.

It is not about tools. It is not about dashboards or threat intelligence feeds or adding another detection layer. The organizations I talk to have already invested heavily in all of that. Their security stacks are mature. Their teams are capable.

What keeps coming up is something more fundamental.

Two recurring gaps surface in almost every serious resilience conversation I have. The first is whether backup data is actually isolated from the production environment that an attacker might already control. The second is whether identity — specifically Entra ID and Conditional Access policies — can be recovered fast enough to keep the business operational.

These are not exotic edge cases. They are gaps that exist in organizations that have otherwise done a lot of things right.

The backup problem is not about volume

Most organizations have backups. That part of the conversation ended years ago. What CISOs are asking now is more precise: where do those backups live, and who can reach them?

If the answer is that backups are stored in the same environment, managed through the same credentials, and accessible through the same administrative plane as production — then a production compromise does not just threaten the data. It threatens the recovery path as well.

I have watched this play out. An organization gets hit. The team moves quickly to activate recovery. And then they discover that the backup infrastructure was reachable from the compromised environment. Either the attacker already found it, or the recovery process itself depends on credentials and administrative access that are now untrusted.

That is when resilience becomes a theoretical concept instead of a practical capability.

The shift I see in the most mature security organizations is a move toward deliberate architectural separation. Backups that live outside the production trust boundary. Immutable storage that cannot be altered even if production credentials are compromised. Recovery paths that do not depend on rebuilding trust inside an environment that is already under stress.

Cloud does not solve this automatically. Moving to AWS, Azure, or GCP creates agility. It does not create isolation unless you design for it. The blast radius question is just as real in the cloud as it is on-premises.

The identity problem is deeper than most people expect

The second gap catches organizations off guard more often than the first.

Entra ID is not just a user directory. It is part of the operational control plane for the business. The app registrations, groups, roles, and especially the Conditional Access policies stored there determine how users connect to systems, how administrators operate, how services authenticate, and what conditions must be met for access to be granted.

Conditional Access policies are where this gets particularly sharp.

Those policies encode decisions that took months to refine. Which users require MFA. Which devices are trusted. Which locations are permitted. What happens when a sign-in looks risky. If those policies are deleted, corrupted, or altered during an incident, the impact can spread far beyond the original compromise. You may still have user accounts. You may still have your data. But access control can break across the organization in ways that are difficult to isolate and slow to fix manually.

The teams that handle this well treat identity recovery the same way they treat workload and data recovery. They have a backup of Entra ID state. They can recover users, groups, app registrations, and Conditional Access policies quickly and cleanly. They do not rely on rebuilding from memory or manual documentation under pressure.

The teams that struggle are the ones who assumed identity was covered because they have a mature IAM practice. Having a strong IAM program is not the same as having a tested identity recovery capability.

Why these two things belong together

Backup isolation and identity resilience are not separate problems. They are connected parts of the same recovery challenge.

If your backups are compromised or unreachable, you cannot restore your data.

If your identity controls are lost or corrupted, you may have restored your data but you still cannot operate. Your users cannot access systems. Your administrators cannot work safely. Your Conditional Access policies are not there to govern what happens next.

Resilience is not proven by owning backup technology or having a mature identity program. It is proven by what you can actually recover, how quickly, and under what conditions.

That is the question I keep bringing back to every conversation: if production was compromised tonight, are your backups recoverable from outside the blast radius, and can your identity controls be restored fast enough to keep the business moving?

Over the next three weeks, I am going to work through both of these gaps in detail — what they actually look like in practice, where organizations tend to find the gaps in their own assumptions, and how to build recovery capabilities that hold up under real pressure.

The goal is not a longer checklist. It is a clearer picture of what resilience actually requires when the environment is under stress.

---

This is the first post in a four-part series on backup isolation and identity resilience. Next week: why cloud backup is not the same as isolated backup, and what separation actually looks like.