Hardware security verification must go beyond functional testing

By John Elliott

August 25, 2026

Imagine you’re an attacker staring at a billion-transistor system-on-chip (SoC). You don’t care whether the design boots Linux, passes simulation, or meets its performance targets. Your objective is far simpler. Find the one flaw nobody thought to look for.

It might be an undocumented debug port or path. Maybe it’s a configuration error between hardware and firmware. Sometimes it’s a perfectly legitimate sequence of operations that exposes sensitive information in a way the original team never anticipated. A single overlooked weakness is all it takes.

Design teams focus on proving that a chip operates according to its intended specifications. Security assurance requires answering a different set of questions to identify the conditions that could violate security objectives. As the above figure illustrates, security verification must test for unexpected data paths that could expose sensitive information, not only confirm that intended paths operate correctly.

Beyond intended behavior

Security verification starts from a different premise. The concern is not whether a protected asset reaches the encryption engine, but whether information associated with that asset can reach an unauthorized destination. A debug interface may unintentionally expose sensitive information, or firmware may fail to clear a memory location after a key has been used. Otherwise, legitimate operations can also interact to create an unexpected path through the system.

To read the full article on EDN, click here.