Rubrik EMEA Tech Champions 2026

Cyber resilience in 2026: when the control plane becomes the threat

Cyber resilience has traditionally focused on stopping attackers: patch vulnerabilities, deploy MFA, monitor endpoints and detect ransomware before encryption begins. But recent incidents point to a broader problem.

The destructive action may now come from a valid identity, a legitimate cloud API, an administrative process, or an autonomous AI agent. In several examples, nothing needed to be “hacked” in the traditional sense. The controls worked as designed — but the credentials and permissions controlling them were used destructively. Therefore, we need to make an important distinction between preventing or detecting an attack and being able to recover the environment afterwards.

Across identity, cloud and AI, the recurring question is simple: If production is compromised, can you still trust the recovery point?

Cyber incidents 2026 taught us the architectural lesson particularly well: production and recovery points should not share the same blast radius — whether that blast radius is a volume, cloud account, identity plane or provider.

1. Public cloud – the cloud account is part of the threat model

Moving workloads to AWS, Azure or another hyperscaler doesn’t remove cyber risk; it changes where the risk lives. Native resilience is excellent at handling hardware, availability-zone and regional failures. The harder question is what happens when someone with legitimate control-plane privileges deliberately deletes the recovery infrastructure.

One incident involving threat actor “Storm-0501” illustrates that change. The incident describes an attack in which valid credentials and legitimate Azure APIs were used to delete snapshots, restore points, storage accounts and Recovery Services vaults. There was no traditional encryption malware involved in the destructive phase.

The second lesson is that multi-region isn’t necessarily independent recovery. If production and all copies remain under the same cloud account, identity and administrative authority, a provider-level or account-level event can potentially affect all of them.

Three questions to ask yourself:

1. If an attacker gained Owner/Admin rights to your cloud account today, which of your backups, snapshots and recovery vaults could they delete?
2. If your entire AWS/Azure account became inaccessible tomorrow, where is the last copy of your data that does not depend on that account or identity plane?
3. You have multi-region resilience — but do you have an independent recovery copy outside the same administrative blast radius?

Move the conversation from “Are your cloud workloads backed up?”  to “Would those backups survive compromise of the cloud control plane?”  Make independence, immutability and recoverability the key tests.

2. Identity, Active Directory & Entra ID — protect the keys to the kingdom

Identity security has received enormous investment: MFA, Conditional Access, PAM and identity threat detection. But those technologies primarily help prevent or detect compromise. I would like to highlight a different question: how do you recover the identity system itself after compromise?

The Co-op incident 2025 (https://www.theregister.com/security/2025/09/25/empty-shelves-empty-coffers-co-op-pegs-cyber-hit-at-80m/1499568) illustrates why detection alone isn’t enough. According to the analysis, attackers obtained legitimate account access through impersonation. Co-op detected the intrusion and shut down systems before ransomware could be deployed, yet the incident still resulted in weeks of disruption, significant lost revenue and theft of member information.

And identity recovery isn’t simply about users and passwords. Modern Entra ID contains application registrations, groups, policies and other objects upon which applications depend. In another example, more than 300 business-critical enterprise applications were registered in Entra ID, and the customer’s estimate was that manually rebuilding those registrations could take years.

Three questions to ask yourself:

1. If your AD or Entra ID were compromised tonight, how would you determine which identities, groups, app registrations and Conditional Access policies were trustworthy?
2. How long would it take you to rebuild your identity environment — including hundreds of application registrations — from a known-good point?
3. Does the identity that administers production also have the ability to modify or destroy the recovery environment you would depend on after an identity attack?

Identity protection shouldn’t stop at MFA and detection. The conversation should include identity recovery: getting AD/Entra back to a known-good state quickly enough for the rest of the business to recover. One Rubrik customer example describes recovery of 300+ Entra application registrations in minutes rather than the customer’s estimated years of manual reconstruction.

3. AI — your fastest-growing privileged user may not be human

AI introduces a fundamentally different operational risk: machine-speed action with legitimate credentials.In particular, CISOs are simultaneously being asked to enable AI and remain accountable when it goes wrong. 

Autonomous agents may be able to access files, APIs, databases and infrastructure using permissions legitimately granted to them.

The PocketOS example (https://www.theregister.com/software/2026/04/27/cursor-opus-agent-snuffs-out-startups-production-database/52244429 ) makes the problem tangible. According to the incident, an AI coding agent found an API token outside the scope of its task and used it to delete a production volume. Because the backups existed inside that same volume, production and its backups disappeared together. The destructive action took nine seconds.

That changes the resilience discussion. A human approval process that takes minutes cannot necessarily protect against an autonomous process capable of destructive action in seconds. AI therefore adds another class of privileged, non-human identity whose permissions and blast radius need to be understood.

Three questions to ask yourself:

1. Which AI agents currently have credentials or API tokens that allow them to modify or delete production data — and do you actually know what those permissions are?
2. If an autonomous agent deleted production at machine speed, could that same identity or API also reach the backups?
3. If an AI agent made a destructive change right now, what known-good point could you confidently roll back to — and how quickly could you recover it?

Don’t position AI resilience as trying to guarantee that AI never makes a mistake. Position it around limiting blast radius and guaranteeing recovery when automation does something unexpected. That shifts the discussion from AI governance alone to recoverability.

The message that connects all three

Cloud, identity and AI initially look like different security problems. This discussion shows that they increasingly converge around the same architectural weakness:

Too much trust sits inside one blast radius.

A compromised Entra administrator can become a cloud administrator. A cloud administrator can delete recovery infrastructure. An AI agent can inherit an API token with destructive permissions. And a backup that shares the same identity, account, volume or administrative plane as production may disappear at exactly the moment it is needed most.

That gives you a strong opening question for almost any meeting around Cyber Resiliency:

“If the credentials controlling your production environment were compromised right now, could those same credentials destroy the recovery points you are relying on?”

If the answer is yes — or “we don’t know” — the conversation is no longer primarily about backup. It is about whether the organisation actually has an independent, immutable and trustworthy path back to business operations.