Drilling campaigns are among the most expensive and operationally complex activities in the energy industry. Rigs, crews, equipment, and logistics are scheduled months in advance, leaving little room for delay. Every hour of downtime can carry significant costs. Geoscientists and engineers rely on reservoir models to understand the subsurface and guide drilling decisions, often under intense time pressure. Yet the current modeling infrastructure that many companies rely on for these critical decisions was designed for smaller datasets, simpler workflows, and siloed operations. As subsurface data grows in scale and complexity, teams need a faster, more connected way to transform uncertainty into actionable decisions.

Now generally available, agile reservoir modeling (ARM) from SLB, integrated with Azure Data Manager for Energy (ADME), is co-engineered for cloud scale to close that gap. The combined solution connects ensemble-centric reservoir modeling and simulation with a governed data foundation, elastic Azure high-performance computing, and scalable storage designed for the throughput and concurrency of large ensemble studies.

Scale ensemble modeling with ARM on Azure

A single reservoir model represents one plausible interpretation of the subsurface. Ensemble modeling evaluates hundreds of model realizations together, giving asset teams a broader view of potential outcomes and a stronger basis for understanding uncertainty and risk.

The industry has long recognized the value of ensemble modeling for risk-aware decision-making, but adoption has been constrained by infrastructure and software designed for smaller, sequential studies. Moving from a limited model set to hundreds of realizations multiplies the compute, storage, data movement, and results that must be managed. ARM addresses this barrier by distributing realization generation and simulation across elastic Azure high-performance computing, while scalable storage provides the capacity, throughput, and parallel access required by ensembles of different sizes.

Connect reservoir workflows to a governed data foundation

Building and updating reservoir models draws on many systems: seismic, wellbore, interpretation, and simulation data, plus the applications and compute that process them. When these pieces are fragmented, customers must connect and orchestrate them on their own, and large-scale simulation becomes a disconnected, one-off exercise.

SLB and Microsoft combined their respective technologies, ARM engineered by SLB and ADME engineered by Microsoft, to remove that burden. Rather than a set of loosely connected tools, customers get one integrated workflow in which each component has a clear role:

• Azure Data Manager for Energy is the governed data foundation. OSDU® Technical Standard-aligned services and OSDU Domain Data Management Services (DDMS) manage seismic, wellbore, interpretation, and simulation data.
• Petrel™ subsurface software is where engineers define interpretation and uncertainty workflows, connected directly to data in ADME.
• Agile reservoir modeling is the ensemble workflow engine. It orchestrates the generation of reservoir realizations and simulation runs and supports discovery and analysis at enterprise scale.

As a result, teams build ensembles from trusted corporate data and publish results back for discovery and reuse, which reduces data movement and improves collaboration across asset teams.

Put ensemble modeling into practice with a connected workflow

Beyond integration and scale, ARM distinguishes itself by orchestrating all stages of an ensemble study across modeling, simulation, data management, and analysis. The workflow tightly connects the tools reservoir teams already use with Azure-scale infrastructure and the governed data services provided by Azure Data Manager for Energy.

A walkthrough of how this works today:

Reservoir engineers define uncertainty workflows in Petrel software and prepare simulation models for supported SLB simulators, including the Intersect™ reservoir simulator and Eclipse™ reservoir simulator. ARM generates the realizations, prepares the simulation cases, and coordinates their execution across the Azure environment.

Azure high-performance computing executes multiple realizations in parallel. A shared, high-performance Azure Files volume holds model inputs, grids, simulation decks, temporary files, and results so the simulation fleet can read and write concurrently. Because compute capacity, storage capacity, throughput, and IOPS can be scaled independently, the environment can be sized for the concurrency of the ensemble rather than the constraints of fixed infrastructure.

As simulations complete, SLB reservoir engineering services manage the resulting ensembles and use OSDU search capabilities on ADME to support discovery, filtering, and sorting across large studies. Teams can locate relevant realizations and supported, published results without manually navigating disconnected project stores.

Engineers can analyze ensembles in the reservoir engineering workspace or load them back into Petrel software for further interpretation, history matching, and reservoir engineering studies. This allows teams to work in the environment and application best suited to each task while maintaining continuity, without having to step outside their workflow to manage orchestration.

ADME provides entitlement-based access control integrated with Microsoft Entra ID and supports compliance controls such as OSDU legal tags. Connecting ARM workflows to this governed data foundation helps maintain consistent access and compliance as corporate subsurface data is used across modeling and simulation. Because ARM workflows are integrated through Petrel software in ADME, reservoir engineers can perform ensemble-scale studies leveraging their corporate-wide data stores and publish results for discovery, eliminating friction and driving collaboration. Microsoft and SLB engineering collaborated closely to build the integration between Petrel software and ARM for enterprise-scale performance.

For reservoir engineers and asset teams, ARM turns ensemble modeling into a repeatable workflow rather than a bespoke infrastructure project. Teams can stress-test development concepts against calibrated ensembles that honor observed production history, not simply run a larger number of models. As new wells are drilled and new data becomes available, they can update their reservoir understanding without waiting for a major model rebuild. For energy IT and data leaders, the workflow connects simulation to an OSDU standard-aligned architecture with consistent identity, governance, search, and interoperability, reducing isolated data copies and disconnected applications.

The future of the reservoir lifecycle

Building on this partnership, Microsoft and SLB are working within the OSDU community to advance a more cloud-native standard for reservoir data. This work will help models, simulation results, and engineering workflows operate more consistently across applications, improving interoperability while reducing dependence on proprietary formats and silos. A shared, governed data foundation also paves the way for AI and agentic experiences that can discover data, coordinate workflows, and surface insights across the reservoir lifecycle. Combined with Azure-scale compute and storage, this creates a path toward more automated and continuous reservoir modeling.

Get started with ARM on Azure Data Manager for Energy

Agile reservoir modeling on Azure Data Manager for Energy is generally available today. Learn more about agile reservoir modeling from SLB and Azure Data Manager for Energy. Contact your Microsoft and SLB account teams to identify an initial reservoir workflow and discuss the path to deployment.

Azure Data Manager for Energy

Accelerate your energy intelligence.

Get started

The post Scale reservoir uncertainty analysis with agile reservoir modeling appeared first on Microsoft Azure Blog.

This challenge is becoming more important as advanced cloud and AI capabilities move into public services, regulated processes and essential operations. Organizations are considering more than where data resides. They also seek to understand who can access and operate their systems, how sensitive digital assets remain protected, which technology dependencies matter most and whether critical services can continue as regulatory, geopolitical, security or network conditions change. Digital sovereignty should give organizations greater control and security over the technology they depend on, while continuing to innovate.

Last year, we introduced Microsoft Sovereign Cloud to give customers more choice in how they address these requirements. Since then, we have continued to turn our commitments into practical capabilities across public cloud and customer-operated environments, while expanding how we enable partners to address sovereignty requirements in their local markets. Today, we are sharing the next stage of that work.

A continuum of control, built around the workload
Microsoft Sovereign Cloud diagram showing a continuum of sovereignty solutions across three areas: Sovereign Public Cloud for control, data protection and regional requirements; Sovereign Private Cloud for critical workloads across connected and disconnected environments; and the Sovereign Partner Ecosystem for trusted, locally operated and specialized solutions.

Our approach to digital sovereignty starts with the workload. Each workload carries different requirements for data, operations, technology dependencies, continuity and risk. Microsoft Sovereign Cloud is designed to make it easier for organizations to apply the appropriate level of control to each workload without forcing every application into the same deployment model.

Those needs can vary widely across organizations. A public-facing digital service may benefit from the scale and pace of innovation in the public cloud. A system supporting essential operations may need to continue running locally if connectivity is disrupted. An AI workload handling highly sensitive data may require models, data and processing to remain within a customer-controlled environment.

Microsoft Sovereign Cloud is designed around this workload-based approach, providing a continuum of management, control and options across Sovereign Public Cloud, Sovereign Private Cloud and the Sovereign Partner Ecosystem. Organizations can apply the level of control appropriate to each workload while maintaining a consistent approach to governance and operations across their digital estate. Sovereign Public Cloud adds capabilities for workloads that require greater control and transparency while continuing to benefit from the scale and innovation of Azure.

Sovereign Private Cloud extends cloud capabilities into customer-operated environments, including connected and disconnected operations. The Sovereign Partner Ecosystem broadens the continuum through independently operated environments, specialized partners, locally relevant expertise and technologies that support customers’ sovereignty requirements.

These are not isolated destinations. Customers can combine public cloud, private cloud and partner capabilities across their digital estate, applying different levels of control to different workloads as their operating needs evolve.

Making control more visible in Sovereign Public Cloud
For many workloads, the public cloud provides a combination of scale, innovation, integrated security and compliance. Organizations can benefit from these capabilities while applying additional sovereignty controls for residency, confidentiality, operator access, policy and continuity. Our work in Sovereign Public Cloud makes these controls easier to understand, apply and demonstrate.

Sovereign Control Panel, entering public preview at Microsoft Ignite, brings these signals together in a unified Azure portal experience. It helps organizations understand their sovereignty posture, apply and manage controls, identify gaps and risks and take action to address them. It also supports business continuity readiness by helping customers understand workload dependencies and assess portability across operating environments when required.

This visibility complements controls across the operator-access lifecycle. Just-in-time Access and Customer Lockbox give customers additional control over access to their environments. For customers in the European Union (EU) and the European Free Trade Association (EFTA), we are rolling out Data Guardian, which adds European-resident oversight by a trusted EU partner for qualifying Microsoft engineer remote access to in-scope production systems. Production Touch Ledger, also launched with phased rollout in the EU and EFTA, creates tamper-evident records of that access and the actions performed.

Azure Key Vault Managed Hardware Security Module (HSM) already gives customers dedicated, single-tenant protection and control over the encryption keys used by supported Azure services. Last year, we committed to extending that control beyond Microsoft infrastructure. External key management with Azure Managed HSM is now generally available, allowing customers to keep the root encryption key in hardware they own and operate on-premises or through a trusted third party. This gives organizations another option for workloads that require physical control of key hardware outside Microsoft infrastructure.

Azure confidential computing helps protect supported data while it is processed in a hardware-based and attested trusted execution environment. We are also increasing transparency into the technologies that underpin that trust. Azure Confidential Clean Rooms, now in limited preview, applies confidential computing to approved multiparty collaboration, allowing participants to analyze shared sensitive data while limiting broader exposure of the underlying information.

Together, these capabilities provide additional technical and operational controls that can support a broader digital sovereignty strategy aligned to an organization’s legal, policy, security, resilience and business requirements.

Designing for resilience and operational independence
For some workloads, digital sovereignty also means maintaining critical operations as connectivity, geopolitical and operating conditions change. Resilience must be designed from the start so essential workloads can continue operating through disruption.

To help customers prepare for these scenarios, we are publishing new sovereign business continuity guidance and architecture patterns. These resources help organizations translate resilience requirements into architectures they can plan, implement and test before they are needed.

For many workloads, the scale and geographic reach of the public cloud provide a strong foundation for resilience across locations and operating conditions. For workloads that require greater operational independence, Sovereign Private Cloud extends that continuum into customer-operated environments. It supports connected and disconnected operating models. The ability to transition workloads from connected to disconnected operations is entering public preview, giving organizations greater flexibility to sustain critical services as connectivity and operating requirements change.

Bringing more of the application lifecycle under local control
Operational independence requires more than infrastructure. Increasingly, organizations need data, development tools, model capabilities and productivity services their applications depend on to operate within the same customer-controlled environment.

Sovereign Private Cloud, built on Azure Local, extends Microsoft cloud capabilities into environments that customers operate and control. SQL Server on Azure Local is already generally available for connected and disconnected deployments. DocumentDB and Blob Storage on Azure Local are both entering public preview, giving organizations more choice in how they run and manage critical data within customer-controlled environments.

GitHub Enterprise Local will become generally available at Microsoft Ignite as a validated GitHub Enterprise Server appliance on Azure Local, helping organizations keep repositories, code and development artifacts under local control. Developers can also use GitHub Copilot with locally hosted models for inference, bringing AI-assisted development closer to their code and data within the environments they control.

The local application environment is expanding with Foundry Local. At Ignite, Foundry Local will become generally available for connected and disconnected operations on Azure Local, with an expanded model catalog that includes Microsoft, partner, open-weight and open-source models. Local inference and agentic retrieval will also enable users to interact with local enterprise data using natural language and receive responses grounded in that data. Integration with Microsoft 365 Local, available in preview for approved customers, extends this functionality to locally operated Microsoft SharePoint and Exchange servers.

Confidential virtual machines on Azure Local are generally available, extending confidential computing capabilities to customer-controlled infrastructure. Hardware-encrypted memory and hardware-based isolation help protect sensitive data while it is being processed. Workload attestation adds assurance before sensitive data or keys are released. For regulated, sensitive and mission-critical workloads, these safeguards provide another layer of protection while giving organizations greater control over where their data and applications run.

Azure Local will support multitenancy, allowing organizations to separate resources, governance and management across multiple tenants while sharing the underlying infrastructure. This significantly expands what customers with distinct business units or security boundaries can achieve with Sovereign Private Cloud. Multitenancy also creates new opportunities for local operators and service providers to deliver differentiated sovereign cloud services on Azure Local infrastructure.

These additions bring more of the application lifecycle under local control, spanning data, development, productivity, AI and operations. Organizations can determine what runs locally based on the requirements of each workload.

Extending the continuum through partners
Graphic titled “Sovereign Partner Ecosystem” with the subtitle “National clouds · Software · Services · Platform co-innovation,” showing 31 partner logos: Accenture, AMD, Armada, Avanade, base-it, Bleu, Capgemini, Cirrus Data, CloudCasa by Catalogic, Cronos Groep, cTelecoms, DataON, Delos Cloud, Dell Technologies, F5, Felo, Fortinet, HPE, Inspark, Intel, Mattermost, Mistral, NVIDIA, Qualidev, Qumulo, RiverMeadow, Rubrik, Supermicro, Tata Consultancy Services (TCS), Veeam and WSO2.

Navigating sovereignty is increasingly complex. Regulatory, security, operational and business requirements vary across countries, industries and workloads. Organizations must translate these needs into technology and operating models that work in their local context. Meeting these needs often requires a combination of technology, local operating authority, sector expertise and specialized solutions.

The Sovereign Partner Ecosystem broadens the ways customers can address these requirements. National Partner Clouds, including Bleu Cloud in France and Delos Cloud in Germany, provide independently operated environments for customers that require a different ownership and operating model. Software partners can enhance Azure Local environments with capabilities across security, identity, observability, backup and recovery, migration, data, networking and applications. Digital sovereignty specialized partners combine Microsoft technologies with local knowledge and implementation expertise. Platform co-innovation partners expand infrastructure choice from datacenter to the edge.

This ecosystem gives customers the flexibility to combine technology, operating models and trusted expertise based on the requirements of each workload.

The next chapter of digital sovereignty
AI is amplifying both the opportunity and the impact of technology choices. As AI systems and agents interact with sensitive data, business processes and essential infrastructure, they also expand the security considerations organizations need to manage. Organizations need clear control over where these systems run, who can operate them, what actions they can take and how critical services continue when conditions change.

Microsoft Sovereign Cloud brings these choices together as a continuum of control across the public cloud, customer-operated environments and our partner ecosystem. It gives organizations the flexibility to apply the appropriate level of control to each workload while continuing to benefit from cloud capabilities and ongoing innovation.

We will continue to expand this continuum so organizations can innovate with cloud and AI while maintaining the control, confidentiality, resilience and operational authority their most important workloads require.

Douglas Phillips leads global engineering efforts for Microsoft’s specialized, sovereign and private clouds. He is responsible for Microsoft’s global strategy, products and operations that bring Microsoft’s industry-leading solutions, including Azure, our adaptive cloud portfolio and Microsoft 365 collaboration suite, to customers with additional sovereignty, security, edge and compliance requirements.

Learn more

Microsoft Sovereign Cloud
Sovereign Landing Zone architecture guidance
Sovereign Public Cloud Tech Community blog
Sovereign Private Cloud Tech Community blog

The post Advancing digital sovereignty with greater control and choice appeared first on Microsoft Azure Blog.

• Manufacturers can analyze confidential production data next to the systems that generate it.
• Pharmaceutical companies can apply AI to clinical trials within controlled environments.
• Government agencies can run AI applications on sensitive information while maintaining established security and operational boundaries.

This shift reflects ongoing innovation across the technology ecosystem to give organizations greater flexibility in where they run AI and process sensitive data, and it is changing the digital sovereignty conversation. It now encompasses where data is stored and processed, where workloads run, who can access and operate the systems around them, and how those systems remain secure and operational as requirements change. The next phase of digital sovereignty will take shape across the technology ecosystem, through closer alignment among silicon, infrastructure, cloud, security, data, and AI.

As AI extends into more sensitive and mission-critical workloads, sovereignty must be designed across the stack, from silicon and infrastructure to cloud, data, and AI. Microsoft and Intel® are working together to help organizations create a more consistent foundation for innovation, while retaining greater choice over where workloads run and how they are controlled.

A flexible sovereign architecture allows organizations to place each workload in the right environment, apply the controls it requires, and maintain a more consistent technology and operating foundation as requirements evolve.

Sovereignty must work across the technology stack

Sovereignty requirements vary by workload. The right level of control depends on factors such as data sensitivity, regulation, latency, connectivity, operational access, and resilience requirements. This creates a continuum, where organizations can apply different levels of control across public cloud, customer-controlled environments, and trusted partner solutions.

Delivering that flexibility requires the underlying technology layers to work together. The controls that shape where a workload runs, how data is protected, who can access it, and how the environment is verified extend across silicon, infrastructure, cloud, security, data, and AI.

This is where the Microsoft and Intel partnership comes into focus. Together, we are working to create a more consistent foundation across these layers, giving organizations greater choice in where workloads run and how they are controlled. This principle is central to the work between Microsoft and Intel. Azure Local, running on Intel® Xeon® 6 processors, brings distributed Azure infrastructure together with a common compute foundation for customer-controlled environments. Organizations can extend cloud and AI capabilities closer to their data and operations while maintaining consistent approaches to security, management, and governance.

Trust must be designed for and verified

For sensitive workloads, trust must be supported by technical protections and verifiable evidence. Organizations need to protect workloads across the technology stack and verify that systems are operating under the security conditions they have established.

That starts at the compute layer and extends through identity, encryption, governance, policy, and operations. For supported Azure Confidential VM configurations, Intel® Xeon® processors provide hardware-based protections, including Intel® Trust Domain Extensions (Intel TDX), which can help isolate workloads while they are in use. Hardware-backed attestation can provide evidence that helps organizations verify relevant security properties of the environment against their requirements. Microsoft extends this foundation through security and governance controls across cloud and customer-controlled environments.

Together, these capabilities can help organizations verify relevant security properties of the environment against their requirements. This is particularly important as AI brings regulated, proprietary, and mission-critical data into new workloads.

Each workload should receive protections proportionate to its risk. Isolation, encryption, attestation, and operational controls can be applied where they provide meaningful value while preserving a manageable operating model across the broader environment.

Digital sovereignty requires trust across the technology stack. Together, Intel and Microsoft are combining hardware-based security and confidential computing with cloud, AI and distributed infrastructure to help customers protect sensitive workloads and verify the environments in which they run. This shared foundation gives organizations greater control, confidence and choice, with the performance and scale to continue innovating as AI moves into more regulated and mission-critical environments.

—Anand Pashupathy, Vice President and General Manager, Intel Product Assurance and Security

Sovereign AI brings intelligence closer to data

Much of the data with the greatest potential for AI must remain within defined operational, regulatory, or security boundaries. This includes data tied to industrial operations, government services, clinical environments, intellectual property, and proprietary research.

Workload placement has therefore become a practical AI decision. Organizations need the flexibility to run AI closer to their data, applications, and operations. Delivering that flexibility requires infrastructure, cloud platforms, AI software, and security capabilities to work as a connected foundation.

Microsoft Foundry helps organizations build and deploy AI applications and models, with options for where AI runs based on their requirements. Foundry Local enables organizations to run AI inference in their own environments, closer to the data and applications those models rely on. On the same infrastructure, Intel Xeon 6 processors with Intel® Advanced Matrix Extensions (Intel AMX) can accelerate AI workloads directly on the CPU. Intel® OpenVINO™ helps developers optimize and deploy models across supported infrastructure.

This approach extends across the broader application environment. Organizations may need to manage AI, applications, data, development, and productivity workloads within the same governance and operational boundary. Microsoft 365 Local and GitHub Enterprise Local extend customer-controlled options to collaboration, source code, and software development workflows.

Sovereign AI brings models, data, applications, development tools, and infrastructure together under the controls each workload requires. This approach allows organizations to apply AI within the operational and governance boundaries established for their most sensitive data.

Organizations want to apply AI to their most valuable data while maintaining the controls that data requires. On supported Azure confidential VM configurations, Intel TDX helps make that possible by running AI workloads in hardware-isolated trust domains, protecting models and data while in use and isolating them from the host and hypervisor. Hardware-backed attestation then gives organizations evidence they can check against their own requirements, so they can move from trusting their environment to verifying it.

—Anand Pashupathy, Vice President and General Manager, Intel Product Assurance and Security

Sovereignty architecture must be adaptable

Sovereignty requirements will continue to change. A workload that runs in a connected environment today may face different regulatory, resilience, or connectivity requirements tomorrow. AI models, applications, and infrastructure will also continue to evolve.

A sovereign architecture must therefore provide control without creating rigidity. Organizations should be able to adapt where workloads run, how they are secured, and how they connect without rebuilding their management and security model each time requirements change.

This is another reason partnership across the technology stack matters. Alignment across silicon, infrastructure, cloud, security, and AI software can give organizations a more stable foundation even as individual technologies and workload requirements evolve.

A well-designed sovereign architecture gives organizations room to respond as regulations, technologies, and operating conditions change.

Explore Microsoft Sovereign Cloud in Europe

Discover how Microsoft Sovereign Cloud in Europe helps organizations address evolving data sovereignty, security, and compliance requirements while accelerating cloud and AI innovation.

Learn more

Three questions leaders should ask

Digital sovereignty can become abstract quickly. A better place to start is the workload.

1. What must remain under your control?

Consider the data, infrastructure, administrative access, software operations, and connectivity on which the workload depends. The answer may differ by application, even within the same organization.

2. Can you verify that those controls are working?

Policies and contractual commitments are important, but sensitive workloads may also require technical evidence. Consider how your architecture supports encryption, isolation, identity and access control, policy enforcement, attestation, and operational transparency.

3. Will the architecture leave you room to adapt?

AI capabilities, regulations, operating conditions, and workload requirements will continue to change. Your architecture should allow you to adopt new models, move processing closer to data, and adjust where workloads run without creating an entirely separate technology environment each time.

Digital sovereignty depends on cloud, infrastructure, security, AI, and silicon working together. Our collaboration with Intel gives customers a more consistent foundation across these layers, so they can apply stronger controls where needed while retaining the flexibility to innovate.

—Bernardo Caldas, CVP, Azure Edge Product Management

The strongest sovereignty strategy preserves choice

Digital sovereignty should give organizations greater control over the technology and data they depend on while preserving their capacity to innovate.

Achieving that outcome requires collaboration across the technology ecosystem. Microsoft and Intel are connecting silicon, infrastructure, cloud, security, and AI to give organizations greater flexibility in where workloads run, how they are protected, and how they evolve.

A shared foundation across these layers allows organizations to apply the right controls to each workload and benefit from advances across the broader technology ecosystem.

A strong sovereignty strategy meets today’s requirements while preserving tomorrow’s options.

Resources to learn more

• Dive deeper into digital sovereignty to learn how Microsoft is helping organizations address data residency, operational control, security, and regulatory requirements across cloud and customer-controlled environments.
• Learn more about Microsoft Sovereign Private Cloud.
• Join us at Microsoft Ignite in November to hear the latest on Microsoft Sovereign Cloud, Azure Local, AI, security, and infrastructure innovation.

Azure Local

Learn how organizations can run distributed infrastructure and applications with a consistent Azure experience

Read more

The post Designing for sovereign AI: A shared foundation from edge to cloud appeared first on Microsoft Azure Blog.

While that flexibility can be valuable, it also affects how enterprises evaluate models, where they implement safeguards, and who is responsible for maintaining those safeguards over time.

As enterprises choose which models to deploy, the relevant question is broader than whether a model is open-weight or closed-weight. Enterprises need to understand what they are using the model for, what could go wrong in that context, and what evidence and controls they need to manage risks.

Today, Microsoft and NVIDIA are publishing Risk Management for Open-Weight Models in Enterprise, the first in a planned series of joint resources intended to help enterprises address those questions. The paper introduces a shared risk taxonomy and an approach to managing model risks grounded in established standards and frameworks, including International Organization for Standardization (ISO) standards and the National Institute of Standards and Technology (NIST) AI Risk Management Framework.

The paper reflects a core idea: weight openness alone does not determine an AI system’s risk. Risk depends on the model, use case, deployment, and safeguards.

Read the whitepaper: Risk Management for Open-Weight Models in Enterprise
Understanding risk in the deployment context
Open- and closed-weight models can share many of the same underlying risks, but how those risks materialize depends on the deployment. A model used to help an employee draft a document presents different considerations than the same model used in a customer-facing workflow, just as a standalone inference endpoint differs from a system connected to external data or tools.

The architecture matters too. A risk may originate in the model, while the most effective control may sit in the inference environment, application, or surrounding operational processes. The joint guidance looks beyond the model label to factors including provenance, intended use, users, deployment conditions, and surrounding controls. This first paper focuses primarily on model-layer risks. Evaluating a model alone does not establish the safety of an agent or application: teams must also assess its permissions, data access, tools, runtime, and operational controls.

Establishing a common language
Managing these risks consistently also requires a common vocabulary across engineering, security, legal, safety, and business teams.

The initial Microsoft and NVIDIA taxonomy organizes risks into five broad categories: Cybersecurity, Data Protection, Content, Human-AI Interaction, and Bias. It is not a policy or deployment checklist, but instead it should be used by enterprises to adapt it to their own systems, use cases, and risk criteria, then connect relevant risks to evaluations, mitigations, and accountable owners.

Using evaluations as risk evidence
Evaluations help turn the taxonomy into something enterprises can use. The paper maps evaluations to a selection of risks across the five categories, giving teams a way to start with a risk that matters for their deployment and identify evaluations that can produce relevant evidence about it.

Microsoft Foundry helps enterprises assess quality, groundedness, and safety with built-in and custom evaluations and automated red teaming. Its configurable content-safety controls help detect and mitigate harmful inputs and outputs and prompt attacks. Teams should validate control availability for their model and deployment, including preview status, and combine these capabilities with application-specific testing, monitoring, and human oversight.

Evaluations still need to be interpreted in the context of a particular deployment and the goal is to make it easier for teams to connect the risks they identify with useful evidence, while building a broader set of evaluation resources that can evolve alongside models, deployment patterns, and emerging risks. Microsoft and NVIDIA plan to use the joint repository to share additional evaluations and point to existing resources that can help enterprises assess specific risks.

Accounting for changes in control and responsibility
Open-weight access gives enterprises greater control over how a model is evaluated, modified, and deployed. Model access and deployment are separate choices: open-weight models can also be used through managed platforms. Responsibility for safeguards depends on the service and deployment configuration; enterprises that operate their own model deployments may take on controls otherwise provided by a managed service.

Those safeguards can operate at different layers, and (depending on the risk) enterprises might use model changes, access controls, input and output filtering, monitoring, or human review. The important step is connecting each identified risk to controls that can effectively address it within the deployed system. Those decisions need to be revisited as models and deployments change.

Building on this work
Risk Management for Open-Weight Models in Enterprise focuses primarily on the model layer. Future work from Microsoft and NVIDIA is intended to extend this approach across the runtime, harness, and application layers, with additional technical guidance on evaluation and mitigation.

We also expect the resources supporting this work to evolve as new models, evaluations, and deployment patterns emerge. The joint repository will provide a place to share additional evaluation resources, including contributions from the broader community.

For enterprises deploying open-weight models today, the paper provides guidance they can begin applying to their own use cases. We encourage developers, security practitioners, researchers, and others working in this space to read the paper, explore the evaluations, and contribute evaluations that can help strengthen this shared body of work.

Read the joint Microsoft-NVIDIA paper, Risk Management for Open-Weight Models in Enterprise.

Explore the joint repository and technical resources.

Risk Management for Open-Weight Models in Enterprise was developed jointly by Microsoft and NVIDIA, with Andrew Berkley and April Chen of Microsoft and Michael Boone, Eileen Long, and Arun Rao of NVIDIA leading the development and editing of the paper.

Explore Microsoft Foundry evaluations and content-safety controls for implementation guidance.

To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.

The post Managing open-weight model risk in enterprise deployments appeared first on Microsoft Azure Blog.

The relationship between model innovation and AI infrastructure has never been more clear; as AI becomes more capable, the platform underneath it matters even more. Agents are fundamentally changing how applications work, and with that, what organizations need from the cloud.

Cloud-native practices gave organizations the scale, flexibility and resilience to build a generation of distributed applications. Agents build on that foundation, but they work differently, placing new demands on it. Unlike applications designed around more predictable workflows, agents behave in entirely new ways, gathering information and deep intelligence from across the business, using tools, making decisions, and coordinating work across long-running processes. To complete complex tasks, they pause for approval, respond to new information in real time and change course as conditions evolve. All this changes what the platform needs to deliver.

Customers need infrastructure that adapts as demand changes, applications that remain reliable as work becomes more dynamic, and the visibility and control to understand what is happening across the system. Meeting those needs doesn’t mean starting over, but it does require that the cloud-native foundation organizations already rely on, to evolve. Compute, storage and networking need to work together. Application platforms need to make it easier to build and run AI workloads. Open technologies need to give customers flexibility without adding unnecessary complexity.

The platform decisions organizations make today are increasingly strategic, shaping how effectively they can put AI to work for their business. Evolving the cloud-native foundation is essential to helping organizations get more from AI today while giving them the flexibility to take advantage of new capabilities as they emerge.

Optimize infrastructure for AI workloads

The true measure of AI infrastructure is the useful work it enables. AI workloads rarely place the same demands on infrastructure from beginning to end. Different parts of the work may need accelerated compute, CPUs, fast access to data or connectivity across applications and environments. The answer isn’t simply more capacity, but rather, to match the right resources to the right work at the right time.

That makes coordination across the infrastructure extremely important. Compute, storage and networking need to work together as demands change. When they do, teams can spend less time managing infrastructure and more time focused on the applications and outcomes that matter to their business.

Economics matter, too. Infrastructure needs to be tuned to the demands of the application and the business value it delivers, with the right balance of performance, reliability and cost across the complete workload.

Basecamp Research is one example. The company used Azure to assemble 9.7 trillion nucleotides for EDEN, its therapeutic-design models, and reported laboratory validation across three therapeutic applications within about three weeks. In this example, AI didn’t simply require more infrastructure, it needed AI infrastructure that was coordinated and designed around the outcome – bringing together the compute, data and platform capabilities needed to move complex work forward.

As Glen Gowers, co-founder of Basecamp Research put it: “To really be successful here, we need those three ingredients to come together. We need someone scaling the data; that’s us. But someone who really knows how to scale models and scale compute is Microsoft.”

Leadership takeaway: Measure success by the useful work AI completes. Judge infrastructure investment by the performance, reliability and cost of delivering those outcomes, with compute, storage and networking operating as one system.

Turn open-source innovation into production capability

Open technologies have long helped drive cloud innovation, and AI is accelerating that pace. New models, frameworks and cloud-native technologies give organizations more choice in how they build and adapt applications.

That opportunity builds on an established cloud-native foundation. Gartner forecasts that by 2028, 95% of new AI agent deployment will use Kubernetes.¹ Reusing established components can shorten the path to production, allowing developers to focus on differentiated business capabilities rather than rebuilding the foundation.

More choice can also bring more complexity. Taking advantage of open-source innovation often requires specialized expertise to integrate, manage and maintain technologies in production. That expertise is hard to find and even harder to scale. We need to make these capabilities accessible to more businesses, without requiring every organization to build and maintain that expertise themselves.

Azure helps reduce that burden. Services like Azure Kubernetes Service give teams access to open-source innovation while helping manage the complexity and risk of running it in production. This makes it easier for more businesses to take advantage of open technologies while preserving the flexibility to adapt with changing needs.

Leadership takeaway: Choose a platform that helps turn open-source freedom into business advantage. Preserve the ability to adapt and optimize while reducing the expertise and operating effort required to sustain those choices in production.

Align AI infrastructure costs with business value

As more organizations put AI into production, understanding the economics becomes increasingly important. AI investment starts with an expectation of business value: faster decisions, more responsive services or greater capacity to get useful work done. Then, it’s evaluating whether the value justifies the investment to deliver it. FinOps can help teams understand that return and make more informed decisions in this area.

For customers, that starts with understanding the full investment required to run AI applications and how to optimize it as workloads scale. Models represent a significant expense, with token usage and agent behavior influencing spending. Compute, storage, networking and operations also factor into the equation. Considering these together helps customers make more informed decisions about where to optimize.

Teams can’t simply place their bets on spending less. They need to carefully consider that a more capable model or additional infrastructure that costs more may be the right choice if it produces greater value long-term. Teams need to understand the full cost, establish ownership and put guardrails in place as they scale. From there, they can use business outcomes to decide where to optimize and where to invest.

Leadership takeaway: Manage AI investment against the business return it needs to deliver. Evaluate model and platform costs together, then use evidence of outcome value to decide where to optimize and where to invest.

Transform cloud operations with agentic AI

Operations teams are already stretched thin, keeping critical services running while balancing competing priorities and constant change. AI adds new complexity, and it also creates an opportunity to change how those environments are managed.

Cloud-native operations gave teams a new model for managing infrastructure, bringing increased automation, visibility and resilience. Agentic operations build on that foundation, bringing deeper intelligence across applications and infrastructure by connecting signals from otherwise disconnected systems. This helps teams identify issues earlier and resolve them faster, while increasing automation and continuously improving how their environments perform; all within the tools they already use.

Over time, AI can help operations teams move from reacting to problems toward anticipating and addressing them before they disrupt the business. As these capabilities mature, more actions can be automated within defined controls, with people remaining in the loop and accountable for critical decisions. When operations teams have greater reach without additional manual effort, reliability, performance and cost are continuously improved while critical services remain uninterrupted.

Leadership takeaway: Invest in operations that can anticipate problems and coordinate action across the environment. Expand autonomy as capabilities are validated, with clear controls and human accountability protecting critical business services.

Build a cloud-native AI foundation on Azure

Azure serves as the foundation customers need to put AI to work at scale. That means infrastructure designed around the complete workload, access to open innovation without unnecessary complexity, and a clear view of cost and business value. Greater intelligence across cloud operations helps teams anticipate issues and continuously improve how their environments perform as application needs evolve.

We’re continuing to invest in capabilities across Azure that give customers greater flexibility in how they build and run AI applications. From secure, isolated environments for agents to simpler application deployment and the ability to run workloads across cloud and edge environments, these investments help customers take advantage of new capabilities without adding unnecessary operational complexity.

AI is changing what applications can do, and Azure has already evolved to support that shift. The cloud platform has to evolve with them. Years of focused engineering investment have built the foundation for some of the most advanced AI workloads running today, with continued innovation to support what comes next.

Build for the next generation of AI

Platform value compounds when improvements reinforce one another: faster information access keeps compute productive, operational insight exposes waste, and open technologies preserve room to adapt. The leadership task is to make those gains work together. That is the next chapter of cloud native: a foundation that turns advances in AI into dependable business value.

To learn more about the recent Azure innovations and how Azure is evolving the cloud-native foundation for AI applications and agents, explore:

• Flex Nodes for AKS
• Azure SRE Agent
• Azure Container Apps Sandboxes
• Azure Container Apps Express

Explore what this means for your organization. Register for our upcoming discovery session to learn how to put a cloud-native foundation for AI applications and agents into practice.

Build your AI foundation

Learn how to put a cloud-native foundation for AI applications and agents into practice in our upcoming discovery session.

Register now

¹ Gartner®, Magic Quadrant™ for Container Management, Dennis Smith, Wataru Katsurashima, et al., 6 August 2025

GARTNER and MAGIC QUADRANT are trademarks of Gartner, Inc. and/or its affiliates.

The post Evolving the cloud-native foundation for the next generation of AI appeared first on Microsoft Azure Blog.

From choosing a hypervisor to choosing an operating model

For years, the primary virtualization decision was which hypervisor to run. Today, the more consequential decision is how infrastructure will be operated across every environment the business depends on. Virtualization remains a critical foundation, but the value of the platform increasingly depends on how infrastructure is managed, governed, secured, updated, and connected across environments. As infrastructure becomes more distributed, how it is operated becomes as important as where it runs.

Microsoft delivers that consistency at two complementary levels:

• Operational consistency: Azure provides common management, governance, and security across cloud, datacenter, and edge environments. Azure Arc extends those capabilities to distributed infrastructure, giving organizations a unified way to operate diverse environments.
• Infrastructure consistency: Hyper-V provides a common virtualization foundation across Azure, Azure Local, and Windows Server, helping organizations maintain a consistent infrastructure layer wherever workloads run.

Together, these layers help organizations preserve choice without multiplying operational models. Workloads can move, environments can evolve, and new technologies can be adopted without requiring a separate operating model for every environment.

Ready for what comes next

Operational and infrastructure consistency will become even more important as AI reshapes enterprise IT. Models, agents, applications, and data will increasingly span cloud, datacenter, edge, and sovereign environments. AI alone will not reduce the complexity of distributed infrastructure; in many cases, it will increase the need for common management, governance, security, and infrastructure foundations.

Being named a Leader in this Magic Quadrant is an honor for us. More importantly, we believe it reflects a direction many organizations are pursuing: operational consistency across increasingly distributed environments. We remain committed to helping customers combine the flexibility to run workloads where they choose with the consistency required to manage them as one environment.

Recognized as a Leader

in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms

Read the report

Gartner, Magic Quadrant for Server Virtualization Platforms, Tony Harvey, Daniel Bowers, Paul Delory, Tony Iams, Owen Marino, 14 September 2026.

Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.

Gartner and Magic Quadrant are trademarks of Gartner, Inc., and/or its affiliates. This graphic was published by Gartner, Inc. as part of a larger research document and should be evaluated in the context of the entire document. The Gartner document is available upon request from Microsoft here.

The post Microsoft named a Leader in the 2026 Gartner® Magic Quadrant™ for Server Virtualization Platforms appeared first on Microsoft Azure Blog.

The motivation behind Project Tessera is straightforward: the entire industry benefits when we collaborate and advance hardware security together.

Project Tessera carries forward the workload directly attached to the HSM architecture introduced by Azure Integrated HSM, making the architecture, specifications, protocols, drivers, software, firmware, and reproducible build environments open source for the broader community. Over time, the initiative will advance toward a fully open-source silicon implementation, while making hardware broadly available, enabling organizations across the ecosystem to adopt, integrate, and contribute to the platform.

This approach builds on the model Microsoft established with other industry collaborators on Caliptra, a fully open-source silicon root-of-trust that has since been broadly adopted across the hardware ecosystem. Through Project Tessera, industry leaders including Microsoft, Marvell®, Oracle, and the Open Compute Project will apply that same model of transparency and collaboration to advance hardware key protection with the industry.

The cybersecurity landscape is rapidly changing, and protecting keys and credentials has never been more important. We are now facing two generational transformations that are fundamentally reshaping how we view the cybersecurity landscape:

1. AI is increasing the speed and scale of cyberattacks
   
   AI-orchestrated attacks are increasing the scale, speed, and sophistication of attacks, giving adversaries new ways to operate and compressing the time between vulnerability discovery and exploitation. These capabilities amplify risks such as credential theft, key exfiltration, and signing abuse.
   
   Keys and credentials are high-value control assets. When compromised, they can enable attackers to impersonate trusted entities, bypass security controls, authorize malicious operations, expose sensitive data, and undermine software security defenses. Protecting these assets requires infrastructure with layered, hardened protections capable of withstanding sustained attacks across multiple concurrent attack vectors.

2. Quantum computing is changing the cryptographic risk horizon
   
   Quantum computing promises transformative advances, but it also presents a risk to many of today’s cryptographic algorithms. A sufficiently powerful quantum computer could break widely used public-key cryptography, undermining digital signatures, authentication, and identity verification.
   
   Post-quantum cryptography was once viewed as an important but distant technology shift. Advances in quantum computing have changed that perspective as organizations recognize the urgency, scale, and complexity of the transition. HSM-backed signing infrastructure will be among the first critical systems to migrate, requiring HSMs that support post-quantum cryptography and are interoperable with classical HSMs to support migration.

These emerging threats motivated the development of Azure Integrated HSM, which was designed to meet rigorous security standards for hardware-based key protection, while also accelerating Microsoft’s transition to post-quantum cryptography through scale deployments of quantum resilient integrated HSMs.

Azure Integrated HSM introduced a workload-attached HSM that performs cryptographic operations closer to the workload while keys remain continuously protected within the HSM security boundary. This architecture strengthens key protection, improves cryptographic performance, offers crypto-agility, and provides a simpler operational model.

Tessera is an evolution of Azure’s first integrated HSM model, incorporating insights gained from deploying Azure Integrated HSM at scale, and advances the technology through collaboration in the Open Compute Project, with the goal of broadly addressing the challenges of key and credential management in the era of AI and quantum computing.

Eliminating key management anti-patterns

In central HSM deployment models, HSM infrastructure is separate from compute resources, requiring cryptographic operations to traverse the network. The resulting latency and operational dependencies can lead enterprises to adopt workarounds that improve performance or availability but unintentionally weaken key protections. Some of these common key-management anti-patterns include:

• HSM keys may act as certificate authorities and endorse externally generated keys. These keys can then serve as trusted delegates without receiving the same hardware protection.

• HSM generated keys may be created as extractable and exported from the HSM in wrapped form. When used outside of the HSM the keys may not receive assurance levels equivalent to a FIPS 140-3 Level 3 HSM and become more susceptible to exfiltration or misuse.

Other anti-patterns include caching keys outside of HSMs for resilience, using software-held keys to reduce network latency to remote HSMs, sharing keys and security domains to simplify governance, and relying on proprietary protocols for interoperability. These practices intend to prioritize operational flexibility but can make key protection, policy enforcement, and auditable provenance less consistent across environments, undermining the security value HSMs are designed to provide.

The goal of Project Tessera is to advance the integrated HSM model to address these challenges in the industry, without compromising on security. The project will deliver Tessera Integrated HSM, a fully open-source integrated HSM designed to consistently enforce FIPS 140-3 Level 3 key protection throughout the key’s lifecycle.

By combining strong hardware-rooted protection with an open-source implementation and open protocols, Tessera Integrated HSM creates a path toward greater transparency, interoperability, and innovation across the HSM ecosystem. The native support for quantum-resilient cryptography will help ease the industry’s transition to post-quantum cryptography.

Demonstrating an open, interoperable HSM ecosystem

Today at the Open Compute Project Global Summit, Microsoft and Marvell® demonstrated the Tessera Integrated HSM transfer protocols establishing HSM partition cloning and resiliency rings across a Tessera Integrated HSM and a Marvell® LiquidSecurity® 2 HSM. The demonstration showed how two heterogeneous HSMs can operate in a resilient and unified security domain. Non-extractable keys within the security domain always remain protected within the HSMs and are available only to the authorized HSM partitions participating in the security domain and remain under the sole control of the partition owner.

The Tessera Integrated HSM protocols use post-quantum cryptography to protect communication between HSMs. This enables authorized workloads with a Tessera Integrated HSM to use both classical cryptography and post-quantum cryptographic services while their keys remain secured within the HSM boundary and can only be authorized for use by the key owner.

The Project Tessera specifications, protocols, software libraries, drivers, firmware, and hardware are available through the Tessera Integrated HSM GitHub. Going forward, this repository will add more open-source silicon, new hardware designs, and enhancements developed with the community.

Expanding Project Tessera through confidential computing

The early collaborators working on Project Tessera within the OCP community are exploring how the Tessera Integrated HSM key protection architecture can extend beyond systems with dedicated integrated HSM hardware. As part of this work, the project is making a minimal, unikernel-based Tessera firmware stack open source, designed to run within hardware-isolated confidential computing environments.

This implementation uses the same firmware stack as the hardware integrated HSM, extending a common security architecture across HSMs and confidential computing environments. In this model, cryptographic keys are protected within a confidential computing container, which provides cryptographic services to securely bound workloads, including worker containers and virtual machines. The initial implementation leverages AMD SEV-SNP and integrates with open-source virtualization technologies such as OpenVMM, with the Open Compute community working to extend support to other confidential computing architectures.

The complementary deployment models in Project Tessera extend strong key protection across systems with different hardware capabilities and assurance requirements. For platforms without dedicated integrated HSM hardware, confidential computing provides broadly deployable, hardware-isolated key protection with a minimal trusted computing base.

Project Tessera provides the highest level of hardware assurance, protecting keys within a dedicated, tamper-resistant security boundary designed to meet demanding certification requirements, including FIPS 140-3 Level 3 and Common Criteria.

The deployment models share the same Project Tessera firmware and programming model, giving organizations a consistent foundation for cryptographic security across their infrastructure while providing a natural path to integrated HSM and higher levels of assurance in newer systems.

Together, these models make strong key protection accessible across a broad range of systems with different security assurance needs, all built on a common, open architecture. As the Open Compute Project community continues to advance Tessera Integrated HSM, we see an exciting opportunity for broader industry collaboration to strengthen key protection, expand secure key management, and accelerate innovation across the ecosystem.

For more information, visit the Microsoft booth at the Open Compute Project Global Summit for live demonstrations, explore Tessera Integrated HSM implementation on GitHub, and read the Microsoft Infrastructure Community blog for additional hardware security announcements: OCP2026 Hardware Security Updates.

Check out Microsoft’s presence at OCP Summit this year: aka.ms/OCP2026

Learn more about Azure Infrastructure: aka.ms/silicontosystems

The post Advancing hardware security with open-source Integrated HSM technology appeared first on Microsoft Azure Blog.

But realizing that potential requires frontier infrastructure. The next phase of Super Intelligence needs a unified infrastructure engine that delivers more intelligence with greater efficiency, making AI more available, reliable, and sustainable across science, healthcare, education, and the economy. This is the work of an entire ecosystem, and precisely the vision we have advanced for years through our industry collaboration within the Open Compute Project Foundation.

Designing silicon in the loop with real workloads

As we enter the next phase of Super Intelligence, inference is becoming the dominant workload and that’s where efficiency, latency, and cost really matter. Azure Maia 300, our next generation AI accelerator from our Maia family, advances the inference efficiency frontier. Maia 300 is a complete system designed for the new types of AI workloads emerging today: long-context reasoning, latency-sensitive conversational experiences, and sustained, multi-step agentic tasks. By improving efficiency across the system, we expect Maia 300 to deliver 40% more tokens per watt compared to leading GPU-based systems. And in a full 96-accelerator configuration, it delivers up to seven times the rack-scale token throughput of Maia 200.

Maia reflects our system co-design approach. It is designed alongside Microsoft infrastructure and production workloads, bringing models, application frameworks, kernels, communication libraries, systems software, and custom silicon into one optimization loop. Maia 200 is deploying across the United States, Europe and Australia and delivering up to 1.7x more tokens per watt for built-in AI capabilities in Microsoft Teams, Copilot and Cowork experiences compared with leading GPU infrastructure.

AI is not only about accelerators. Agentic workloads create entirely new demands on CPUs. Every agent interaction generates orchestration, data retrieval, memory management, and service calls that must occur quickly and efficiently. That is why we designed Cobalt 200 as an agent-native CPU. Cobalt 200 delivers more than 50% performance improvement over Cobalt 100 and reduces agent call latency by 33%, while providing 23% higher throughput on agentic workloads.

Maia and Cobalt are designed in the loop with our largest enterprise workloads. That gives Microsoft a unique advantage in tuning performance, reliability, and cost to exactly what customers need in production.

We are applying the same principle to storage and security. The Azure Boost Data Processing Unit moves compression, networking transactions, and security functions away from the CPU onto purpose-built silicon, enabling us to deliver four times more performance while using significantly less power.

And Azure Integrated HSM makes security part of the hardware foundation, with our in-house security chip in all new datacenter servers. It brings cryptographic operations closer to the workload while keeping keys protected inside the hardware security boundary—not exposed in application memory.

Building an open, resilient AI fabric

Compute creates intelligence and networks make it usable at scale.

Working with industry partners, Microsoft developed Multipath Reliable Connection (MRC), rethinking Ethernet for AI. Its multi-plane architecture scales beyond 100,000 GPUs with two network tiers, reducing power, complexity, failure points, and cost. By intelligently distributing traffic across multiple paths and through packet spraying, MRC limits congestion and maintains reliable performance for frontier-scale training.

We are also advancing open scale-up connectivity through Optical Compute Interconnect Multi-Source Agreement (OCI MSA). OCI, the first optical specification for multi-rack scale-up systems, enables high-bandwidth, power-efficient, multi-vendor infrastructure. Moving forward, we will continue to work with the industry to expand participation in OCI MSA.

In parallel, The Ethernet for Scale-Up Networking (ESUN) workstream brings together more than 175 organizations to define requirements for Ethernet-based scale-up networking. The group has released specification version 1.0 and is developing version 1.1 for later this year. Read more about our networking innovations with the open community.

Rethinking power from grid to silicon

AI infrastructure is also forcing a fundamental redesign of power delivery. Through OCP and the Open Systems for AI initiative, Microsoft is helping advance the industry’s transition toward 800 volt direct current (VDC) infrastructure.

Mt. Diablo, Microsoft’s disaggregated high-voltage datacenter (DC) sidecar architecture, separates power conversion from the compute rack so each can scale independently. It includes a modular design supporting approximately 100 kilowatts (kW) to beyond one megawatt (MW), with redundant feeds, telemetry and optional energy storage. Microsoft, together with OCP partners, contributed Mt. Diablo specifications v0.7 and v1.0 to OCP.

Microsoft and its partners are advancing solid-state transformer-based architectures to make power conversion more efficient, responsive, and scalable for next-generation 800 VDC datacenters. Through OCP’s Clean Backup Power initiative, we are developing open requirements for reliable backup systems that reduce reliance on diesel. In parallel, Microsoft collaborated with partners to release a common grid-interface specification to align utilities, operators, and equipment vendors as hyperscale power architectures evolve. Read more about Microsoft’s approach to 800VDC transition and scaling power infrastructure sustainably.

Cooling as a first-class design consideration

Microsoft approaches cooling as a datacenter-wide challenge, driving innovation from DC facility design to rack-level liquid cooling technologies.

Our third-generation Azure Heat Exchanger Unit, Mt. Atlas, nearly doubles cooling capacity compared to the previous generation while maintaining the same operational footprint. We are also contributing public reference architecture through OCP to help accelerate industry adoption.

At the datacenter level, Microsoft is advancing a zonal cooling strategy in its next-generation AI datacenters to handle the growing mix of liquid-cooled accelerators and traditional air-cooled systems. By tailoring cooling to the specific needs of each workload, and introducing multiple independent water loops, each supplying coolant at different temperatures, we aim to increase efficiency and performance while supporting Microsoft’s energy, carbon, and water reduction goals.

Open hardware security innovation

Microsoft believes strong cloud security is built through openness, transparency, and industry collaboration. This principle is reflected in our founding role in the Confidential Computing Consortium, our work to establish Caliptra as an open-source silicon root of trust, and our contributions to the OCP S.A.F.E. security conformance framework. As AI reshapes the cybersecurity landscape and advances in quantum computing introduce new cryptographic risks, protecting the keys and credentials at the foundation of digital trust has never been more important.

To address these challenges, and building on our commitment to security transparency and industry collaboration, Microsoft, Marvell, and Oracle are introducing Tessera Integrated HSM, an open-source initiative for integrated hardware security modules. Tessera Integrated HSM carries forward the workload direct attached HSM architecture introduced by Azure Integrated HSM, open-sourcing its architecture, specifications, protocols, drivers, software, firmware, and silicon to the broader community. Learn more about Tessera Integrated HSM.

Fleet resiliency at scale

As AI infrastructure scales, fleet reliability is essential to protecting customer workloads, capacity, and service quality. Through OCP, Microsoft has published common RAS, debugging, telemetry, and diagnostics specifications, while contributing work on hardware fault management, CPU and GPU management, and fleet memory fault management. We are using years of fleet data and using AI to validate, predict, and drive fleet actions aimed at preventing faults, pinpointing issues, and recovering more autonomously. Learn more about how Microsoft is advancing fleet reliability through industry collaboration.

Advancing sustainability across the infrastructure stack

Scaling AI responsibly means considering the full datacenter lifecycle to help reach our 2030 commitments to be carbon negative, water positive, and zero waste. As a company, we are committed to incorporating sustainability into how we design, build, and operate our datacenters extending to the communities where we build them. Through OCP, Microsoft is collaborating with partners on low-embodied-carbon steel and concrete—with pathways to reduce concrete emissions by more than 50% per cubic yard.

We are advancing waste-heat reuse, and helping develop Cloud Services Product Category Rules for consistent, auditable lifecycle-carbon reporting. Inside our datacenters, closed-loop liquid cooling, intelligent power management, and renewable-energy agreements help reduce resource use, while Circular Centers reuse or recycle more than 90% of servers and components. Beyond the datacenter, we are investing in local skills, partnerships, and infrastructure so the communities hosting this growth can grow with us. Read Microsoft’s 2026 Environmental Sustainability report.

Building the frontier together

Our vision is to help every organization become a Frontier Firm, uniting human expertise with AI in a continuous learning loop that turns knowledge and ingenuity into scalable intelligence. Realizing that vision requires full-stack co-design: silicon, compute, memory, networking, power, cooling, models, and applications working as one secure, reliable, efficient, and sustainable platform while giving customers choice without passing complexity on to them.

Such a future cannot be realized by a single organization. Through OCP, we are advancing open interfaces, sharing lessons from operating infrastructure at global scale, and collaborating across the industry so innovation moves faster, and the ecosystem stops solving the same problems repeatedly. Together, we can transform frontier innovation into infrastructure that makes intelligence accessible and affordable for every organization, in every industry, and across every region of the world.

At OCP Global Summit 2026, we invite the community to build that future with us.

Build for what’s next

Learn more about Microsoft’s systems approach to infrastructure.

Start here

The post Infrastructure for the frontier era: Scaling intelligence through open industry collaboration appeared first on Microsoft Azure Blog.

That system-level approach is increasingly necessary as agentic workloads, including multi-step execution, long-context decoding, and tool use, change the computational profile and arithmetic intensity of inference. Meeting these demands requires sustaining locality, supplying compute with enough memory capacity and bandwidth, minimizing data movement, scaling communication efficiently, and fitting the most capability within a datacenter’s fixed power and cooling envelope.

At Microsoft, we see this transformation firsthand through the products and platforms our customers use every day, from Microsoft Copilot and GitHub Copilot to Microsoft Foundry. Operating these workloads at scale gives us a unique view into how AI is being adopted across industries and the infrastructure needed to support the next generation of AI applications and agents. Maia 300 is designed to maximize useful tokens per watt and useful tokens per dollar, bringing more capacity, capability, and performance to these products and Microsoft’s broader AI portfolio for our customers.

Energy-efficient inference through software-defined dataflow

Maia 200 introduced a new class of accelerator architecture called Software Defined Locally Accessed Dataflow Architecture, or SDLA. It begins with the observation that efficient data management, including storing, moving and converting data, is one of the central challenges in modern AI systems. The Maia programmable dataflow architecture separates control path programming from data path execution and allows software to explicitly coordinate data placement, movement, conversion and synchronization across specialized local memories, DMA engines, compute engines, and the network.

Maia 300 evolves this architecture for long-context, reasoning-intensive, and decode-heavy inference. First, memory moves from the uniform memory access (UMA) organization of the SoC to a locality-aware non-uniform (NUMA) organization across chiplets, so software can place data near the compute that uses it. Second, new narrow-precision formats with hardware-accelerated data type conversion reduce the bytes moved for each token. Third, the rack doubles to 96 accelerators and the scale-up domain grows to a superpod of 12,288 accelerators, enabling more accelerators to work effectively as a single system.

Rather than scaling performance through increased power and silicon area alone, Maia 300 improves performance per watt through a set of architectural innovations that optimize data movement, locality, precision, and memory efficiency across the system:

• Multi-chiplet architecture boosts performance by placing compute on TSMC N2P, where the advanced process delivers the greatest performance-per-watt benefit, while separating memory-controller and I/O functions onto dies optimized for bandwidth, connectivity, and cost. This increases the silicon area dedicated to compute performance and allows each function to use the technology best suited to its role, while SDLA manages locality and data movement across the package. This strategy increases the system’s compute FLOPs by 36%, adds 2.5 times HBM bandwidth, and provides 14% more scale-up bandwidth.
• Optimized low precision inference, introducing enhanced MXFP4 and sub-3-bit storage formats. Narrower representations reduce memory footprint and data movement, allowing the system to support larger models, longer contexts, and more concurrent sessions within the same power envelope.
• Optimized inference kernel through ISA enhancement: The vector engine adds optimizations for key inference kernels, including softmax, low precision data casting, and other operations.
• Efficient on-die data movement, Maia 300 changes memory from a uniform organization to a non-uniform (NUMA) one across chiplets. Each compute region has nearby memory, and SDLA’s explicit control over DMA engines, local SRAM, HBM and the network-on-chip places data next to the compute that uses it. Data travels shorter distances, which reduces the energy spent moving it.
• Memory hierarchy optimized for bandwidth per watt, combining software-managed on-die SRAM with eight HBM4 stacks providing 288 GB of capacity and 18 TB/s of bandwidth per accelerator. Compared with Maia 200, this delivers 2.5 times the memory bandwidth, 33% more capacity, and approximately 2 times the HBM bandwidth per watt, keeping more model and KV state close to compute.

Maia 300 brings 2.5 times the memory bandwidth, 33% more capacity, and approximately 2 times the HBM bandwidth per watt compared with Maia 200

One scale-up fabric: From pod to superpod

Maia 300 makes the network a native extension of its software-defined dataflow architecture. Maia’s AI network controller implements custom AI transport based on Ethernet. A two-tier network builds a high-performance superpod with up to 12,288 accelerators. Maia presents one communication model to software—the same semantics to move data directly to any accelerator within a superpod.

• Half-switched in-rack topology
  Each accelerator divides its scale-up connectivity between direct links and switched paths. Direct links connect two accelerators in a tray, while the switched fabric connects all 96 accelerators in the rack to form a pod. All in-rack connectivity uses electrical links to reduce power and cost.
• Optical second tier across racks
  Second-tier switches connect up to 128 racks together to form a superpod. Optics provide the reach required to extend scale-up network across the pods.

• One fabric rather than separate scale-up and scale-out domains
  Integrated network controllers and specialized AI transport use the same communication semantics inside the pod and across the superpod. Maia accelerators can directly initiate communication to any accelerator in the superpod, without involving the host or a discrete scale-out NIC.
• Low-hop communication paths
  There are three latency domains: A direct connected accelerator pair is the lowest latency domain, then accelerators within a pod are one switch hop away, and any accelerator across pods is three switch hops away. Software can keep latency-sensitive tensor-parallel traffic local within the lowest latency domains.
• Bandwidth allocated to the workload
  The bandwidth split between in-rack and cross-rack bandwidth per accelerator is not fixed at the system design time. It becomes a parameter that is set based on job packing. An accelerator can drive up to 750 GB/s to any peer within the superpod, when only a subset of accelerators are going cross-rack. Refer to the spare tray example below.
• Flexible job placement
  Tensor parallelism can remain within the 96-accelerator rack, while wider expert and pipeline parallelism span racks. Jobs can use capacity across rack boundaries, reducing stranded accelerators when workload sizes do not align with the physical rack configuration.

• Disaggregated inference within the scale-up domain
  Prefill and decode workers can be sized and placed independently. After prefill computation completes, KV state moves directly to the selected decode workers over the same scale-up fabric rather than leaving the domain through a separate host-mediated scale-out path.
• Resilience across racks
  When accelerators become unavailable, schedulers can use hot-spare capacity in another rack within the superpod transparently to software kernels. The workload remains on the scale-up fabric, trading additional path latency for improved availability and resource utilization.

Rack-scale architecture for deployment efficiency

At datacenter scale, efficiency is determined by how much useful infrastructure can be deployed and operated within a fixed power and cooling envelope. Building on the foundational energy efficiency of the Maia SoC architecture, the Maia 300 rack co-designs server layout and density, network topology and switching, power and cooling design, and advanced telemetry to deliver up to 2.5x more performance per watt compared to Maia 200.

• 96 accelerators within 167 kW
  Maia 300 integrates 96 accelerators across 24 four-accelerator trays within a 167-kW rack, doubling the accelerator density of Maia 200. Each tray incorporates four accelerators with its host processor, memory, storage, and cooling. Eliminating separate host trays frees rack space and allows power and thermal resources to be managed as one system, increasing the inference capacity deployed within each rack.

• Consolidated switch architecture
  Six high-radix switch ASICs are integrated into three liquid-cooled switch trays, providing the rack-local connectivity required by all 96 accelerators while minimizing the space and power consumed by switching.
• Rack-level power delivery
  Dual power feeds, high-capacity power shelves, and a 50 V busbar architecture distribute power efficiently across accelerator and switch trays while providing operational redundancy. The integrated rack automatic transfer switch maintains high availability even when a single power feed is offline for servicing.
• Flexible cooling architecture
  Liquid cooling removes more than 80% of the rack’s thermal load from accelerators, voltage regulators, and switch ASICs, while air cooling supports memory, storage, and other ancillary components. Maia 300 can connect directly to facility water where it is available or use a heat-exchanger unit to reject heat in air-cooled datacenter environments. This provides greater flexibility in where and how the system can be deployed at scale.
• Datacenter-integrated telemetry
  We have incorporated deployment learnings to strengthen reliability, availability, and serviceability (RAS), observability, debuggability, fault handling, and redundancy, improving robustness as we deploy additional volume. Rack and row level power telemetry connect with datacenter operations, enabling operating points to be managed against available power and cooling capacity. This data informs algorithms that dynamically allocate power and optimize workload placement and deployment density, improving utilization and tokens delivered per watt.

What Maia 300 delivers

Maia 300 is the next step in a multigenerational program to deploy efficient AI systems at scale. The design is optimized end to end across software, silicon, physical rack infrastructure, networking, and datacenters to deliver a leap in performance and efficiency for cloud-scale agentic inference.

Relative to Maia 200, Maia 300 delivers up to 7 times greater rack-scale token throughput in its full 96-accelerator configuration and more than 2.5 times the performance per watt. It brings more memory bandwidth per watt and twice the accelerators per rack, while building on SDLA, our software-defined dataflow architecture and a two-tier scale-up network to support a single programming model spanning kernel to data center scale. Together, these advances enable us to deliver more useful intelligence, more efficiently, to more people and organizations.

Maia 300 delivers up to 7 times greater rack-scale token throughput and more than 2.5 times the performance per watt compared with Maia 200

The opportunity ahead is not simply to build more compute. It is to make advanced AI capabilities more accessible, affordable, and useful. Maia 300 is an important step toward that goal.

Next month at Microsoft Ignite 2026 in San Francisco and online, we’re looking forward to sharing more information on our AI strategy, technology adoption trends, and success in Frontier Transformation.

Read about the latest Azure Maia 300’s news here.

Learn more about Azure Maia 300 here.

Learn more about Azure’s silicon to systems approach here.

The post Deep dive into Azure Maia 300 architecture appeared first on Microsoft Azure Blog.

This feedback matters because the system never stands still. Demand shifts, component constraints emerge, new capacity comes online, and hardware requirements evolve across the fleet. Keeping infrastructure reliable means continually learning and adapting as requirements change.

At Microsoft, Azure Hardware Systems and Infrastructure works across that lifecycle, from systems architecture and design through supply chain, deployment, and fleet operations across Azure’s more than 80 regions and 500 datacenter campuses. This end-to-end view gives us an opportunity to connect insights across the hardware lifecycle, so what we learn in one part of the system can improve decisions across the others.

AI can accelerate that learning. Across our own AI transformation, we are applying agentic and AI tools to help teams connect information, understand what is changing, and act sooner while keeping human judgment at the center. The opportunity is bigger than making individual tasks faster. It’s to build a system that learns from how infrastructure is designed, sourced, and operated, and applies those learnings to what comes next. This approach is part of our broader AI transformation journey.

Start with the work, not the AI

This process has reinforced a critical lesson as we’ve scaled how we apply AI as a force multiplier across our cloud infrastructure: AI transformation starts with the work, not the technology. Speed matters, but the greater opportunity is to redesign how decisions are made: what information is available when a decision needs to happen, how quickly teams can understand what changed, and where human judgment matters most.

Our cloud supply chain is a good example of this principle in practice. Every month, demand-planning teams forecast Azure’s infrastructure needs years into the future, accounting for changing customer demand, regional needs, installed capacity, and decommissioning activity. When a plan changes, determining why could require reconciling information across multiple systems, turning a single investigation into a lengthy process. It was tempting to look at that work and ask where we could add an agent.

For any company, putting AI on top of a fragmented process can simply make the fragmentation move faster. Before applying AI, our teams mapped and simplified the work, established a shared data foundation with quality, governance, and access controls, and identified decisions where people needed to remain accountable. We call this approach “Lean before AI.”

Starting with end-to-end processes and taking an AI-driven approach provides new ways of working and moves teams to parallel execution rather than sequential handoffs, resulting in integrated, collaborative workflows.

From days of research to decisions in minutes

With this foundation in place, we approached demand planning differently. A multi-agent workflow can examine signals such as installed-base shifts, regional demand, and decommissioning changes, then help planners understand what changed, where, and what drove the movement. Work that previously took five to seven business days can now be completed in hours, and sometimes in less than 20 minutes. Across more than five monthly planning cycles, our full demand-planning team saw approximately 50% less manual effort and cycle time fell by up to 75% in selected workflows.

The same pattern is taking shape across planning, product data, sourcing, fulfillment, logistics, and operational workflows. Specialized agents are helping teams spend less time finding and reconciling information and more time applying expertise.

In fulfillment, understanding why rack delivery is blocked from meeting customer demand could require teams to pull information manually from multiple sources. An intelligent assistant now brings together information about blockers and compatible or incompatible supplies, saving investigation time by as much as 55%. In logistics, an AI-powered logistics agent brings together data across air, land, and sea options to help teams evaluate speed, cost, as well as carbon tradeoffs and forecast emissions.

Building the learning loop

These individual applications matter, but the larger opportunity is to connect them. Our cloud supply chain team is moving toward end-to-end multi-agent workflows across bill-of-materials generation, capacity delivery, spare-parts management, capacity docking, and sales and operations execution. This work reflects a broader shift in our business: moving beyond isolated experiments toward a faster, more resilient, and intelligent operating system that places human judgment at the center.

The important outcome is not simply speed. Planners can begin with connected evidence instead of spending days assembling it, giving them more time to examine the explanation, add business context, and determine what it means for the decision ahead.

That is the learning loop we want. AI helps people reach the evidence faster. People bring context and judgment, act on what they learn, and create new information that can improve the next decision.

Learning across the fleet

The hardware lifecycle does not end when a server reaches a datacenter. Once infrastructure is deployed, the challenge becomes keeping it operating reliably for customers. Across millions of nodes in our fleet, continuous monitoring generates signals that help our teams investigate issues and determine root causes to decide how to act.

Across Azure, we’re moving cloud reliability upstream—transforming fleet management from reactive firefighting into a closed-loop system that prevents defects, predicts failures, and automatically restores hardware back into service. As we move toward a self-healing fleet, we are applying the same principles: connecting data across the lifecycle, continuous evaluation, redesigning workflows for human-agent orchestration, and keeping engineers in control of production decisions. Ultimately, this is also when the next learning cycle begins: systems collect and analyze information about the fleet, and failure patterns become evidence for how suppliers design and build the next generation of hardware.

Azure failure prediction and detection uses AI to analyze fleet telemetry so teams can identify emerging hardware failure patterns sooner and take action before potential issues impact customers. Engineers retain oversight of production decisions. This has already resulted in a 92% reduction in disk-related virtual machine (VM) interruptions and reduced repair time on out-of-service nodes by 53%. For rack managers, prediction provides up to three days of advance warning, enabling proactive recovery that cuts out-of-service repairs by 40%.

We also proactively and periodically screen our fleet to identify hardware vulnerable to silent data corruption before customer workloads are deployed, helping strengthen platform reliability.

We are also developing workflows that preserve context as hardware moves through investigation and recovery. For faulted resources, these workflows track assignment, action, outcome, and next step, with policy and approval controls around fleet actions. History and outcomes can then inform future decisions.

This is where the broader systems story comes together. Demand-planning decisions influence sourcing. Logistics affects when capacity reaches a datacenter. Once hardware is running, fleet telemetry and operational outcomes create another source of learning. Information about component performance can help teams proactively address potential issues before customers experience them. Those insights can also feed forward into the next generation of silicon, system, and rack design, while giving suppliers information to improve future components.

AI can make that loop faster, but the value comes from helping the system work better as a whole.

What we learned when things did not work

Some of our most useful lessons came from approaches that fell short.

We learned that applying AI to one part of a fragmented process can accelerate that task while creating more work somewhere else. An agent might produce its output faster, but if a downstream team must interpret, reformat or reconcile it manually, the workflow as a whole has not improved.

That changed how we measured success. Instead of evaluating only the task an agent performs, teams must examine the full workflow: the work removed, the new work created, the quality of the decision, and the outcome.

Reliable, accessible, and well-governed data is a prerequisite, not an afterthought. AI cannot compensate for conflicting definitions, unclear permissions, or information isolated across systems.

And we learned not to become attached to a particular architecture or agent. Models, frameworks, and business needs continue to change. A solution that is useful today may need to be redesigned six months from now or retired if the original business need no longer applies.

The resulting rhythm is practical: begin with a consequential decision, simplify the work around it, connect the right governed data, build alongside the people who know the work, evaluate the complete outcome, and keep changing as the business and technology evolve.

What we measure next

The next phase of enterprise AI will require us to measure more than adoption: how many people use an agent, how many agents are deployed, or how much time they save. Those measures matter, but they don’t tell us whether the work itself has improved. Can a planner understand in minutes a change that once took days to explain? Can a fulfillment manager resolve a capacity blocker without manually reconciling information across systems? Can an engineer identify a potential hardware problem before it becomes a customer problem? And can teams apply their expertise, so the next decision is better than the last?

That is the direction we are pursuing: a way of working that keeps learning as the technology and the business change. We are not trying to build the largest collection of agents or automate decisions simply because we can. We are working to produce more useful output from the infrastructure, information, and expertise already in the system.

If AI is going to change what the world can build, we need to keep evolving how we build the infrastructure behind it. By connecting insights across silicon, systems, supply chain, and fleet operations, each stage can help improve the next. The result is reliable infrastructure ready when customers need it, and a system that learns how to deliver it better with every cycle.

Azure infrastructure

Learn more about Microsoft’s systems approach.

Get started

The post AI transformation across the infrastructure lifecycle: From supply chain to fleet operations appeared first on Microsoft Azure Blog.