Disconnected Azure Local: Truly Sovereign Infrastructure
Earlier this week, Microsoft published an update on their Sovereign Cloud strategy, announcing enhancements to governance, productivity, and support for large AI models running in fully disconnected environments. This builds on the disconnected operations GA announced at Ignite 2025 , and it’s worth taking stock of what’s now possible with Azure Local when there is absolutely no connection to the internet.
Because let’s be honest, “disconnected” has been a word thrown around loosely in the hybrid infrastructure world for a long time. Most platforms that claim disconnected or edge capability still require some level of periodic connectivity for updates, licensing validation, or management operations. Azure Local’s disconnected operations capability is genuinely air-gapped. No network connectivity to Azure, no phone-home requirements, no dependency on external services for day-to-day operation.
What Disconnected Operations Looks Like
In a fully disconnected Azure Local deployment, everything that normally flows through Azure has to be handled locally.
Deployment is performed using local tooling and offline media. The Azure Local OS image, the Arc Resource Bridge components, and the Solution Builder Extension are all installed from local sources. There’s no Arc registration with Azure, because there’s no Azure to register with.
Management is performed through local management tools rather than the Azure portal. This is the most significant operational difference from a connected deployment. You lose the Azure portal experience, Azure Policy, Azure Monitor, and the other Azure management services that connected deployments rely on. In exchange, you get complete independence from any external service.
Updates are applied through an offline process. Microsoft provides update packages that can be transferred to the air-gapped environment through approved media transfer processes (the specifics of which will depend on the security requirements of the environment). Dell’s Solution Builder Extension similarly provides offline update packages for firmware and driver updates.
Lifecycle management works, but it requires more manual orchestration than in a connected environment. The automated, Azure-driven update process that connected deployments enjoy is replaced by a locally-driven process that requires more operational involvement.
Who Needs This
I touched on the target audience in my M365 Local post last month, and the customer base for disconnected Azure Local overlaps significantly.
Defence and intelligence organisations are the most obvious consumers. Classified environments are air-gapped by mandate, and the compute and storage requirements within those environments are growing as AI, analytics, and modern applications move into classified spaces.
Critical national infrastructure operators in energy, water, transportation, and telecommunications increasingly need modern compute infrastructure in environments that are deliberately isolated from the internet for security reasons. SCADA and ICS environments have historically run on legacy infrastructure precisely because modern alternatives required internet connectivity.
Diplomatic and forward-deployed operations need compute and collaboration capability in locations where reliable internet connectivity doesn’t exist. Military deployments, embassy operations, scientific research stations, disaster response, all of these scenarios benefit from modern infrastructure that works without connectivity.
Regulated industries in specific jurisdictions face requirements that mandate not just data residency, but operational isolation. The data must stay local, the management plane must stay local, and there can be no external dependency.
The AI Dimension
One of the more recent additions to the disconnected story is support for running large AI models locally. Microsoft’s February announcement specifically called out support for AI models in disconnected environments, building on the NVIDIA GPU support that’s been maturing on Azure Local.
This is significant because AI workloads in sovereign environments are one of the fastest growing use cases. Defence organisations want to run AI models against classified data. Healthcare providers want to run diagnostic AI against patient data that can’t leave the facility. Financial institutions want to run fraud detection models against transaction data that’s subject to strict handling requirements.
The combination of Azure Local’s disconnected operations, NVIDIA GPU hardware, and the ability to deploy AI models locally creates a sovereign AI platform that addresses requirements that were previously unmet. You can train models in a connected environment (or acquire pre-trained models), transfer them to the air-gapped environment through approved processes, and run inference locally against sensitive data that never leaves the secure boundary.
The Dell Perspective
For disconnected deployments, the hardware partner matters even more than in connected scenarios. When you can’t phone home for support, when you can’t download firmware updates from the internet, when you can’t open a remote support session, the reliability and supportability of the hardware becomes critical.
Dell AX nodes are designed with these scenarios in mind. The Premier Solution validation means the hardware, firmware, and drivers have been tested against the Azure Local software before it reaches you. The offline SBE update process provides a validated, repeatable mechanism for applying hardware updates without internet connectivity. And Dell’s support organisation has experience supporting air-gapped environments in defence and government contexts.
The supply chain is also a consideration. For classified environments, hardware procurement often involves specific supply chain requirements around country of origin, handling, and chain of custody. Dell’s manufacturing and logistics capabilities can accommodate these requirements, which is an important practical consideration that’s easy to overlook when evaluating platforms on features alone.
The Trade-offs
I want to be straightforward about the trade-offs of running disconnected. You lose a lot.
You lose the Azure portal experience. You lose Azure Policy. You lose Azure Monitor. You lose the automated update pipeline. You lose the ability to quickly spin up new Azure services. You lose the hybrid cloud story entirely, because there’s no cloud to be hybrid with.
What you get in return is sovereignty, independence, and security isolation. For the environments that need this, there’s no substitute. But for environments that don’t strictly require disconnected operation, the connected or intermittently connected deployment models provide a much richer operational experience.
The decision to go fully disconnected should be driven by genuine requirements, not by a vague sense that “disconnected is more secure.” Connected Azure Local deployments are secured by Azure’s security infrastructure, which is formidable. Disconnected deployments trade that security investment for isolation, and that trade-off should be made with eyes wide open.
Where We Are
Fully disconnected Azure Local with M365 Local, AI workloads, and enterprise storage is a platform that simply didn’t exist two years ago. The pace at which Microsoft and Dell have brought this capability to market is impressive, and it addresses a set of customer requirements that have been underserved for far too long.
If you’re in one of the sectors or scenarios where disconnected operation is a requirement, this is the most capable platform available for running modern workloads in an air-gapped environment. It’s not perfect, the operational overhead is real, and the feature set is necessarily narrower than connected deployments. But it’s functional, it’s supported, and it’s here. That’s a significant milestone.