Governments and systems companies are fundamentally changing the rules around semiconductor security, forcing chipmakers and their suppliers to comply with tough new regulations that require resiliency in hardware. Unlike in the past, chips and systems deployed in these markets must be able to respond to threats rather than waiting for the next version of a chip or IP to address vulnerabilities.
Attached to these regulations are costly penalties, which can range from enormous fines to being frozen out of lucrative markets. And while they vary by region and by market segment, collectively they almost certainly will increase the cost of doing business across the semiconductor supply chain. Underlying these new rules is a recognition that data is becoming more valuable, accessible through nearly everything with a battery or a plug, and the chips that enable the processing, storage, and movement of that data are becoming a bigger target for bad actors looking to steal or control it.
As a result, hardware vendors need to begin thinking about security at every step of the design-through-manufacturing process, both individually and in the context of larger systems. At risk are different processor types and memories, chiplets, the interconnects between those chiplets, soft IP, and packaging. In the past, these components were generally developed according to a specification, with security layered on top or around those components. In the future, that won’t be enough. Companies may be held liable or barred from doing business if they don’t comply with the new regulations, regardless of whether they meet those specifications.
Four main sets of regulations affect chipmakers and their suppliers, and all of them are becoming more stringent:
- The new version of the European Union’s Cyber Resilience Act (CRA) will impose fines of up to 2.5% of a company’s total revenue, or up to €15 million — whichever is greater — for failure to comply with regulations involving hardware and software. This applies to manufacturers, distributors, importers, or anyone else in the supply chain, and it will ban any products or services that do not comply, effective Dec. 11, 2027.
- OCP SAFE, which is being driven by Google and Microsoft, shifts the security burden to makers of processors and peripherals with updatable software. The goal, as defined by the Open Compute Platform, is to ensure the “provenance, code quality, and software supply chain” of firmware releases and patches, essentially putting the onus on third parties rather than the systems companies to fix security issues for whatever they sell.
- The U.S. National Cybersecurity Strategy Implementation Plan (NCSIP) likewise emphasizes resiliency over static security measures in a far-reaching plan that requires companies working with the U.S. government to support a broad framework of requirements, under the aegis of the National Institute of Standards and Technology (NIST).
- OCP also has developed a tamper-resistant root-of-trust specification called Caliptra for data center hardware. Supported by Microsoft, Google, AMD, and NVIDIA, it’s aimed at bringing security into heterogeneous systems that may include CPUs, GPUs, NPUs, TPUs, DPUs, and various controller chips.
While not every company or market segment is directly affected, resiliency will be viewed as an advantage in most markets, and companies that do business in these regulated markets will leverage security as a competitive edge.
“In the past, security could have been something that’s one and done,” said Maarten Bron, managing director at Keysight Technologies. “You’d launch a product into the market, and it had a certain shelf life, which for IoT devices could be very short. But now, all of a sudden, there is a requirement to keep your finger on the pulse because it’s not static. What’s secure today could be insecure tomorrow, and there’s a requirement not just to notify your customers that something may be wrong, but to fix it. That means a firmware update capability needs to be part of the product, and there has to be a secure way of commissioning those firmware updates.”
Security experts have been warning about a widening attack surface that includes semidconductors since the early 2000s, but until recently most of the attention has been focused on software. “I’ve been railing for years that if companies didn’t provide secure products, or take the need to protect their products seriously, that eventually they would be boxed in with legislation,” said Mike Borza, principal security technologist and scientist at Synopsys. “Some places want to deregulate, but others will insist there’s security in these products so that it’s not possible for adversaries to continue romping through them and taking control of them at will. The European legislation is serious.”
Unanswered questions
These new regulations are just the beginning, and it may take years to sort out exactly how and where legislation will be applied to security. But the underlying concepts are well understood. New vulnerabilities in hardware are sprouting up faster than new chips or systems can be developed to close them. As a result, designs need to include some method of isolating attacks or updating firmware to prevent attackers from holding data hostage or controlling the processing, storage, or movement of data.
The big question is how to implement hardware security in a cost-effective way. “The scope and purview of these requirements is critical infrastructure, data centers, and those kinds of areas,” said Erik Wood, senior director of product security at Infineon. “If we deliver these standards of care that are well-known, well-adopted, and all the standards bodies, certification labs, and industry organizations are saying, ‘Yeah, that’s the right standard of care for these devices,’ that’s important. But remember, some of these are $2 and $3 devices, where 5% is what the market will bear in security costs. As we’ve seen recently in radio equipment, the outcome has turned into a technical requirement. There’s a harmonized standard with EN 18031 (Europe) as the benchmark radio equipment directive, and with CRA, we’re expecting it to be a harmonized standard that allows us to benchmark our hardware and software against something. But as that does not exist yet, we’re still in the standard of care phase.”
That standard of care is basically a recipe of best practices, similar to how the software industry has addressed security in the past. When vulnerabilities are found, security patches are developed. But patching hardware can be a lot more difficult than patching software, and the results are not always optimal.
“With Spectre and Meltdown, we had to provide patches, and everyone at that point seemed to be mandated to provide those patches,” said Nandan Nayampally, chief commercial officer at Baya Systems. “Because they were bypassing caching, the only way to undo that was to kind of flush it at times. It took a performance hit to the tune of 20%.”
Whether these regulations will work for semiconductors as well as patches for software remains to be seen. Chips are becoming increasingly complicated, particularly at the leading edge of designs where a monolithic planar SoC is being decomposed into chiplets. These are predominantly bespoke multi-die assemblies targeted at specific markets, and they are at the bleeding edge of performance and power management. Adding active security — or more accurately, the ability to update security to address known vulnerabilities — will be unique to each design. Moreover, security takes on a whole new challenge as chips begin to age. Electromigration, time-dependent dielectric breakdown, and functional updates can open entirely new vulnerabilities that were not there in the first place, particularly in AI data centers, where utilization of resources is higher than in other markets.
“On the one hand, I’m glad standards are being established for systems where security critically informs, like user safety in an automobile,” said Scott Best, senior director for silicon security products at Rambus. “Standards groups are documenting and saying, ‘These are the requirements. If you’re going to deliver security into this system, it needs to achieve this level of performance in a security sense.’ That’s a good thing because safety is critical. “
But exactly what’s required isn’t entirely clear at this point. “It’s a work in progress, because the EU still has to publish the detailed testing requirements,” said Keysight’s Bron. “There’s a possibility that the introduction will be delayed a little bit because of pushback, but we don’t expect it to be canceled. We think CRA is there for a good reason. It’s going to protect everybody. And yes, it will have an effect on prices. But the current situation is not sustainable with so many attacks going on, so much ransomware, and so many state actors abusing stuff. Still, this won’t be an easy step.”
A long liability chain
One of the big changes coming to hardware security involves an increase in the number of suppliers on a bill of materials. While liability generally starts with the system vendor, which acts as the general contractor, it ripples down from there. Think about a multi-die assembly, for example, in which there are a variety of chiplets, interconnects, memories, and embedded IPs. Was there a latent defect somewhere in the device? Did a particular wafer degrade faster than another wafer due to a buildup of residue in a chamber or deeper dishing from chemical mechanical polishing? Was the photoresist contaminated by impurities in one of the materials? Was there silent data corruption due to a design or manufacturing error?
“The whole idea of UCIe is that it leads to a marketplace of chiplets, where you can put together a heterogeneous system and package based on supplies of chiplets from multiple vendors,” said Synopsys’ Borza. “That creates the possibility that people are going to pass the buck. First, the vendor of the system and package ends up being identified as the source of a problem because there’s a vulnerability. Then, they will start trying to isolate that within their system and package. That means they’ll be looking at the individual vulnerable components of that system and package to determine where the vulnerability stems from, what the root cause is, and whether there’s somebody liable in there.”
This will hit some industries harder than others. “Carmakers currently have functionally safe processes,” said Andy Heinig, head of department for efficient electronics in Fraunhofer IIS’ Engineering of Adaptive Systems Division. “For them, it’s only a small effort. It’s a new feature they have to check, but they have very well-established processes for quality. Companies designing for industry, or for products with a lifetime of 15 years or so, are well-equipped with processes for that. But companies that have never looked into that are really in trouble. These may be companies that develop Bluetooth or Zigbee chips for consumer applications that are very easy to penetrate.”
Which parties are ultimately liable, and for how much, has yet to be worked out. It’s also not clear how much any of this is going to cost to implement, and who ultimately will pay for that. How companies tackle resiliency can vary greatly, from a secure system that does firmware updates to simple firewalling of critical data.
“We’ve always had features for security isolation,” said Charlie Janac, CEO of Arteris. “You can have a secure and non-secure section, and you can poison data that are not allowed to be on that trace. So if we detect packets that are not supposed to be on that particular connection, we can poison them and kill them. Another approach involves functional safety, where if you detect an error and you have duplicated units that are comparing each other right at the interface of the network, then you can identify packet errors and shut down the IP that’s generating the errors. And we can analyze whether one IP is generating too many errors and take it off the network. Right now, the biggest chips are about 500 IPs. We can put firewalls on the interconnects, which are specialized IPs that detect security problems with data flows going through the trace.”
Nevertheless, even fully understanding what is required at any time is a challenge, given the growing number of security organizations and updates.
“The main challenge people have had is that nothing is designed perfectly, so now we’ve given them a patch,” Baya Systems’ Nayampally said. “So what are they going to do with it? That has implications for most contracts in terms of increasing the level of liability and indemnity. Best practices will come out. But, of course, there will be other standards bodies competing.”
Others point to similar potential for confusion. “There are updates to the specifications that are difficult to track, and all the overhead in figuring out which one your customers must have,” said Rambus’ Best. “And sometimes the standards groups start moving in a direction where the people who are contributing to the specification are not necessarily from businesses that are security-based. They’re not delivering security components into the automotive space, but they’re contributing to some degree to these automotive certifications and the standards requirements going into them.”
That tends to favor large players over startups and small companies, because it requires a compliance team to stay on top of these updates, and a legal team to defend against any fines.
“Only a large organization can afford to put 5 to 10 people on the certification compliance team to track all of these standards, attend all the meetings, and make sure their products are conforming to these rapidly changing standards,” Best said. “Rambus is large enough to pay that tax. We have a compliance certification team of experts that has now gone through the process to say, ‘Here’s where are products are certified now.’ But we have smaller competitors that can’t afford that level of resources.”
It will take time to sort out exactly what is required and what is an acceptable solution. “It’s not really defined in all these specifications and documents how much you have to do,” said Fraunhofer’s Heinig. “This is similar to the functional safety discussion in automotive that we had with ISO 26262 early on. It’s really hard for all the partners to understand what it means. It took three or four years to understand which document you have to fill out, what is enough for that, what is necessary, or what is missing. This is the critical phase because nobody knows, if it goes into law, if you will need more.”
Past, present, and future
Wherever hardware resiliency exists today is where the perceived value of data is high enough to warrant the investment. Set-top boxes, credit cards, and automotive and industrial applications are prime examples.
“The roots of security certification started in payments,” said Marc Witteman, senior director of device security testing at Keysight. “There’s a global organization called EMVCo. The E stands for Europay, the M for Mastercard, and the V for Visa. They set up a security certification for payment, and they also pioneered the trust models. What’s interesting is they also defined the so-called composition model, which starts with the chip. On top of the chip is an operating system, and on top of that are payment applications. So there could be a lot of combinations of chips and operating systems. It’s a composition model, and you add layers on layers on layers. Now we’re seeing that model repeating in other industries, but it’s a lot more fragmented and diverse. But if you think about the BOM and the SBOM (software bill of materials), these are relatively new concepts. People want to know what hardware and software is in this device. Then you can build a chain of trust, starting with the root of trust in the hardware.”
That chain of trust is expanding. Chipmakers already have begun compliance efforts and are designing new chips and systems that include more security features and update options.
“And security engineers who are creating the data center security based on CNSA 2.0, which starts kicking in this year, share office space with engineers at those same companies contributing to the security requirements of medical devices and wearables, thermostats, and stuff like that,” said Infineon’s Wood. “So there’s cross-pollination of the critical infrastructure requirements from CNSA 2.0 that, after a year or two, lead into IoT manufacturing and those requirements.”
How quickly the rest of the industry will follow remains to be seen. But no matter how rocky the start, changes are coming to hardware security. Something fundamental has changed, and if regulators continue to push, hardware patches soon may become just as prevalent and persistent as software updates.