In this blog post Cross Tenant Restore with Azure Backup Cyber Resilience Playbook we will show why having backups may not be enough when attackers control the same cloud environment your recovery team depends on.
Cross-tenant restore allows Azure Backup recovery points to be restored into a separate Microsoft cloud tenant. A tenant is the identity and security boundary containing your users, administrators and access rules. If your primary tenant is compromised or inaccessible, the separate tenant provides a cleaner place to rebuild critical services.
Microsoft released this capability in public preview in October 2026. That preview status matters: it is a valuable addition to cyber recovery planning, but organisations should test supported workloads and operational limits before treating it as their only recovery path.
Why restoring inside the same tenant can be risky
Many Azure recovery plans assume the production tenant will still be available after an incident. Administrators sign in, select a recovery point and restore the affected virtual machines, databases or files.
CPI Consulting helps organisations design, build and secure Azure AI solutions, from Azure OpenAI and Microsoft Foundry to agents, governance and production deployment.
Visit CPI ConsultingThat approach works for hardware failure, accidental deletion and many ordinary outages. It becomes more difficult when the tenant itself is part of the incident.
A serious ransomware attack may involve stolen administrator accounts, changed security policies, disabled monitoring or blocked access to subscriptions. Your backups might still exist, but the people responsible for recovery may be unable to reach or safely use them.
This is the gap cross-tenant restore is designed to address. Our earlier article on building stronger Azure cyber recovery plans with cross-tenant restore explains the strategic case. The next step is turning that capability into a practical, tested process.
How the technology works
Azure Backup stores protected recovery points in a vault. Think of the vault as the controlled service used to retain, manage and restore your backup data.
With cross-tenant restore, your recovery team creates a secure mapping between a source vault in the production tenant and a target vault in the recovery tenant. The target tenant can then view eligible protected items, select a recovery point and restore the workload into its own Azure environment.
The source and target vaults must be in the same Azure region. Only vaulted recovery points are eligible, meaning backups stored in the Azure Backup vault tier. Snapshot-only and archive-tier recovery points cannot be used for this process.
Cross-tenant restore currently supports alternate-location recovery rather than restoring over the original production resource. That is usually desirable during a cyber incident because it prevents the recovery process from reconnecting directly to an environment that may still be compromised.
The public preview covers common Recovery Services vault workloads, including Azure virtual machines, Azure Files, SQL Server in Azure virtual machines, SAP HANA and SAP ASE. Some configurations have exclusions, so support should be checked against your actual workloads rather than assumed.
A practical six-step cyber resilience playbook
1. Decide which services must return first
Do not begin with a list of every server. Start with the business services that create revenue, support customers, process payroll or meet legal obligations.
For each service, identify the applications, databases, file shares, identities and network connections it needs. This produces a recovery sequence based on business impact rather than technical convenience.
2. Prepare a clean recovery tenant before an incident
Creating a second tenant during a ransomware crisis wastes valuable time. Prepare the target tenant in advance with secure administrator accounts, subscriptions, networking, monitoring and enough Azure capacity for priority systems.
The recovery tenant should not simply copy every trust relationship from production. Keep its administrators separate, require phishing-resistant multi-factor authentication and avoid unnecessary connections that could allow an attacker to move between environments.
This supports the Essential Eight, the Australian Government’s cybersecurity framework that many organisations use to measure security maturity. Cross-tenant restore is particularly relevant to regular backups, restricted administrative privileges and multi-factor authentication, although it does not satisfy those controls by itself.
3. Protect the vault mapping with separate approval
Azure requires the target vault to be protected by Resource Guard, which adds an independent approval layer around sensitive backup actions. Multi-user authorisation means one compromised administrator should not be able to create mappings or perform protected operations alone.
Use separate people or teams for production administration and recovery approval. Access should be temporary wherever possible, and permissions used to create the mapping should be removed when the task is complete.
This separation may feel inconvenient during setup. During a real attack, it can prevent a stolen administrator account from controlling both production and recovery.
4. Combine cross-tenant restore with immutable backups
Cross-tenant restore changes where you can recover. Immutability protects the recovery points themselves by preventing them from being changed or deleted during their retention period.
You need both controls. A separate recovery tenant is of little value if attackers can delete the usable backups first.
Our guide to immutable Azure backups for ransomware resilience covers this protection layer in more detail. Organisations running business-critical databases should also review practical immutable backup planning for Azure SQL.
5. Document what happens after the restore
Restoring a virtual machine does not automatically restore the complete business service. The recovered system may still need networking, name resolution, security policies, application secrets, certificates and access to dependent databases.
Your runbook should state who validates the restored data, who approves reconnection and how users will access the temporary environment. It should also explain how clean data will eventually return to the primary tenant.
Include a manual alternative for every automated step. Automation credentials stored only in the compromised tenant may not be available when you need them.
6. Test the recovery path regularly
A backup report showing green ticks proves that backup jobs completed. It does not prove that the business can recover within an acceptable timeframe.
Run a controlled exercise at least annually, with more frequent tests for critical services. Measure how long it takes to obtain approval, access the target tenant, locate the correct recovery point, restore the workload and make the application usable.
Record the recovery time and compare it with the outage the business has agreed it can tolerate. Testing can also uncover workload-specific limitations, including cases where file-level or item-level recovery is faster than rebuilding an entire system. Our article on recovery planning for Premium SSD v2 and Ultra Disks explores this decision.
What this looks like in a mid-market business
Consider a 200-person professional services company whose document platform, finance application and reporting database run in Azure. An attacker compromises a privileged account, changes access rules and locks the internal IT team out of the production tenant.
Without a prepared cross-tenant process, the company must first regain control of production before meaningful recovery can begin. That delay could leave employees unable to access client files or issue invoices for several days.
With a prepared recovery tenant, protected vault mapping and tested runbook, the company can begin restoring priority systems into an isolated environment while the security investigation continues. The business outcome is not merely a successful restore. It is fewer lost working hours, reduced revenue impact and less pressure to make rushed decisions during an attack.
Questions leaders should ask their IT provider
- Can we restore critical Azure workloads if our production tenant is inaccessible?
- Which of our recovery points are vaulted and eligible for cross-tenant restore?
- Are our source and recovery vaults in compatible Azure regions?
- Who holds the separate approval required for sensitive recovery actions?
- Are our critical backups immutable and protected from deletion?
- When did we last prove that a restored application actually worked?
- How long would it take employees to regain access to priority services?
If these questions cannot be answered clearly, the organisation has a backup configuration rather than a complete cyber recovery plan.
Build the capability before you need it
Cross-tenant restore closes an important gap in Azure recovery by giving organisations an independent path when their main identity and administration environment cannot be trusted. Its value depends on preparation: secure the target tenant, protect approvals, confirm workload support and test the full business service.
CloudPro Inc brings more than 20 years of enterprise IT experience to Azure resilience planning. As a Microsoft Partner and Wiz Security Integrator, we help organisations connect Azure Backup, Microsoft Defender, Wiz and Essential Eight controls into practical recovery plans rather than disconnected security tools.
If you are unsure whether your Azure backups would still be usable after a tenant compromise, we are happy to review the current setup and identify the gaps — no strings attached.