Caliptra Explained: Open Source Silicon Root of Trust for Data Centers

Caliptra is an open source root of trust block that chip designers place inside a data center system on a chip (a CPU, GPU, DPU or accelerator). It measures the firmware the chip boots, derives a per-device identity with TCG DICE, and signs attestation evidence that a remote verifier can check. The specification, RTL, ROM and firmware are public under Apache 2.0.

This guide goes one level deeper than our posts on CPU microcode updates and coreboot and verified boot. We read the Caliptra 1.x and 2.0 specifications, the caliptra-sw and caliptra-rtl documentation, the release process, security policy and charter, and the GitHub release record for every tag cited, plus DMTF DSP0274, the OCP attestation requirements, NIST SP 800-193, SP 800-208, FIPS 204 and RFC 9334. Where the project marks something as work in progress, we say so.

Key takeaways

• Caliptra is a Root of Trust for Measurement (RTM) and for Identity (RTI) inside the SoC, not on the motherboard, with a deliberately narrow scope: identity, measured boot and attestation.
• Its identity follows TCG DICE: an obfuscated, fused Unique Device Secret (UDS) feeds IDevID, LDevID and two firmware alias keys, each mixing in a hash of the firmware it represents, so changed firmware means a different key.
• Caliptra does not secure the data path. Its services are control plane only: loading firmware, stashing measurements, signing for an SPDM responder.
• Version 1.x leaves firmware update and recovery to a separate platform root of trust. Caliptra 2.0 adds a subsystem mode with a Manufacturer Control Unit (MCU), OCP streaming boot and recovery, and ML-DSA firmware signatures. Caliptra 2.1 adds ML-KEM and support for OCP L.O.C.K.
• Invasive attacks that remove the package lid, foundry integration, physical design countermeasures, manufacturing test and certification are explicitly outside the specification's scope. Open RTL lets you review the logic, but it does not prove that a given chip was built from that logic.
• The project publishes digests for every official ROM and firmware release, runs a PSIRT and is a CVE Numbering Authority, which gives you hooks to check what you trust.

What is Caliptra, who started it, and when?

The Caliptra README describes the project in one line: IP and firmware for an integrated root of trust block. It targets "datacenter-class SoCs like CPUs, GPUs, DPUs, TPUs" and covers the specification, silicon logic, ROM and firmware needed to implement an RTM block inside the chip. A Caliptra integration gives that chip identity, measured boot and attestation.

The name comes from biology. A footnote in the 1.x specification explains that caliptra is Spanish for "root cap", the deepest part of a plant root.

OCP origins and CHIPS Alliance hosting

The project was created inside the Open Compute Project (OCP), and its major specification revisions are still published at OCP. The day to day source code and documentation live in GitHub repositories under the CHIPS Alliance, which is a Series of LF Projects, LLC under the Linux Foundation. The CHIPS Alliance Technical Steering Committee adopted the Caliptra Workgroup Technical Charter on 4 May 2023. The GitHub API shows the specification repository was created on 7 February 2023 and the caliptra-rtl and caliptra-sw repositories on 14 February 2023, with the subsystem repository (caliptra-ss) following on 24 January 2024. All of them carry the Apache 2.0 licence.

The 1.x specification's acknowledgments list engineers from several chip designers and cloud operators. Governance sits with a Technical Advisory Committee defined in the charter, which merges pull requests for the workgroup.

Why put the root of trust inside the SoC?

A root of trust is the component every later check depends on. Data center boards already carry discrete roots of trust, such as a board security chip or a TPM, and the Caliptra specification argues those are not enough on their own.

NIST SP 800-193 splits firmware resiliency into three functions: protection, detection and recovery. The Caliptra specification notes that physical adversaries "with reasonable skill" can bypass a discrete root of trust's detection capabilities, for example with SPI interposers that sit between the flash chip and the device reading it. A root of trust embedded in the SoC raises that bar because the attacker has no exposed bus between the measuring logic and the code being measured.

So Caliptra takes detection for itself and offers measurement and identity to the rest of the chip. In 1.x it leaves update and recovery to an external platform root of trust, reasoning that a physical adversary can nullify those wherever they live, so moving them out costs nothing while keeping the block small and reusable.

The second argument is consistency. Cloud operators had no uniform root of trust across very different hardware, and a shared reference implementation "intended to be adopted as-is, without modification" gives every chip in a fleet the same identity model and attestation format.

Timeline

Release dates below are the GitHub release publication dates for the tags named. Roadmap target dates in the 2.0 roadmap document differ from some of these, so treat the roadmap as a plan and the tags as what shipped.

What does Caliptra actually do?

The specification frames Caliptra as a small set of services offered to the rest of the SoC through a command mailbox. None of them touch user data at line rate. In the specification's words, supporting "line rate high performance IO cryptography" or any data path capability "is not required".

The boot flow, step by step

Caliptra is among the first microcontrollers released from reset. The 1.x specification (and the passive mode of 2.x) describes this sequence:

1. Power-on reset logic starts both the SoC ROM and the Caliptra ROM.
2. The SoC ROM waits for Caliptra's ready_for_fw signal.
3. The SoC ROM fetches the first mutable code (FMC). If it is Caliptra's firmware, the SoC ROM pushes it into the Caliptra mailbox and issues the firmware load command, and Caliptra ROM authenticates, measures and starts it. If it is the SoC's own FMC, the SoC ROM measures it and sends a "stash measurement" command to Caliptra before running it.
4. The SoC FMC continues the boot as a chain: each stage fetches, authenticates, measures and runs the next, depositing each measurement into Caliptra before running that code.
5. Once Caliptra's runtime firmware is up, it serves attestation APIs over all the measurements it holds.

Caliptra ROM can stash at most eight measurements before its own firmware boots. The rule for integrators is simple: anything security sensitive that the SoC loads before Caliptra firmware is running must be stashed, because a measurement that never reaches Caliptra cannot be attested.

The measurement registers

Caliptra holds 32 PCR banks of 384 bits each, extendable by its SHA engine and readable by its firmware. Extending works the same way a TPM PCR does: the new value is a hash of the old value concatenated with the new measurement, so the final value depends on every measurement and on their order. The measurement log itself needs no protection, because a verifier replays it against the signed PCR value.

The specification uses separate "current" and "journey" PCRs for Caliptra's own firmware. The current PCR reflects what is running now. The journey PCR accumulates every firmware version the device has run since cold boot, including hitless updates. That matters because a device that moved from version A to version B without a reboot may still carry state left by A. A verifier that only sees B would miss that.

How does Caliptra's DICE identity work?

DICE, the Device Identifier Composition Engine from the Trusted Computing Group, is a way to give a device an identity that is bound to the code it runs. The core idea is that each boot layer receives a secret from the layer before, mixes in a measurement of the next layer, and passes the result on. If the next layer's code changes, the derived secret changes, and so do the keys derived from it. The Caliptra specification cites the TCG DICE Layering Architecture (version 1.0, revision 0.19, July 2020), the TCG DICE Attestation Architecture (version 1.00, revision 0.23, March 2021) and the TCG hardware requirements for a DICE "Family 2.0" level.

The key chain

The UDS is never stored in the clear. It sits in fuses as ciphertext, and only Caliptra hardware holds the obfuscation key. A footnote says that key can be a chip class secret or a chip unique physically unclonable function (PUF), with the PUF preferred. At cold boot the hardware deobfuscates the UDS, uses it to derive the first compound device identifier (CDI), and clears it. Private keys and CDIs live in a hardware key vault that firmware cannot read; firmware works with handles, not raw key bytes.

The security state is an input. Debug unlock, design for test and design for debug modes change the FMC CDI and appear in the FMC alias certificate. A device booted with debug enabled therefore presents a different identity, and a verifier can tell.

The owner key is an input too. When firmware is dual signed by vendor and owner, Caliptra latches the owner's public key at cold boot, mixes it into the FMC CDI and reports it in the FMC alias certificate, so a verifier can check that the right owner key was provisioned.

Field entropy and LDevID

IDevID is set at the factory and cannot be renewed. The specification is frank about the risk: a supply chain attacker who obtained the UDS before the part reached its owner could derive IDevID and mint a full fake DICE hierarchy. Field entropy is the hedge. Caliptra provides two 16-byte slots of one-time programmable fuses that the owner can program at onboarding. After the next reset, the device derives a fresh LDevID that the earlier thief cannot compute. The owner registers that LDevID and from then on trusts only keys that chain to it.

The hedge has limits. It does not help against attackers who obtain fuse data after field entropy is programmed, for example during an RMA flow. There is no generic Caliptra revocation service for LDevID, so owners keep an allowlist or revoke an upstream CA. And with only two slots, a second-hand buyer may have none left to program, though the DICE identity still works.

Certificates

Caliptra issues X.509 v3 certificates. In 1.x every certificate uses ecdsa-with-SHA384. The Alias FMC certificate carries FWIDs for the security state and the FMC digest, and the Alias RT certificate carries the runtime firmware digest. Caliptra does not generate CSRs for LDevID or the alias keys; the specification says owners who want to endorse those keys with their own CA must use their own flows. In the 2.0 specification each certificate carries dual signatures based on ECC secp384r1 and ML-DSA-87, to make the RTM quantum resistant.

Security states

Caliptra's state is a three bit encoding driven by the SoC. The top bit says whether debug is locked; the lower two bits map to the device lifecycle.

Any other state counts as insecure and requires Caliptra to flush its secrets. In the SoC's end-of-life state, Caliptra must not come out of reset at all.

How is Caliptra built?

Caliptra ships as independently versioned components. The README lists four of them: RTL, ROM, FMC and runtime firmware. Each uses major.minor.patch numbering. Mutable firmware also carries security version numbers (SVNs) that increase when a security critical fix needs anti-rollback.

The repositories

The hardware

Caliptra Core runs its firmware on a VeeR EL2 RISC-V core, also hosted by CHIPS Alliance. Around it the 1.x specification lists hardware for SHA256, SHA384 and SHA512, ECDSA secp384r1 with HMAC-DRBG for key generation, signing and verification, HMAC SHA384 and AES256-CBC, plus a TRNG (or an API for SoCs that bring their own TRNG, which the specification advises only for early development), a key vault, a deobfuscation engine, PCR banks and the mailbox. Version 1.1 RTL added LMS hardware acceleration and faster ECC. The 2.x line adds the Adams Bridge accelerator for ML-DSA, and in 2.1, ML-KEM.

The firmware stages

How firmware images are verified

In the 1.x image format, a manifest starting with the magic number CMAN carries vendor and owner public keys (ECDSA P384, and up to 32 vendor LMS keys), their signatures, and a table of contents with the SVNs and SHA384 digests of the FMC and runtime images.

At boot, ROM checks the hash of the vendor public keys in the manifest against a hash in fuses, checks the owner key hash if one is fused, checks that the selected vendor keys are not revoked by fuse masks, verifies the signatures, verifies the table of contents, and then compares each image's SVN against its fuse counter. Each anti-rollback fuse bank must support a counter of at least 64. If a layer's signed SVN is below the fused counter, Caliptra refuses to boot it even if the signature is valid. Platforms that handle rollback in a separate platform root of trust can disable this with a fuse.

Post-quantum signatures

The 1.x specification cites CNSA 2.0 guidance and gives Caliptra an option to require LMS signatures in addition to ECDSA. It uses the LMOTS_SHA256_N24_W4 and LMS_SHA256_M24_H15 parameter sets from NIST SP 800-208 (published October 2020), meaning SHA256 truncated to 192 bits and a tree height of 15. Caliptra supports 32 LMS trees for the vendor and one for the owner, and recommends generating them on geographically distributed HSMs, since LMS is a stateful scheme and each one-time key must never be reused.

The 2.0 specification adds an option to use ML-DSA-87 firmware signatures in addition to ECDSA, citing FIPS 204 and CNSA 2.0 category 5 requirements. ML-DSA is the module lattice based signature standard NIST published as FIPS 204 on 13 August 2024. Caliptra 1.3 runtime firmware adds a software-only ML-DSA-87 identity, called PQ.DevID, for silicon already in the field. The specification spells out its limits, covered below.

Caliptra 2.0 and 2.1: passive mode and subsystem mode

From 2.x onwards there are two modes. Passive mode is the 1.x model: the SoC ROM pushes firmware into Caliptra and stashes measurements. Subsystem mode adds a Manufacturer Control Unit, a second microcontroller that holds platform and SoC specific firmware. In subsystem mode the 2.0 specification describes this flow:

1. Power-on reset starts both the MCU ROM and the Caliptra ROM.
2. The streaming boot interface stays gated until Caliptra ROM signals that it is ready for recovery.
3. A platform component, typically something like a BMC, streams Caliptra firmware through the OCP streaming boot interface into Caliptra's mailbox SRAM.
4. A SoC manifest is streamed next, and Caliptra authenticates and measures it.
5. MCU runtime firmware is streamed, and Caliptra routes it to MCU SRAM, authorizes it and lets the MCU run it.
6. MCU runtime firmware enumerates over MCTP and fetches the remaining SoC firmware with DSP0267 PLDM for Firmware Update, using Caliptra to authorize each image.

That is a real change in scope: recovery, which 1.x left to an external device, now follows OCP recovery and streaming boot flows inside the subsystem. The README lists the 2.0 additions as ML-DSA firmware signatures, OCP recovery, the Caliptra Subsystem, HMAC signing of the IDevID CSR and crypto offload mailbox services. Version 2.1 adds ML-KEM and ML-DSA external mu mode in Adams Bridge, OCP L.O.C.K. support (key handling for storage devices, per the roadmap), AES DMA mode, and reduces the Caliptra Core mailbox to 16 KiB in subsystem mode.

The README marks the 2.x ROM, FMC and runtime specifications as work in progress and the subsystem specifications as version 1.0rc1, even though tagged releases exist. Read the specification at the tag you integrate, not at the head of main.

Which versions work together

The compatibility tables in the Caliptra README are short but important:

The 2.0 row carries a warning: only RTL 2.0.2 or later should be used, because of ROM compatibility requirements. Teams that taped out against an earlier 2.0 RTL drop need to check that note carefully.

How do Caliptra measurements connect to SPDM and OCP attestation?

Caliptra produces evidence. Something else has to carry it to a verifier, and in data centers that something is usually SPDM.

SPDM in one paragraph

The Security Protocol and Data Model, DMTF document DSP0274, defines messages a requester (for example a BMC or host) sends to a responder (a device) to authenticate it and read its measurements. Version 1.3.0 was published on 28 June 2023 and supersedes 1.2.1. The core message pairs are GET_DIGESTS and DIGESTS (which certificate chains the device holds), GET_CERTIFICATE and CERTIFICATE (fetch a chain), CHALLENGE and CHALLENGE_AUTH (prove possession of the private key over a fresh nonce), and GET_MEASUREMENTS and MEASUREMENTS (signed firmware and configuration measurements).

Where Caliptra fits in an SPDM exchange

Caliptra does not have to implement SPDM itself. The specification describes DPE as a way for Caliptra to act as "a signing oracle" for an SPDM responder running elsewhere in the SoC, such as on the application processor or the MCU. The responder handles transport, such as MCTP, and message parsing. When it needs to sign CHALLENGE_AUTH or MEASUREMENTS, it asks Caliptra, which signs with a DPE derived key whose certificate chains back through Alias RT, Alias FMC and LDevID to IDevID.

The verifier then gets two things: a certificate chain that encodes Caliptra's own firmware measurements and security state, and signed measurements of the rest of the SoC. If either the Caliptra firmware or the SoC firmware differs from what the verifier expects, the evidence shows it.

OCP specifications Caliptra builds on

The Caliptra specification references three OCP documents directly. The OCP Secure Boot specification governs its firmware signing and key rotation rules. The OCP Attestation of System Components v1.0 (initial release 4 November 2020) sets requirements for device identity, keys and attestation and describes the provisioning CA that endorses IDevID. The OCP ownership transfer work shapes the vendor plus owner dual signature model. Caliptra 2.x adds OCP secure recovery and streaming boot.

Mapping to RATS roles

RFC 9334, the IETF RATS architecture, gives verifiers their vocabulary.

Mapping to NIST SP 800-193

NIST SP 800-193 (May 2018) is the federal guideline for platform firmware resiliency. The Caliptra specification includes a requirement by requirement table showing which SP 800-193 requirements Caliptra meets, alone or with other SoC components. For example, it anchors the chain of trust in immutable ROM, runs on a physically isolated microcontroller, keeps firmware signing key hashes in fuses, refuses older firmware by SVN, and tells the SoC through the mailbox when it detects corruption. The table states plainly that most update and recovery requirements are outside Caliptra Core's scope.

What are Caliptra's trust assumptions and limits?

The specification is unusually direct about what it does not cover.

Out of scope by design

The 1.x specification lists these as explicitly out of scope: foundry IP integration, physical design countermeasures, analog IPs, post manufacture test and initialization (OSAT), and certification. Operational security during manufacturing, which is where the UDS is generated and IDevID is certified, is also called out as outside the specification.

The physical attacker

Non-invasive physical attacks (electromagnetic, electrical, thermal and acoustic, plus fault injection and power analysis) are in the threat model; attacks that depackage or delayer the chip are not. The physical countermeasures section adds two blunt observations. A supply chain adversary has essentially unlimited time to glitch a chip, so the most critical countermeasures must stop non-destructive extraction of secrets. And any key embedded in the RTL itself, and therefore shared across all chips, must be treated as low value, "reaching zero value in a number of quarters".

Manufacturing and the provisioning CA

The vendor's provisioning CA endorses IDevID, typically using an HSM attached to the high volume manufacturing line. The specification states that Caliptra 1.0 alone does not stop a person in the middle in the supply chain from submitting a forged IDevID CSR to that CA. It asks vendors to threat model the UDS injection flow (could the same obfuscated UDS go to several devices?) and the path between Caliptra and the HSM. Field entropy and LDevID exist precisely because IDevID cannot be fully trusted forever.

Measurements are only as honest as the measurer

The asset table in the threat model lists boot measurements that the SoC sends to Caliptra as an asset at risk from manipulation in transit or from the SoC sending false measurements. That row lists no Caliptra mitigation. Caliptra records what the SoC tells it, so a flawed SoC ROM can stash wrong measurements. Only Caliptra's own firmware is measured by Caliptra ROM directly.

Quantum and cryptography assumptions

The 1.x threat model treats any algorithm below 128 bits of security as providing none, assumes NIST-unapproved algorithms provide no security, and excludes quantum attacks, noting that "this exclusion will be removed soon". Firmware verification can require LMS alongside ECDSA, but the 1.x certificate chain itself is ECDSA. The 1.3 software ML-DSA-87 identity has three documented limits:

• It runs in software on the VeeR core because 1.x silicon has no ML-DSA acceleration, so some commands carry significant tail latency.
• PQ.DevID deliberately does not bind to Caliptra's own FMC and runtime measurements, so a PQ.DevID signature says nothing about which Caliptra firmware is running. DPE-mediated ML-DSA-87 leaf certificates do attest runtime measurements, but the specification notes that this is weaker than the classical chain because it depends on the same runtime firmware it attests.
• The production PQ.DevID seed must never be delivered while Caliptra is DebugUnlocked, and runtime firmware does not enforce that rule itself.

For new silicon, Caliptra 2.0 adds ML-DSA hardware in the Adams Bridge accelerator and puts dual ECC and ML-DSA-87 signatures on every certificate in its DICE chain, so the post-quantum signatures cover the same measurement-bound chain as the classical ones.

No data path, no update in Core

Caliptra does not encrypt PCIe links, memory or storage traffic. It can anchor keys that other engines use (the roadmap for OCP L.O.C.K. support describes releasing a key to a storage device's line rate encryption engine), but the encryption happens elsewhere. In 1.x, update and recovery are someone else's job.

Certification is not automatic

Caliptra may fall inside the target of evaluation when a product seeks FIPS 140-3 or similar, but it is not certified on its own account. It runs known answer tests for its algorithms at boot (a failed power-on self test fails boot) and conditional tests before use. The 2.0 roadmap lists subsystem FIPS certificate availability as "TBD". A chip that integrates Caliptra is not automatically certified for anything.

How is open source RTL reviewed and released, and why does it matter?

The release process

The hardware release process in the specification repository describes two tracks. Nightly: a workflow updates the RTL submodule pointer in caliptra-sw to the head of caliptra-rtl main, runs a Verilator smoke regression, and on success produces a release collateral archive tagged release_vYYYYMMDD_N. Major releases: the hardware team works through a release checklist, tags vMAJOR.MINOR on main, and creates a patch_vMAJOR.MINOR branch for later fixes. The software repository then pins that exact RTL in a submodule, and the rule is that RTL included in a caliptra-sw release "must exactly match" the RTL release tag.

The release checklist (version 2.1) requires closing critical issues, auditing CI pipelines (coverage, lint, synthesis, nightly UVM regressions including ROM), auditing RTL for FIXME and TODO items, a manual coverage review, FPGA validation and a completely clean lint run. Documentation-only changes get identifiers such as v2.0.2+1.doc so nobody mistakes them for RTL changes.

Release collateral includes RTL source, ROM binaries, register headers, release notes listing which tests passed and failed, and git hashes from both repositories, plus a separate archive with an FPGA bitstream and an integrator checklist.

Published digests you can check

The caliptra-sw README lists every official ROM release with SHA256 and SHA384 digests (with and without logging) and its git commit, and the SHA384 digests in each FMC and runtime manifest. A documented command regenerates the table from source. That is an open reference value: if a vendor says its chip uses ROM 2.1.2, you can compare the reported measurement against a digest you can rebuild yourself.

Vulnerability handling

Caliptra has a PSIRT made up of Technical Committee members. Its security policy commits to acknowledge reports within two working days and, if a report is accepted, to assign it for analysis within seven calendar days. Reports go through GitHub private vulnerability reporting on each repository or by email, optionally encrypted with a published PGP key. The project is listed as a CVE Numbering Authority, and registered product creators can receive embargoed vulnerability notifications before public release.

The specification repository also contains a third-party security assessment report in two revisions dated October 2023, and the 2.0 roadmap lists further third-party ROM and RTL security reviews under the OCP SAFE program as a planned item.

Why open RTL matters for supply chain trust

A closed root of trust asks you to trust the vendor's description. An open one lets anyone read the logic, rerun the regressions and compare reported measurements to published digests. Our microcode post shows the opposite case, where you can check a signature but not read what was signed.

Open RTL does not solve everything. The silicon a foundry builds may differ from the reviewed RTL through the physical design flow, and the specification puts physical design outside its scope. Vendors integrate Caliptra into their own SoC, with their own SoC ROM and fuse controller, and those parts are usually closed. What open RTL buys is a shared, reviewable baseline and a common measurement format, which is a large improvement over every vendor inventing its own.

The project also publishes a trademark policy with a checklist and evaluation methodology, and says reference RTL and firmware are meant to be adopted without modification, which keeps measurements comparable across vendors.

How does Caliptra compare with a TPM, a management security processor and OpenTitan?

These are categories, not products. A real server can carry several of them at once, each doing a different job.

None of these replaces the others. Caliptra measures the SoC from inside, a board level root of trust can still handle flash protection and recovery, and a TPM can still hold operating system keys; the Caliptra specification even lists authenticating to a discrete TPM as a DPE use case.

Step by step: build Caliptra firmware and run the tests

These commands come from the caliptra-sw README and the Verilator README in the same repository. You need Linux and a recent Rust toolchain; the project's CI uses Rust 1.95. Nothing here touches real hardware or fuses.

Step 1: clone with the DPE submodule

Install Rust with the official installer first and check cargo --version.

git clone https://github.com/chipsalliance/caliptra-sw \
    --config submodule.recurse=true \
    --recurse-submodules=dpe
cd caliptra-sw

Step 2: pick the line you care about

The main branch tracks 2.x. The 1.x line lives on the caliptra-1.x branch. To work against a specific firmware release, list and check out its tag:

git tag --list 'fw-2.1.*' 'rom-2.1.*'
git checkout fw-2.1.3
git submodule update --init --recursive

Step 3: build

cargo build

Step 4: run the tests against the software emulator

cargo test runs the unit tests on your host CPU and the integration tests against sw-emulator, a fast software model of Caliptra hardware. The README notes its fidelity "may not be perfect", so treat it as a development tool, not a substitute for RTL simulation.

cargo test

To run one emulator test, for example the deobfuscation engine driver test, and capture an instruction and register trace:

CPTRA_TRACE_PATH=/tmp/trace.txt cargo test -p caliptra-drivers test_doe
head -40 /tmp/trace.txt

Step 5: regenerate the release digest table

The README documents a command that rebuilds release binaries and prints the same digest table it publishes. Run it on a clean checkout and compare against the README:

cargo xtask release info --markdown --build

If your rebuild gives a different ROM digest from the published one for the same tag, stop and find out why before you trust either.

Step 6: run against the RTL with Verilator (optional, slow)

For high fidelity, the project simulates the real RTL with Verilator 5.004 or later. The full suite "will take several hours". A single test runs in seconds:

git submodule update --init --recursive hw/latest/caliptra-ss
cargo test --features=verilator -p caliptra-drivers test_pcrbank

To dump all waveforms for debugging:

CPTRA_TRACE_PATH=/tmp/trace.vcd cargo test --features=verilator -p caliptra-drivers test_pcrbank

What should operators ask chip vendors about Caliptra?

If you buy servers rather than design chips, these questions turn the specification into procurement checks:

Common mistakes

Treating Caliptra as a full platform root of trust. In 1.x it measures and attests; it does not protect flash, orchestrate updates or recover a bricked board. Plan for a board level root of trust or the 2.x subsystem for those jobs.

Trusting IDevID forever. The specification says IDevID is not renewable and that a supply chain attacker with the UDS can wield it. Register LDevID at onboarding and trust that from then on.

Reading the head of main as the specification for your chip. The 2.x module specifications are marked work in progress. Use the documents at the release tag your vendor integrated.

Assuming SoC measurements are self-verifying. Caliptra stores what the SoC sends it. If the SoC ROM or a later stage is faulty, the measurement can be wrong while the signature over it is perfectly valid. Verify reference values for every stage, not just Caliptra's own.

Ignoring the security state in the certificate. A part booted with debug unlocked derives a different FMC identity. Verifier policy should reject anything not in DebugLocked production unless you are explicitly debugging.

Delivering a production PQ.DevID seed in debug mode. The 1.3 specification says runtime firmware does not enforce this, so your manufacturing flow must.

Burning SVN fuses casually. Each bank must support at least 64 increments and the specification expects the feature to be "used sparingly". A burned fuse cannot be unburned, and an early burn can lock out a firmware you still need.

FAQ

What is Caliptra in simple terms?

It is an open source security block inside a data center chip. It records which firmware the chip booted, gives the chip an identity tied to that firmware, and signs a report a remote service can check.

Who maintains Caliptra?

The CHIPS Alliance Caliptra workgroup, under the Linux Foundation, maintains the code under a charter adopted on 4 May 2023. Major specification revisions are published at the Open Compute Project, where the project began.

Is Caliptra the same as a TPM?

No. A TPM is usually a separate board chip holding keys and PCRs for the platform and operating system. Caliptra sits inside the SoC die and measures and attests that chip's firmware. Both use PCR style measurements.

Does Caliptra use DICE?

Yes. Its identity follows TCG DICE: a fused Unique Device Secret feeds a chain of compound device identifiers and keys (IDevID, LDevID, Alias FMC, Alias RT), each mixing in a measurement of the next layer. It also implements the DICE Protection Environment so other SoC components can get DICE identities.

How does Caliptra relate to SPDM?

Caliptra provides the keys and measurements; an SPDM responder in the SoC provides the protocol. Through DPE, Caliptra acts as the signing oracle for messages such as CHALLENGE_AUTH and MEASUREMENTS defined in DMTF DSP0274.

Is Caliptra post-quantum safe?

Partly, depending on version. Version 1.x can require LMS hash based signatures for firmware, and the 1.3 runtime adds a software ML-DSA-87 identity with documented limits. Version 2.0 adds hardware ML-DSA firmware signatures and dual ECC plus ML-DSA-87 certificates, and 2.1 adds ML-KEM.

What does Caliptra not protect against?

Invasive attacks that open the package, flaws in the vendor's SoC ROM that send wrong measurements, compromise of the manufacturing line or provisioning CA, and anything on the data path. In 1.x it also does not handle firmware update or recovery.

What is the difference between Caliptra Core and Caliptra Subsystem?

Caliptra Core is the root of trust block: RISC-V core, crypto, key vault, ROM and firmware. Caliptra Subsystem, from 2.0, adds a Manufacturer Control Unit and peripherals so the block can also stream in firmware, recover from failure and authorize the rest of the SoC's firmware.

Where Safeguard fits

Safeguard does not analyse RTL, silicon, fuses, firmware images or attestation evidence, and it does not act as an attestation verifier. Nothing in Safeguard checks whether a Caliptra ROM digest matches a published value or whether a DICE chain is valid; that is your verifier's job. The fit is with the software that surrounds a root of trust. The caliptra-sw tree is a Rust workspace with a Cargo lockfile, and the services a fleet builds around attestation (verifiers, onboarding and provisioning tools, BMC management software, certificate handling code and the CI containers that build all of it) are ordinary repositories and images with open source dependencies. Safeguard's dependency scanning covers Cargo alongside npm, PyPI, Maven, Go and other ecosystems, so those repositories can be inventoried, matched against vulnerability data and gated like any other code you ship.

A root of trust is only useful if the verifier, provisioning service and build tooling around it are kept patched, and every one of those is assembled from open source components that get CVEs. The fit here is indirect: the steps below cover the code you build and ship, not the silicon or the firmware the chip vendor signs.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The demos below show the software side only. They do not inspect silicon, fuses or attestation reports.

The first demo is a real Safeguard CLI session: ask it to fix a lodash CVE and it reads the advisory, asks before each command, edits package.json, runs npm install and npm test, and pushes nothing. The same flow applies to a Rust attestation verifier or build tool, where the inventory covers Cargo crates.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and then scans from the terminal. That suits firmware and verifier teams who keep source on internal build hosts and do not want it sent to a hosted scanner first.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude may use. An engineer reading the Caliptra runtime specification in one window can ask, in the same conversation, which of their services still carry a vulnerable dependency.

Click through it at your own pace, or open it full screen.

To try the CLI yourself, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Caliptra project README (chipsalliance/Caliptra)
• Caliptra specification 1.x (Caliptra.md)
• Caliptra 2.0 specification source and README
• Caliptra 2.0 and 2.1 roadmap
• Caliptra Workgroup Technical Charter
• Caliptra hardware release process
• Caliptra security policy
• Caliptra specification repository documents folder
• caliptra-sw README
• caliptra-sw ROM specification
• caliptra-sw FMC specification
• caliptra-sw runtime specification
• caliptra-sw Verilator README
• caliptra-sw releases
• caliptra-rtl README
• caliptra-rtl release checklist
• caliptra-rtl releases
• Caliptra Subsystem hardware specification
• caliptra-dpe README
• VeeR EL2 RISC-V core
• CHIPS Alliance
• Open Compute Project security project
• OCP Attestation of System Components v1.0 (4 November 2020)
• DMTF DSP0274 Security Protocol and Data Model 1.3.0 (28 June 2023)
• NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)
• NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes (October 2020)
• FIPS 204, Module-Lattice-Based Digital Signature Standard (13 August 2024)
• RFC 9334, Remote ATtestation procedureS (RATS) Architecture
• OpenTitan
• OpenTitan documentation: introduction

Last reviewed: 24 October 2026. Caliptra releases often, and the 2.x module specifications are still marked work in progress; check the release tag and specification your silicon vendor integrated.