At Rambus, we create cutting-edge semiconductor and IP products, providing industry-leading chips and silicon IP to make data faster and safer.
[Live Webinar] Enabling Next‑Generation Client Memory with Rambus DDR5 CUDIMM/CSODIMM and LPCAMM2 Chipsets
As client platforms push toward higher performance, greater efficiency, and AI‑ready computing to address the latest developments in gaming, content creation and other advanced applications, memory subsystem design has become a critical differentiator. Next-generation DDR5 and LPDDR‑based memory modules demand state-of-the-art approaches to power management, clocking, and system reliability, especially as data rates scale to […]
As client platforms push toward higher performance, greater efficiency, and AI‑ready computing to address the latest developments in gaming, content creation and other advanced applications, memory subsystem design has become a critical differentiator. Next-generation DDR5 and LPDDR‑based memory modules demand state-of-the-art approaches to power management, clocking, and system reliability, especially as data rates scale to 7200 MT/s and beyond. In this webinar, Rambus experts will explore how complete client memory interface chipsets enable high‑performance DDR5 CUDIMM and CSODIMM modules operating up to 7200 MT/s, with capabilities for overclocking. Also covered will be chipsets for the latest LPCAMM2 modules designed for thin, power‑efficient client systems. Attendees will gain insight into the architectural challenges of high‑speed client memory, including signal integrity, power delivery, sideband management, and thermal considerations, and how Rambus chipset solutions address these challenges at the module level.
[Live Webinar] Reliability and Supply Chain Security for the Automotive Semiconductor Industry
As vehicles become increasingly software‑defined and electronics‑driven, the cost of semiconductor failure, whether due to reliability issues or security breaches, has never been higher. Automotive recalls tied to electronic failures continue to rise, exposing a critical gap between existing standards compliance and real‑world field performance. While ISO 26262 and AEC‑Q100 provide an essential foundation for […]
As vehicles become increasingly software‑defined and electronics‑driven, the cost of semiconductor failure, whether due to reliability issues or security breaches, has never been higher. Automotive recalls tied to electronic failures continue to rise, exposing a critical gap between existing standards compliance and real‑world field performance. While ISO 26262 and AEC‑Q100 provide an essential foundation for functional safety and reliability, they are no longer sufficient on their own to eliminate failures across the full chip lifecycle. At the same time, semiconductor security must extend beyond protecting devices from hackers to securing the entire supply chain, from fabrication to deployment in the field. This webinar examines why reliability and security have become inseparable drivers for next‑generation automotive chips, and how a lifecycle‑based approach is required to meaningfully reduce recall risk. We will review real‑world examples of recalls caused by electronic failures, explore the evolving standards landscape driving higher expectations for reliability and traceability, and walk through the end‑to‑end chip lifecycle from wafer fabrication to in‑vehicle operation.
Reliability and Supply Chain Security for the Automotive Semiconductor Industry
This webinar examines why reliability and security have become inseparable drivers for next‑generation automotive chips, and how a lifecycle‑based approach is required to meaningfully reduce recall risk. We will review real‑world examples of recalls caused by electronic failures, explore the evolving standards landscape driving higher expectations for reliability and traceability, and walk through the end‑to‑end chip lifecycle from wafer fabrication to in‑vehicle operation.
[Live on May 21 at 11am PT] This webinar examines why reliability and security have become inseparable drivers for next‑generation automotive chips, and how a lifecycle‑based approach is required to meaningfully reduce recall risk. We will review real‑world examples of recalls caused by electronic failures, explore the evolving standards landscape driving higher expectations for reliability and traceability, and walk through the end‑to‑end chip lifecycle from wafer fabrication to in‑vehicle operation.
Enabling Next‑Generation Client Memory with Rambus DDR5 CUDIMM/CSODIMM and LPCAMM2 Chipsets
n this webinar, Rambus experts will explore how complete client memory interface chipsets enable high‑performance DDR5 CUDIMM and CSODIMM modules operating up to 7200 MT/s, with capabilities for overclocking. Also covered will be chipsets for the latest LPCAMM2 modules designed for thin, power‑efficient client systems. Attendees will gain insight into the architectural challenges of high‑speed client memory, including signal integrity, power delivery, sideband management, and thermal considerations, and how Rambus chipset solutions address these challenges at the module level.
[Live on Apr 29 at 9am UTC +8) In this webinar, Rambus experts will explore how complete client memory interface chipsets enable high‑performance DDR5 CUDIMM and CSODIMM modules operating up to 7200 MT/s, with capabilities for overclocking.
MACsec Explained: Everything You Need to Know
[Last updated on April 8, 2026] MACsec (Media Access Control Security) is an Ethernet security standard that encrypts and authenticates data in motion at Layer 2 of the OSI model, protecting traffic as it moves between directly connected devices. To achieve end‑to‑end security, data must be secured throughout its entire lifecycle: when it is stored, […]
[Last updated on April 8, 2026] MACsec (Media Access Control Security) is an Ethernet security standard that encrypts and authenticates data in motion at Layer 2 of the OSI model, protecting traffic as it moves between directly connected devices. To achieve end‑to‑end security, data must be secured throughout its entire lifecycle: when it is stored, when it is actively processed, and when it is transmitted between devices. Hardware root of trust anchored in silicon provides foundation for securing data at rest, while inline memory encryption protects data in use. For data in motion, however, security must be enforced at the point where information first leaves the device, before it traverses a network that may not be fully trusted. This is where MACsec plays a critical role. By anchoring security in hardware at the Ethernet layer, MACsec ensures that all network traffic is encrypted and authenticated the moment it goes on the wire. This approach protects against eavesdropping, tampering, and impersonation without relying on higher‑layer software or application changes. In this blog, we’ll explore what MACsec is, how it works, how it compares to higher-layer security approaches, and why it is essential for modern Ethernet-based systems. Table of Contents: What is the OSI Model and How Does it Relate to Network Security? What Is MACsec and Why Does It Matter? How Does MACsec Work at the Ethernet Layer? How Does MACsec Authentication and Key Management Work? MACsec vs. IPsec and TLS: What’s the Difference? What Are the Performance, Latency, and Power Considerations for MACsec? Where is MACsec Used Today? Rambus MACsec IP Solutions Summary: Why MACsec Matters for Modern Ethernet Security Frequently Asked Questions about MACsec What is the OSI Model and How Does it Relate to Network Security? The OSI model explains how MACsec, IPsec, and TLS secure data at different layers of the network communication. <img fetchpriority="high" decoding="async" class="size-full wp-image-66288" src="https://www.rambus.com/wp-content/uploads/2026/04/case-for-layer-2-security.png" alt="Graphic explaining why we should secure at Layer 2" width="1000" height="487" srcset="https://www.rambus.com/wp-content/uploads/2026/04/case-for-layer-2-security.png 1000w, https://www.rambus.com/wp-content/uploads/2026/04/case-for-layer-2-security-300x146.png 300w, https://www.rambus.com/wp-content/uploads/2026/04/case-for-layer-2-security-150x73.png 150w, https://www.rambus.com/wp-content/uploads/2026/04/case-for-layer-2-security-768x374.png 768w" sizes="(max-width: 1000px) 100vw, 1000px" /> The Case for Layer 2 Security The OSI model is a seven‑layer framework for network communications, with each layer describing how data moves through a network. Each layer can also introduce its own form of security. In this section, we focus on three of those layers and the technologies commonly used to protect data in motion at each one: MACsec, IPsec, and TLS. How MACsec, IPsec and TLS Map to the OSI Model At Layer 2 of the OSI model, MACsec protects data as it travels between devices on the same local network, such as switch‑to‑switch, switch‑to‑host, or host‑to‑host connections. A simple way to think about MACsec is that it protects the cable itself. If someone gains access to the physical network, MACsec ensures the data on the wire is encrypted and cannot be read or altered. Because Layer 2 is the last point where data exists in clear form before leaving a device, securing traffic here stops attacks like sniffing, spoofing, and unauthorized monitoring early, without relying on higher‑level software behaving correctly. Layer 2 security provides a strong foundation for network protection. Internet Protocol Security (IPsec) operates at Layer 3, the network layer. Rather than securing a single physical link, IPsec protects data as it moves between networks, including traffic that traverses the public internet. This makes IPsec well suited for use cases such as site‑to‑site and remote access VPNs, where data must be protected across longer distances and multiple network hops. Transport Layer Security (TLS) sits near the top of the stack, typically at Layer 4 and above, and focuses on securing individual application communications. A familiar example is the “https” prefix in a web browser. TLS encrypts specific conversations, such as a browser accessing a website or an application calling an API, ensuring the data remains confidential, the server is authenticated, and the communication cannot be tampered with. Together, these technologies demonstrate how security can be applied at different layers of the network stack, with MACsec protecting the link, IPsec protecting network paths, and TLS protecting application‑level communication. What Is MACsec and Why Does It Matter? Defined by the IEEE 802.1AE standard, MACsec provides encryption and authentication for Ethernet traffic at the data link layer of the OSI model. Its purpose is to protect data as it travels across local and metropolitan area networks by ensuring that Ethernet frames can only be read and modified by authorized devices. Under IEEE 802.1AE, Ethernet frames are encrypted and integrity-checked before they are transmitted over a physical link, which prevents eavesdropping, data tampering, and replay attacks. Because this protection happens at the MAC layer, it is independent of higher-layer protocols such as IP, TCP, or application-level encryption, and it works transparently without requiring changes to applications or network configurations. This makes MACsec especially valuable for environments where physical access to network links cannot be fully trusted, such as shared data centers, campus networks, and inter-rack connections. In short, MACsec is a Layer 2 security standard that encrypts and authenticates Ethernet frames, ensuring that only trusted devices can access data in transit on local and metropolitan networks. How Does MACsec Work at the Ethernet Layer? MACsec works by securing Ethernet frames themselves, before they ever become IP packets or application data. To understand how it operates, it helps to think about what normally happens at the Ethernet layer and how MACsec modifies that process. Under normal Ethernet operation, a device (like a server or switch) builds an Ethernet frame containing a destination MAC address, a source MAC address, payload data, and a frame check sequence. That frame is then put directly onto the wire, where any device with access to the physical network could potentially observe or copy it. With MACsec, an additional security step is inserted inside the Ethernet layer, between frame creation and transmission on the physical link. Before the frame is sent, MACsec treats it as protected data that must be authenticated and optionally encrypted. When two MACsec-capable devices are connected, they first establish trust. This is usually done using IEEE 802.1X for authentication and key agreement, although pre-shared keys can also be used. During this process, the devices agree on cryptographic keys known as Secure Association Keys (SAKs). These keys are unique to the link and can be rotated periodically to limit exposure. Once keys are established, each Ethernet frame is processed by the MACsec engine. The original Ethernet payload is encrypted using symmetric cryptography (typically AES). MACsec also calculates an integrity check value for the frame, ensuring that the data cannot be altered in transit without detection. A small MACsec header and security tag are added to the frame to indicate that it is protected and to carry information such as packet numbers used to prevent replay attacks. Importantly, MACsec does not encrypt everything in the Ethernet frame. The source and destination MAC addresses remain visible so switches can still forward traffic correctly. What is protected is the Ethernet payload, along with integrity and authenticity information. From the perspective of higher layers like IP, TCP, and applications, nothing changes; they see the same data as if MACsec were not present. When the encrypted frame reaches the receiving device, the MACsec engine verifies the integrity check and packet number to confirm the frame has not been tampered with or replayed. If the frame passes validation, it is decrypted and handed up to the normal Ethernet processing path. If validation fails, the frame is silently dropped. All of this happens at line rate, often using dedicated hardware in network interface cards, switches, or routers. Because the work is done at Layer 2, latency is extremely low, and applications do not need to be modified or even be aware that encryption is occurring. Conceptually, MACsec turns each Ethernet link into a private, secure tunnel. Instead of assuming the local network is trusted, it assumes the wire itself could be hostile and protects traffic the moment it leaves a device. This makes MACsec especially valuable for securing data center links, campus networks, and any environment where physical or internal network access cannot be fully trusted. By encrypting Ethernet payloads at line rate before they leave the device, MACsec turns each physical or logical link into a secure, trusted communication channel. How Does MACsec Authentication and Key Management Work? MACsec itself is responsible for encrypting and authenticating Ethernet frames, but it does not decide who is allowed to communicate or which keys should be used. That responsibility is handled by IEEE 802.1X and a companion protocol called MACsec Key Agreement, commonly referred to as MKA. The process begins with IEEE 802.1X authentication, which answers a fundamental question at the Ethernet layer: is this device trusted enough to participate in secure communication? When two devices are connected by an Ethernet link, such as a switch and a server, each device must prove its identity before any protected traffic is allowed to flow. IEEE 802.1X uses a familiar identity model with three roles: the supplicant, which is the device requesting access; the authenticator, which controls the port and enforces access; and an authentication server, typically a RADIUS server. Using Extensible Authentication Protocol, or EAP, the supplicant and authentication server exchange credentials such as certificates or usernames and passwords. If authentication succeeds, the link is considered authorized. <img decoding="async" class="alignnone size-full wp-image-66287" src="https://www.rambus.com/wp-content/uploads/2020/12/IEEE-802.1X-Key-Management.png" alt="IEEE 802.1X Key Management" width="787" height="479" srcset="https://www.rambus.com/wp-content/uploads/2020/12/IEEE-802.1X-Key-Management.png 787w, https://www.rambus.com/wp-content/uploads/2020/12/IEEE-802.1X-Key-Management-300x183.png 300w, https://www.rambus.com/wp-content/uploads/2020/12/IEEE-802.1X-Key-Management-150x91.png 150w, https://www.rambus.com/wp-content/uploads/2020/12/IEEE-802.1X-Key-Management-768x467.png 768w" sizes="(max-width: 787px) 100vw, 787px" /> Once authentication is complete, IEEE 802.1X does more than simply open the port. It also establishes a shared secret known as a Master Session Key. This key is cryptographically strong and unique to the authenticated session. At this point, the devices trust each other, but they still do not have the specific encryption keys required for MACsec traffic protection. This is where MACsec Key Agreement (MKA) comes into play. MKA is defined as part of IEEE 802.1AE and runs directly at the Ethernet layer between authenticated peers. Using the Master Session Key as its foundation, MKA derives one or more Secure Association Keys, or SAKs. These SAKs are the actual keys used by MACsec to encrypt and authenticate Ethernet frames. MKA serves several important purposes beyond simple key derivation. It securely distributes SAKs to all participants on a protected link or, in the case of point‑to‑multipoint scenarios, to multiple authorized devices. It also assigns each device a role, such as key server or participant, to coordinate key generation and updates. MKA includes mechanisms for key rotation, allowing SAKs to be periodically replaced without interrupting traffic. This limits the amount of data protected by any single key and reduces the impact of potential compromise. As encrypted traffic begins to flow, each MACsec‑protected frame includes a packet number that is checked by the receiver. MKA ensures both sides agree on packet number handling and anti‑replay rules. If a frame arrives with an unexpected or reused packet number, it is rejected. This prevents attackers from capturing and replaying old Ethernet frames. Importantly, MKA continues running in the background for the lifetime of the connection. If a device disconnects, fails authentication checks, or violates policy, MKA signals MACsec to stop accepting traffic from that device. If a new device joins, it must complete its own 802.1X authentication before receiving any MACsec keys. This tight coupling ensures that encryption keys are always tied to authenticated identities, not just physical access to a cable or switch port. From an operational perspective, the combination of IEEE 802.1X and MKA allows MACsec to behave like a zero‑trust system at Layer 2. Every device must authenticate, keys are unique to each link or group, keys are refreshed automatically, and encrypted communication starts immediately at the edge of the network. All of this happens transparently to IP, TCP, and applications, which remain unaware that encryption and identity enforcement are taking place underneath. IEEE 802.1X and MACsec Key Agreement work together to authenticate devices, derive encryption keys, and continuously manage trust for secure Ethernet communication. MACsec vs. IPsec and TLS: What’s the Difference? MACsec, IPsec, and TLS are all technologies used to protect data in motion, but they operate at different layers of the network stack and address different security needs. Rather than competing with one another, they are complementary and are often deployed together as part of a layered security strategy. The simplest way to distinguish them is by where encryption is applied. MACsec operates at Layer 2, securing Ethernet frames as they move across a physical or logical link. IPsec operates at Layer 3, protecting IP packets as they travel between hosts or networks, including across the public internet. TLS operates at the application level, typically above Layer 4, securing individual sessions such as web traffic, APIs, and application‑to‑application communications. Because of where each technology sits in the stack, each one protects a different portion of the data path. MACsec encrypts the Ethernet payload on a hop‑by‑hop basis while leaving MAC addresses visible so switching can function normally. IPsec encrypts IP packets end to end or between security gateways, depending on deployment mode. TLS encrypts only the application data itself, leaving lower‑layer headers exposed to the network. These differences also shape how trust is established. MACsec relies on IEEE 802.1X authentication and MACsec Key Agreement to ensure only authorized devices receive encryption keys at the network edge. IPsec uses Internet Key Exchange with certificates or pre‑shared keys to establish trust between endpoints or gateways. TLS depends on public key infrastructure to authenticate servers and sometimes clients directly at the application layer. From a performance standpoint, MACsec is optimized for line‑rate, low‑latency operation, often using dedicated hardware in NICs and switches, and is largely invisible to applications. IPsec introduces more overhead due to encapsulation and policy processing, though it may also be hardware accelerated. TLS adds encryption and handshake overhead at the application layer but benefits from widespread CPU optimizations and broad software support. In practice, each technology is best suited to a specific role. MACsec is ideal for securing internal or local Ethernet links without modifying applications. IPsec is commonly used to protect traffic between sites or across untrusted networks, such as VPN connections. TLS is the dominant choice for securing application‑level communication, especially over the public internet. MACsec vs. IPsec vs TLS at a Glance Aspect MACsec IPsec TLS Primary purpose Secure Ethernet links Secure IP traffic Secure application sessions OSI layer Layer 2 (Data Link) Layer 3 (Network) Layers 4–7 (Application) What is encrypted Ethernet payload IP packets Application data Scope of protection Hop by hop, link local End to end or tunnel based End to end per application Typical authentication IEEE 802.1X, MKA IKE with certificates or PSKs Certificates and PKI Visibility to applications Transparent Transparent Application aware Performance characteristics Line rate, very low latency Moderate overhead Session setup and crypto overhead Common implementations NICs, switches, routers Hosts, gateways, VPN devices Web servers, apps, APIs Best suited for Internal Ethernet security Inter network security Application level security In summary, MACsec protects the link, IPsec protects the route, and TLS protects the application. Used together, they form a layered approach that secures data in motion from the wire to the workload. What Are The Performance, Latency, and Power Considerations for MACsec? MACsec is designed to secure Ethernet traffic with minimal impact on performance, especially when implemented in hardware. Modern switches, routers, and NICs typically include dedicated MACsec engines that perform encryption and integrity checks at line rate using symmetric cryptography. In these deployments, MACsec does not reduce throughput, even at high speeds like 25G, 100G, or higher. Performance degradation is mainly a concern with software‑only implementations, where cryptographic processing competes with other workloads and can limit scalability. From a latency perspective, MACsec adds very little overhead. Because it operates at the Ethernet layer and processes each frame independently, encryption and decryption are done inline as frames enter and exit the interface. In hardware‑accelerated designs, the additional latency is usually measured in tens or hundreds of nanoseconds, far below what applications or even most network monitoring tools can detect. Key rotation events are handled seamlessly by MACsec Key Agreement, allowing keys to change without interrupting traffic or adding noticeable delay. Power consumption depends heavily on where MACsec is implemented. Hardware MACsec slightly increases silicon area and power use, but the incremental cost per port is typically modest and predictable, making it suitable for large‑scale deployments. In contrast, software‑based MACsec is far less energy‑efficient because general‑purpose CPUs are not optimized for sustained cryptographic workloads, resulting in higher power draw per bit of data protected. At scale, this difference becomes significant. Overall, MACsec offers a strong security‑to‑cost trade‑off when hardware acceleration is available. It provides near‑zero performance loss, extremely low and deterministic latency, and manageable power overhead, making it well suited for data centers, enterprise networks, and embedded systems. The primary architectural consideration is ensuring MACsec support across network devices, but from a performance, latency, and power standpoint, hardware‑accelerated MACsec is one of the most efficient ways to encrypt data in motion. When implemented in hardware, MACsec delivers strong security with near‑zero throughput impact, extremely low latency, and predictable power consumption at scale. Where is MACsec Used Today? MACsec is used today anywhere organizations want to protect data in motion at the Ethernet layer, especially in environments where internal networks can no longer be assumed to be trusted. Common MACsec deployment environments include: Data centers and cloud infrastructure Enterprise campus networks Service provider and 5G transport networks Automotive and industrial Ethernet systems In data centers and cloud infrastructure, MACsec is commonly deployed to secure east‑west traffic between servers, switches, and storage systems. Hyperscalers and enterprise data centers use MACsec to encrypt traffic on switch‑to‑switch and switch‑to‑server links without adding noticeable latency or CPU overhead. Because MACsec operates transparently below IP and applications, it allows operators to enforce blanket encryption for all workloads, including legacy protocols that lack native security. In enterprise campus and corporate networks, MACsec is used to secure access links at the network edge. Switch‑to‑endpoint, switch‑to‑access‑point, and inter‑building fiber links are frequent use cases. When combined with IEEE 802.1X authentication, MACsec ensures that only authenticated devices can send or receive traffic and that all Ethernet frames are encrypted once they leave the device. This is especially valuable for protecting traffic across shared wiring, campus backbones, and leased lines. MACsec is also widely adopted in telecommunications and service provider networks. Mobile backhaul, fronthaul, and metro Ethernet links use MACsec to protect traffic between radios, aggregation nodes, and core infrastructure. These environments benefit from MACsec’s low latency and deterministic performance, which are critical for 5G and timing‑sensitive workloads. Finally, MACsec is increasingly found in embedded, automotive, and industrial Ethernet systems. Automotive Ethernet uses MACsec to protect in‑vehicle networks from spoofing and tampering, while industrial control and operational technology environments use it to secure machine‑to‑machine communication without modifying application protocols. In these contexts, hardware‑based MACsec provides strong security while meeting strict real‑time and power constraints. In short, MACsec is widely deployed across data centers, enterprise networks, service provider infrastructure, and embedded systems wherever Ethernet security, performance, and transparency are critical. Solutions and next steps For organizations looking to implement MACsec at scale, hardware-accelerated solutions are essential. Rambus offers a complete family of silicon-proven MACsec silicon IP solutions for applications ranging from automotive/enterprise SOC/PHY to high-performance optical PHY, switch/router and AI interconnect silicon. All Rambus MACsec IP solutions are IEEE 802.1AE-2018 compliant and come with industry-proven Driver Development Kits (DDK). Rambus MACsec IP enables standards‑compliant, hardware‑accelerated Ethernet security for high‑performance, scalable systems across data center, networking, automotive, and AI applications. Summary: Why MACsec Matters for Modern Ethernet Security As Ethernet serves as the backbone of modern computing, securing data in motion is mission critical. MACsec addresses this challenge by delivering line-rate, low-latency, standards-based security directly at the link layer. By encrypting and authenticating every Ethernet frame, MACsec provides strong protection against eavesdropping, tampering, and unauthorized access without impacting performance or requiring changes to applications and protocols. For enterprises, data centers, and service providers building next-generation networks, understanding and deploying MACsec is a critical step toward a secure, scalable, and high-performance Ethernet infrastructure. Frequently Asked Questions About MACsec Is MACsec end‑to‑end encryption? No. MACsec is hop‑by‑hop encryption at Layer 2, meaning each Ethernet link is secured independently. Does MACsec encrypt MAC addresses or Ethernet headers? No. MACsec leaves source and destination MAC addresses visible so that switching and routing can function normally. It encrypts the Ethernet payload and protects it with integrity and replay protection. Can MACsec be used together with IPsec or TLS? Yes. MACsec, IPsec, and TLS are complementary and often used together. MACsec secures the underlying Ethernet link, IPsec protects traffic across networks, and TLS secures application‑level communication. Does MACsec require application or protocol changes? No. MACsec operates transparently at Layer 2, so applications, operating systems, and higher‑layer protocols do not need to be modified. Is MACsec suitable for high‑speed networks? Yes. When implemented in hardware, MACsec supports line‑rate encryption with extremely low latency, even at speeds of 25G, 100G, and higher. What standards are associated with MACsec? MACsec is defined by IEEE 802.1AE, and it is commonly used with IEEE 802.1X and MACsec Key Agreement (MKA) for authentication and key management. Why MACsec? MACsec protects data at the Ethernet layer before it reaches higher‑layer security controls, reducing exposure to internal threats and protecting traffic that may not be covered by application‑level encryption. Need more details? Contact us here and request a meeting with one of our dedicated sales specialists. More on MACsec: – Ask the Experts: MACsec at Terabit Line Rates – Network Security at Terabit-per-second Rates with MACsec, IPsec and UEC – Secure by Design Series: Inline Memory Encryption & MACsec: Protecting Data in Use and in Motion – MACsec Fundamentals
Google, Quantum Attacks, and ECDSA: Why There’s No Need to Panic and Why Preparation Matters Now
Over the past several weeks, we’ve seen growing discussion across the industry about Google’s latest publications on quantum computing and cryptography. In some corners, those discussions have quickly escalated into claims that widely deployed elliptic curve cryptography (ECC), including ECDSA, is on the verge of collapse.
Over the past several weeks, we’ve seen growing discussion across the industry about Google’s latest publications on quantum computing and cryptography. In some corners, those discussions have quickly escalated into claims that widely deployed elliptic curve cryptography (ECC), including ECDSA, is on the verge of collapse. Customers are understandably asking questions: Has ECDSA been broken? Are today’s systems suddenly at risk? Do migration timelines need to change? At Rambus, our view is clear and measured: there is no need to panic, but there is every reason to prepare thoughtfully and deliberately for the post‑quantum transition already underway. What Google Has Actually Published To put recent claims into context, it’s important to separate what has been said from what has been inferred. In November 2025, Google published an academic paper outlining its perspective on the state and trajectory of quantum computing. This work reinforced a view shared by many in the research community: progress is steady and meaningful, but not sudden or magical. More recently, in March 2026, Google made two notable public moves. First, it announced plans to migrate its cryptographic infrastructure to post‑quantum cryptography (PQC) by 2029, one of the most aggressive migration timelines publicly stated by a major technology provider. Shortly thereafter, Google and academic collaborators published a white paper analyzing the impact of quantum attacks on cryptocurrencies, including an improved theoretical attack against ECDSA. That white paper, in particular, has drawn significant attention well beyond the cryptocurrency ecosystem. Has ECDSA Been “Broken”? No. Despite some dramatic headlines, ECDSA has not been broken. The improved attack described in the paper is still estimated to require hundreds of thousands of physical qubits. Today’s quantum systems are typically well below 10,000 physical qubits, and scaling reliably to that level remains a substantial technical challenge. In practical terms, there is still a wide gap between theoretical cryptanalysis and a cryptographically relevant quantum computer capable of threatening 256‑bit ECC in the real world. How Credible Is the Claimed Attack Improvement? The honest answer is that it deserves attention, but also scrutiny. Many technical details have been withheld for responsible disclosure reasons, which limits independent evaluation. At the same time, the authors include highly respected researchers, and Google has deep expertise across quantum algorithms, hardware, and systems engineering. History provides useful caution here. Previous claims of improved quantum attacks have sometimes failed under close review, often because they underestimated the cost of classical computation moved outside the quantum portion of the attack. Proper validation typically requires interdisciplinary teams spanning quantum theory, hardware constraints, and classical cryptanalysis. From our perspective, it would be unwise to dismiss the work outright. When an organization with Google’s depth of quantum expertise commits publicly to an accelerated PQC migration timeline, the signal is worth taking seriously, even as the details continue to be reviewed by the broader community. Putting Google’s Migration Timeline in Context A 2029 target is aggressive, but not wildly out of step with other guidance. For example, CNSA 2.0 mandates migration completion around 2030 or 2033 depending on application class. Several European national security organizations operate with timelines in the 2030–2035 range. While the difference between 2029 and 2030 may seem small, the pace implied by Google’s announcement is notable. It’s also important to remember that national security organizations continuously reassess timelines as new research emerges. Migration plans typically include buffer to absorb unexpected breakthroughs. Whether Google’s claimed improvements exceed those buffers remains to be seen—but this is precisely the kind of development such buffers are designed for. What PQC Migration Timelines Really Mean One common misunderstanding is that a migration deadline reflects when a quantum break is expected to occur. In reality, migration must be completed years before any such break is anticipated. The required lead time depends on how long protected data must remain secure: TLS key exchange has a long vulnerability window due to “store‑now, decrypt‑later” attacks. TLS handshake signatures have a very short window; once a session is established, the signature no longer matters. Digital signatures on contracts may need to remain valid for decades, covering employment agreements, mortgages, retirement savings, or long‑term commercial obligations. A timeline without a concrete migration plan offers little value. Effective planning requires knowing where cryptography is used across hardware and software, how systems interact, what natural replacement cycles look like, and which assets are business‑critical. This is where cryptographic bills of materials (CBOMs and SBOMs) become essential. Without visibility into which algorithms are used where, it is impossible to prioritize migration effectively. How Far Away Is a Cryptographically Relevant Quantum Computer? No one knows with certainty. Public forecasts estimate how many logical qubits would be required to threaten RSA or ECC, but translating that into physical qubits depends heavily on error rates, error‑correction overhead, and system architecture. Multiple quantum computing technologies are still competing, and it remains unclear which will scale fastest. Key challenges—error rates, error‑correction overhead, and interconnect scalability—remain significant. Progress continues, but additional breakthroughs are still required before quantum systems pose a direct threat to deployed cryptography. Beyond Cryptocurrencies: Broader PQC Challenges While cryptocurrencies have attracted attention, they are far from unique. Some cryptographic applications go beyond basic encryption, key exchange, or signatures and require special consideration in a post‑quantum world. Protocols based on elliptic curve pairings, for example, currently lack mature, standardized PQC replacements. Certain group and threshold signature schemes may also require careful reevaluation. The good news is that many widely used primitives, such as AES, SHA‑2, and SHA‑3, are already considered quantum‑resistant. And for RSA and ECC, standardized PQC replacements now exist, with defined migration paths. At Rambus, our security IP portfolio is designed with this transition in mind, supporting quantum‑resilient symmetric cryptography today and standardized PQC algorithms as replacements for public‑key mechanisms, along with clear roadmaps for adoption. The Bigger Picture The real takeaway from Google’s announcements is not that catastrophe is imminent. It’s that the industry has entered a more serious phase of post‑quantum transition. Cryptography underpins nearly every digital system. Migrating it is complex, slow, and deeply interconnected with hardware lifecycles, software ecosystems, standards, and operational reality. Cryptocurrencies may face unique governance challenges, but every global digital infrastructure faces similar technical hurdles. So no, there is no need to panic. But there is every reason to inventory, plan, prioritize, and execute. In the post‑quantum era, preparedness, not fear, will define resilience.
<img decoding="async" width="400" height="400" src="https://www.rambus.com/wp-content/uploads/2023/06/Lou_Ternullo.jpg" class="attachment-full size-full wp-image-63035" alt="Lou Ternullo" srcset="https://www.rambus.com/wp-content/uploads/2023/06/Lou_Ternullo.jpg 400w, https://www.rambus.com/wp-content/uploads/2023/06/Lou_Ternullo-300x300.jpg 300w, https://www.rambus.com/wp-content/uploads/2023/06/Lou_Ternullo-150x150.jpg 150w, https://www.rambus.com/wp-content/uploads/2023/06/Lou_Ternullo-75x75.jpg 75w" sizes="(max-width: 400px) 100vw, 400px" /> About Lou Ternullo <div class="elementor-element elementor-element-8682cda elementor-grid-3 elementor-grid-tablet-2 elementor-grid-mobile-1 elementor-posts--thumbnail-top elementor-posts--show-avatar elementor-card-shadow-yes elementor-posts__hover-gradient elementor-widget elementor-widget-posts" data-id="8682cda" data-element_type="widget" data-e-type="widget" data-settings="{"pagination_type":"prev_next","cards_columns":"3","cards_columns_tablet":"2","cards_columns_mobile":"1","cards_row_gap":{"unit":"px","size":35,"sizes":[]},"cards_row_gap_tablet":{"unit":"px","size":"","sizes":[]},"cards_row_gap_mobile":{"unit":"px","size":"","sizes":[]}}" data-widget_type="posts.cards"> <img loading="lazy" decoding="async" width="500" height="286" src="https://www.rambus.com/wp-content/uploads/2025/04/abstract-tech-still.jpg" class="attachment-full size-full wp-image-65455" alt="Join us for a webinar: Unleashing the Performance of AI Training with HBM4" srcset="https://www.rambus.com/wp-content/uploads/2025/04/abstract-tech-still.jpg 500w, https://www.rambus.com/wp-content/uploads/2025/04/abstract-tech-still-300x172.jpg 300w, https://www.rambus.com/wp-content/uploads/2025/04/abstract-tech-still-150x86.jpg 150w" sizes="(max-width: 500px) 100vw, 500px" /> Accelerating AI Workloads with Composable Memory & Hardware Acceleration Join Lou Ternullo from Rambus along with Yiannis Nikolakopoulos from ZeroPoint as they discuss a solution that addresses the evolving requirements of hyperscale data centers, Read More » Lou Ternullo August 1, 2025 <img loading="lazy" decoding="async" width="500" height="286" src="https://www.rambus.com/wp-content/uploads/2024/10/RDS-featured-img.jpg" class="attachment-full size-full wp-image-65104" alt="Rambus Design Summit - featured image" srcset="https://www.rambus.com/wp-content/uploads/2024/10/RDS-featured-img.jpg 500w, https://www.rambus.com/wp-content/uploads/2024/10/RDS-featured-img-300x172.jpg 300w, https://www.rambus.com/wp-content/uploads/2024/10/RDS-featured-img-150x86.jpg 150w" sizes="(max-width: 500px) 100vw, 500px" /> Why PCIe and CXL are Critical Interconnects for the AI Era Join Lou Ternullo, Senior Director of IP Product Management at Rambus, as he discusses the critical role of PCIe and CXL interconnects in enabling the Read More » Lou Ternullo October 5, 2024 <img loading="lazy" decoding="async" width="1000" height="572" src="https://www.rambus.com/wp-content/uploads/2024/07/Ask-the-Experts-PCIe7.jpg" class="attachment-full size-full wp-image-64640" alt="Ask the Experts: PCI Express 7.0" srcset="https://www.rambus.com/wp-content/uploads/2024/07/Ask-the-Experts-PCIe7.jpg 1000w, https://www.rambus.com/wp-content/uploads/2024/07/Ask-the-Experts-PCIe7-300x172.jpg 300w, https://www.rambus.com/wp-content/uploads/2024/07/Ask-the-Experts-PCIe7-150x86.jpg 150w, https://www.rambus.com/wp-content/uploads/2024/07/Ask-the-Experts-PCIe7-768x439.jpg 768w" sizes="(max-width: 1000px) 100vw, 1000px" /> Ask the Experts: PCI Express 7.0 Interface IP Video: Why PCIe 7.0 Is Evolving to 128 GT/s for AI and Disaggregated Compute PCI Express technology is advancing faster than ever, moving from 32 Read More » Lou Ternullo July 9, 2024 <img loading="lazy" decoding="async" width="500" height="286" src="https://www.rambus.com/wp-content/uploads/2024/01/cxl-launch-blog-img.jpg" class="attachment-full size-full wp-image-63779" alt="New CXL 3.1 Controller IP for Next-Generation Data Centers" srcset="https://www.rambus.com/wp-content/uploads/2024/01/cxl-launch-blog-img.jpg 500w, https://www.rambus.com/wp-content/uploads/2024/01/cxl-launch-blog-img-300x172.jpg 300w, https://www.rambus.com/wp-content/uploads/2024/01/cxl-launch-blog-img-150x86.jpg 150w" sizes="(max-width: 500px) 100vw, 500px" /> Unlocking the Potential of CXL 3.1 and PCIe 6.1 for Next-Generation Data Centers [Live on Feb 28] Increased demand for bandwidth, capacity and compute, coupled with the implications for increased data center costs, are the realities of the Read More » Lou Ternullo February 21, 2024 <img loading="lazy" decoding="async" width="500" height="286" src="https://www.rambus.com/wp-content/uploads/2023/08/rds-2023.jpg" class="attachment-full size-full wp-image-63215" alt="RDS 2023" srcset="https://www.rambus.com/wp-content/uploads/2023/08/rds-2023.jpg 500w, https://www.rambus.com/wp-content/uploads/2023/08/rds-2023-300x172.jpg 300w, https://www.rambus.com/wp-content/uploads/2023/08/rds-2023-150x86.jpg 150w" sizes="(max-width: 500px) 100vw, 500px" /> System Level Design Considerations for PCIe 6.0 PCIe 6.0 offers many new and exciting features including a 64 GT/s data rate, PAM4 signaling, forward error correction, and a low power L0p mode. Read More » Lou Ternullo August 31, 2023 <img loading="lazy" decoding="async" width="800" height="600" src="https://www.rambus.com/wp-content/uploads/2023/06/PCI-SIGDevConBlog-Image_3.jpg" class="attachment-full size-full wp-image-63066" alt="Rambus PCIe 6.0 Digital Controller Demo" srcset="https://www.rambus.com/wp-content/uploads/2023/06/PCI-SIGDevConBlog-Image_3.jpg 800w, https://www.rambus.com/wp-content/uploads/2023/06/PCI-SIGDevConBlog-Image_3-300x225.jpg 300w, https://www.rambus.com/wp-content/uploads/2023/06/PCI-SIGDevConBlog-Image_3-150x113.jpg 150w, https://www.rambus.com/wp-content/uploads/2023/06/PCI-SIGDevConBlog-Image_3-768x576.jpg 768w" sizes="(max-width: 800px) 100vw, 800px" /> PCIe 6.0 Takes the Spotlight Written by Frank Ferro and Lou Ternullo We wrapped up a great PCI-SIG Developers Conference (DevCon) last week which really showed off the strength and Read More » Lou Ternullo June 21, 2023
Rambus Recognized by Forbes as One of America’s Most Successful Mid‑Cap Companies for 2026​
Rambus is proud to announce that we have been named one of Forbes’ Most Successful Mid‑Cap Companies for 2026, ranking #21 out of 100 companies nationwide. This recognition highlights Rambus’ sustained financial performance, disciplined execution, and continued focus on delivering differentiated semiconductor technologies that address the world’s most demanding compute challenges. ©2026 Forbes Media LLC. […]
Rambus is proud to announce that we have been named one of Forbes’ Most Successful Mid‑Cap Companies for 2026, ranking #21 out of 100 companies nationwide. This recognition highlights Rambus’ sustained financial performance, disciplined execution, and continued focus on delivering differentiated semiconductor technologies that address the world’s most demanding compute challenges. <img loading="lazy" decoding="async" class="alignnone size-full wp-image-66275" src="https://www.rambus.com/wp-content/uploads/2026/04/Forbes-Blog.png" alt="Rambus is named one of Forbes' Most Successful Midsize Companies!" width="600" height="230" srcset="https://www.rambus.com/wp-content/uploads/2026/04/Forbes-Blog.png 600w, https://www.rambus.com/wp-content/uploads/2026/04/Forbes-Blog-300x115.png 300w, https://www.rambus.com/wp-content/uploads/2026/04/Forbes-Blog-150x58.png 150w" sizes="(max-width: 600px) 100vw, 600px" /> ©2026 Forbes Media LLC. All rights reserved. Used under license. ​​ Each year, Forbes evaluates publicly traded mid‑cap companies with market capitalizations between $5 billion and $20 billion, using data from FactSet. To qualify, companies must demonstrate positive sales growth over the past year and meet additional financial criteria. The final rankings are based on earnings growth, sales growth, return on equity, and total stock return over the past five years, with greater emphasis placed on the most recent year’s performance. All data for the 2026 ranking reflects results as of December 5, 2025.​ Rambus’ placement on this list reflects the strength of our long‑term strategy and the impact of our product portfolio across memory interface chips, interface IP, and security IP solutions. As data volumes continue to grow and system complexity increases, Rambus technologies help enable higher performance, greater efficiency, and stronger security across data centers, AI systems, networking infrastructure, and edge devices.​ This recognition is also a testament to the people behind the technology. The Rambus team continues to innovate with purpose, working closely with customers and partners across the semiconductor ecosystem to solve real world challenges and accelerate the future of compute. Consistent execution, technical excellence, and a focus on delivering value have been central to our growth.​​ Being named to the Forbes list reinforces our commitment to building sustainable success while advancing the technologies that matter most to our customers and the industry. We are honored to be recognized alongside other high‑performing companies that are shaping the future of technology and business.​ ​To learn more about the Forbes 2026 Most Successful Mid‑Cap Companies list and the full ranking methodology, visit the Forbes website: https://www.forbes.com/lists/best-mid-cap-companies/​ ​We thank our employees, customers, and partners for being part of this journey and look forward to continuing to deliver innovation that drives performance, efficiency, and security in the years ahead.​ ​
We are excited to be participating at RISC-V Now! by Andes in Shanghai! Stay tuned to learn more. About RISC-V Now! RISC-V Now! is the conference focused on turning RISC-V standards into products that ship — where spec goes to scale. Built for Practitioners RISC-V Now! addresses the realities of moving from evaluation to production: […]
We are excited to be participating at RISC-V Now! by Andes in Shanghai! Stay tuned to learn more. About RISC-V Now! RISC-V Now! is the conference focused on turning RISC-V standards into products that ship — where spec goes to scale. Built for Practitioners RISC-V Now! addresses the realities of moving from evaluation to production: • System-level trade-offs in shipping AI and compute platforms • CPU and SoC strategy under power, cost, and scaling constraints • Software enablement challenges encountered in real deployments • Lessons learned—what worked, what didn’t, and what teams wish they had known earlier It brings together customers, ecosystem partners, and teams evaluating RISC-V for silicon, software, and system integration to share real-world experience deploying RISC-V at commercial scale. From AI and automotive to datacenter and IoT, RISC-V Now! goes beyond standards discussions to address the realities of execution: architecture decisions, software enablement, system integration, and business outcomes. To learn more, follow the link here: https://riscv.org/event/risc-v-now-by-andes-shanghai/
We are excited to be participating at RISC-V Now! by Andes in Taiwan! Stop by booth #9 to learn more about our solutions. About RISC-V Now! RISC-V Now! is the conference focused on turning RISC-V standards into products that ship — where spec goes to scale. Built for Practitioners RISC-V Now! addresses the realities of […]
We are excited to be participating at RISC-V Now! by Andes in Taiwan! Stop by booth #9 to learn more about our solutions. About RISC-V Now! RISC-V Now! is the conference focused on turning RISC-V standards into products that ship — where spec goes to scale. Built for Practitioners RISC-V Now! addresses the realities of moving from evaluation to production: • System-level trade-offs in shipping AI and compute platforms • CPU and SoC strategy under power, cost, and scaling constraints • Software enablement challenges encountered in real deployments • Lessons learned—what worked, what didn’t, and what teams wish they had known earlier It brings together customers, ecosystem partners, and teams evaluating RISC-V for silicon, software, and system integration to share real-world experience deploying RISC-V at commercial scale. From AI and automotive to datacenter and IoT, RISC-V Now! goes beyond standards discussions to address the realities of execution: architecture decisions, software enablement, system integration, and business outcomes. To learn more, follow the link here: https://riscv.org/event/risc-v-now-by-andes-hsinchu/