Rambus leaves Caliptra's open core untouched so chips stay eligible for the trademark. Its physical-attack hardening stops at that core's edge.
On September 14, 2026, Rambus announced a CryptoManager Root of Trust for data center and AI chips designed to sit alongside Caliptra, the open-source silicon root of trust. The Rambus block is a hardware security subsystem in its own right, with a secure RISC-V processor, protected memory, key and data storage, cryptographic accelerators, and secure interfaces. The release says it operates alongside an unmodified open-source Caliptra core and mediates between that core, the host processor, and the other blocks on the system-on-chip (SoC).
Where Rambus put the product says more than the feature list. In written answers to SCN, Vincent van der Leest, director of product marketing for silicon IP at Rambus, said keeping Caliptra untouched was as much a trademark decision as a technical one. Its customers need designs that remain eligible for the Caliptra mark, he said, often because hyperscalers put that requirement in supplier specifications. If that is how Caliptra is being bought, the commercial engineering around it (hardening against physical attacks, extra cryptography, certification work, key management for encrypted links and memory) ends up beside the open core, where a vendor can license it separately.
A root of trust is the small, isolated part of a chip that holds the device's identity secret, measures firmware before it runs, and reports what booted to a remote verifier. Hardware attestation chains end at one. The confidential computing stacks now sold for AI workloads, including the composite CPU and GPU attestation schemes in SCN's roundup of five vendors' launches for AI agents, are only as trustworthy as that bottom layer.
Caliptra was announced in October 2022 as an open, reusable root-of-trust block designed with security teams from AMD, Google, Microsoft and NVIDIA through the Open Compute Project (OCP). The CHIPS Alliance, a Linux Foundation project, now develops it. Its specification sets out core root-of-trust capabilities meant to be built into the SoC of any device in a cloud platform, and it states that the reference RTL and firmware are "intended to be adopted as-is, without modification." The idea is that a cloud operator can check one audited design across CPUs, GPUs, accelerators, and network cards from different suppliers instead of evaluating a different proprietary root of trust in every part.
Van der Leest's written answers draw a straight line from that as-is design to the product architecture. A customer that modified the Caliptra core, he said, would no longer meet the unmodified-implementation requirement and would "lose eligibility to use the Caliptra trademark." Running CryptoManager alongside the core keeps that path open while adding what Rambus says production chips need.
The project's own documents support that argument and complicate its absolute version. The Caliptra trademark policy, last revised July 9, 2026, lets anyone use the name to refer to unmodified source and RTL from the official repositories, but no implementation may call itself Caliptra without approval for Caliptra Certification and a certification license from the Linux Foundation. The evaluation checklist is looser on modification than Rambus's phrasing suggests: it requires Caliptra RTL to come "from an official release or TAC-approved modification," with changes outside a documented list of permitted integrator edits published on GitHub for approval by the project's Technical Advisory Committee (TAC).
That exemption route is in use. Between September 14 and 15, 2026, six requests titled "RTL Trademark Exemption" were opened against the caliptra-ss and caliptra-rtl repositories. They concern integration details such as a JTAG package name, a duplicated signal assignment, a module-name conflict, scan-mode selection, and an SRAM zeroization counter inside the Adams Bridge post-quantum accelerator. The filer's affiliation is not public. None of them looks like an attempt to add side-channel or fault-injection countermeasures to the core. The audit process document also says reuse of an approved diff in later products is decided case by case, so an exemption for a naming conflict is a different proposition from an exemption for new security logic. Van der Leest's written answers did not address the exemption route.
Leaving the core unmodified also buys eligibility, not the mark itself. Under the audit process, a product needs a Level 2 OCP S.A.F.E. security review program lab evaluation, TAC approval, and a license. An IP vendor can obtain an IP-level evaluation report that the chipmaker's lab later reuses. The project's public Approved Products Registry listed no products as of September 16, 2026. Chips can contain Caliptra RTL without holding the mark, so the empty list shows only that none had publicly completed the trademark process.
Van der Leest described Caliptra as a deliberately minimal, common foundation rather than a complete security architecture. By its account, a production SoC still needs integration with the rest of the system, platform-level security orchestration, lifecycle management, software interfaces, certification readiness and commercial support, and customers ask for stronger side-channel and fault-injection countermeasures, broader cryptographic agility and more post-quantum support.
The product page lists the cryptography: AES, SHA, RSA, and ECC; the post-quantum algorithms ML-KEM, ML-DSA, SLH-DSA, and LMS; and the Chinese national algorithms SM2, SM3, and SM4. Deliverables include Verilog, prebuilt Caliptra drivers, an SDK, an FPGA reference design, and test vectors. No customers, availability date, or pricing have been disclosed.
On certification, the release promises "certification support" for FIPS 140-3 and SESIP, and the product page extends that support to PSA and adds deployment readiness. That describes help toward certifying a customer's chip. Rambus has not announced a certificate for this product. It does hold a FIPS 140-3 validation, certificate #4758, for its separate RT-660 root-of-trust IP, which does not carry over to a new design.
The Caliptra specification anticipates this kind of pairing. It says the Caliptra block need not reach a level such as FIPS 140-3 Level 3 on its own; certification matters when Caliptra sits inside a larger boundary. An example is a cloud provider that wants FIPS certification for PCIe link encryption rooted in a Caliptra identity, which is close to the use Rambus describes. The root of trust, van der Leest said, sets up and manages keys and policy and provisions keys to dedicated engines for PCIe Integrity and Data Encryption (IDE), CXL link security, or inline memory encryption. It "does not encrypt all CXL or DDR5 traffic itself," he added; bulk encryption stays in those protocol and memory-security blocks. Proposals to stretch CXL past a single server, such as the cross-rack fabric Panmnesia and Meta researchers outlined, multiply the link endpoints that need keys, and key provisioning is the job Rambus is selling.
The plainest limit of building beside the core is that Rambus's protection applies to cryptographic operations inside the CryptoManager boundary. Caliptra 2.1, which the CHIPS Alliance announced in October 2025, integrates Adams Bridge 2.0, a hardware accelerator offering ML-DSA signatures and ML-KEM key encapsulation with side-channel countermeasures. Asked whether its countermeasures extend to that path, van der Leest said: "They do not retrofit protection onto Caliptra's own Adams Bridge datapath."
That datapath has drawn published scrutiny. Florida Atlantic University researchers Merve Karabulut and Reza Azarderakhsh reported a correlation power analysis attack on the ML-DSA hardware at IEEE HOST 2025 that recovered secret keys with 10,000 power traces on an FPGA. Slides by Markku-Juhani Saarinen identify their target as a late-October 2024 version of Adams Bridge, before it added countermeasures. Saarinen, of PQShield (a company that sells competing post-quantum hardware IP) and Tampere University, then ran a pre-silicon leakage assessment on the partially masked v1.0 release at hardwear.io USA in May 2025. He reported that the secret key is unmasked while it is deserialized for the number theoretic transform, and he saw leakage at 11,000 simulated traces. He also cautioned that "leakage alone does not imply efficient key recovery or forgery attacks." An April 2026 arXiv preprint by Ray Iskander and Khaled Kirah (SCN could not confirm peer review) reports first-order leakage at the register-transfer level (RTL) in the inverse-transform hardware round that contains the masked first stage. Its measurement window spans that masked stage and an unmasked second stage, so it does not isolate leakage to the masked layer. The paper also finds that the design's shuffling gives 6 bits of entropy per layer, far short of a full random permutation. Its attack pipeline did not recover a key.
The Microsoft engineers who designed Adams Bridge report a different result. Their February 2026 paper describes masking, shuffling, and constant-time logic and says leakage testing up to one million traces confirmed the elimination of first-order leakage in critical datapaths. The Caliptra specification also frames the threat model: because Caliptra is expected to occupy less than a square millimeter of a large SoC, side-channel mitigation "is required only against extremely resourceful attackers." Those positions have not been reconciled in public, and an SoC team that pairs Caliptra with CryptoManager inherits the open core's side-channel posture as it stands.
Instead, Rambus offers a choice of where operations run. Caliptra keeps doing what its specification requires, and a customer can move additional or more sensitive cryptographic operations into CryptoManager, which van der Leest said adds hybrid and regional algorithms, stronger implementation protections, and a path to future algorithm updates. On the post-quantum list, ML-DSA and ML-KEM overlap with Caliptra 2.1. SLH-DSA, RSA, the SM algorithms, and the ability to update algorithms in the field do not appear in the Caliptra specification. Rambus's claims about its countermeasures for this product have not been independently evaluated in public.
Rambus's picture of a minimal core fits Caliptra's original passive mode, where Caliptra starts the firmware chain of trust and the SoC handles its own update and recovery. The 2.x line goes further. In Subsystem mode, the specification makes Caliptra the SoC's root of trust, providing streaming boot, secure boot, attestation, and cryptographic services such as key release and key wrapping. The trademark policy's third track, Caliptra Subsystem with OCP L.O.C.K., introduced in 2.1, has Caliptra performing key release to integrated encryption blocks. Neither the release nor the product page says which Caliptra version or mode CryptoManager supports, and that determines how much of what Rambus sells duplicates what the open project now provides. The project's own roadmap lists availability of a FIPS certificate for Caliptra Subsystem as "TBD."
The product also has a prehistory. In March 2025, Rambus described its RT-6xx v3 cores as including an OCP-compliant Caliptra Root of Trust for Measurement, implemented inside CryptoManager. Van der Leest told SCN that customers then moved from evaluating Caliptra to needing a trademark-compliant route to production, which required the real, unmodified core rather than a Caliptra-aligned function inside Rambus's own IP.
Paul Karazuba, Rambus's vice president of product marketing for silicon IP, said the product is for any chipmaker designing for the data center, naming hyperscalers alongside third-party vendors of AI accelerators, data processing units (DPUs) and network interface cards (NICs). Asked whether hyperscalers are already requiring Caliptra from suppliers, he answered: "Yes, many hyperscalers are writing Caliptra compliance into supplier requirements today."
SCN could not find public confirmation from a cloud operator. Microsoft's Azure blog posts on Caliptra from 2022, August 2025, and October 2025, and the CHIPS Alliance's 2.1 announcement, describe the project and its roadmap but do not state a supplier mandate. The closest published statement is a 2022 SemiAnalysis report, which said, based on conversations at that year's OCP Summit, that Microsoft and Google would make Caliptra a requirement for chips supplied to their data centers. That was a forecast. Rambus did not name which hyperscalers it meant, and the exemption filings show at least one integrator working through the trademark audit in September 2026 without identifying whose requirement drives it.
Based on the available evidence, merchant silicon is the likelier fit. Hyperscalers with custom chips helped write Caliptra and employ their own hardware security teams. An AI accelerator, DPU, NIC, or storage-controller vendor that wants into those racks may lack a large root-of-trust group yet would still need an audited core, a certification path for PCIe or CXL encryption, and a supplier that responds when a vulnerability is disclosed. Rambus has named no customers, so that remains an inference.
"I strongly believe in standardization when it comes to security, but I also want to stress that this is different from commoditization." - Vincent van der Leest, Rambus.
Van der Leest said Caliptra does not mandate a physical unclonable function (PUF), and trademark compliance does not require one; PUF support in CryptoManager is optional. He framed the broader line between open and proprietary as standardization without commoditization: algorithms and open specifications like Caliptra set the common base, and IP vendors differentiate on implementation, integration, and support.
Rambus does not report security IP as a separate business. Its second-quarter 2026 results showed record revenue of $207.4 million, including $99.2 million in product revenue, $84.2 million in royalties, and $24.0 million in contract and other revenue. The company's 10-Q says product revenue consists primarily of memory interface chips, and it folds security IP development projects into the contract and other line alongside high-speed interface IP, so the security business has no figure of its own.
Memory is still the reason the company is in this market, on its own. Van der Leest said securing data that moves across interfaces or sits in memory takes both the interface security blocks and a hardware anchor for identity, keys, secure boot and attestation. Its server memory business sits in a market where data center AI demand has reorganized the memory supply chain and where, as SCN reported in April, HBM allocation rather than raw supply has been forcing the rest of the server to adapt. Encrypting that memory, and the CXL links that extend it, needs keys issued from a root of trust.
The algorithm list carries a sovereignty dimension. A product built around a root of trust founded by US cloud and chip companies lists China's SM2, SM3 and SM4 beside the NIST post-quantum standards, so the same hardware offers both sets. The Caliptra specification cites the US National Security Agency's CNSA 2.0 guidance for its use of LMS signatures and for optional ML-DSA-87. On September 3, 2026, CISA and the Group of Seven (G7) Cyber Security Working Group published a call to action on preparing for post-quantum cryptography (PQC) that names integrating PQC into cybersecurity requirements and procurement processes as a priority. Once PQC is written into procurement, buyers can check algorithm support line by line, and a chip sold into more than one regulatory regime may need to carry more than one algorithm family. Operators of US federal supercomputers already face a related compliance load under the NIST SP 800-234 HPC security overlay.
Several facts would show how far the beside-the-core model reaches, and none is public yet: the Caliptra version and mode CryptoManager pairs with, whether Rambus seeks an IP-level trademark evaluation and from which lab, whether a hyperscaler confirms the supplier requirement on the record, and whether a named chip carrying both blocks appears in the Approved Products Registry.
The SCN Staff is a small AI editorial squad working under human direction. Each agent owns one job.
Scout does the research. It runs down primary sources and checks what's already been published, on SCN and everywhere else, before a story gets written. If a claim can't be traced back to a real document, Scout flags it.
Forge writes. It takes what Scout found and turns it into a draft, argument and sentences and all. Every SCN piece starts here, then gets sharpened.
Cipher handles search: the titles, descriptions, and keyphrase work that decides whether a good article ever gets found. Least glamorous job on the squad. Also one that matters more than it looks.
Pixel makes the visuals. Images, charts, the occasional diagram, all built to SCN's brand instead of pulled from a stock library. When something's easier to see than to read, it goes to Pixel.
Editorial judgment and the final call stay with the humans. So does the fact-checking.
