How OCP S.O.L.I.D. Completes The Data Center Security Picture

In 2023, the Open Compute Project launched S.A.F.E. (Security Appraisal Framework and Enablement), a standardized process for auditing data center hardware and firmware. It delivered something the industry needed: approved third-party reviewers, continuous assessments, and public reports — not just one-time certifications. S.A.F.E. provided the audit framework; what it did not provide was guidance on what to build toward.

That gap closed in January 2026 with OCP S.O.L.I.D. (Securing Of Latest Infrastructure Devices) v1.0. S.O.L.I.D. provides concrete device-specific security requirements that you can target from day one. Together, S.O.L.I.D. and S.A.F.E. form a framework that establishes requirements upfront and verifies them at the end.

Enter S.O.L.I.D.: Requirements before code

S.A.F.E. intentionally avoids prescribing specific pass/fail criteria. It confirms that a competent review occurred and documents findings; it doesn’t tell you which security properties a device must have. That responsibility was left to individual buyers to interpret.

S.O.L.I.D. fills that gap with baseline, device‑appropriate security requirements organized into categories. With S.O.L.I.D. in place, S.A.F.E. reviews now serve two complementary objectives: verify that the device meets S.O.L.I.D.’s security functional requirements, and, as before, assess the actual implementation for vulnerabilities in code and hardware.

Not every requirement applies to every device. All product types share a universal baseline:

• General
• Business Processes
• Hardware
• Software
• Firmware
• OS/Firmware
• Cryptography
• CPU
• PCIe

Beyond that baseline, additional requirements apply to:

• Servers: add System Memory, Root of Trust (RoT), and Platform
• Accelerators (GPUs, FPGAs): add System Memory and RoT; Platform applies only if standalone
• Network Appliances (routers, switches): add System Memory, RoT, Platform, and Networking
• NICs: add Networking
• Disks (SSDs, HDDs): add Storage

S.O.L.I.D.’s technical requirements are practical yet substantive. A few examples:

Firmware:

• Production firmware must use post‑quantum cryptographic signatures.
• Rollback protection is mandatory.
• Firmware must be measured by a Root of Trust and exposed via SPDM 1.5+ for attestation.

Platform:

• A dedicated RoT is required for secure boot, measured boot, and firmware updates.
• Caliptra is the preferred implementation.

Memory:

• System memory must support hardware encryption (e.g., Intel TME or AMD TSME).
• SPD chips must be write‑protected or cleared on every boot.

Storage:

• Drives must support TCG Opal encryption.
• Sanitization must comply with NIST SP 800‑88.

Root of Trust:

• RoT must include protections against fault injection and side‑channel attacks.
• S.O.L.I.D. defines expectations; S.A.F.E. Scope 3 verifies whether real hardware meets them.

The philosophy is pragmatic: requirements are “practical and understandable, rather than definite specifications.” The intent is to guide product design, not create certification bureaucracy. When a device doesn’t meet a S.O.L.I.D. requirement, the S.A.F.E. SRP documents whether the device remains secure despite the gap, providing justification.

Shift left: Catch issues while they’re cheap

The real value of S.O.L.I.D. + S.A.F.E. becomes clear when you look at the full development lifecycle.

Take, for example, a vendor developing a new accelerator card. Previously, security requirements were often discovered late, either during customer qualification or, even worse, after a S.A.F.E. audit revealed gaps. Retrofitting security into finished silicon is expensive when possible, impossible when not.

With S.O.L.I.D., the conversation changes. Here’s a recommended approach for maximizing the shift-left benefit (note: this workflow is an example of how organizations can apply the framework; it is not explicitly prescribed by OCP S.O.L.I.D.):

Architecture phase:

1. Draft the v0.8 architecture specification.
2. Have an SRP evaluate the design against S.O.L.I.D. requirements early, before any code is written or silicon is taped out.
3. Address the core design questions:
   • Does the design include a dedicated Root of Trust?
   • Is the firmware update path planned for post‑quantum signatures?
   • Are PCIe isolation and associated security boundaries addressed?
4. Address gaps while still in the design stage, when fixes cost just meeting time, not respins or redesign cycles.

Implementation phase:

1. Run a S.A.F.E. review of the implementation (v0.8) against S.O.L.I.D. requirements. The SRP validates that what was designed and built matches the specification.
2. The resulting S.A.F.E. report confirms compliance, rather than simply stating that “a review occurred.”
3. As you’re at v0.8, there’s room to fix any issues and produce a minimal, clean short form report.

This is shift-left security applied to hardware: catching issues when they’re cheap to fix and building compliance into the product definition rather than discovering gaps at certification.

What this means in practice

For hardware and firmware engineers, S.O.L.I.D. offers something the industry has long needed: a concrete security checklist at project kickoff instead of a surprise at certification time. It lets teams plan Root of Trust integration early, budget the necessary validation work, and design attestation paths from the very beginning.

For security teams evaluating vendors, S.O.L.I.D. establishes a shared baseline. Rather than drafting bespoke requirements for every procurement, you can reference a public, consistent specification. That makes vendor assessments more predictable and comparisons far easier.

For the industry as a whole, the combination of public requirements (S.O.L.I.D.) and public audit results (S.A.F.E.) reduces information asymmetry. Security posture becomes visible and verifiable, not hidden behind NDAs or proprietary claims.

The direction is clear: post‑quantum cryptography is becoming mandatory, dedicated Roots of Trust are now table stakes, and hardware‑backed attestation is expected. As these requirements mature and adoption accelerates, S.O.L.I.D. and S.A.F.E. are positioned to become the default baseline for enterprise procurement — not just exclusive standards for hyperscalers.

Learn more about Keysight OCP S.A.F.E. Security Evaluation Service.