OCP S.A.F.E. Updates: What’s Changing and Why it Matters
OCP S.A.F.E. continues to mature as a practical assurance framework for hardware and firmware used in cloud-scale environments. The focus remains unchanged: generate security evidence without turning the process into a checkbox exercise.
Jasper van Woudenberg Senior Principal Security Technologist - Keysight Technologies joined Eric Eilertson (Security Architect - Microsoft), Nick Hummel (Senior Security Engineer at Google), ilja van Sprundel (Sr. Director of Operating Systems Security - IOActive) at the OCP Global Summit in Santa Clara, CA last October to share the latest OCP S.A.F.E updates. This blog is a concise, technical rundown of what’s was discussed and how it affects vendors, Security Review Providers (SRPs), and Cloud Service Providers (CSPs).
Reporting moves to CBOR
The short-form report format is moving from JSON to CBOR. This isn’t cosmetic. CBOR’s compact, schema-friendly encoding yields artifacts that are easier to validate at scale and better aligned with existing verifier tooling. Many vendor pipelines can already emit CBOR or adapt quickly, which cuts one-off converters and free-form interpretation.
What this buys you: more predictable ingestion by CSPs, fewer format mismatches between SRPs, and cleaner downstream automation for vendors.
Integrity anchored in execution: runtime hashes
S.A.F.E. is shifting emphasis from on-disk file hashes to runtime measurements. In real products, multiple firmware components often land in merged images where offsets drift across SKUs and versions. Validating what actually executes, such as post-decompression digests, loader-verified measurements, and PCRs, removes ambiguity and pairs naturally with attestation. Net effect: integrity checks survive repacking and layout changes.
SRP requirements: evidence over paperwork
SRP qualification is being refocused on demonstrated technical capability such as methodology depth, design review rigor, testing coverage, and quality of findings, with less emphasis on low-value business boilerplate.Why it matters: the credibility of “S.A.F.E.-reviewed” hinges on engineering substance. This shift keeps the signal high for vendors and CSPs.
A clearer threat model, aligned to CSP reality
The integrated threat model focuses reviews on what CSPs actually need to hold: strong tenant isolation, denial-of-service containment, trustworthy attestation of the boot/runtime state, and confidential computing boundaries that keep tenants separated from other tenants, and from administrators where applicable. S.A.F.E. looks specifically at the hardware/firmware controls that enforce those guarantees.
Takeaway: threat models drive what is relevant for vendors to protect, and what is relevant for SRPs to review. Continued clarification reduces any protection and review gaps.
Scopes that map to attacker reality
Scope 1 - Remote attack surface in ROM/boot/firmware. Classic software exploit classes (logic flaws, memory corruption) and timing side channels are in. Confidential-computing angles (admin vs. tenant) are considered here too.
Scope 2 - Escalation and isolation integrity. Reviews examine boundaries between secure/non-secure compute, control vs. data paths, and software-triggered hardware vulnerabilities (e.g., Spectre-class issues, Rowhammer). The question is simple: what is the impact of an escalating attack after a first compromise?
Scope 3 - Practical physical attacks on persistent secrets. The emphasis is on feasible supply-chain windows and limited in-datacenter access, not cinematic attack rigs next to a live rack. PCB-level access, exposed debug, fault injection, and side channels matter when secrets are at risk—especially class secrets that enable break-once-run-everywhere. Countermeasures are evaluated via design review and, where appropriate, RTL-level analysis and simulation; costly destructive testing for every SKU is not required by default.
Example context: using roots like UDS and device entropy (e.g., in Caliptra-style designs) to derive secrets reduces class-secret exposure.
Hardware severity: use JIL, not CVSS
For hardware-centric findings, S.A.F.E. will use JIL-style scoring. CVSS was built for software and doesn’t model equipment, skill, and physical steps well. JIL maps to attacker economics for hardware attacks use as side channel analysis and fault injection, enabling crisper risk quantification.
Not a certification - on purpose
S.A.F.E. remains a review framework, not pass/fail certification. The deliverable is a public report that explains findings and risks. Findings are expected to occur in every evaluation and do not constitute a S.A.F.E. failure; what matters is clarity, context, and mitigation posture so CSPs and other integrators can use components with eyes open.
What to do next
Vendors: engage SRPs early, map your persistent secrets and countermeasures for Scope 3, and ensure your isolation story stands up in Scope 2. Align your attestation records with runtime measurements.
SRPs: keep pushing clarifications into the public docs. Prioritize reproducible methods, crisp evidence, and JIL-based severity for hardware issues.
Operators: ask for S.A.F.E. reports up front. You’ll get comparable, machine-ingestible evidence tied to the threats that matter - so you can deploy faster without blind spots.
Preparing for an OCP S.A.F.E. review? We can help you translate your threat model into Scope 1–3 evidence (including runtime measurements/practical physical attack coverage) and package results in CSP-friendly formats. Learn more information about Keysight’s OCP S.A.F.E evaluation services on our webpage or contact us at [email protected]