Compromising a single weak chiplet or the interconnect can be sufficient to threaten the entire device platform.
Chiplet architectures are quickly becoming the dominant approach for building scalable, heterogeneous SoCs. By disaggregating a monolithic die into multiple interoperable chiplets, silicon designers gain flexibility in process node choices, reuse of proven functions, and faster time-to-market. At the same time, disaggregation breaks one of the most fundamental assumptions in traditional SoC security: that the system trust boundary maps neatly to a single piece of silicon.
With chiplets, the device is no longer monolithic but a distributed, frequently multi‑vendor die design. Trust must extend across multiple dies, across die-to-die links, and across different suppliers. This shift transforms the threat model: attackers no longer need to compromise a single SoC; compromising one weak chiplet, or the interconnect, can be sufficient to threaten the entire platform.
This multi-part blog series explains why chiplet security must be addressed at a system-level, proposes a practical security model for chiplet-based platforms, and introduces a reference architecture that anchors trust and orchestration in the Main Security Chiplet through the RT-6xx Root-of-Trust family, while extending cryptographic enforcement across the remaining chiplet fleet using the RT-1xx Root-of-Trust family.
The motivation for chiplets is clear: performance scaling is increasingly limited by yield, scaling constraints, and economics. Partitioning an SoC into chiplets creates modularity, enabling rapid integration of compute, AI acceleration, memory controllers, and I/O into customizable platforms. Standardization efforts such as UCIe and BoW (Bunch of Wires) accelerate this direction by encouraging interoperability and enabling multi-vendor ecosystems.
Security, however, shall not lag the architectural revolution. Traditional SoC security design implicitly relies on a “unified silicon boundary”: the die itself becomes the physical container for assets, the execution environment, and the trust anchor. Chiplets break this model.
Once an SoC becomes an assembly of dies, the trust boundary expands into packaging, substrate routing, die-to-die fabrics, and supplier logistics. In other words, the platform is no longer secured by the fact that everything lives on the same die. Trust must become explicit, composable, and verifiable across the whole supply chain.
Chiplets increase the number of places where an attacker can interact with the system.
Substitution and counterfeit risks become more prevalent. If a chiplet is sourced externally, transported through distribution channels, or integrated by a third party, it can be swapped with a malicious or counterfeit die anywhere in the supply chain. A chiplet with the correct interface can behave “normally” while quietly weakening security assumptions, leaking secrets, or disabling integrity protections.
Die-to-die interconnect is another potential attack surface. High-speed fabrics carry traffic that used to be internal to the SoC but now traverses package wiring. Without protection, sensitive data can be observed or manipulated. Even when physical tapping is difficult, the interconnect becomes a target for fault injection, replay, or protocol-level exploitation, especially when link setup and identity binding are weak.
Finally, this trend introduces the “weak chiplet” problem: Not every die is built to the same security posture. I/O chiplets, analog chiplets, or partner-provided accelerators may have weaker debug controls, weaker key management, or less hardened firmware. Attackers do not need to compromise the entire platform; they only need a foothold, and chiplets create more footholds than monolithic SoCs.
A secure chiplet platform requires a tradeoff between two competing needs: the system needs a single authority to define what is trusted and what is allowed; yet security enforcement must be distributed, because each chiplet is a potential entry point for a malicious actor.
This naturally leads to a hierarchical design pattern: one component anchors the system, while all chiplets participate in trust enforcement. This becomes the only scalable way to secure a modular platform without turning every chiplet into a fully independent security island, increasing cost and complexity.
This blog therefore assumes a reference model that includes a Main Security Chiplet that serves as the platform’s trust anchor and orchestration authority. All other chiplets become security-aware endpoints, each capable of local identity, secure storage, cryptographic services, and secure link establishment, sufficient to avoid becoming the weak link, without forcing every chiplet to carry the complexity of a comprehensive security control plane.
From a practical standpoint, chiplet security must satisfy four system goals:
The critical insight is that these goals cannot be achieved with point solutions. If the main chiplet alone is secure, attackers will go after a weaker one. If the link alone is encrypted, attackers may substitute a malicious chiplet with an insecure session establishment. If each chiplet defines its own policy, the platform becomes inconsistent and difficult to certify or operate at scale.
The system needs one component that defines and enforces trust as a platform.
An ideal chiplet security architecture needs three things to be true simultaneously.
First, every chiplet must have a cryptographic identity that is bound to each die (or to a verifiable manufacturing process) and can be validated by the platform. Second, that identity must be connected to a trust chain so the platform can decide which vendors, models, versions, and lifecycle states are acceptable. Third, the platform must use identity to establish policy-controlled security sessions for boot, communication, and lifecycle operations.
A multi-step approach to establish platform trust:
In a future blog, we will focus on addressing several other challenges in chiplet security: provisioning at scale, boot authentication across multiple dies, and a trust-chain infrastructure that works in multi-vendor ecosystems.
Rambus Root of Trust Solutions
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply