Securing a chip is no longer a matter of final verification or a certificate attached to the product before launch; it has become a process that extends from design through deployment and monitoring. This was the main conclusion of a closed discussion organized by Semiconductor Engineering during the Design Automation Conference, with experts from Arteris, Cadence, Keysight EDA, Rambus, Siemens EDA, Synaptics, and Synopsys participating. This article is based on excerpts from that discussion, which was moderated by Ann Mutschler.
The attack surface is expanding with the spread of artificial intelligence, chiplets, software-defined systems, FPGAs, and connected systems. The risk is therefore not limited to a physical defect in the circuit or an attack on the chip itself; it may begin with the network, embedded software, or a programmable layer, and then exploit a weakness to access or disrupt the system.
From Certification to Actual Use
Yathiendra Vunnam of Cadence said that many customers are adopting a multilayered defense, using mechanisms such as IPsec and MACsec across different layers of the OSI model to meet performance and computing needs. He also explained, however, that some companies focus on certification because it helps them sell the product, then reduce the set of required protections to achieve a smaller, lower-cost, reusable design.
The problem, according to Scott Best of Rambus, is that possessing protection technology does not prove that it has been properly implemented. A customer may request protection against side-channel attacks, fault-injection attacks, or PUF technology, then treat these elements as completed boxes on a requirements checklist without clarifying how they should be integrated and used within the final system. The same applies to compliance with frameworks such as CRA and ISO 26262, or obtaining CSIP Level 3 from Keysight or a competing organization.
This does not mean that certifications or standards have no value; it means that, by themselves, they do not provide sufficient evidence that a product is secure under actual operating conditions. The gap emphasized by the participants is the difference between having a security mechanism on paper and its ability to function when integrated with the rest of the hardware, software, and networks.
Visibility Begins with the Bill of Materials
Alexander Petr of Keysight EDA said that modern systems are built across layered levels: a chip, then a package, a board, and a system, followed by a connected ecosystem encompassing data centers and wide-area networks. As more functions move into embedded software, knowing what enters the product becomes a prerequisite for tracking risks.
This includes creating a software bill of materials for hardware components, or what Petr described as the importance of a Software Bill of Materials for hardware, alongside vulnerability tracking and post-deployment monitoring. The challenge increases with open-source software, as he noted attempts by malicious parties to infiltrate open-source communities and inject backdoors. Discovering a zero-day vulnerability is also not enough; a company must first know whether its system uses the affected component, and then whether it can fix it or create an appropriate defense.
The chiplet architecture adds another challenge. The ability to assemble units from different sources may reduce costs, because each block does not necessarily need the most advanced nodes, but it raises a practical question: how does a designer verify the security of every chiplet, and how can the designer ensure that the least secure unit does not put the entire system at risk?
Regulation Raises Awareness, but Does Not Guarantee Behavior
Participants agreed that regulations, including the European Cyber Resilience Act, or CRA, have raised awareness and prompted some companies to invest in roots of trust and embedded protection. Chris Giles of Siemens EDA said that the existence of the law is not enough, because enforcement will be necessary to turn the requirements into sustained investment. Participants said that the date associated with semiconductors is September 11, 2026, while questions remain about what will have to be disclosed and how this will be applied in practice.
Mohit Arora of Synaptics also noted that penalties could reach 4% of annual revenue, while Reed Hinkel of Synopsys said that this kind of pressure has begun pushing companies that had been hesitant to place a large root of trust on the chip or adopt Open Compute Project approaches such as Caliptra. But the discussion showed that the regulations' effect on behavior has not yet been settled: Giles said that CRA is strongly present in conversations, but he was unsure whether it had changed practices, while Petr noted that no fines had been imposed by the time of the discussion.
What Is Changing in Practice?
The required shift is not simply the purchase of additional security tools or intellectual property, but the distribution of responsibility across design, software, product-management, and operations teams. The greater the value of the service provided by the product, the higher the cost of a security failure and the associated liability. Hinkel therefore argued that promises of high-value services must be paired with an actual ability to meet service-level agreements and respond to vulnerabilities.
Commercial and military incentives also emerged in the discussion. Products that earn users' trust may justify greater security investment, while the needs of the U.S. Department of Defense and its suppliers, including Boeing and Airbus as mentioned in the discussion, are driving part of the investment in this field. But this does not eliminate the constraints: security is always competing with cost and launch schedules, and certification may remain easier to measure than the quality of deployment and monitoring.
Regarding post-quantum cryptography, Hinkel explained that the challenge is not limited to hardware or firmware, but extends to public-key accelerators, or PKAs, which have historically been built on accumulated layers that are difficult to update and expand. According to the discussion, products need to support new algorithms within three years, while the retirement of old algorithms is tied to a five-year horizon. This indicates that preparing for post-quantum cryptography requires architectural reorganization, not merely adding an algorithm to an existing design.
The most important takeaway for the technical reader is that provable security must encompass what exists inside the product, how it was integrated, and how it will be monitored after sale. Certification remains a checkpoint within this process, not a substitute for it. The details of regulatory enforcement, the limits of vulnerability disclosure, and companies' ability to address products already distributed in the market remain open questions that the source did not resolve.