From Monolithic SoCs to Chiplets: A New Hardware Security Paradigm

Chiplet-based architectures are quickly becoming a promising approach for building scalable, heterogeneous multi-die chips that effectively compete as a high-performance alternative to traditional, monolithic 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’s “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.

In this first of a two-part Tech Talk, we’ll explain why chiplet security must be addressed at a system-level, propose a practical security model for chiplet-based platforms, and introduce a reference architecture where trust is anchored in a Main Security Chiplet such as one built with a security-processor core from the Rambus RT-6xx Root-of-Trust family, while extending cryptographic enforcement across the remaining chiplet fleet using lighter-weight security-processor cores from the Rambus RT-1xx Root-of-Trust family.

Chiplets change the security boundary

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, should 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 a monolithic SoC is disaggregated into a heterogeneous 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 attack surface

Chiplets increase the number of places where an attacker can interact with the system. For example, 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 remanufactured or even malicious 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 more easily 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.

The new security paradigm: distributed trust with centralized authority

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 is the most scalable path to secure a modular platform without turning every chiplet into a fully independent security island increasing cost and complexity.

This paper 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:

1. Authenticity: every chiplet must be able to cryptographically prove it is genuine, with the ability to re-authenticate on demand, after reset or power loss, or re-entry into the system.

2. Boot integrity: every chiplet must be able to cryptographically verify its firmware and configuration, with rollback resistance.

3. Protected communication: every chiplet must be able to protect die-to-die links, including confidentiality, integrity, and replay protection.

4. Lifecycle security: every chiplet must be able to support secure provisioning, lifecycle, debug, field updates, revocation, and decommissioning.

Importantly, though individual chiplets might achieve these specific goals in isolation, a larger solution is still necessary to ensure these goals are met for the whole multi-die chip platform. 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.

A framework to establish chiplet trust

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:

1. Provision identities and trust anchors (at manufacturing and at onboarding)
2. Authenticate chiplets (at assembly and at boot)
3. Establish secure channels (die-to-die and management paths)
4. Boot and measure (per-chiplet secure boot with attestation)
5. Enforce lifecycle policy (debug, update, revoke, RMA)

Provisioning subordinate chiplets

In a monolithic SoC, device identity is often anchored in a single root of trust that owns key material and policy. In a chiplet platform, every security-relevant chiplet must have an identity, and the system must be able to validate it consistently.

Two provisioning patterns are common, and a robust platform often supports both depending on the chiplet class and supplier model.

Provisioning pattern A: externally provisioned identity (certificate-based)

In this approach, each subordinate chiplet is provisioned with device-unique key material (or a keypair) in a controlled manufacturing environment, then issued a certificate that chains to a vendor root.

What matters is not only the mechanics of injection but the resulting property: the chiplet can present an identity credential that the platform can validate through a chain of trust. This enables multi-vendor operation, because the Main Security Chiplet can be configured with one or more vendor trust anchors (public keys, roots, or intermediates) and evaluate chiplet credentials against platform policy (allowed vendors, product IDs, security versions, lifecycle state, revocation status, etc.).

This pattern is operationally attractive when suppliers already operate a Public Key Infrastructure (PKI)-backed provisioning service or when the platform requires strong traceability and explicit certificate lifecycle management.

Provisioning pattern B: silicon-derived identity (PUF-based or self-generated key derivation)

In this approach, the chiplet self-generates root key material from sensing its own silicon characteristics (for example, using a PUF-based mechanism) and then derives operational keys from that root. With sufficient cryptographic capability, the chiplet can further generate associated public key and request certification (or platform enrollment) without ever exporting the underlying root secret.

The platform still needs a trust chain: either the chiplet vendor provides a certification flow for the derived identity, or the platform performs a “local enrollment” where the Main Security Chiplet validates the chiplet via an authenticated onboarding step and binds that identity into its platform trust database. This approach reduces reliance on key injection logistics and can simplify supply-chain handling for certain chiplet classes, while still yielding a platform-usable identity.

The real requirement: identity must be policy-bound

Regardless of the provisioning approach, the platform must ensure that “has an identity” is not the same as “is trusted”. Trust is a policy decision made by the platform authority. The system must be able to verify not only that the chiplet is genuine but also acceptable (correct vendor, model, not revoked, debug state allowed, most recent security version, etc.). That is why chiplet identity must connect to a platform-controlled trust chain and revocation mechanism.

Boot authentication across the chiplet system

Chiplets turn boot integrity into a distributed problem. If one chiplet runs untrusted firmware, it can become a covert channel, a DMA attacker, or a protocol manipulator, even if the rest of the platform boots securely.

A scalable model  requires orchestrated secure boot:

1. The Main Security Chiplet establishes the platform boot policy. This includes what chiplets must be present, acceptable identity roots, allowed firmware images/versions, rollback constraints, and debug state constraints.

2. Each subordinate chiplet performs local secure boot anchored in its own Root of Trust. The subordinate chiplet must be able to verify its boot images, enforce anti-rollback, and lock down debug according to policy. The key point is that verification happens locally, because the subordinate chiplet must not depend on an unauthenticated external environment to become secure.

3. The platform collects evidence and makes a system decision. Each chiplet produces boot measurements and attestation evidence. The Main Security Chiplet evaluates this evidence against platform policy and either allows the platform to proceed, degrades capabilities, or blocks operation.

This is the difference between a secure chiplet and a secure chiplet platform. The multi-die chip (i.e., the system of chiplets) must be able to produce a coherent statement of integrity that represents the whole chiplet set, not just the main die.

Trust-chain infrastructure: enabling multi-vendor platforms

A chiplet ecosystem requires a trust model that works when different dies originate from different suppliers. That implies a pragmatic trust-chain infrastructure:

• Multiple trust anchors: the platform may accept chiplets from multiple approved vendors, each with their own PKI root/intermediates.
• Policy mapping: certificates and identity claims must map into platform policy (allowed SKUs, required security versions, lifecycle state, debug constraints, etc.).
• Revocation and update: the platform must support revocation (e.g., known-bad batches, compromised keys) and secure policy updates across product lifetime.
• Auditability: especially in regulated markets, the platform needs evidence that the trust decision is consistent and enforceable.

Securing die-to-die communication: identity-bound secure sessions

Protecting the interconnect is not just about encryption but it is about binding communication sessions to authenticated chiplet identities and enforcing platform policy on which chiplets are authorized to communicate with each other.

A robust model requires:

• Mutual authentication between endpoints using chiplet identities validated against platform policy
• Session establishment using fresh ephemeral keys, with replay protection
• Confidentiality and integrity for data-in-motion across the package fabric
• Granular authorization (which chiplets may talk, which services may be invoked, under what lifecycle state)

In other words: secure links should be the consequence of trust decisions, not a substitute for them.

Lifecycle security: provisioning, debug, updates, and revocation

Chiplet systems increase operational complexity: multiple dies, potentially multiple firmware domains, and multiple vendors. The platform requires centralized lifecycle governance or it could quickly drift into inconsistent states that are difficult to secure and impossible to reason about.

Key lifecycle controls include:

• Secure onboarding: controlled acceptance of chiplets and enrollment into the platform trust database
• Debug policy enforcement: debug must be explicitly governed
• Secure update: updates must be authenticated and rollback-resistant per chiplet, yet coordinated at the platform level
• Revocation: the platform must be able to reject known-bad chiplets or identities, even after deployment
• RMA/decommissioning: controlled teardown so field-handling does not leak secrets or weaken fleet integrity

These controls are not optional in markets like cloud infrastructure, automotive, and high-value AI accelerators, where the lifecycle is long and the incentive to attack is high.