Imagine a morning when an organization loses trust in its own IT environment. Production systems are encrypted, administrator accounts are compromised, and the available backups may have been deleted or tampered with. At that moment, one question matters above all: do we still have data from which we can safely rebuild the business?
This is exactly what the concept of a digital bunker is for: a separate repository for critical data, designed to survive the compromise of the production environment. Its value comes from combining several independent protection mechanisms. Microsoft Azure provides the building blocks for such an architecture.
Isolating the backup environment with a separate Entra ID tenant and PIM
The protection boundary starts with identity and administration. The bunker is maintained in a separate Microsoft Entra ID tenant, secured specifically for this purpose, with Azure subscriptions assigned to it. A Global Administrator from the production tenant cannot use the elevation mechanism to grant themselves access to resources in the bunker tenant. The separation covers administrative accounts and access recovery mechanisms, so that an identity compromise in the organization does not open a side door into the protected environment.
The only administrative account in the bunker tenant is an emergency (break-glass) Global Administrator account, subject to special protection and never used in day-to-day work. The password for this account is split into two parts, stored as static strings on multi-function hardware security keys. Each part has a primary and a backup copy (two sets of two parts in total). The fragments are held by different custodians, and the backup copies are stored separately. Assembling the full password requires the cooperation of the custodians of both parts.
The same devices also serve as the second authentication factor, using a mechanism supported by Entra ID. For this account, we use sign-in with a password plus a hardware second factor (without enabling passwordless sign-in). Storing a password fragment and acting as a second factor are two separate functions of the same token. Apart from the emergency account, all users of the bunker tenant are required to use hardware security keys as their second authentication factor. Each user has their own key and a separately stored backup key, prepared for the same function.
Nobody works in the bunker tenant on a daily basis. If someone needs to perform operations there (including recovery), they do so with elevated privileges, obtaining time-limited access to data exclusively through Privileged Identity Management (PIM). Activating the relevant data access roles requires a justification and approval by an authorized representative of the steering group. When the activation period ends, the permissions expire. Use of the only administrative account (the emergency GA) is subject to separate control and logging. Automated feeding of the bunker runs through tightly scoped Managed Identity permissions, without interactive PIM activation.
Immutable backups with Azure Blob Storage WORM, ZRS and GZRS
The foundation is Azure Blob Storage with WORM (Write Once, Read Many). Stored data can be read, but for a defined period it cannot be overwritten or deleted. A locked immutability policy means the retention period cannot simply be shortened by an administrator’s decision. For the business, this means the protected copy survives even when someone gains permissions that, in ordinary storage, would allow them to destroy it.
Data durability is strengthened by ZRS (Zone-Redundant Storage). The entire contents of the storage account are replicated synchronously across at least three availability zones within a single Azure region. This protects every written byte in physically separate data centers belonging to independent zones, each with its own power, cooling and networking. Zones are typically kilometers apart; each may contain one or more data centers. As a result, the failure of a single zone does not cause the loss of acknowledged writes.
Protection can be extended to cover the failure of an entire region by choosing GZRS (Geo-Zone-Redundant Storage), where this option is available. It retains synchronous zonal replication in the primary region and additionally replicates data asynchronously to a secondary region. The organization gains another level of geographic resilience, provided the recovery plan accounts for the replication lag and the possibility of losing the most recent writes in the event of a regional outage.
This is complemented by data lifecycle management. Azure Blob Storage Lifecycle Management can automatically move older data to cheaper storage tiers. The organization can reconcile multi-year retention with cost control, while accounting for the time needed for later restoration. Space-saving rules, however, do not bypass WORM protection: automation cannot delete data covered by an active immutability policy.
Envelope encryption with HSM-protected keys in Azure Key Vault Premium
Another layer of protection is created before the data is even sent to the cloud. Data is encrypted at the source with a randomly generated Data Encryption Key (DEK). This key is then wrapped (key wrapping) using a master Key Encryption Key (KEK), hardware-protected in Azure Key Vault Premium (HSM). This is the envelope encryption model: the storage receives the encrypted data and the wrapped DEK needed to read it.
In this architecture, the master key is generated in the HSM as non-exportable. Its private key material cannot be downloaded and taken out as an ordinary file. An authorized process can request a cryptographic operation, but never receives the HSM key itself. As a result, simply copying the contents of the storage does not make it possible to read the information. The right to use the key must therefore be protected just as carefully as access to the data.
A hardware-protected master key in Azure Key Vault Premium does not depend on a single HSM device or a single data center. Azure provides redundancy of vault contents within the region and, in regions that support availability zones, replicates them synchronously across zones. The failure of a single data center therefore does not mean losing the key. In supported paired regions, there is also automatic asynchronous replication to the secondary region, with hardware protection of the key preserved. The key remains non-exportable throughout: the service’s internal replication does not give the user any way to retrieve its private material.
However, the key’s resilience to loss must be distinguished from the time it takes to restore access to it after a full regional outage. Failover to the paired region is managed by Microsoft, so the bunker recovery plan should also account for a possible interruption in the availability of cryptographic operations.
Securing backup access with Azure Arc, Managed Identity, RBAC and ABAC
What remains is the identity of the system that feeds the bunker. This is where Azure Arc comes in. In this model, a dedicated server running in the on-premises data center is registered through Azure Arc in a subscription linked to the bunker tenant. Its Managed Identity is created in that same tenant and is used to authenticate to Key Vault and Storage. Administrator permissions on this server must also follow the adopted separation, because control over the server means the ability to use its identity. The process does not need to store long-lived passwords or access keys for these services in its configuration. This reduces the number of secrets that could leak and simplifies access management in a hybrid environment.
Everything is tied together by a deliberately designed permission model. RBAC for Key Vault and Storage defines who can write data, who can read it, and who can perform cryptographic operations. The role that delivers backups is separated from the role responsible for restoring them. The system sending data to the bunker has no right to decrypt it.
ABAC (Attribute-Based Access Control) for Storage complements these roles with three access conditions. First, it checks whether the identity writing or reading data has the required Custom Security Attributes in Microsoft Entra ID. This also applies to Managed Identities, and therefore to the identity of the server connected via Azure Arc. Second, it makes access dependent on the request passing through a specified private endpoint. Third, it restricts specific operations to objects with an allowed name or path prefix. This lets us allow a given system to write only to its own area of the bunker, while granting the recovery process read access to the appropriate scope of data.
We apply these conditions together: the right identity, an approved access path, and an allowed data scope for a specific operation. Their effectiveness requires control over the assignment of attributes and permissions, as well as the elimination of alternative authorization paths that would bypass these restrictions. Separating bunker administration from production administration matters here as much as the choice of services.
Redundant private connectivity with ExpressRoute and private endpoints
The bunker is reached via private ExpressRoute connections from two on-premises locations. Each location uses its own circuit, and the circuits terminate at two different peering locations with the Microsoft network. This is a dedicated telecommunications service providing access to Microsoft’s global backbone network. Traffic to the bunker bypasses the public internet: it travels through the provider’s network to Microsoft, and then across Microsoft’s backbone to the region where the storage resides.
Each ExpressRoute circuit has two redundant connections to two Microsoft edge routers. In our model, both run in Active-Active mode, exchanging routes via BGP. Two locations and two circuits therefore mean two active paths per circuit. We also maintain redundancy on the provider side and in the on-premises infrastructure, so that a shared router or cable route does not become a single point of failure.
On the Azure side, traffic reaches Storage and Key Vault through private endpoints, with public access to these services disabled. Private connectivity, identity control and ABAC conditions together determine who can enter the bunker and how. This is logical isolation; physical disconnection from the network would require a different operating model.
The bunker itself can even be on the other side of the world. A well-chosen Azure region makes it possible to separate the protected data from local failures, disasters and the unavailability of your own data center. The location must be chosen in line with data residency requirements, service availability and recovery time. The recovery plan brings together the availability of data, private connectivity and cryptographic operations, taking into account the redundancy and failover mechanisms of each of these layers.
Recovery testing and Azure prepayment for cyber resilience
The bunker’s resilience also covers how it is funded. We purchase subscriptions directly from Microsoft, with separately controlled access to billing. Where this model is available under the chosen agreement, we plan for an Azure consumption prepayment, to reduce the bunker’s dependence on day-to-day payment processing during a crisis. This requires monitoring the balance, the expiry date of the funds, and the cost of services not covered by the prepayment. A spending commitment alone, such as a MACC, does not mean the services are paid for in advance.
This is why a digital bunker should be judged by its ability to restore the business. What is needed are regular recovery tests, protection of keys against deletion, and certainty that we also retain copies from before the moment of compromise. Immutability protects the stored state — even when corrupted data has already made its way into storage.
The business value of this architecture lies in preserving the ability to operate in a situation where ordinary safeguards have failed. WORM protects the immutability of copies, zonal and geographic replication increases resilience to failures, source-side encryption protects confidentiality, and the HSM secures the master key. Identity, permissions and private communication control access to the whole.
