PCI Express Security and TEE Integration, Part 2 - Protecting PCIe Traffic

By Rajesh Pamujula

November 3, 2026

Protecting PCIe Traffic: Understanding Link IDE and Selective IDE

Part 1 of this series examined how Data Object Exchange (DOE), Security Protocol and Data Model (SPDM), and Component Measurement and Authentication (CMA) establish the control-plane trust required to authenticate PCI Express® (PCIe) devices and validate their security state. Once that trust has been established, the next requirement is to protect data in motion. This blog examines how Integrity and Data Encryption (IDE) secures PCIe traffic, including the roles of link IDE and selective IDE in direct-attached and switched topologies.

IDE: Protecting PCIe Traffic

Once trust has been established between the communicating IDE terminals, the next requirement is to protect the data in motion. This is the role of IDE.

PCI-SIG defines IDE as a mechanism that provides confidentiality, integrity protection, and replay protection for PCIe transaction layer packets (TLPs). The IDE security model specifically addresses attacks involving physical probes, malicious interposers, compromised switches, extension devices, and traffic manipulation.

IDE introduces a cryptographic processing layer between the PCIe transaction layer and the data link layer. The technology uses Advanced Encryption Standard Galois Counter Mode (AES-GCM), which provides both encryption and authentication of PCIe traffic. PCI-SIG® standardized the use of 256-bit AES-GCM keys for IDE.

Example: Why IDE Matters

Imagine an AI server connected to an external accelerator through a PCIe switch.

Without IDE:

• Model weights travel in plaintext
• Intermediate AI results can be observed
• A malicious interposer could alter transactions
• Packets could potentially be replayed or reordered

With IDE enabled:

• Traffic is encrypted
• Tampering is detected
• Replay attacks are prevented
• The communication channel remains protected even if an attacker gains physical access to the interconnect

Understanding IDE Streams

IDE organizes protected traffic into streams. A stream represents a cryptographically protected communication channel. Each stream contains three substreams:

• Posted requests
• Non-posted requests
• Completions

PCIe uses different ordering rules for these transaction classes, so PCI-SIG created separate cryptographic substreams to preserve protocol ordering while maintaining strong security guarantees. Each sub-stream maintains an independent cryptographic state.

Link IDE vs. Selective IDE

The IDE architecture supports two complementary protection models: link IDE and selective IDE. While both use the same cryptographic foundation and provide confidentiality, integrity protection, and replay protection, they operate at different points in the PCIe hierarchy and address different security requirements.

Link IDE

Link IDE provides protection between two directly connected PCIe ports. The cryptographic relationship exists only across a single PCIe link, and protection terminates at the adjacent port.

Each side of the link contains an IDE engine that encrypts outbound TLPs and validates inbound traffic. The protected traffic is decrypted when it reaches the opposite port. If the packet subsequently traverses another PCIe link, a different IDE relationship must be established for that next hop.

From an implementation perspective, link IDE behaves similarly to other link-level protection schemes used in networking. The security boundary is the physical link itself rather than the complete end-to-end transaction path.

This model is particularly attractive when:

• The device is directly attached to the host
• Traffic does not need to traverse switches
• All traffic on the link requires the same security policy
• Hardware simplicity and minimum management overhead are priorities

For example, a directly attached SSD or SmartNIC may use link IDE to ensure that data cannot be observed or modified through a malicious probe attached to the PCIe connection.

Why Link Protection Is Not Sufficient

As PCIe fabrics become larger and more disaggregated, the trust boundary often extends beyond a single link.

Consider a rack-scale AI server, connecting a CPU ⟺ Switch ⟺ GPU. If link IDE protects only the CPU-to-switch link: CPU ⟸ Encrypted traffic ⟹ Switch ⟺ GPU, traffic is protected while crossing the first link. However, it must be decrypted inside the switch before being forwarded to the GPU. In this case, the switch becomes part of the trusted boundary.

For many traditional deployments, this may be acceptable. However, confidential computing environments increasingly require security that extends through the switch fabric itself. PCI-SIG specifically calls out the need to address threats involving compromised or malicious switches and manipulation of switch routing mechanisms. This requirement led to the introduction of selective IDE.

Selective IDE

Selective IDE protects specific PCIe traffic flows associated with an IDE stream. Unlike Link IDE, which secures an entire PCIe link, selective IDE can protect selected traffic between directly connected ports or across one or more intervening switches.

If Root Complex⟺ Switch⟺ GPU are covered by selective IDE, the cryptographic relationship exists between the Root Complex and the GPU endpoint even though the traffic traverses a switch. PCI-SIG describes selective IDE as traffic that can pass through switches while maintaining cryptographic protection between the terminal ports.

This distinction becomes increasingly important where resources may exist several PCIe hops away from the host processor, such as in:

• AI clusters
• Composable infrastructure
• PCIe-attached accelerator pools
• Disaggregated memory systems
• Confidential computing deployments

IDE Streams and Traffic Selection

Unlike Link IDE, which generally protects all applicable traffic crossing a link, selective IDE operates on explicitly defined criteria to select the traffic that needs to be protected. An IDE stream can be viewed as a cryptographically protected communication context.

Traffic is associated with a particular stream using stream-identification information carried within the IDE architecture. The receiving endpoint uses the stream identifier and associated cryptographic information to validate and decrypt the transaction. This allows multiple security policies to coexist on the same PCIe fabric.

This flexibility is one of the primary reasons selective IDE is so important for cloud and multi-tenant infrastructure.

Streams, Substreams, and Ordering

PCIe uses different ordering rules for each flow class. Rather than applying a single encryption context to all traffic, IDE maintains separate cryptographic state for each substream. PCI-SIG notes that each substream maintains its own key and invocation counter. TLPs within a substream are processed in order, preserving PCIe's transaction semantics while supporting AES-GCM encryption.

This design is particularly important for selective IDE because traffic may traverse switched topologies where ordering behavior becomes more complex.

Figure 2: Link IDE vs selective IDE (image generated by Microsoft Copilot)

Link IDE and Selective IDE in Confidential Computing

A useful way to think about the two mechanisms is:

In practice, modern confidential computing deployments increasingly rely on selective IDE because trusted device assignment often involves accelerators, SmartNICs, or storage devices located behind switches. Link IDE remains valuable for directly attached devices and simpler system topologies. Together, the two modes provide PCIe architects with the flexibility to align security boundaries with system-level trust requirements.

PCIe 6.x Security Enhancements

PCIe 6.0 introduced FLIT Mode.

A flow control unit (FLIT) is a fixed 256-byte packet format that supports PAM4 signaling and FEC. Unlike previous generations, PCIe 6.x transports traffic using fixed-size FLITs rather than variable-sized packets.

To support emerging security requirements, PCI-SIG has continued enhancing IDE. One important enhancement is partial header encryption (PHE). PHE allows portions of PCIe transaction headers to be encrypted while leaving sufficient information exposed to support routing and protocol operation. This improves confidentiality without breaking interoperability. PCI-SIG identifies PHE and enhanced downstream-link security as key additions to newer IDE implementations.

From Protected Traffic to Trusted Device Assignment

IDE protects PCIe traffic against observation, tampering, and replay, whether across a directly connected link or an end-to-end path through a switched fabric. However, protecting the communication channel does not determine whether a device can be trusted by a confidential workload.

Part 3 of this series will examine how the TEE Device Interface Security Protocol (TDISP) builds on DOE, SPDM, CMA, and IDE to enable trusted device assignment and extend the chain of trust into PCIe-attached devices.

Learn more about Cadence’s controller and PHY IP for PCIe on the PCIe and CXL landing page.

Explore Cadence IP:

• PHY for PCIe 6.0 and CXL