Decoupled: What OpenSFF Can Learn from DC-SCM

Introduction

Our previous articles on open hardware highlighted specifications or products that became foundations for their respective ecosystems. In this article, we are going to see that it is possible to define a format for a narrow subset of users, redefining what a standard can be in the process.

In the last 5 years, data center hardware has been shifting to a modular management architecture. Open Compute Project (OCP) and its contributors are leading this transition through the Datacenter Secure Control Module (DC-SCM) specifications. Their implementations prove that the benefits we aim to bring to small form factor computers through our Management Module Specification are significant and achievable. But there are also lessons that we can take from what DC-SCM leaves out.

OpenBMC: DC-SCM’s foundation

It is impossible to discuss DC-SCM without at least a brief explanation of the firmware that makes the module possible. The Linux Foundation’s OpenBMC is an open-source firmware stack for Baseboard Management Controllers (BMCs). It serves as a common target for DC-SCM implementations, and relieves vendors and data center operators from the burden of developing their own management platform from scratch.

The OpenBMC project’s scope and members are also going to be key aspects of our discussion. It is explicitly aimed at servers used in enterprise environments, telecommunications, high performance computing, and cloud-scale data centers. This is reflected in the roster of its founding members: Microsoft, Intel, Facebook, Google, and IBM.

A brief history of DC-SCM

Origin

In most server motherboards, the BMC, storage for BIOS images, and several security-related chips and circuitry are directly soldered onto the board. This integration stayed in place for decades largely because enterprise servers operate in walled gardens. An enterprise server is compatible only with its vendor’s accessories and services, including its management platform.

But there are other drawbacks of this integration that drove enterprise server users, e.g. the organizations behind OpenBMC, to decouple management from performance. They wanted to be able to replace those security and control-related components without throwing out the rest of the server. They also wanted to be able to refine or customize security configurations, or even the BMC itself, without overhauling entire server designs.

In 2016, Microsoft introduced Project Olympus, a design for hyperscale cloud hardware that modularized core components, from the motherboard to the software. A year later, the company made Project Olympus open-source by handing it over to OCP. In 2020, Microsoft introduced DC-SCM and its interface, DC-SCI, building off of Project Olympus’ modular tenets.

DC-SCM 1.0

DC-SCM moves the BMC, Root of Trust (RoT), Trusted Platform Module (TPM), BIOS firmware flash, and other security and control components into a removable module distinct from the server motherboard, aka the Host Processor Module (HPM). The first major version of the DC-SCM Specification was released in 2021. It defined that the module would use the 4C+ SFF-TA-1002 card-edge connector, but with a custom pin assignment.

The document also identifies the interfaces that the connector carries, such as PCIe, USB, UART, SPI for communicating with BIOS flash devices and TPMs, NC-SI for OCP NIC Ethernet adapters, eSPI/SSIF for CPU communication, and SGPIO for status and control signals.

DC-SCM 2.0

The second and latest version of the DC-SCM Specification was first released in 2022, and has had major revisions since then. The most significant change from DC-SCM 1.0 is the introduction of Low-voltage differential signaling Tunneling Protocol & Interface (LTPI). An alternative to SGPIO, LTPI is a high-bandwidth interface that carries low-speed signals such as GPIO, I2C, and UART with lower latency and using fewer pins. LTPI can also carry custom channels to communicate with other enterprise server components, such as FPGA-based cards and Complex Programmable Logic Devices (CPLDs).

The SGPIO pin assignments are still present in DC-SCM 2.0. In fact, the HPM Common Circuit Type 1 Specification recommends wiring both LTPI and SGPIO to DC-SCI for maximum interoperability. The resulting pinout change as well as a modification in the card edge design makes the two DC-SCM versions incompatible.

DC-SCM’s success

In 2023, Cloudflare partnered with Lenovo to create its own DC-SCM, which it called Project Argus. That concept would go on to become one of the reference designs for DC-SCM 2.0. The enterprise server industry quickly adopted the module. Server vendors such as Dell, HPE, Pegatron, and Supermicro now offer servers that are compatible with DC-SCM. Manufacturers such as Flex, Axiado, and MSI offer third-party DC-SCM implementations.

Cloudflare’s Project Argus announcement confirmed the benefits of DC-SCM: unified firmware via OpenBMC, customizable security and controls, and the ability to refine management and security for multiple server platforms. The company added that this new modular component can also reduce manufacturing costs. DC-SCM’s board doesn’t need to have as many layers or use the highest quality materials that HPM boards need to take full advantage of today’s technologies such as DDR5 and PCIe gen 5.

In a 2025 article, ServeTheHome notes that DC-SCM allows some Dell customers to choose between the company’s iDRAC management platform or OpenBMC, and that organizations in China use the module to implement security features that are specific to their region.

DC-SCM’s stance on interoperability

DC-SCM 2.0’s section on interoperability is less than a page long, and briefly defines a “Plug-and-Code” model: it is possible for a DC-SCM to be compatible with HPMs from multiple vendors, but each pairing will require changes to the BMC, CPLD, and FPGA firmware. As for the rest of the specification, Cloudflare’s Project Argus blog post enumerates just how much of the hardware is left up to implementers. The company came up with its own set of suggestions for numerous external and internal elements, such as the locking mechanism, faceplate design, BMC chip, and the DC-SCI, BMC, and hardware RoT pinouts.

DC-SCM’s emphasis on flexibility over interoperability also becomes evident when you look up its implementations. OCP’s product page defines the “OCP Inspired” or “OCP Accepted” labels as proof that an OCP-member product has complied with an approved specification. However, as far as we can tell, there is no publicly accessible information about DC-SCM compliance, or which DC-SCMs are readily compatible with which servers. Meanwhile, the conformance and interoperability program for OCP’s Datacenter NVMe SSD Specification is highly visible. The group also has publicly accessible design files for OCP NIC 3.0 test fixtures.

Lessons for OpenSFF

Similar to Project Olympus, OpenSFF separates small form factor computers into three core components: the Compute Node, the Enclosure, and the Management Module. We also standardized around the 4C+ connector for both the Compute Node and the Management Module. Our scalability and serviceability principles are also similar to the motivations that led to DC-SCM.

However, OCP and OpenSFF diverge in our target audiences and priorities. We are developing a hardware standard for use cases outside the traditional data center: small-to-medium businesses, edge deployments, and consumer devices. Most importantly, we emphasize interoperability for all three components. The lessons from this contrast are just as important as the ones from DC-SCM’s success.

Provide detailed electrical and logic requirements

We must define electrical timing and link-error behavior explicitly rather than leaving them for any vendor pairings to figure out. We already landed on the Raspberry Pi Compute Module 5 as the platform for Management Modules with embedded CPUs, and we have a fixed pinout and power target for the module. But we will continue to analyze our design and seek feedback from experts and future members to ensure that compatible implementations will be interoperable.

Specify what vendors can and cannot customize

We must draw clear lines between what our specifications require and what vendors are free to extend, on both the hardware and software sides of the Management Module. With DC-SCM, third-party vendors can customize their implementation to use a completely different management software instead of OpenBMC. Our prescribed hardware and software for smart Management Modules already goes a long way to minimize the risk of fragmentation. But we must still inform vendors about the behaviors and endpoints that they are required to support, especially for vendors who want to develop or use their own management software.

Be transparent about compliance

At the moment, we do not have the support or network that OCP has. Most users of OpenSFF-compatible systems may not have the same level of access that OCP members have regarding compliance and testing. We must work with multiple Compute Node, Enclosure, and Management Module vendors to demonstrate our standard’s interoperability, and publicly share details about such tests as much as possible.

Build with OpenSFF

DC-SCM proves that it is possible to decouple management and security from compute, and that the benefits are significant enough for even the largest server vendors and users to support it. OCP’s specifications also show that it is possible to have modularity without guaranteed interoperability, and through the same connector that we are using at that. In OCP’s case, it was a deliberate decision, but we are working to provide both benefits at once, albeit at a smaller scale.

We are taking our time and reaching out to as many industry experts as we can to create a modular management solution that is equally interoperable, scalable, and serviceable. If you would like to collaborate with us, we encourage you to read our specifications and to reach out to our development team at [email protected]. We would also be grateful if you spread the word about OpenSFF.