Summary

  • Caliptra is an open-source root-of-trust project for data-centre systems-on-chip, launched in 2022 by AMD, Google, Microsoft and NVIDIA through the Open Compute Project.
  • Its core combines immutable ROM, mutable firmware, lifecycle controls, cryptographic hardware, a DICE Protection Environment and attestation services for CPUs, GPUs, DPUs, accelerators and storage controllers.
  • Caliptra 2.x, the Subsystem, Adams Bridge and OCP L.O.C.K. broaden the design, while component compatibility, patch history and integration remain material operating risks.
  • Public RTL improves scrutiny but does not expose every physical implementation, provisioning system, endorsement certificate or production deployment; no comprehensive shipping census was supplied.

Four competitors treated a root of trust as shared infrastructure

AMD, Google, Microsoft and NVIDIA announced Caliptra at the Open Compute Project Global Summit in October 2022. The founding group combined silicon vendors and hyperscale operators whose commercial interests often compete. Their security problem overlapped.

AMD and NVIDIA build complex processors and accelerators that need internal trust mechanisms. Google and Microsoft operate fleets large enough that inconsistent component evidence becomes an operational cost. A proprietary root of trust can be effective within one product, but every separate design requires new review, integration and verifier logic.

The shared project offered a pre-competitive foundation. The companies could collaborate on identity, measured boot, firmware authentication and attestation while continuing to differentiate processors, accelerators, cloud services and manufacturing.

Open Compute Project was a natural launch venue because it already brought large operators and hardware suppliers together around server, storage and security requirements. Major Caliptra specifications remained in that environment. The design was not framed as a hobbyist open-hardware exercise. It was intended to be consumed by organisations building data-centre silicon.

Specification work alone would have been insufficient. Text can define interfaces and required behaviour, but it cannot reveal bugs in RTL, firmware or verification. In December 2022, Caliptra joined CHIPS Alliance, which provided public repositories, contribution rules, licences, meetings and a continuing implementation process under the Linux Foundation ecosystem.

This institutional split remains one of the project’s defining features. OCP publishes major requirements and use-case specifications. The Caliptra Workgroup within CHIPS Alliance develops the code, firmware, verification and releases. The separation is not perfectly clean—many of the same companies participate in both—but it prevents the project from being presented as one vendor’s private security controller with a public document attached.

The founding alignment also has limits. Shared code does not imply a shared endorsement hierarchy, factory process or deployment schedule. Each integrator decides how to manufacture and provision the block. A common root can reduce duplicated engineering without transferring product control to the project.

Open licensing moves cost into integration and assurance

Caliptra is released under the Apache License 2.0. Vendors can reuse and modify the design without a per-unit proprietary IP licence from a conventional security-block supplier. Shared development can reduce duplicated work and give operators more influence over the common interface.

The cost moves rather than disappears. Engineers must integrate the block, verify the product, implement physical protections, manage provisioning and support field updates. Independent assessment and post-silicon evaluation are expensive. A vendor that forks the code must maintain the fork through vulnerabilities and standards changes.

Large founding companies can absorb these costs and contribute specialists. Smaller silicon firms may benefit from the common design while lacking the resources to evaluate it at the same depth. Open access can widen participation and produce uneven assurance.

The project’s sustainability depends on contributors continuing to fund work that benefits the ecosystem. The common block reduces cost only if fixes and features return upstream instead of fragmenting into private branches. Product schedules and disclosure constraints can work against that incentive.

For buyers, the economic benefit is not simply free RTL. It is the possibility of comparable evidence across suppliers and less dependence on a private root design. That benefit materialises only when implementations are documented well enough to substitute or audit.

A healthy ecosystem may support commercial verification, integration and certificate services around the open core. Those businesses can finance expertise without owning the project. They can also create new dependencies that need to be distinguished from the shared specification.

Caliptra is best understood as pre-competitive infrastructure. Its licence makes collaboration legally possible. Governance and sustained engineering determine whether the collaboration remains economically credible.

The server no longer has one first instruction or one security boundary

The familiar secure-boot diagram starts with a single processor, an immutable first stage and a chain of signed software leading toward an operating system. A data-centre server is now a collection of computing systems. A GPU can run substantial firmware. A DPU can control networking, storage and host management. An accelerator may load code independently. A storage controller can hold encryption keys and decide whether media is readable.

Each component creates a first instruction and a first trust decision of its own. If one controller is compromised before the host begins its checks, the host’s clean boot may prove little about the whole machine. Cloud operators need evidence from components whose internal security designs have historically differed by vendor and product line.

Caliptra addresses this fragmented boundary at the silicon level. It defines and implements an integrated root of trust for measurement inside a system-on-chip. The block establishes a device identity, authenticates and measures firmware, enforces lifecycle policy and produces signed evidence that another system can evaluate.

The project is deliberately narrower than a complete platform-management processor. It does not schedule workloads, operate a cloud certificate authority or define every secure-boot stage in a server. The narrow scope is intended to make the block reusable inside many classes of chip.

That reusability is strategically important. A cloud provider buying components from several suppliers wants a common way to ask: which device is this, what code did it start and which authority endorsed the evidence? A silicon vendor wants to avoid rebuilding every cryptographic and attestation primitive while retaining control of product integration.

The shared layer cannot make all devices identical. Manufacturers choose fuse maps, physical protection, packaging, clocks, memories and provisioning. Platform owners decide which measurements are acceptable. Caliptra’s value lies in creating a common point of inspection inside a supply chain that remains diverse.

The distinction also explains why it should not be introduced as a chip company. Caliptra has no product catalogue, shareholders or sales organisation. It is a collaborative hardware-and-firmware project whose outputs become real only when another organisation integrates them into silicon.

A device secret needs a common evidence profile

A root of trust needs a starting fact that ordinary software cannot rewrite. Caliptra combines unique device material, lifecycle state and immutable first-stage code to establish that base. The design then derives identities and evidence for later components rather than handing the deepest secret to every caller.

The boot sequence begins in ROM. The ROM authenticates and measures First Mutable Code, which in turn establishes runtime firmware and services. Security version numbers can prevent an attacker from rolling mutable firmware back to an older signed but vulnerable release. The sequence creates a chain in which the state of later code is connected to an earlier, more restricted authority.

Caliptra aligns with Trusted Computing Group DICE concepts through a DICE Protection Environment. DPE can derive compound identities from measurements and context, allowing components within a system-on-chip to obtain signing or attestation capability without direct access to the root secret.

This delegation matters in a large chip. A management controller, security service or component can present evidence tied to its measured context. Verifiers can distinguish identities that descend from the same physical root but represent different functions or states.

The mechanism is often summarised as identity, measured boot and attestation. Those words can conceal a critical division of responsibility. Caliptra can sign evidence. It does not decide whether the evidence is acceptable. A cloud verifier needs an endorsement chain, a database of expected measurements and a policy for what happens when the result differs.

A correctly signed measurement can describe firmware that is authorised and still vulnerable. A device can be genuine and misconfigured. An attestation service can reject healthy hardware because its policy is stale. Trust is not produced by the signature alone; the signature makes a claim attributable.

The project’s contribution is to make that claim originate inside a public, reusable design. The fleet operator’s contribution is to govern the identities and the consequences attached to them. Conflating the two would turn a measurement engine into a promise it cannot keep.

Caliptra’s DPE can derive identities for components inside a chip. Those identities become useful when they are presented through protocols and evaluated by systems that understand their meaning. Standards such as DICE and SPDM provide parts of that wider vocabulary; a TPM may supply another trust service in the platform.

The components are complementary. Caliptra can establish an internal measured identity. An SPDM responder can use device and measurement evidence in communication with another component. A TPM can hold or report host-oriented state. The exact chain depends on the system architecture.

Interoperability requires more than choosing the same signature algorithm. Participants must agree on certificate profiles, measurement formats, context labels and error handling. A verifier needs to know whether an identity represents the physical chip, a firmware environment or a delegated component. Treating all certificates as equivalent can collapse distinctions the architecture was designed to preserve.

Profiles narrow optional behaviour so independent products can be tested together. They also create a governance question: who defines the profile accepted by a cloud or industry segment? A vendor-specific profile can use open protocols while recreating lock-in at the policy layer. A broadly governed profile can improve substitution and may move more slowly than product development.

Caliptra’s reusable block gives implementers a common source for identity derivation. It does not eliminate the need for agreement above it. The most credible product evidence will connect the internal DPE state to an external protocol and verifier policy without leaving ambiguous jumps in the chain.

This is another reason a root of trust should be described as an evidence producer rather than a universal trust service. Cryptography can bind the steps. Profiles and institutions decide what the binding means.

Entropy and key storage sit beneath every signed measurement

A root of trust can authenticate firmware and sign attestation only if its cryptographic material is unpredictable and protected. Caliptra includes entropy and key-vault functions so sensitive values do not need to pass through ordinary host memory.

The logical design cannot guarantee the quality of every physical entropy source. Process variation, startup behaviour and health testing affect randomness. A downstream integrator can connect the block incorrectly or weaken isolation through surrounding logic.

The key vault also creates availability and lifecycle questions. A locked key protects confidentiality and may prevent recovery when policy is wrong. Erasing a slot can be the correct decommissioning action and an irreversible mistake if the identity or media key is still needed.

Verification should therefore cover not only cryptographic test vectors but entropy health, access-control transitions, reset behaviour and failure under power interruption. The strongest signature algorithm cannot repair a predictable secret or a key exposed before it reaches the accelerator.

Immutable ROM stays small because every line becomes a lifetime obligation

The earliest executable code has unusual authority. It also has the worst update story. Once ROM is manufactured into a device, a defect may require a workaround in later firmware, a change to fuse policy or retirement of the silicon. Caliptra therefore moves substantial functionality into authenticated mutable stages.

First Mutable Code provides an early updateable layer. Runtime firmware exposes operational services such as mailbox commands, signing and attestation. The ROM’s task is to establish that these stages are permitted and to preserve the security conditions needed for them to run.

The architecture creates independent version lines for RTL, ROM, FMC and runtime firmware. That is more realistic than pretending the project has one version number. It is also more difficult to operate. An integrator must know which combinations are compatible, which security version numbers are accepted and which component can safely work around a defect in another.

The Caliptra 2.0 line included compatibility guidance that required particular RTL patch levels because of ROM interactions. Such warnings are not a footnote. They show how an immutable component can constrain every update above it.

Anti-rollback policy creates another trade. Rejecting an old version protects a device from downgrade attacks. Burning a security version too aggressively can make legitimate recovery impossible. A corrupted update, lost signing key or emergency image may be unusable because the hardware correctly refuses to move backwards.

Manufacturers control how version fuses, image authorities and recovery paths are provisioned. The open project can define fields and logic. It cannot ensure that every product chooses a safe operational policy.

The 2025 and 2026 patch releases are evidence of a living project, not evidence that the architecture was defective beyond use. Security hardware is complex and will produce bugs. The important question is where a defect resides and whether the affected layer can be updated. An open patch history improves visibility while reminding buyers that silicon maintenance is a multi-year obligation.

Lifecycle recovery must not become a second boot authority

A chip passes through manufacturing, testing, production, field operation, return and decommissioning. The access appropriate at one stage can be dangerous at another. Factory engineers need test and debug capabilities. A production device should not expose the same path to a remote attacker or a technician without authority.

Caliptra uses lifecycle inputs, fuse state and debug-unlock mechanisms to distinguish these stages. The exact integration remains a manufacturer decision. The root of trust can evaluate state and enforce policy, but the physical pins, debug fabric and provisioning station are outside the generic block.

Closing debug permanently can reduce attack surface and make later diagnosis difficult. Leaving an unlock route supports repair while creating a high-value credential or challenge mechanism. A poorly designed return-material process can reintroduce access that production policy intended to remove.

Lifecycle errors can also be irreversible. A device fused into the wrong state may be unusable. A manufacturing key retained too long can undermine field ownership. A product that cannot transition safely at decommissioning may expose data or credentials in resale and recycling.

These decisions are often treated as factory detail. They are part of the security architecture because the root of trust cannot distinguish a legitimate technician from an attacker without a policy and credential system that the manufacturer designed.

Public lifecycle logic can improve review. Integrators can inspect the permitted transitions and reason about failure. It does not reveal whether a particular factory protected keys, whether fuses were programmed correctly or whether a board exposes another debug route around the block.

Caliptra therefore moves one important part of lifecycle enforcement into shared code while leaving responsibility where physical reality sits. The project can make unsafe states harder to define. It cannot supervise every manufacturing line.

A root of trust that only rejects bad firmware can turn a recoverable incident into a dead device. Caliptra 2.0 added support aligned with OCP recovery work so a platform can restore software after corruption or a failed update. Recovery is necessary because mutable firmware is expected to change throughout the life of the chip.

The recovery path is also an authority capable of replacing code. It needs its own authentication, version rules and triggering conditions. If an attacker can invoke it with a malicious image, secure boot has been bypassed through the repair mechanism. If the policy is too strict, an operator may be unable to restore a device after keys or manifests are lost.

Designing recovery therefore requires a second chain of trust that does not silently exceed the first. The root needs to know which authority can provide recovery material, whether rollback is allowed and how lifecycle state affects the operation. Platform owners need a process for storing and rotating recovery credentials over a product lifetime that may outlast the original engineering team.

Recovery also interacts with availability. A device that repeatedly enters recovery can fail to join the fleet even though secrets remain protected. Operators need telemetry that distinguishes a signature failure, corrupted storage, incompatible component version and deliberate quarantine. Without that evidence, a secure controller can appear simply broken.

The project can specify mechanisms and test common paths. Downstream systems control image distribution, network access, physical service and the decision to retire hardware. A recovery feature becomes resilient infrastructure only when those operational pieces are exercised before an emergency.

The existence of a standard path is nevertheless valuable. It reduces the temptation to leave an undocumented factory interface as the only repair option. Caliptra can make recovery part of the reviewed architecture rather than a privileged exception designed after the product ships.

Provisioning is the private ceremony behind every later measurement

Before Caliptra can attest anything, a manufacturer has to create or derive device-unique material, program lifecycle state and establish an endorsement that verifiers will trust. This occurs in factories and secure provisioning systems that the public project does not operate.

A compromised provisioning station can insert predictable secrets, issue fraudulent certificates or record private material. Later boot measurements may be cryptographically correct and rooted in an identity the attacker controls. No amount of field verification repairs a corrupted origin without an independent recovery design.

Factories also need yield testing and debug. The process must allow enough access to diagnose new silicon while ensuring that test credentials and lifecycle permissions do not reach production. Contract manufacturers, package houses and logistics providers can add organisational boundaries beyond the chip designer.

Open specifications can define expected fuse fields, identity derivation and transitions. They can support audits by making the logical ceremony explicit. They cannot publish every key, process control or facility layout. Some secrecy is necessary to protect operational systems; secrecy also makes external assurance harder.

Buyers should therefore ask for provisioning evidence appropriate to the risk: separation of duties, key-generation controls, certificate audit, lifecycle test records and continuity if a factory or certificate authority changes. A second source of silicon is not a real substitute if both products depend on one undocumented endorsement service.

The supply-chain value of Caliptra lies in standardising the interface after provisioning and clarifying what the manufacturer had to do before it. The project does not remove the ceremony. It gives customers a better way to identify the private trust that remains.

The mailbox is a service boundary and an attack surface

Host firmware and other components need a way to request services from Caliptra. The mailbox provides a controlled command path into runtime firmware for functions such as measurement, signing, cryptographic operations, updates and recovery.

A narrow interface is preferable to exposing internal memory or keys. Commands can validate parameters and limit access. The root of trust can keep secrets isolated while still supporting the rest of the chip.

The same interface is an attack surface. A caller may be compromised, malformed or simply noisy. Parsers must handle untrusted inputs. Long cryptographic operations can consume the root’s limited processing capacity. A flood of requests can delay boot or attestation. Privilege mistakes can expose commands to components that should not use them.

Because the root of trust is central, denial of service has wider consequences than failure in an ordinary peripheral. A secure component that becomes unavailable can prevent the platform from proving its state or completing recovery.

The design needs command authorisation, rate or sequencing controls, careful memory boundaries and observability. Integrators need to decide which host agents can call which functions and how failures appear in fleet telemetry.

This illustrates a broader truth about secure hardware. Isolation is not enough. A protected service must remain usable under hostile or faulty demand. The performance and availability of the trust boundary are security properties.

Caliptra’s public implementation allows these paths to be reviewed and tested across contributors. A downstream product can still change wrappers, buses and arbitration. Product assurance must identify the complete call path, not only the upstream command handler.

Independent assessment moved the project beyond self-description

Open hardware is often defended with the claim that anyone can inspect it. The practical question is whether qualified reviewers have the time, tools and product context to do so. Caliptra’s public assessment by NCC Group in 2023 provided an important external examination of a defined architecture and implementation state.

An assessment can find design ambiguity, unsafe assumptions and implementation defects. It can also confirm that important boundaries were considered. Public findings allow the community to see how issues were handled rather than relying solely on assurances from founding companies.

The scope matters. A review applies to specified versions, configurations and attack models. Later releases add code. A vendor can modify the RTL, synthesise it through different tools, choose a memory implementation and place it in a physical environment with new side channels. No project-level review certifies all those outcomes.

Verification dashboards, regression tests and release checklists address another part of assurance. They can show that defined properties and test cases continue to pass. Coverage is useful evidence and not proof that an unseen flaw does not exist.

Hardware verification also differs from software testing because some defects become permanent. Simulation, formal methods, FPGA prototypes and pre-silicon tests need to identify errors before tapeout. Post-silicon evaluation can expose physical and integration behaviour that the models missed.

The project’s willingness to publish issues and patch releases should be read as maturity. Security claims become more credible when the history includes defects, decisions and fixes. A repository with no visible problems may reflect perfection, weak review or private handling; the public cannot tell which.

The next assurance step is product-specific evidence. Buyers need to know which upstream revision was used, what changed, how physical protection was evaluated and which provisioning process established identity. Caliptra provides a stronger starting point for that inquiry. It does not end it.

Component versions turn a release into an integration contract

Software products often present one release number even when they contain many libraries. Caliptra cannot safely simplify its lifecycle that way. RTL, ROM, First Mutable Code and runtime firmware have different update constraints. The subsystem and cryptographic accelerators add their own versions. A product is a combination.

Independent versioning allows mutable code to improve without manufacturing new silicon. It also creates a matrix in which a security fix can be valid only with certain ROM or RTL levels. Integrators need bill-of-material records precise enough to identify the combination inside each product revision.

Security version numbers add another dimension. A runtime image may be functionally compatible and rejected because its anti-rollback value is lower than the fused minimum. A patched image may require an earlier stage that an old chip does not have. A subsystem release can depend on a core interface that changed between minor versions.

This is ordinary configuration management with irreversible hardware in the loop. The consequences of a mistaken dependency are larger and slower to correct. A data-centre operator may have thousands of devices whose product name is identical while internal revisions differ.

A useful product attestation should therefore report enough component identity for the verifier to apply the right policy. “Caliptra 2” is not specific enough. The report may need core RTL, ROM, mutable firmware security version, subsystem revision and vendor integration profile.

That detail can make fleet policy complex. It is still preferable to treating all devices as equivalent and discovering the distinction during an incident. Version transparency converts hidden heterogeneity into a manageable inventory.

The project’s compatibility tables and patch notes are part of the security model. They define which combinations the upstream team has reason to believe work together. Downstream vendors remain responsible for documenting deviations and testing the exact product.

The Caliptra Subsystem eases integration by enlarging the trusted base

The original Caliptra Core was deliberately constrained. As implementers considered full products, they needed management functions, peripheral interfaces and recovery services around the root. The Caliptra Subsystem added a manufacturer control unit and wider integration environment.

This expansion can reduce duplicated engineering. A system-on-chip vendor receives more of the scaffolding needed to connect the root of trust with buses, storage, recovery and host components. Common implementation can improve interoperability and concentrate review on shared code.

The cost is a larger trusted computing base. More firmware, peripherals and commands create more states to verify. A controller that manages recovery or cryptographic services can become a path into secrets and lifecycle policy. Bugs in the surrounding subsystem may undermine an otherwise sound core.

The distinction between Core and Subsystem should remain visible in product claims. A design may integrate the core with proprietary management logic. Another may use the public subsystem. Their assurance evidence is not interchangeable.

Scope growth is a normal sign of adoption pressure. Users discover that the minimal primitive is difficult to integrate consistently and ask the project to standardise more. The governing question is where to stop. Every common function can improve portability and add maintenance obligations for the project.

Caliptra’s subsystem work also changes the competitive context. A minimal root block can complement an existing security controller. A fuller subsystem begins to overlap with proprietary platform-security processors. Vendors may welcome common APIs while protecting differentiated management features.

The project will need to preserve modularity so an integrator can choose the appropriate boundary without forking the entire design. Security benefits when the trusted base is no larger than the use case requires. Ecosystem benefits when common functions are not reimplemented poorly in every product. The subsystem sits between those objectives.

Adams Bridge brings post-quantum verification into long-lived hardware

Data-centre silicon can remain in service for years, and firmware images may need to be trusted long after manufacture. Cryptographic transitions therefore have to begin before the old algorithms are practically broken. Caliptra 2.x added Adams Bridge, an open hardware accelerator for post-quantum mechanisms including ML-DSA and ML-KEM.

The immediate use is not to declare an entire server quantum-safe. Hardware support can accelerate firmware-signature verification and key-establishment operations that would otherwise be expensive on the small processor inside a root of trust. It gives long-lived devices a path toward algorithms selected through the NIST process.

Post-quantum schemes bring larger keys, signatures and implementation complexity. They create new memory, performance and side-channel considerations. The algorithms and code have had less deployment time than established elliptic-curve systems. Patch history around the accelerator is therefore important evidence, not an embarrassment to conceal.

A hybrid transition may use classical and post-quantum mechanisms together. That approach can protect against uncertainty in either family while increasing message size, verification work and compatibility requirements. Immutable ROM has to know enough to accept the chosen format or delegate safely to mutable code.

The transition also extends beyond the chip. Endorsement certificates, attestation services, update-signing systems and verifier software must understand the new algorithms. A root that verifies ML-DSA firmware can still present an identity through an older external chain.

Version 2.1 added further post-quantum capability, including ML-KEM and an External-Mu mode for ML-DSA. These are concrete project features and not evidence that every downstream product enables them. Integrators will choose profiles based on performance, threat model and ecosystem readiness.

Caliptra’s value is that several vendors can examine and implement a shared accelerator rather than repeat the transition privately. The risk is that a common defect can propagate widely. Independent review, test vectors and clear version reporting are essential precisely because the code is intended for reuse.

OCP L.O.C.K. extends trust from boot to storage reuse

Storage devices present a different security problem. Data-at-rest encryption can make a drive’s contents inaccessible by destroying or changing the media-encryption key. The assurance depends on where the key is generated, stored and erased. A host command that claims to sanitise media is only as trustworthy as the controller enforcing it.

OCP L.O.C.K., whose version 1.1 was published in June 2026, extends Caliptra for storage media-key protection and cryptographic erase flows. The work connects the root-of-trust block with storage-controller functions without pretending the root itself is the encryption engine.

The use case matters for circularity. Data-centre drives may be redeployed, repaired or retired. Secure key destruction can make reuse safer and reduce the need to destroy functioning hardware. A verifiable controller can provide evidence that the key path followed the required state transition.

The boundary remains product-specific. A storage vendor supplies the media encryption, controller firmware and physical design. The device owner supplies sanitisation policy and inventory. Caliptra can isolate and authorise key operations, but it cannot guarantee that every data copy or remapped block is covered by the vendor’s encryption design.

L.O.C.K. also illustrates how a project can expand through a profile. Not every Caliptra integration becomes a storage device. The extension defines a particular set of interactions and named industry participants. Claims should identify whether the downstream product implements the relevant version and has been tested under the intended erase and recovery scenarios.

There is a governance implication. Once a common root controls keys whose destruction determines legal and operational reuse, its lifecycle becomes part of asset management. A firmware bug can delay decommissioning across a fleet. An overly permissive recovery route can undermine erase assurance. A mistaken irreversible transition can destroy data still needed.

The storage extension moves Caliptra from a boot-security component toward a broader infrastructure security service. That growth increases its economic relevance and the cost of a defect.

Open logic leaves physical assurance private and expensive

Caliptra’s RTL and firmware can be inspected, simulated and synthesised. Reviewers can study key-vault access, lifecycle transitions, cryptographic command paths and DPE context management. The public record allows different companies to discuss the same implementation rather than compare marketing descriptions of private blocks.

The final chip contains choices that are not present in generic RTL. A foundry process, memory macro, clock tree, floor plan, packaging and power distribution affect resistance to physical attack. Fault injection can target voltage or clock behaviour. Side channels can leak through timing, power or electromagnetic emissions. An invasive attacker may bypass logical controls.

Vendors also add wrappers and fuse logic. A secure upstream module can be integrated with an exposed bus or weak debug path. A cryptographic accelerator can be correct and supplied with poor entropy or compromised keys. Synthesis and tool configuration can change assumptions.

An open design should therefore not be sold as automatic assurance. It improves the opportunity for review and reduces secrecy around common logic. Product security still requires physical evaluation, supply-chain control and integration testing.

The project can help by defining security properties, test hooks and integration guidance. It can publish known limitations and encourage independent assessment. It cannot force a manufacturer to disclose every layout or factory procedure, and public disclosure may itself create risks for a particular product.

The practical standard should be evidence proportional to the claim. A vendor saying that a chip incorporates Caliptra can identify the upstream version and modifications. A vendor claiming resistance to physical attacks should present evaluation for the actual implementation. A cloud operator claiming attested fleet integrity should explain the endorsement and verifier model at an appropriate level.

Open hardware moves the baseline from “trust the vendor’s private implementation” to “inspect the shared design and demand evidence for the private remainder.” That is a meaningful change. It is not the end of trust.

Attestation reports the start of execution, not everything that follows

A root of trust produces measurements so that another system can act on them. In a fleet, the verifier may compare evidence with approved firmware manifests, certificate chains and lifecycle state. It can admit a device, quarantine it or withhold keys and workloads.

Common evidence across CPUs, GPUs and DPUs can reduce integration cost. A platform operator can build one policy framework instead of interpreting unrelated vendor formats. Component identities can make inventory and incident response more precise.

The verifier gains substantial power. It decides which firmware is acceptable and which endorsement authorities are trusted. A policy error can reject healthy devices at scale. A compromised verifier can admit malicious state or correlate identities beyond the original security purpose.

Caliptra does not operate that service. Founding cloud companies have strong incentives to develop their own fleet verification and certificate infrastructure. Silicon vendors establish device endorsements. Customers may see only the result, not the full policy.

This division protects commercial autonomy and limits project control. It also means that two Caliptra-based products can produce evidence that is technically compatible and operationally accepted by different authorities. Common format does not imply common governance.

Fleet operators need verifier continuity plans. Policy changes should be versioned and tested. Endorsement roots need rotation and recovery. Exceptions should be auditable. Evidence retention should reflect privacy and incident requirements rather than default to indefinite collection.

The open root can make the measurement path more inspectable. The next concentration point moves into the service that interprets it. Security leadership should examine that service with the same scepticism applied to the chip.

Caliptra can measure authenticated firmware and derive evidence from the boot chain. That evidence is valuable because early code establishes identities, memory protections and update policy. It has a temporal boundary.

After boot, authorised firmware can encounter a vulnerability, receive hostile input or make a bad decision. A DPU can start from an approved image and later enforce the wrong network policy. An accelerator can attest its firmware and produce an incorrect result because of a runtime bug or fault. The root of trust does not observe every instruction or application outcome.

Fleet systems need to combine boot evidence with runtime telemetry, vulnerability inventory and behavioural controls. A measurement should identify the state it covers and the time it was taken. Long-lived credentials may need renewal or re-attestation after important changes.

This boundary protects against exaggerated claims. “Attested” should not become a synonym for safe. It means that specified evidence was signed by an identity under a verifier’s policy. The quality of the claim depends on what was measured and how the system responded afterward.

The distinction also helps incident response. A valid attestation can narrow an investigation away from boot tampering and toward runtime or application causes. An invalid result can trigger isolation without proving malicious intent. Evidence is most useful when it reduces uncertainty rather than pretending to eliminate it.

Governance and deployment remain divided across institutions

Caliptra has no conventional executive team. Technical authority is distributed among the OCP specification process, the Caliptra Workgroup, CHIPS Alliance governance, maintainers, repository reviewers and contributing companies. Downstream integrators control the final product.

The arrangement gives each institution a defined purpose. OCP connects requirements to data-centre operators and hardware suppliers. CHIPS Alliance supplies a neutral legal and project home. The workgroup conducts public meetings and develops releases. Maintainers decide whether changes meet technical standards. Companies provide most of the specialist labour and deployment knowledge.

Neutral hosting reduces the risk that one vendor can close the project or redefine interfaces privately. It does not equalise resources. A hyperscaler or silicon company can assign engineers, run expensive verification and bring product constraints unavailable to an independent contributor. Informal influence follows capacity.

Public repositories and meetings make decisions more visible. Some of the evidence needed to reproduce a choice may remain proprietary: physical results, customer requirements or unannounced product schedules. The community can review the implementation without seeing every deployment fact that motivated it.

The project’s graduated status within CHIPS Alliance in 2025 signalled process maturity. A supplemental funding mechanism and company contributions support shared work, though no consolidated project budget is public. The absence of accounts should not be mistaken for low cost. High-assurance RTL, Rust firmware, cryptography, verification and security response require sustained experts.

Long-term governance will be tested when founding priorities diverge. A vendor may freeze an older branch for a product. A cloud operator may demand a feature others do not need. A security issue may require coordinated disclosure across confidential integrations. The neutral project has to preserve a common line without pretending every participant ships it on the same schedule.

The institutional design is part of Caliptra’s value. A root of trust shared by competitors needs a forum in which technical legitimacy does not depend on one company’s market position.

Caliptra has releases, public repositories, assessments, patch trains and named integration work. Those facts establish a serious project. They do not establish how many production chips include the block or which fleets rely on its evidence.

AMD has described integration work. Founding companies have presented demonstrations and use cases. Storage participants have contributed to L.O.C.K. The project is aimed at CPUs, GPUs, DPUs and related controllers. A complete product list, unit count and conformance register were not publicly available as of 5 August 2026.

The gap can produce opposite errors. Skeptics may assume there is no adoption because product details are confidential. Advocates may convert founding membership and roadmaps into claims of universal deployment. Neither conclusion follows from the public evidence.

Product cycles partly explain the delay. A root-of-trust block must enter a chip design before tapeout, pass verification and manufacture, then be integrated into boards, firmware and fleet systems. Years can separate project announcement from a named shipping product.

Public conformance would improve the evidence. A registry could identify product, Caliptra revision, profile, assessment scope and relevant extensions without exposing factory secrets. Test suites could establish functional behaviour, while vendors publish separate physical and provisioning assurance.

The project must decide how much control it wants over the name. A permissive label encourages adoption and risks ambiguity. A strict certification programme costs money and may discourage modified implementations. A middle ground can require version and modification disclosure without promising universal security.

The next material milestone is not another broad commitment. It is a product whose integration, evidence path and operating outcome can be examined. Until then, Caliptra should be described as technically mature open infrastructure with incomplete public deployment visibility.

OpenTitan, TPMs and proprietary processors draw trust boundaries differently

Caliptra is often mentioned alongside OpenTitan because both publish root-of-trust hardware and firmware. The projects are distinct. OpenTitan developed a broader standalone design and reached documented production shipment in Chromebooks. Caliptra focuses on an integrated measurement root for data-centre-class systems-on-chip and a multi-vendor component evidence model.

Some concepts and open-hardware work are shared or reused, but a deployment of one does not prove a deployment of the other. Their governance, top-level architecture and product pathways differ.

A discrete Trusted Platform Module offers standardised commands and identity functions at a separate component boundary. It can complement a Caliptra-based chip rather than compete directly. The TPM may attest host state while Caliptra establishes trust inside a processor or accelerator before the host can reach it.

Microsoft Cerberus and other OCP security specifications address platform and firmware protection from another angle. Proprietary security processors can integrate tightly with a vendor’s product and may have mature physical hardening. Their implementation and interfaces are less available for common review.

The choice is not between one universal winner and obsolete alternatives. A server can contain several roots and evidence chains. The engineering challenge is to understand which component vouches for which state and how the verifier combines them.

Caliptra’s structural advantage is a common public block supported by both buyers and suppliers. Its disadvantage is that generic reuse cannot optimise every product, and public implementation does not include the full assurance stack.

The comparison should therefore focus on boundary and evidence. Which code is immutable? Where are secrets stored? Who provisions endorsement? Which measurements cross the interface? Which organisation can update policy? The project name matters less than the answers.

Accelerators and DPUs can alter data without asking the host CPU

The data-centre focus is not an arbitrary market choice. Accelerators and infrastructure processors now perform work that used to pass through the host. A GPU runs kernels and firmware over valuable model and training data. A DPU can enforce network policy, terminate storage paths and manage isolation. A compromised component can affect confidentiality or integrity even when the host operating system is fully patched.

A common internal root lets these devices present identity and boot evidence before the operator entrusts them with workloads. Fleet systems can distinguish a genuine accelerator running an approved firmware line from an unknown or altered device. That evidence can support quarantine, key release and maintenance decisions.

Attestation does not prove the accelerator computed a model correctly. It reports measured code and device state. Runtime faults, malicious workloads and bugs in authorised firmware remain possible. The distinction is essential in AI systems, where a clean boot can be mistaken for proof of trustworthy output.

DPUs create another boundary. They are often intended to isolate infrastructure services from tenant-controlled hosts. The root of trust must remain credible when one side of the interface is hostile. Mailbox permissions, update authorities and reset behaviour need to preserve that isolation.

Because these processors sit on high-bandwidth paths, availability matters. A root-of-trust failure can prevent an otherwise functional accelerator from joining a cluster or a DPU from presenting network services. Operators need redundancy and replacement procedures that account for component identity changes.

Caliptra’s architectural opportunity is to make this evidence consistent across suppliers. Its strategic risk is that one verifier policy becomes the admission gate for a heterogeneous fleet. The component root reduces uncertainty inside the device while increasing the importance of the control plane outside it.

Coordinated disclosure becomes harder when products are undisclosed

A vulnerability in ordinary open-source software can be mapped to package versions and public distributions. A Caliptra flaw may have been synthesised into silicon whose existence, revision and customer are confidential. The upstream project can publish a patch while lacking a complete list of affected products.

This makes coordinated disclosure a supply-chain exercise. Maintainers need to determine whether the problem sits in mutable firmware, ROM, RTL or a particular integration. Founding and downstream companies need time to identify products and mitigations. Cloud operators may have fleet telemetry that cannot be shared publicly. Researchers need a route to report findings without approaching every possible vendor independently.

The response options vary sharply. Runtime firmware can be updated if the product exposes a trusted path. A ROM or RTL defect may require a mutable workaround, restrictive policy or replacement hardware. A physical weakness may be relevant only to products with a particular layout or package.

Public advisories should therefore identify the affected component and version assumptions without implying universal exposure. Vendors should publish product mappings when disclosure permits. Customers need enough information to decide whether an upstream fix has reached their device.

The March 2026 patch lines show why this machinery matters. Active security hardening is evidence that the project is being examined and maintained. The risk lies not in the existence of fixes but in downstream invisibility. A chip can continue shipping an older snapshot long after the public repository has moved.

A mature Caliptra ecosystem will treat security provenance as a product feature. The bill of materials should connect the physical part to upstream commits and advisories. Without that connection, open development improves the common code while customers remain uncertain about the silicon in front of them.

A common root improves supplier choice only when evidence survives a vendor change

One promise of shared infrastructure is reduced dependence on proprietary security blocks. A buyer could ask several silicon suppliers for a root that exposes familiar measurements and identity. The verifier would not need to be rebuilt from the beginning for every device.

Functional compatibility is not enough for substitution. Vendors may provision different endorsement hierarchies, support different lifecycle states or expose different recovery guarantees. One implementation may use the Caliptra Core and another the Subsystem. Physical hardening and post-quantum options may differ.

A buyer therefore needs a profile that states which behaviours are required and which remain vendor-specific. Conformance tests can verify command and evidence formats. Procurement terms can require disclosure of versions, update support and certificate continuity. Independent evaluation can address product-specific physical and integration claims.

The exercise may reveal that two “Caliptra-based” parts are not interchangeable. That is a useful outcome. Real resilience comes from knowing the cost and limits of substitution before a supplier fails, not from assuming that a shared logo guarantees it.

The project can support this market by keeping interfaces stable, documenting optional features and resisting vague use of its name. It need not become a central certification authority to make evidence comparable.

If Caliptra succeeds at this layer, its greatest economic contribution may be quiet. Cloud and hardware buyers will be able to negotiate around a common trust interface while vendors continue to compete on processors, performance and assurance. The open block will not eliminate supplier power. It will make one of its most opaque foundations easier to test.

Caliptra makes the first component claim inspectable rather than automatically trustworthy

The modern data-centre security problem is not a lack of cryptographic primitives. It is the number of components whose first code and identity must be trusted across vendors. Caliptra offers a common internal root from which those components can measure themselves and present evidence.

Its architecture is concrete: ROM, mutable firmware, lifecycle state, key storage, cryptographic accelerators, DPE and a mailbox. Its institutions are concrete too: OCP specifications, CHIPS Alliance repositories and a public workgroup. Patch releases and external assessment show that the design is maintained rather than frozen in a launch announcement.

The boundary remains equally concrete. Manufacturers own physical implementation and provisioning. Platform operators own verifier policy. Product vendors decide which version and extensions ship. Customers may lack a complete view of all three.

That division is not a reason to dismiss the project. It is the reality an open root of trust needs to expose. Caliptra can make the shared logical foundation inspectable and reduce the number of private designs. It cannot turn a complex supply chain into one trust decision.

The project will deserve broader claims when product evidence, conformance and field outcomes catch up with code maturity. Until then, its achievement is narrower and still significant: competitors agreed to build the component that makes a device’s first security statement in public.