Azure News - 2026-10-14

At the Open Compute Project Global Summit, we introduced six open security innovations spanning hardware-protected key management, platform resilience, system-wide attestation, scalable bare-metal management, recovery, and silicon hardening:

• Tessera Integrated HSM, an open-source silicon HSM designed to scale with modern workloads while protecting keys and credentials to the highest industry standards.
  
  
• Platform Integrated TPM, a system TPM designed to improve security and recoverability while maintaining always-available host system measurements
  .
• Composite Entity Attestation Token (EAT), a whole-system attestation solution that aggregates attestation evidence from components across the system.
  
  
• Hierarchical Hardware Management, an architecture for modular hardware management that separates control environments for system and control plane.
  
  
• Network Recovery, an extension of OCP Streaming Boot that enables immutable BMC recovery through a unified boot and recovery path.
  
  
• Caliptra 2.2, scheduled for release in December, adds USB Streaming Boot and a smaller, fully masked Adams Bridge post-quantum cryptography accelerator.

Together, these technologies advance hardware security and resiliency.  Each section below explains one innovation, the challenge it addresses, and how it contributes to the broader design.

Tessera Open Integrated HSM

Tessera Integrated HSM is an open-source silicon HSM initiative developed by Microsoft with Marvell®, Oracle, and the Open Compute Project.  It represents an evolution of the Azure Integrated HSM workload-attached architecture, opening its specifications, protocols, drivers, software, firmware, and reproducible build environments, with a path toward fully open-source silicon. Building on the collaborative model established with Caliptra, Tessera Integrated HSM extends this approach to hardware key protection, enabling greater transparency and interoperability across the ecosystem.

Tessera Integrated HSM is designed for a security landscape being reshaped by AI and quantum computing. As AI increases the speed and scale of cyberattacks, protecting cryptographic keys, credentials, and other high-value digital assets has never been more critical. At the same time, advances in quantum computing are increasing the urgency of the transition to post-quantum cryptography.

Azure Integrated HSM was designed for this evolving landscape, continuously protecting keys in hardware while expanding access to quantum-resilient cryptography. Tessera builds on the lessons learned from deploying this architecture at Azure scale and extends them through open industry collaboration.

Tessera adopts the workload-attached Integrated HSM model to address fundamental limitations of centralized HSM architectures. Network latency, availability dependencies, operational complexity, and limited interoperability can lead organizations to generate, export, or cache keys outside the HSM, weakening the protections the HSM is intended to provide.

By bringing hardware key protection closer to the workload, Tessera enables keys to remain protected while improving interoperability, crypto-agility, and the transition to post-quantum cryptography. Its fully open-source architecture combines these benefits with the performance required for demanding workloads, supporting thousands of post-quantum key operations per second.

At the Open Compute Project Global Summit, Microsoft and Marvell® demonstrate Tessera interoperability through an Integrated HSM ring spanning Azure Integrated HSM hardware and Marvell® LiquidSecurity 2 HSM hardware, with keys remaining protected within the HSM security boundaries.

Tessera also extends to systems without dedicated Integrated HSM hardware. The Open Compute Project community has developed a model that runs the same Tessera firmware in hardware-isolated confidential computing environments, initially demonstrated with AMD SEV-SNP and community work already underway to extend the model to other confidential computing architectures.

These deployment models provide a common architecture and programming model, across different assurance levels. Confidential computing extends hardware-isolated key protection to systems without dedicated HSM hardware, while Tessera Integrated HSM provides dedicated, tamper-resistant key protection for high assurance environments.

The open-source Tessera repository includes the firmware, drivers, software, and sealing services needed to operate enclaves and Tessera compliant hardware.  The community has already begun the development of fully open-source silicon for compliant Tessera devices.  Together, the open-source confidential computing Tessera enclave, open-source firmware and services, enables the broader adoption of open, scalable, interoperable hardware-backed key protection.

Platform Integrated TPM

In 2022, Microsoft introduced Hydra, a security-centered Baseboard Management Controller (BMC) architecture built around hardware isolation. Hydra integrated the Platform Root of Trust (PRoT) into the BMC chip, consolidating capabilities traditionally provided by discrete platform security components into an integrated root of trust and companion security processor. This design enabled stronger runtime control of the BMC while isolating the security subsystem from the BMC’s management processors and interconnects.

At the Open Compute Project Global Summit, we demonstrated the next step in this evolution: moving the server’s traditional discrete host TPM functionality into the BMC root of trust security subsystem co-processor.  The host CPU continues to provide and retrieve measurements through the standard TPM interface.  However, unlike a traditional discrete TPM, the integrated design also makes measurements independently available through the BMC.  The source code for the security coprocessor integrated TPM, is available in GitHub.

This out-of-band path enables both TPM measurements and system attestation throughout the server lifecycle, even when the host operating system is unavailable, has not fully booted, or lacks a TPM software stack. Platform integrity can therefore be evaluated independently of the host software environment.

This capability is particularly relevant to modern virtualization architectures that do not have traditional host management partitions. Integrating host TPM functionality into the BMC root of trust security subsystem maintains an independent, always-available path to host measurements while preserving hardware isolation between security and management functions.   In addition, the architecture supports the secure “Kirkland” transport binding we announced in 2022, while simplifying the attestation and recovery of the TPM itself.  

As major BMC silicon manufacturers adopt Caliptra as their preferred root of trust security subsystem, the coprocessor integrated TPM architecture benefits from Caliptra's hardware key protection and dedicated DICE Protection Engine (DPE) contexts.

Composite Entity Attestation Token (EAT)

Modern platforms contain many independently attestable components such as, CPUs, GPUs, solid-state drives, network adapters, and other devices. Establishing trust requires a verifier to understand the system’s composition, identify each component, and retrieve its attestation evidence independently. As systems become more disaggregated, this process grows more complex and can require repeated interactions between the remote attestation service and the platform.

Composite Entity Attestation Token (EAT) provides a more scalable approach. Instead of requiring a verifier to discover and attest each component separately, the platform returns one signed attestation that cryptographically binds platform measurements to evidence from its constituent devices. The BMC collects fresh evidence from each component, and its integrated root-of-trust security subsystem binds those claims with the BMC measurements into a single platform attestation claim.

The approach preserves each device’s native attestation evidence. CPUs, GPUs, storage devices, and other components continue using their existing mechanisms and evidence formats while that evidence is bound to the platform attestation. It also minimizes trust in collection and transport infrastructure: a collector can assemble the composite evidence without being trusted for the integrity of the underlying component claims.

This platform evidence bundle provides a foundation for simpler, interoperable attestation across increasingly disaggregated systems. The approach has been contributed to the Open Compute Project, with reference implementations on Azure GitHub and integrated into major BMC SDKs (Aspeed RoT, Aspeed BMC, Nuvoton RoT,  Nuvoton BMC). At the Global Summit, we demonstrated composite EAT spanning CPU and GPU architectures, enabling a verifier to attest a system without prior knowledge of its hardware configuration.

Hierarchical Hardware Management

Modular cloud infrastructure and bare-metal services are reshaping system management. There is a need for diagnostics and direct control over hardware at scale, while independently securing control-plane management, recovery, and infrastructure connectivity.

Two trends drive this change; in bare-metal instances, control of the host software stack increases the need to manage and understand the underlying hardware subsystems.  At the same time, AI and compute platforms are becoming highly disaggregated across boards, chassis, accelerators, and configurable hardware partitions.

Traditional servers rely on a single Baseboard Management Controller (BMC) for diagnostics, recovery, and hardware debug, and do not easily scale to modular, multi-board, and multi-chassis systems. Modern platforms instead require a hierarchy in which Satellite Management Controllers (SMCs) provide local management and aggregate capabilities to a system BMC. The same model supports composable architectures, where socket-level and sub-socket partitioning create additional management domains and interconnects.

The Open Boot and Management Framework (OBMF), an open standards initiative within the Open Compute Project, modernizes connectivity for these architectures. It consolidates interfaces such as SPI, LPC, eSPI, UART, and SMBus over a single USB transport that enables protocol discovery and enumeration. This common interconnect foundation raises the next question: how should management responsibilities be divided across a disaggregated server?

At Open Compute, we demonstrated a hierarchical management topology for bare-metal systems. A system-level BMC manages the system hardware domain, while a separate isolated control plane management domain manages connectivity, for example; a SmartNIC with integrated BMC, or separate rack management appliance. This creates a clear boundary between system management and control plane hardware management.  This also allows control of plane management subsystems orchestrated system recovery and management of submodule system boards.  For example, during bare-metal system rotation, the control plane can orchestrate transitions where the system BMC is recovered to a known state through USB streaming-boot or, as an interim mechanism, USB Device Firmware Update (DFU).

The next step in the standardization of the OBMF and hierarchical management architecture in OCP is to define open API contracts between the management domains.  This will be part of the DPU abstraction layer project announced at the Open Compute Project Global Summit.  The contracts must specify which capabilities are shared from the system domain to the control plane, for operators to ensure reliability, availability and serviceability, without weakening security isolation across domains. Clear interfaces will make hierarchical management scalable, interoperable, and secure across the next generation of cloud and AI infrastructure.

Network Recovery

Conventional hardware designs typically boot CPUs, GPUs, and add-in cards from nearby SPI Flash or non-volatile media within the device. This model reflects the historical design of components as semi-discrete units that rely on firmware storage for security and dependency isolation. However, distributing firmware across device-specific stores creates silos that complicate system monitoring, update, and recovery.

Manufacturers commonly use dual A/B flash images to improve resilience, but additional copies do not remove the underlying risk. Bit corruption, operational errors, firmware vulnerabilities, or compromised signing keys can affect both images and leave hardware unrecoverable without physical intervention.  The method of adding more recovery images adds redundancy but does not meaningfully improve recovery or mitigate the risk of a persistence attack.

In 2022, Microsoft worked with the Open Compute Project community to develop streaming-boot. Instead of storing firmware images on flash alongside every device, streaming-boot delivers firmware over interfaces such as I3C, USB, or PCIe. This method of boot enables flashless devices and replaces custom device-local recovery flows with a unified boot and recovery architecture.

Streaming-boot provides several important capabilities:

• An assume-breach design, the recovery-first architecture is designed to mitigate persistent denial-of-service attacks.
  
  
• Reduced dependence on device-local non-volatile firmware storage and the persistence risks it introduces (i.e corruptible state, persist malware, etc).
  
  
• Modular firmware delivery using standard protocols and interfaces, including SPDM, PLDM, I3C, and USB.
  
  
• Consistent recovery-first workflows across boot and update paths.
  
  
• Complement secure boot and attestation flows, with authentication and measurement performed in device isolated memory.

Streaming-boot removes the need for device side non-volatile firmware storage and uses the OBMF transport.  It is also a default Caliptra capability, embedding recovery-oriented boot in devices that use the Caliptra root-of-trust security subsystem.   At the Open Compute Global Summit, we demonstrate Calitpra streaming boot over USB.  

In the fully resilient streaming-boot architecture, the BMC presents a final challenge because it sits at the bottom of the management and recovery chain.  A Caliptra extension addresses this with a network boot processor peripheral that sits outside of the root-of-trust boundary. The processor boots from its own ROM and downloads firmware into isolated SRAM. Caliptra treats the SRAM as an untrusted source, copies the firmware into protected memory, then authenticates and measures it before any execution.  

Together, these capabilities move firmware resilience beyond redundant flash images. They establish a recovery-first architecture designed for continuous updates, with unified servicing and recovery paths across the platform.

Caliptra 2.2: Expanding Connectivity and Hardening Security

Caliptra is an open-source silicon Root of Trust that provides identity, attestation, secure boot, key management, and other low-level security services within modern SoCs. Version 2.2 expands Caliptra’s interconnects, optimizes crypto engine area, while adding new hardware security controls.

Caliptra 2.2 adds native multi-device USB support through a new hub and controller block. This interconnect improves SoC streaming boot performance and integrates naturally into modern system management architectures. Alongside I3C and other supported interfaces, USB gives designers greater flexibility in how firmware is loaded and management services are delivered across modular systems.

Caliptra 2.2 reduces the implementation area of the Adams Bridge post-quantum cryptography engine by 50% while delivering a fully masked design. This update also adds Dual Core Lock Step (DCLS), control-flow monitoring, and hardened platform configuration registers.

Together, these improvements extend Caliptra from a silicon root-of-trust into a broader security subsystem for modern cloud and AI infrastructure. Native USB strengthens integration with streaming boot and hierarchical systems management, while additional silicon hardening reinforces secure boot, recovery, identity, and attestation.

Together, these innovations advance a security architecture built for modern cloud and AI infrastructure. Tessera Integrated HSM brings strong isolation to key management; Platform Integrated TPM and composite EAT provide continuous, system-wide measurement; hierarchical management scales partitionable control across disaggregated systems; and streaming-boot establishes recovery as a core platform capability. Caliptra 2.2 ties these advances together with broader connectivity, post-quantum cryptography, and deeper silicon hardening. The result is an open, interoperable foundation that puts isolation, attestation, scalable management, recovery, resilience, and security hardening at the forefront of a modern system design.

AI is fundamentally changing what we ask of the network. As models become more capable and AI systems grow larger, adding more compute is only part of the challenge. Today’s largest AI systems bring together hundreds of thousands of accelerators in a datacenter, while AI infrastructure increasingly extends across sites, requiring compute to work together across increasingly distributed environments.  

That growth requires networking to scale in multiple dimensions at once. Scale-up networks provide the extremely high-bandwidth, low-latency connectivity required within tightly coupled AI systems, with the industry now extending scale-up connectivity across multiple racks. Scale-out networks connect increasingly large clusters of accelerators, while another layer of networking connects AI infrastructure across datacenters. Together, these networks are becoming part of the architecture of the AI system itself, requiring networking to be designed alongside the compute and infrastructure it connects.  

With compute distributed across larger systems, networking can become a bottleneck to keeping that compute productive, whether a job is constrained by its slowest connection or congestion, or link failures prevent data from moving reliably and quickly across a network. But networking is also an enabler: connecting accelerator capacity across datacenters can allow distributed compute to operate as a much larger coordinated system, opening new possibilities for AI training and inference. This means that we must think about networking from the system up. Together, scale-up and scale-out networks have evolved into critical infrastructure innovations for operating AI at scale. Open specifications provide common foundations that we can build on with the broader ecosystem, enabling interoperability, coordination, and resiliency across increasingly large AI systems while leaving room for continued innovation. 

Keeping the system productive  

Large AI workloads depend on constant communication. Training, inference, and memory access all require data to move quickly and reliably across increasingly complex systems.  

As those systems become larger and more tightly coordinated, a networking problem can become a system problem. Congestion or a failed connection can leave expensive compute waiting for data instead of doing useful work. A network fault can affect the progress of an AI job spanning thousands of accelerators.  

Speed matters, but the greater opportunity is to design the network around the productivity of the entire AI system. Instead of asking only, how do we make an individual connection faster? We can ask, how do we keep the entire system productive, efficient, and resilient as conditions change?  

One example is Multipath Reliable Connection, or MRC. MRC rethinks Ethernet networking for large-scale AI systems. Rather than relying on a single network path, it distributes an RDMA connection across multiple paths, so the system can make more effective use of available network capacity and remain more resilient when congestion or failures occur.  
  

By managing congestion and failures end-to-end, MRC allows traffic to move around impaired paths rather than letting one network issue stall a much larger AI job. The underlying network can remain simpler and switch-agnostic while the system adapts as conditions change. Microsoft and industry partners have released the MRC v1.0 specification through OCP as an open foundation the ecosystem can implement and build on.   

The important outcome isn’t simply a better network. It is more of the infrastructure doing useful work. When the network can adapt while keeping accelerators working together, jobs become more resilient, capacity can be used more, and more deployed compute can contribute to useful intelligence. For customers, that system productivity can translate into more dependable performance, more consistent capacity and less infrastructure complexity standing between an AI workload and the outcome it is meant to deliver. 

Building an open AI fabric 

AI requires connectivity at several levels: high-bandwidth, low-latency communication within tightly coupled systems; high-performance fabrics across large clusters; and networks that connect AI infrastructure across datacenters. This is forcing us to rethink the network end to end, including the optics and interfaces that connect these systems. 

Microsoft’s work on scale-up optical networking is focused on the high-bandwidth, power-efficient connectivity required by the next generation of AI systems. Through the Optical Compute Interconnect Multi-Source Agreement, or OCI MSA, the industry is developing an open, interoperable optical specification for multi-rack scale-up systems.  Moving forward, we will continue to work with the industry to expand participation in OCI MSA.

In parallel, efforts such as the Ethernet for Scale-Up Networking (ESUN) workstream are bringing operators and technology providers together around the requirements for Ethernet-based scale-up networking. These are distinct efforts, but they reflect the same principle: the infrastructure connecting increasingly large AI systems must be developed with interoperability and ecosystem-scale implementation in mind.   

No company builds every part of an AI system. AI infrastructure depends on an ecosystem spanning silicon, networking, optics, systems, power, cooling, software, and datacenter technologies. As these systems become larger and more interconnected, open collaboration becomes an engineering requirement. 

Through the Open Compute Project and across the broader industry, Microsoft is working with others on specifications, interfaces, and networking technologies that allow innovation from different parts of the ecosystem to work together. MRC is one example. OCI MSA and ESUN address different parts of the emerging connectivity challenge. Together, these efforts can establish common foundations while giving companies room to innovate and differentiate above them. 

Open standards for resilient networks 

The next generation of AI infrastructure will require deep innovation within every technology, along with much stronger coordination across the boundaries between them.  

Open specifications give the industry a foundation for solving these system constraints together. They allow advances in silicon, networking, optics, software, and datacenter design to contribute to a larger whole, without requiring every organization to approach the problem in the same way. 

As AI systems continue to scale, the network will increasingly shape what those systems can achieve. Open standards can turn that challenge into an opportunity for the industry to innovate faster, together. 

Learn more 

• Multipath Reliable Connection through OCP 

• Optical Compute Interconnect MSA  

• Ethernet for Scale-Up Networking 

As AI infrastructure scales, power availability is increasingly setting the ceiling on how much compute we can deploy.

With workloads evolving towards long-context reasoning and memory-intensive agentic tasks, the power envelope of operating AI at scale has changed dramatically. High density AI systems built with the latest cutting-edge GPUs and AI accelerators are fundamentally changing the demands placed on power infrastructure. As we build the unified engine for intelligence, our ability to deliver compute at the scale required by Frontier AI today rests on a simple reality: greater intelligence relies on how efficiently energy can be delivered through the infrastructure system. This question of energy efficiency spans far beyond sheer compute: it is a challenge that sits across the entire datacenter stack–from the way silicon, servers, and racks are designed to how datacenters and power grids distribute power across the facility.

Scaling AI fundamentally requires us to rethink the power path

As Microsoft scales AI for the frontier era, we’re rethinking power delivery at every layer of the stack, from the grid to the chip. This requires designing the power path as one complete, interconnected system—bringing together the transmission, distribution, conversion, and delivery of power to create a flywheel of efficiency. When each layer is designed with the others in mind, the infrastructure can respond more effectively to the growing scale, density, and dynamism of AI workloads.

Higher-density AI systems are changing the demands placed on power infrastructure. The challenge is not only delivering more power, but coordinating how it is distributed and converted across the facility and the systems it supports. Unlike conventional workloads, large-scale AI training can create rapid changes in demand and power oscillations. Addressing those dynamics requires utility-aligned requirements, responsive control, and filtering within the rack as part of the broader engineering approach.

These demands are prompting a closer look at higher-voltage distribution and opportunities to simplify the power path. Every conversion stage introduces equipment, control requirements, and potential losses. A systems approach creates an opportunity to connect decisions that have traditionally been made independently, from how power enters the datacenter to how it reaches a rack, a server, and ultimately the silicon.

The goal is not to replace every existing architecture at once. Datacenters differ in age, design, available utility service, and deployment needs. The opportunity is to establish a flexible path forward: one that supports existing infrastructure while creating new options as AI power density continues to increase.

Connecting the system through LVDC

A central element of Microsoft’s approach is advancing 800-volt direct-current, as part of the LVDC (Low Voltage Direct Current) power infrastructure with industry partners through the Open Compute Project (OCP). The vision extends beyond the rack to a connected power architecture reaching from the utility grid toward the silicon. It treats facility power, conversion, distribution, rack design, and compute as parts of one engineering system rather than a chain of isolated components.

At a high level, the distribution approach can include 800 VDC/ ±400 VDC . Aligning datacenter distribution, rack interfaces, and downstream conversion around a common strategy can reduce unnecessary conversion complexity and provide a clearer framework for scaling. It also supports more than one adoption path. Existing facilities can introduce local conversion alongside compute racks, while future datacenters can incorporate DC distribution more directly into their architecture.

800VDC architecture improves sustainability by delivering the same power at lower current, enabling smaller conductors and less copper and thereby reducing the embodied carbon associated with mining, refining, manufacturing, and transportation. It also simplifies the power-delivery chain by reducing intermediate conversion stages, lowering electrical losses and waste heat. Together, these improvements reduce both the Scope 3 footprint of the infrastructure and the operational energy required to power AI at scale. 

This flexibility matters because infrastructure transitions happen over time. Operators need options that account for existing investments as well as new builds. By developing common specifications and interfaces, the industry can enable gradual adoption without losing sight of the longer-term grid-to-chip architecture.

Rethinking datacenter and rack power through disaggregated power conversion

Mt. Diablo is an open standard, disaggregated power rack architecture platform for AI infrastructure co-developed with industry partners. By moving power conversion out of the compute rack, the architecture allows power and compute to scale independently while supporting 800 VDC/ ±400 VDC distribution, redundant power delivery, telemetry, and optional energy storage.

This disaggregated “sidecar” model makes the conversion layer modular, allowing power capacity to evolve with increasingly dense AI systems without impacting the compute rack

At the datacenter and rack levels, we are exploring complementary approaches to simplify power delivery for AI. This means rethinking where and how power conversion happens. SST research explores moving conversion upstream from medium-voltage AC directly to LVDC distribution, while Mt. Diablo disaggregates power conversion from the compute rack to support scalable DC power delivery for AI systems.

Collectively, they illustrate an evolution from today's AC infrastructure toward DC-native AI datacenters.

The future: Solid-state transformer (SST) enablement and datacenter distribution

Together with partners, we are also exploring a solid-state transformer (SST) architecture that converts medium voltage AC (13.8 to 34.5kV) to 800VDC using intermediate medium to high frequency transformer, for direct distribution to the IT rack. This architecture will improve power distribution efficiency, simplify power architecture by eliminating power conversation steps, and provide better energy management with integrated energy storage systems (ESS). We are developing and validating next-generation solid-state transformer technology with integrated energy storage to improve fault ride-through and power resiliency. The work is progressing from prototype validation toward commercial-scale architectures designed for future datacenter power systems

To enable this architecture, key building blocks are SST, ESS for fault ride through & power smoothing, 800VDC switchboard, solid state circuit breakers for fast fault isolation, busway and tap boxes. This entire eco-system of the products is under development, and active engagement with equipment suppliers and industry partners is key to enabling the equipment needs of this transition.

Reliable operation is equally important. OCP’s Clean Backup Power Initiative is developing technology-agnostic requirements for alternatives to traditional diesel-based backup systems. A resilient grid-to-chip architecture must consider normal operation, transient demand, and continuity during disruptions—not as separate problems, but as related design conditions.

The grid-to-chip story does not stop at the rack. LVDC distribution must connect with server-level conversion and the final delivery of power to the processor. Bringing those layers into the same design conversation helps ensure that upstream infrastructure responds to the actual requirements of the silicon it serves.

As LVDC enters the compute tray through the busbar, the Power Delivery Board (PDB) provides the bridge between rack-level distribution and server-level power conversion. It combines key protection and control functions, including LVDC fusing and hot-swap control (HSC), before converting the incoming LVDC to a lower intermediate bus voltage (IBV) for efficient distribution closer to the processors. This conversion stage represents an important opportunity for innovation. Microsoft is working with partners to advance LVDC-to-DC technologies that can support the efficiency, power density, scalability, and dynamic load requirements of next-generation AI systems. But reaching the compute tray is not the end of the power-delivery journey. As power moves closer to the processor, the same system-level design approach must continue through the board, package, and ultimately to the silicon itself.

Vertical power delivery (VPD) carries this grid-to-chip architecture through that final stretch, extending power delivery from the board into the package and silicon domain. By bringing power conversion and delivery closer to the processor, VPD allows power density, distribution path, silicon requirements, chip package architecture and board design to be considered part of a connected system. The result is a continuous engineering path from facility power and rack conversion to the point where power is ultimately consumed by the compute silicon.

Engineering efficiency across the stack

This is where full-stack co-design becomes tangible. Decisions about voltage, conversion, packaging, board design, and workload behavior can be evaluated together. That shared view can help teams identify constraints earlier and avoid optimizing one layer in ways that create complexity elsewhere.

The objective is not a collection of isolated power innovations, but a coordinated system designed for efficiency, resilience, and scalability. Full-stack co-design creates opportunities to simplify conversion, align controls, and use infrastructure capacity more effectively. It can also make the system easier to evolve because interfaces and requirements are considered across layers rather than negotiated, one component at a time.

Building through open collaboration

No single company can make this transition alone. Scaling new power architectures requires collaboration among utilities, datacenter operators, equipment vendors, silicon designers, and technology partners. Each participant owns a different part of the path, and progress depends on interfaces that allow those parts to work together.

Through OCP, Microsoft is contributing to work on disaggregated power racks, solid-state transformers, DC distribution, clean backup power, and a common interface between hyperscale datacenters and the utility grid. These efforts help establish shared requirements as architectures evolve, giving the ecosystem a common foundation for development and deployment.

Open collaboration also creates room for practical choice. Organizations can adopt the elements that fit their facilities and timelines while maintaining alignment with a broader architecture. Published specifications, reference designs, and interoperable interfaces can help turn individual innovations into repeatable building blocks for the industry.

Powering the next generation of AI infrastructure

Scaling AI requires innovation across the entire infrastructure stack, including the path that powers it. By connecting grid, datacenter, rack, server, and silicon design, Microsoft is working toward a more efficient, resilient, and scalable foundation for Azure AI infrastructure.

As AI continues to reshape the scale and design of infrastructure, the power path must evolve with it. Learn more about Microsoft’s infrastructure innovations and follow our work with the Open Compute Project as we continue building from the grid to the chip.