Where Trust Ends, And Assurance Begins

On August 25, the National Security Agency and the Department of War's Joint Federated Assurance Center Hardware Assurance Laboratories (JFAC HwA) published two technical reports on securing custom chips: an ASIC Best Practices Threat Catalog, and the first of three planned Level of Assurance reports, LoA1. Together they're the clearest public statement yet of how the government intends to think about hardware security once a chip's development spans more organizations than any single accreditation program can realistically cover.

Trust has a boundary

DoD Instruction 5200.44 already requires defense programs to use suppliers accredited through the Defense Microelectronics Activity's (DMEA) trusted-supplier program, covering design, aggregation, fabrication, packaging, and test. That requirement isn't going anywhere, and the new guidance says so explicitly.

What it adds is a plan for the parts trust doesn't reach. Accreditation isn't available for every step of every modern ASIC program, and the guidance is direct about what that means: unless the entire development and manufacturing effort runs through accredited trusted suppliers, programs need additional validation to confirm nothing was altered outside that boundary. Assurance, in this framing, is the separate and broader question of whether the resulting device can be trusted against real threats — a question that doesn't stop existing just because the trusted-supplier boundary does.

Eighteen ways in

The Threat Catalog organizes adversary compromise into eighteen categories spanning the full development and manufacturing lifecycle:

The point isn't the length of the list. It's the implication: an ASIC's integrity depends on every organization and handoff in that chain, not just the reputation of the fab that eventually stamps it out. A compromised EDA tool, a malicious edit buried in a flow script, and a tampered shipment in transit are all the same category of problem from a program's point of view — each one means the delivered device might not be the one that was designed.

Five questions before any mitigation

Rather than prescribing a fixed checklist for every chip, the LoA framework asks programs to characterize threats along five dimensions before deciding what to do about them:

LoA1 covers designs where a successful attack would meaningfully reduce, but not eliminate, a U.S. Government capability — threats defined by low cost and high payoff for the adversary. It's a mission-risk-first approach, not a mitigation-first one: programs are told to understand their own threat space before reaching for a control, and hitting LoA1 doesn't mean applying every safeguard everywhere. It means matching the safeguard to the threat.

What assurance actually looks like day to day

The most concrete part of the guidance is also the most operational. It describes a Protected Design Flow Environment: a development repository where engineers do their work, a separate production repository holding only reviewed and approved files, and a continuous-integration process that runs the actual implementation flow without human hands on the machine. Nothing reaches production without passing acceptance review first, and nothing already in production can be touched by a designer directly.

Layered on top of that: role-based access that keeps administrators, designers, and verification engineers from overlapping; documented review of every requirements document, every line of HDL, every script, and every piece of third-party IP before it's trusted; and a verification plan expected to hit full code coverage, run by people who didn't write the design being verified. Requirements documents are treated as the “golden model” the entire design gets checked against — which means protecting them from tampering matters as much as protecting the silicon itself.

None of this is exotic. Version control, code review, and continuous integration are standard practice in software engineering. What's notable is seeing them codified as the government's baseline expectation for how a custom chip should be built — with an explicit rationale that a comprehensive verification suite is one of the few things that can catch a malicious change that slipped past everything else.

What it doesn't cover, yet

The guidance is careful about its own edges. It applies to single-die, digitally designed parts — multi-chip modules, 3D packaging, and analog or mixed-signal designs are explicitly out of scope for now, though the authors note the guidance overlaps with them. Firmware and software running on the ASIC are out of scope entirely. Confidentiality, physical theft, and cost or schedule impacts are treated as separate concerns from assurance, even where the guidance acknowledges they intersect.

That's a reasonable place to draw a first line. It's also a visible one. As programs move further into chiplet-based and heterogeneously integrated systems, the gap between “this component is assured” and “this system built from several assured components is assured” is exactly the kind of question that tends to get addressed in report two or three of a series, not report one.

Why this reads differently outside defense programs

Nothing about this guidance requires a clearance to be useful. The chain it describes — requirements, EDA tooling, third-party IP, HDL, scripts, fabrication, test, packaging, delivery — is the same chain every commercial semiconductor program runs today, and the same one straining against counterfeit parts, IP leakage, and supply-chain concentration risk regardless of who the end customer is. What NSA and JFAC have done is give that chain a name, a threat catalog, and a repeatable structure for deciding what “secure enough” means for a given design.

That's worth sitting with regardless of your customer base. The underlying premise — that no single supplier, tool, or facility can be responsible for the integrity of a modern ASIC end to end — is becoming the default assumption for how chips get built, not just how they get protected.