IC Security Threats Spike With Quantum, AI, And Automotive

Key Takeaways:

• The top challenge for the chip architect is building post‑quantum cryptography securely into real hardware from the start, not just selecting approved algorithms.
• Security must be treated as a core silicon architecture decision early on, especially for long‑lived, automotive, and multi‑vendor systems.
• Automotive cybersecurity now requires a holistic approach spanning hardware, software, AI threats, sensors, supply chains, and regulatory compliance.

The most urgent security challenges in chips are no longer abstract quantum-secure algorithm choices or late-stage feature additions. They are architectural decisions that must be made early, under real constraints of area, power, performance, cost, with long product lifetimes.

Several security issues directly impact silicon architecture, including the integration of post-quantum cryptography into real hardware, the widening gap between mathematically secure algorithms and physically secure implementations, and the growing exposure created by complex, multi-vendor supply chains. As systems scale into chiplets, heterogeneous compute, and software-defined platforms — particularly in automotive — architects are increasingly responsible for defining trust boundaries, key lifecycles, update mechanisms, and resilience against side-channel, fault-injection, and AI-accelerated attacks. Security must be treated as a first-order architectural constraint, designed into silicon from the outset, because once the masks are cut, there is no second chance.

“Some of the most urgent security issues originate with the supply chain, because everyone is involved and there are established standards and certifications,” noted Sylvain Guilley, co-founder and CTO at Secure-IC, a Cadence company. “What makes it especially challenging is that it’s a system made up of multiple interconnected systems. If gaps exist, it’s crucial to focus on the interfaces between these systems when they’re combined. This is challenging, and it raises the question of responsibility. Whose business is it? Each party might be compliant individually, but unexpected issues can surface during integration. More transparency throughout the supply chain, along with improved auditability and traceability of how components are assembled, would be highly beneficial.”

Work is already underway here, starting at the chiplet level. “We’re collaborating with standards organizations such as UCI Express and considering regulations like the Federal Acquisition Supply Chain Security Act (FASCSA) to establish traceability and transparency directly within the silicon itself. The idea is to build trust in the security of the supply chain from the silicon upwards. We believe this approach should be more widely adopted and potentially standardized across the entire supply chain in the future,” Guilley said.

Post-quantum cryptography
PQC is the most pressing issue, according to security experts, and it requires immediate attention.

Within PQC, the most urgent and underdiscussed security issue is the “trust now, forge later” (TNFL) scheme of post-quantum cryptography. “I don’t think this threat is highlighted enough,” said Dana Neustadter, senior director of product management for Security IP Solutions at Synopsys. “People talk about ‘harvest now, decrypt later,’ (HNDL) in terms of confidentiality, but one that is not talked about enough is TNFL, which undermines the foundation of every single security in our lives, because it can affect things back in time. First, it means you may be able to create a document that shows it was signed in the past. Second, things that were true and proven in the past are no longer provable. Quantum-safe solutions and migrating to post-quantum crypto are more prevalent nowadays because of the pressure and the deadlines associated with them, but it’s not clear how big a risk TNFL is.”

Others agree on the seriousness of the quantum threat. “The concept of post-quantum security is widely recognized as an important issue,” said David Garrett, vice president of technology and innovation at Synaptics. “Although post-quantum technologies are not yet fully developed for practical implementation, many organizations are actively preparing for their integration. There is significant attention being paid to ensuring readiness for the challenges posed by post-quantum advancements. If you thoroughly research quantum computers, you’ll find that the technology still has a long way to go before it becomes relevant. But security poses a significant challenge because it creates obstacles for developing and debugging applications.”

In the U.S., the National Institute of Standards and Technology (NIST) is pushing hard on this issue. “Digital signatures and the CNSA and the deadlines [are of great concern], precisely because TNFL needs post-quantum cryptography and quantum-safe digital signatures,” Neustadter said. “There are other encryption mechanisms. But again, there is a push for that. It just really needs to be in place across the board.”

NIST is actively standardizing and promoting the adoption of PQC algorithms resistant to future quantum computer attacks. NIST released the first three finalized PQC standards in 2024 and is now focused on finalizing additional standards, creating migration guidelines, and facilitating interoperability testing through its National Cybersecurity Center of Excellence (NCCoE).

There are unique challenges to PQC in an automotive setting. Car manufacturers often face difficulty managing and overseeing numerous subcomponents, making it especially complex to monitor PQC challenges. “In typical IT environments, individuals are generally unaware of where cryptographic methods are employed within their systems, leading to considerable expenditure on understanding cryptography usage,” noted Yan-Taro Clochard, product marketing group director – security at Cadence. “Knowing these details is crucial for PQC, as tracking complete subsystems based solely on software becomes nearly impossible if visibility is lost. Addressing this challenge is vital for enhancing overall security management.”

Modern vehicles have as many as 150 Electronic Control Units (ECUs) sourced from numerous Tier 1 suppliers, creating uniquely complex supply chains. “Roughly half of those ECUs may be cybersecurity-relevant, which is why a modern vehicle is often referred to as ‘a datacenter on wheels’ and thought of as a rich collection of potential targets for cyber threats,” said Scott Best, senior technical director of Product Management, Silicon IP at Rambus. “Today’s automotive cybersecurity landscape is being shaped by ISO/SAE 21434 as the engineering backbone, with UNECE R155 and R156 making cybersecurity and secure updates a regulatory requirement rather than a best practice or a competitive product distinction. From chipmakers that service the Tier 1 suppliers, these standards translate into building trust anchors directly into silicon, with secure boot, protected key storage, hardware-isolated cryptography, and chain‑of‑custody secure-supply-chain mechanisms becoming table stakes for the semiconductors they deliver.”

Secure algorithm versus secure implementation
According to Durga Ramachandran, innovation director at Keysight EDA, the most urgent issue to address with PQC is bridging the gap between “secure algorithm” and “secure implementation,” especially under real hardware constraints.

Ramachandran cited four key quantum security issues:

1. Designers assume that with a NIST‑approved PQC, the implementation is secure. But a secure algorithm isn’t necessarily a secure implementation. PQC schemes are mathematically designed to resist quantum attacks, but once mapped onto real chips, FPGAs, and IoT devices, they inherit all the classic issues like side‑channel leakage, fault injection, timing behavior, and memory and power constraints.
2. PQC is not immune to attacks that affect AES/RSA/ECC, such as fault injection (voltage, EM, laser, temperature, etc.), and side‑channel leakage (power, EM, timing, even acoustic or other emissions).
3. PQC implementations can be 10× to 1,000× larger and slower than traditional cryptography. Adding protections against FI/SCA can further blow up area, power, and latency (4× to 8× or more), which makes it very easy for architects to cut corners on security to meet PPA/timing, which is precisely where exploitable weaknesses appear. The result is a complexity and cost explosion for secure PQC on hardware.
4. Security is not being pulled into the architecture phase early enough. Once silicon is built, there is no going back. Therefore, the urgent need is to move PQC and hardware‑attack thinking into early architecture/spec. That means identifying the critical assets (keys, long‑lived secrets, key usage patterns); deciding where they live, for how long, and how often they’re used; and planning protections and tradeoffs before RTL is frozen or masks are cut.

AI attacks
Quantum attacks aren’t the only looming threat worrying security experts. AI adds yet another urgent concern.

“AI systems learn, and they can do things very, very, very fast,” Synopsys’ Neustadter said. “They can learn from a particular threat or a particular attack, adjust to it on the fly, and become so powerful that the systems cannot keep up with it. In terms of the AI implications on adversarial attacks, AI systems must be created that are secure, as well as understand what happens when AI is used to attack. I’m speaking of AI-accelerated ransomware, and this is not a one-off. You learn, and you get better. Can the technology adjust as fast? I see all the positives and the amount of investment globally in this technology that is, at its heart, the evolution of everything, and of our lives. I’m highly confident, but there will be a need for more regulations, including AI systems governance, and there’s a long list already.”

Chip architects and designers spend a lot of time worrying about these issues, and it leads to considerations for other parts of the system. “When I have a device, and I’m developing firmware, I want full control. I want to inspect everything that’s happening, check details, and figure out what’s going wrong,” Synaptics’ Garrett noted. “Debugging is straightforward, but when it comes to security, I lose that access and visibility. Everything is protected, which creates significant challenges. Locking devices can really slow down debugging. However, there are initiatives to address this. For instance, Arm separates secure and non-secure domains to keep applications safe. We also use memory protection and encrypt models.”

There is also ongoing research by the CHERI Alliance, an industry initiative that promotes the Capability Hardware Enhanced RISC Instructions (CHERI) security technology that was developed by the University of Cambridge and SRI.

“It is important to consider how individual pointers are safeguarded as data moves through a system,” Garrett said. “A key challenge arises in enabling engineers to build and debug efficiently while maintaining security — for instance, avoiding practices like sharing secret passwords merely for convenience during debugging. Ensuring ease of development without compromising protection is a complex issue that requires careful attention.”

As these challenges continue to evolve, it becomes increasingly crucial to address both the technical and regulatory aspects of security in connected systems, setting the stage for a deeper discussion about how privacy and data protection intersect with advanced automotive technologies.

Tesla users, for example, rely on access to cloud-connected services. Both the Tesla mobile app and owner portal communicate with back-end systems over encrypted channels. Sensitive live feeds, including Sentry Mode live view, are secured by end-to-end encryption so only the owner can see the live stream itself. Users can request data to be exported through a secure download link tied to an account.

Automotive concerns
Automotive is full of potential security problems. And as ADAS systems become more complex, with additional electronics and software being added, cybersecurity risks increase. Even memory is now a potential avenue for attack in vehicles.

“To help secure DRAM against rowhammer attacks and minimize the risk of data corruption, JEDEC’s data integrity task group has created a series of functions, including a per-row activation counter, to maintain data security,” said Randy White, memory solutions program manager at Keysight EDA. “There are many considerations and discussions to align with external standards such as AEC-Q100, ISO 26262, and other reliability and security standards.”

Standards target protection in three main places — within the vehicle, in transit between the vehicle and the cloud, and back-end systems. In the case of Tesla, operating system data, logs, and some settings are stored on internal flash within the vehicle. Safeguard mechanisms are used within the vehicle to protect personal data that can be found in software. There is also a factory reset feature that can effectively wipe personal data before a customer sells or otherwise transfers ownership of the vehicle.

The “in transit between car, app, and cloud” distinction encompasses the security measures Tesla uses to protect personal data during transmission, which includes encrypted connections between the vehicle, servers, and the mobile app.

Tesla’s back-end systems are accessible to certain employees based on their role, and the data is stored in secure data centers. All in all, the consumer has some, but not all, control of their data and usage history.

“Putting it all together, memory is just one component,” White said. “Holistically, Tesla and every OEM must have a ZeroTrust Security Policy. This model operates on the principle of ‘never trust, always verify,’ ensuring strict access controls and continuous validation of users and devices. Tesla secures the overall collected data with a mix of encryption, access controls, and in-car security features, but the exact cryptographic implementations and internal controls are described at a high level, without full technical details.”

To secure the multiple levels of vehicle data, a layered approach is needed, starting at the chip level, to in-vehicle networks, and cloud services. “At the hardware level, data is protected through built-in trust anchors and cryptographic mechanisms that ensure integrity and confidentiality from the moment it is generated,” Cadence’s Clochard said. “Communication between ECUs is secured using standards such as MACsec and secure CAN/J1939, which help maintain data authenticity and support functional safety requirements critical for ADAS and autonomous systems. Complementary to data protection, intrusion detection, vulnerability, and security lifecycle should be managed as mandated in automotive-related standards (e.g., ISO 21434). Long-term protection also relies on secure boot, firmware updates, and cryptography that is designed to remain robust against upcoming threats, including post-quantum cryptography. By combining hardware-based security, secure communications, and lifecycle management, vehicle data can be safeguarded while meeting the high safety and reliability standards expected in modern automotive systems.”

Some automotive manufacturers already are implementing hardware, particularly OEMs that began early due to their products’ long lifespan, said Robert Bach, product marketing manager at Infineon Technologies. “Some companies are preparing for quantum computing threats, while others aim to leverage quantum computers for various beneficial applications. Infineon has a small team developing quantum computer algorithms to optimize our supply chain. With hundreds of thousands of customers and billions of parts, coordinating supply is a major challenge for semiconductor suppliers. Quantum computers offer powerful optimization capabilities. Even with 250 qubits, they could rival the calculation power of the universe. While security concerns exist due to our industry background, the potential opportunities for quantum computing are immense.”

As the industry continues to evolve, these security strategies must adapt to the increasing complexity of vehicle systems and the growing reliance on interconnected technologies. This underscores the need for comprehensive approaches that address both the technical and operational challenges of automotive cybersecurity, paving the way for new standards and practices that ensure data integrity and passenger safety.

Within the automotive industry, the perception of modern vehicles is shifting, increasingly seen as computers on wheels — particularly with the advancement of autonomous driving technologies. “Consider an autonomous shuttle service operating between Heathrow Airport and Victoria Coach Station, for example,” noted Jaroslaw Szostak, product cybersecurity manager at Imagination Technologies. “Passengers rely on these vehicles to transport them safely, highlighting the importance of functional safety. In addition to ensuring operational reliability, it is essential to address security concerns in order to prevent adversaries from compromising passenger safety. Traditionally, drivers could respond to unexpected situations or supervise the journey. However, as we move toward full automation, new challenges arise. Our approach is to address these challenges by thoroughly understanding each use case, conducting comprehensive threat analysis and risk assessments, and identifying potential threats and attack paths. From there, we develop approaches to mitigate the risks.”

This is a significant challenge, especially when it comes to hardware security module (HSM) components. “There are established standards such as FIPS, Common Criteria, and PCIe, particularly relevant for smart cards and the banking industry, Szostak said. “However, no standard currently exists for GPUs, and GPUs aren’t generally regarded as secure or security-related components. The reason for this is that GPUs aren’t directly connected to the vehicle bus — like the chassis bus — but instead interface through the CPU. In contrast, CPUs typically support features like secure boot, secure data storage, and hardware Root of Trust, so we depend heavily on the CPU for security.”

A further challenge is to have GPUs recognized as cybersecurity relevant. “We ensure firmware authentication, use only legitimate VMware, and understand potential attack vectors,” he said. “There are zonal architectures involving virtualization and multiple tenants, prompting important ‘what if’ questions. For example, what happens if system fusion is shared with infotainment or telematics modules? Media reports often highlight vulnerabilities originating from infotainment systems. There’s even a common joke that if the cause of an issue is unknown, it must be the infotainment. Since GPUs are primarily used for infotainment and fusion, this context is crucial.”

Progress is being made here. In 2016, with the introduction of a cybersecurity guideline SAE J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems. “At that stage, J3061 was only a guideline, and some companies regarded it more as a casual reference than a strict requirement,” Szostak noted. “However, the regulatory landscape changed significantly when the UNECE established regulations, transforming compliance from a suggestion to a necessity for vehicle type approval and sales. And with the adoption of R155 and R156, manufacturers are now required to implement a Cyber Security Management System (CSMS) and a Software Update Management System (SUMS). For us, this means that during firmware development, we adhere to the principles of security by design, beginning with the implementation of a robust CSMS. The SUMS ensures that any firmware updates delivered do not introduce new functionalities or disable existing ones without proper documentation and justification. It is critical to maintain accurate records of all changes, as these are evaluated during the OEM’s application for type approval.”

For instance, vehicles equipped with advanced safety features rely on specific sensor calibration parameters, such as a fixed lidar or radar range. These parameters must remain unchanged to ensure vehicle integrity and safety; modifications could alter performance characteristics and introduce untested risks. “Also, liability concerns make it essential that certain aspects — like calibration parameters — remain restricted from user modification. Unauthorized changes could negatively impact the brand and pose significant safety issues. To address these challenges, cryptographic methods and hardware-based solutions, such as leveraging GPUs, are implemented to secure configurations and verify their integrity. This approach helps manufacturers demonstrate that a particular configuration has not been tampered with, even if attempts were made via hardware access points. Ultimately, these measures contribute to ensuring both compliance and end-user safety throughout the vehicle’s lifecycle,” Szostak added.

In fact, some believe the biggest threat to automotive cybersecurity comes from sensors. “When we get to the point where sensors are connected directly up to the Automotive Ethernet network, I’m not convinced there is enough thought in what the sensor companies produce to keep it from spoofing things,” said David Fritz, vice president of hybrid-physical and virtual systems, automotive and mil/aero at Siemens EDA. “A common example is that you could inject something into a camera that finds its way to the central compute and perception stack that makes it look like there’s something in front of you that isn’t there. Then the car takes evasive action, and you have an accident. That’s one of the biggest concerns.”

Conclusion
Security for next-generation silicon must be treated as a first-order architectural constraint, not a late-stage feature, with post-quantum cryptography, secure implementations, and long product lifetime considerations designed in from day one.

Choosing the right algorithms is essential, along with closing the gap between mathematically secure designs and physically secure hardware, while also managing complex supply chains, AI-accelerated attacks, and increasingly software-defined vehicles. Ultimately, building trust in connected systems requires a holistic, layered approach that spans silicon, software, sensors, and cloud infrastructure.