Microsoft is expanding Azure Local’s ability to run workloads on customer-operated infrastructure, including a public preview of transitions between connected and disconnected operation. The changes bring more storage, database and AI functions into environments where access to Azure may be restricted or interrupted. For infrastructure teams, the practical question is which services can keep running locally and which dependencies remain outside the site.
What Disconnected Operation Changes
A disconnected deployment needs more than a local place to store data. It also needs the services required to process that data within the customer-operated environment. Microsoft’s additions address parts of that requirement, although the capabilities have different release statuses.
SQL Server on Azure Local is already generally available for both connected and disconnected deployments. DocumentDB and Blob Storage are entering public preview on the platform. The ability to move workloads between connected and disconnected states is also entering public preview, so teams should distinguish established deployment options from capabilities still being evaluated.
Microsoft plans general availability of Foundry Local at Microsoft Ignite, supporting both modes of operation on Azure Local. Its stated functions include local inference and agentic retrieval through natural-language interaction, with a broader model catalog drawing on Microsoft, partners and the open-source community. Local inference means the model processes requests within the local environment, giving teams another workload they can consider placing on customer-operated infrastructure.
The boundary is practical: where does each workload execute? Douglas Phillips, president and CTO at Microsoft Specialized Clouds, described customers’ concerns as extending beyond data location to system access, operational responsibility, technology dependencies and continuity under changing conditions. The Azure Local expansion gives those questions a more concrete deployment context.
Encryption Control Now Reaches Customer-Owned Hardware
Microsoft is also changing where customers can hold root encryption keys. External key management with Azure Managed HSM is now generally available, allowing those keys to remain in hardware operated by the customer on-premises or by a trusted third party. This extends key control beyond Microsoft’s infrastructure, building on Azure Key Vault Managed Hardware Security Module (HSM).
Key location and workload location are separate architectural decisions. A locally operated system does not, by itself, establish who controls its encryption keys. Conversely, holding keys outside Microsoft’s infrastructure does not mean every service dependency has moved into the customer’s environment.
Protection during processing is another part of the design. Microsoft says Confidential Virtual Machines on Azure Local is now generally available, using hardware-encrypted memory and isolation, with workload attestation before sensitive data or keys are released. Attestation provides a check on the workload before that release, rather than relying only on where the machine is deployed.
Azure Confidential Clean Rooms is in limited preview and addresses a different requirement: collaboration over sensitive information. Microsoft says it uses confidential computing to let participants analyze shared data while restricting wider exposure of the underlying material. Its preview status separates it from the generally available key-management and virtual-machine capabilities.
cEncryption Control Now Reaches Customer-Owned Hardware
The expanded portfolio does not arrive as a single, uniformly available stack. Infrastructure teams evaluating a local deployment need to account for that distinction before treating a proposed architecture as ready for production. Microsoft’s stated availability separates the main additions as follows:
| Capability | Stated availability |
|---|---|
| Connected/disconnected transitions on Azure Local | Entering public preview |
| DocumentDB and Blob Storage on Azure Local | Entering public preview |
| SQL Server on Azure Local | Generally available for both deployment modes |
| Foundry Local on Azure Local | General availability planned at Microsoft Ignite |
| Confidential Virtual Machines on Azure Local | Generally available |
| External key management with Azure Managed HSM | Generally available |
Microsoft is introducing the Sovereign Control Panel as a unified experience within the Azure portal, with public preview scheduled for Microsoft Ignite. It is intended to help customers assess sovereignty, find gaps, apply controls and evaluate whether workloads can move elsewhere. That last function is relevant to architecture planning: portability needs to be examined alongside the ability to run locally.
For customers in the EU and the European Free Trade Association (EFTA), Microsoft is rolling out Data Guardian. A trusted regional partner will independently oversee remote-access requests from Microsoft engineers, while the Production Touch Ledger will maintain tamper-evident records of technical actions. These measures address oversight of access, rather than changing the physical placement of a workload.
Local Infrastructure Still Has External Dependencies
What remains connected when a workload is disconnected? Ashish Banerjee, senior principal analyst at Gartner, cautioned that local operation and the ability to disconnect selected workloads from Azure do not amount to complete customer control. He said enterprises still need to examine Microsoft’s role in identity, updates, management and technical support for the services they choose.
That distinction prevents a deployment label from substituting for an architectural review. A team may gain control over the site, execution environment or root keys while retaining other vendor dependencies. The relevant assessment is therefore specific to the workload and its supporting services.
Pareekh Jain, CEO at EIIRTrend & Pareekh Consulting, said local infrastructure, separately controlled keys and disconnected operation can reduce opportunities for outside access or service disruption. He also cautioned that Microsoft remains subject to applicable US laws, sanctions and export restrictions. Operational independence can increase without removing legal or technological dependence.
The Responsibility Shifts Toward the Local Operator
Banerjee warned that greater sovereignty can bring additional cost and operational responsibility. Local or disconnected environments may require dedicated infrastructure, specialist skills and separate continuity arrangements. They may also offer less elasticity and fewer economies of scale, while some Azure services may arrive later than elsewhere.
Those trade-offs narrow the case for moving every workload into the same deployment model. Banerjee recommended reserving the most restrictive arrangements for workloads whose legal, operational or geopolitical exposure justifies the complexity. For an infrastructure team, that means identifying the necessary local services and remaining dependencies before selecting the degree of disconnection.
Microsoft’s expansion makes more locally operated configurations possible, but availability and responsibility still need to be checked service by service. A production design must distinguish generally available functions from previews and establish who operates the supporting infrastructure. The useful outcome is a documented deployment boundary for each critical workload, including what can run locally and what still depends on Microsoft.
