Beyond Trusted: What the NSA’s New Guidance Means for Hardware Security

By Rambus Inc.

August 28, 2026

On August 25, 2026, the National Security Agency (NSA), working with the Joint Federated Assurance Center Hardware Assurance (JFAC HWA) laboratories, released two technical reports addressing intentional threats to application-specific integrated circuits during design and manufacturing: the “ASIC Best Practices Threat Catalog” and “Application Specific Integrated Circuit Level of Assurance 1 (LoA1) Best Practices”. The LoA1 report is the first of three planned reports intended to establish Levels of Assurance for custom microelectronic hardware. [1,2]

The release is commendable and significant not because it replaces the Department of War (DoW) existing Trusted microelectronics requirements but because it provides a detailed framework for addressing what happens when Trust cannot encompass the entire semiconductor lifecycle.

That distinction matters as DoW increasingly relies on a commercial semiconductor ecosystem spanning third-party intellectual property, electronic design automation tools, commercial foundries, packaging providers, suppliers, and globally distributed technology.

NSA’s guidance is important because it recognizes that reality while remaining squarely within existing DoD policy. It begins with the requirement to use accredited Trusted processes where they apply, then explains how programs should evaluate and mitigate lifecycle risks when those processes do not cover every activity, supplier, or technology needed for a given ASIC.

Trust and Assurance Are Not the Same Thing

The new guidance begins firmly within existing policy. It points programs to DoW Instruction 5200.44 and states that DoW programs must use processes and suppliers accredited through the Defense Microelectronics Activity trusted process unless a waiver is requested.

But the guidance also addresses an important practical reality: trusted processes or services may not always be available.

When that occurs, or when a program determines that additional validation is necessary, JFAC recommends additional mitigations. The report goes further: unless the entire ASIC development and manufacturing effort is conducted by accredited trusted suppliers, programs should use additional validation to identify and mitigate risk associated with lifecycle activities conducted outside the trusted process. [2]

The Trusted model establishes accredited processes and services across activities such as design, aggregation, fabrication, packaging and assembly, and test. It is supported by requirements governing the people, facilities, systems, and suppliers involved. Assurance addresses the broader question of how confidence in the resulting device is established against mission-relevant threats.

Where the trusted boundary ends, assurance does not end with it.

For DoW, that creates a path to use technologies and capabilities that cannot all practically reside inside one large, trusted ecosystem while still addressing risks created outside that boundary.

The Threat Surface Is the Semiconductor Lifecycle

One of the most useful aspects of the new guidance is the breadth of the threat model.

The report considers potential adversary compromise beginning with design requirements and extending through IT systems, EDA software, third-party IP, HDL, design scripts, netlists, foundry process-design information, physical design, tapeout, wafer manufacturing, test, personalization, dicing, packaging, delivery, and user documentation. [2]

That framing is important because even when trusted processes are used across design, fabrication, packaging, and other portions of the lifecycle, assurance still depends on understanding where threats can be introduced and whether the controls applied at each stage are sufficient for the mission.

A compromised third-party IP block presents a different threat from manipulation of an EDA environment, unauthorized modification of a design artifact, malicious changes during fabrication, or compromise during packaging and test. Each occurs at a different point in the lifecycle and may require different methods of prevention, detection, verification, or mitigation.

Assurance therefore cannot be reduced to the trustworthiness of a single supplier, facility, or process. It must consider the chain of technologies, processes, organizations, and people involved in turning requirements into a delivered device, and the threats and consequences relevant to each.

Start With the Threat, Not the Mitigation

Perhaps the most important idea in the guidance is also one of the simplest: programs must understand their own threat environment.

The report’s threat catalog provides a starting point, but NSA/JFAC places responsibility on government program offices and their performers to evaluate and understand their threat space and define appropriate protection. The guidance then provides multiple mitigation options so programs can tailor an approach to their needs. [2]

That is an important architectural principle.

Hardware assurance should not begin with a predetermined security technology and work backward to justify its use. It should begin with the mission. What functions are critical? What happens if the device is subverted? What adversary capabilities are relevant? Where can an adversary gain access? What would an effective attack require?

From there, programs can determine the assurance required and select technical and procedural mitigations appropriate to the risk.

The LoA construct makes that approach more systematic. For LoA1, the framework characterizes threats according to five factors: access, technology, investment, value of effect, and targetability. LoA1 applies to ASIC-based designs where system failure could meaningfully reduce a U.S. Government capability while essential operational capabilities would remain available. [1,2]

This is not an argument for less assurance. It is an argument for assurance commensurate with mission and threat.

The Security Boundary Includes More Than Technology

Another important aspect of the guidance is the attention it gives to the environment in which an ASIC is developed.

The report addresses assurance planning, acquisition considerations, third-party IP, EDA software, protected design-flow environments, role-based access controls, verification and test planning, design repositories, and acceptance criteria for design artifacts. [2]

That matters because a security boundary is not merely a physical boundary around a semiconductor facility or a server. It can include people: who has access to design information, who can modify an artifact, what privileges they possess, how changes are reviewed, how third-party IP enters the design, how tools are controlled, and how design integrity is maintained as it moves toward production.

The semiconductor itself is the end product of a much larger technical and human system.

Reducing the size of the boundary therefore does not mean ignoring those dependencies. It means understanding which dependencies exist and where verification, validation, monitoring, technical controls, and other assurance mechanisms can establish the necessary confidence and resilience.

The Commercial Semiconductor Ecosystem Makes This Increasingly Important

DoW does not operate independently of the commercial semiconductor industry. State-of-the-art microelectronics increasingly depend on commercial technologies, tools, IP, manufacturing capabilities, and suppliers distributed across a complex ecosystem.

The new NSA/JFAC guidance provides a practical framework for addressing that problem at the ASIC level: it identifies relevant threats and offers mitigation options across the development and manufacturing lifecycle.

That is particularly important for DoW because it allows the assurance discussion to begin with mission risk rather than with an assumption that every device, application, or lifecycle stage requires the same controls. Different missions, devices, threats, and consequences of compromise can require different protections.

And Then Comes Heterogeneous Integration

The guidance primarily addresses single-die packaged ASICs. It states that multi-chip modules, 3D packaging, and other ASIC configurations are outside its primary scope, although portions of the guidance may still apply. Firmware and software running on the ASIC are also outside its scope, and confidentiality is generally treated as a security concern rather than an assurance concern except where the two intersect. [2]

That scope provides an important foundation for ASIC assurance, and it could point toward the next challenge.

DoW systems are increasingly moving toward heterogeneous integration and chiplet architectures, where independently designed and manufactured components can be combined within a common package or system. Those components may come from different suppliers and foundries, use different process technologies, perform different functions, and carry different assurance characteristics.

Assuring each component remains essential. But component assurance alone cannot tell us whether the resulting system is secure.

When components are brought together, new boundaries are created. Components must identify and communicate with one another. Information and security state cross interfaces. One component may be allowed to access resources belonging to another. A security-critical component may sit beside a commercial accelerator developed for an entirely different threat environment.

Putting those components inside the same package does not make them secure. And it should not automatically make the package itself the security boundary.

That means the next question for hardware assurance is not simply how to apply today’s ASIC mitigations to every chiplet. It is how component-level assurance, security boundaries, security architecture, interfaces, and system behavior come together to establish confidence in a heterogeneous system.

NSA and JFAC’s new ASIC guidance provide an important foundation for answering that question.

It will be exciting to see the next steps and how the community builds on it.

This is the first in a series examining the evolution of hardware assurance as Defense moves toward assurance of increasingly heterogeneous microelectronics. The next article will examine how RAMP, RAMP-C, and SHIP helped establish the commercial and assurance foundations for heterogeneous Defense microelectronics—and why chiplet architectures can make security architecture a system-level solution from the beginning.

Explore Rambus IP:

• Programmable Root of Trust Family With DPA & Quantum Safe Cryptography
• 800G Multi-Channel MACsec Engine with TDM Interface
• ChaCha20 DPA Resistant Crypto Accelerator
• Embedded HSM Family (Root of Trust) - Automotive Grade ISO 26262 ASIL-B

References

[1] National Security Agency. NSA Releases Best Practices to Mitigate Threats in Development of ASICs. August 25, 2026.

[2] National Security Agency, Cybersecurity Directorate, and Joint Federated Assurance Center Hardware Assurance Laboratories. DoW Microelectronics: Application Specific Integrated Circuit Level of Assurance 1 Best Practices. Version 1.0, August 2026. U/OO/6055347-26, PP-26-3181.