NSA ASIC Guidance Shows Why Hardware Assurance Starts Before the Chip Exists

Evidence boundary. NSA released an ASIC Best Practices Threat Catalog and the first Level of Assurance guidance on 25 August 2026. The catalog groups intentional compromise threats into 18 categories, including design requirements, IT systems, EDA software and third-party IP. LoA1 is the first of three planned assurance levels. The guidance is not evidence that commercial ASICs are compromised by default, and it does not make every mitigation mandatory for every product.

Hardware assurance starts upstream of fabrication

Silicon is the final artefact of a long engineering chain. Requirements, RTL, verification environments, EDA tooling, reusable IP, foundry processes and test infrastructure all influence what reaches the device. A clean production test therefore cannot prove that every upstream design decision or inserted dependency was trustworthy.

The useful assurance chain is:

Security requirements → design provenance → trusted tooling and IP → verification evidence → manufacturing controls → product integration

NSA's threat catalog matters because it treats those stages as potential compromise points rather than reducing hardware security to physical tamper resistance or a root of trust added late in the design.

Third-party IP turns supplier opacity into an assurance problem

Modern ASICs routinely integrate commercial or externally developed IP. That is economically rational, but it means the integrator may not possess complete implementation knowledge. The relevant question is not whether every third-party block can be opened and re-engineered. It is whether the residual uncertainty is explicit and bounded.

Where internals cannot be fully inspected, teams can combine provenance, supplier evidence, interface restrictions, architectural isolation, wrappers, privilege minimisation and targeted verification. Those controls do not create visibility that does not exist. They constrain what an opaque component can influence and make the remaining assumption auditable.

Automotive and industrial assurance need traceable assumptions

For automotive ECUs and industrial controllers, hardware controls eventually support software and system-level cybersecurity claims. A secure boot block, HSM, debug lock or hardware-enforced isolation mechanism becomes meaningful only when the product TARA and security concept state what threat it addresses, what assumptions it relies on and how the delivered implementation is verified.

This is where procurement evidence matters. If a Tier-1 relies on third-party silicon or IP but cannot establish lifecycle provenance, change notification, security-relevant configuration and assurance evidence, the gap should remain visible in the cybersecurity case rather than disappearing behind a component qualification statement.

The decision

Define hardware assurance before supplier selection and design freeze. Require traceable provenance and verification for critical IP, document residual opacity in the TARA or equivalent risk argument, and use architectural isolation or wrappers as explicit compensating controls when full component transparency is unavailable.

Operational checks

Identify ASIC functions whose compromise could invalidate product-security or safety assumptions.
Map third-party IP, EDA tooling and manufacturing dependencies to their evidence owners.
Define provenance, version, change-notification and security-evidence requirements contractually.
Document where supplier opacity remains and which architectural controls bound its authority.
Trace hardware assumptions into the product TARA, cybersecurity concept and verification plan.
Retain evidence that the delivered silicon configuration matches the assured baseline.

Source record