Build with Us: An Overview of OpenSFF Membership and Certification

Introduction

We are committed to maintaining OpenSFF as an open source hardware standard. Our specifications will always be available here on our website. We invite you to use them as a foundation, resource, or inspiration. That said, we want to have a channel where we can collaborate closely with organizations or individuals who aim to faithfully adhere to our standard. We also want to help their users make more informed decisions when purchasing, managing their inventory, or upgrading their systems.

To achieve these goals, we will establish membership and certification programs. We aim to welcome members starting in the third quarter of 2026. OpenSFF will provide members with comprehensive details and other relevant resources through our partner portal. Today, we will go over the basics of OpenSFF membership and certification.

OpenSFF membership

Once we launch our membership program, interested parties will be able to apply for OpenSFF membership through an application page here on our website. Membership is open to anyone, from OEMs and tooling companies to small communities and individuals.

To attain and maintain their status, an OpenSFF Member must officially agree to adhere to our specifications in good faith, use our trademarks and certification marks according to our guidelines, and in general commit to transparency regarding their product’s compatibility with our standard.

In return, an OpenSFF Member will be able to officially claim that their creations based on our standard are OpenSFF Compatible. They will also be eligible to submit a product to undergo our compatibility testing. Should the product pass our tests, it will be awarded the OpenSFF Certified status.

To facilitate design and development, OpenSFF Members will be able to reach us through a dedicated email channel. We will also provide them with early access to specification drafts, design documents, and other related resources, such as our brand guideline. Once again, this will not impact the public availability of release candidates and final releases of OpenSFF specifications. They will always be freely accessible through our Documentation page.

What OpenSFF Compatible and OpenSFF Certified mean

As we mentioned, a product bearing the OpenSFF Compatible status informs the public that its creator is an OpenSFF Member. That entity formally agrees to adhere to our standard in good faith. Meanwhile, OpenSFF Certified is a more stringent and specific status that is awarded on a per product and per version basis. We recommend that you read our versioning guidelines before proceeding with the rest of this article.

When a product is submitted for certification, it will undergo a range of interoperability tests, as well as the tests indicated within the applicable version of the relevant specification/s. If the product passes our tests, it will be permanently awarded the OpenSFF Certified status for that version, e.g. OpenSFF Certified for Compute Node 26.1.

Products can be certified for the latest major version of the current specification cycle, and whenever possible, the final major versions of previous cycles as well. Because products will continue to be released as our standard evolves, let us look at three release scenarios and find out how our guidelines will be enforced in each of them. Please note that the years and version numbers we will use are purely for demonstration purposes only.

Scenario 1: certification for new products

A product released for the first time can be certified for the latest major version of the current specification cycle. For example, if the current final release of the Compute Node specification is 26.2.1, then a product first released in 2026 cannot be certified for Compute Node 26.1 or 26.0. It can be certified only for 26.2.

Scenario 2: certification for existing products

A product that was released during a specification cycle can be certified for the final major version of that cycle once it has passed. To illustrate this, let us imagine that it is 2028, and a vendor has a Compute Node product that they released in 2027.

When the product was released, the latest Compute Node specification was 27.1.0. Eventually, the final version released under the 2027 cycle turned out to be 27.3.4. When the vendor submitted their product for certification, the current Compute Node specification was already 28.2.1.

In this case, the product can be certified for either Compute Node 27.3 or 28.2.

Scenario 3: certification for previously certified products

A product that was previously awarded the OpenSFF Certified status may be additionally certified for the final major versions of previous cycles, and possibly the latest version of the current cycle.

Let us once again imagine that it is 2028. A product certified for Compute Node 26.1 can also be certified for the final major version of the 2026 cycle. It may also be possible for the product to be certified for the final major version of the 2027 cycle, or the latest major version of the 2028 cycle.

On obtaining multiple certifications

As we implied in the previous section, it may be possible and sensible to have a product certified for multiple versions of a specification in one application. In such cases, the certification process for each version will be distinct activities with separate timelines and outcomes.

That said, there will likely be products that cannot be certified for multiple versions of a specification, particularly when there are significant differences between the relevant versions.

About specification cycles and compatibility

We used successive years in the previous section’s scenarios to simplify our discussion. In reality, it is likely that a specification cycle will begin years after the previous one. For example, the next cycle after 26.x may be 32.x. As with other hardware standards, we aim to keep our specifications stable and reliable. Rest assured that we will start new specification cycles only to develop necessary or significant improvements.

We will try our best to maintain compatibility across cycles. In particular, we believe that we can make later versions of the Enclosure compatible with at least some earlier versions of the Compute Node. However, it may be significantly more difficult to make future versions of the Compute Node compatible with earlier versions of the Enclosure.

For instance, let us say that the 32.x Compute Node specification involves upgrading the Core Connector power pins from a 12V rating to 48V. It is possible that 32.x Enclosures will be able to host both 32.x Compute Nodes and Compute Nodes based on earlier versions of the standard. However, a 32.x Compute Node will not work in a 26.x Enclosure due to the latter’s lack of 48V support for power delivery.

How OpenSFF will invest in certification

Certification tests will be conducted only by OpenSFF or a third-party facility acting solely on our behalf. We will use the proceeds from the certification process to operate our own test facility, as well as to develop test systems for third-party facilities. This will allow our members to consistently receive timely and accurate test results even as our community grows.

Build with OpenSFF

OpenSFF is our humble contribution to the open source movement. We are excited to see how our standard will be implemented or spun off, whether for personal projects or for a dedicated business. We created our membership program simply to assist those that are fully committed to following our standard. Our certification program will empower customers by endorsing products that we officially verified to be interoperable, serviceable, and scalable.

We invite you to read our specifications, and we would be grateful if you help spread the word about OpenSFF. For technical clarifications, collaborations, and other inquiries, reach out to our development team at [email protected].