NSA Issues New Security Blueprint To Protect Custom Chips From Supply-Chain Sabotage | #hacking | #cybersecurity | #infosec | #comptia | #pentest | #ransomware

The U.S. National Security Agency has released an extensive set of technical recommendations designed to prevent adversaries from secretly altering application-specific integrated circuits during their design, fabrication, testing, packaging and delivery.

Published on August 25, the new material addresses a security problem that is difficult to detect and potentially far more persistent than conventional malware: the deliberate insertion of malicious functionality into the hardware on which military, intelligence and other sensitive systems depend.

The release consists of two complementary documents: the 30-page ASIC Best Practices Threat Catalog and the considerably more detailed, 109-page ASIC Level of Assurance 1 Best Practices.

Together, the reports identify 18 categories of intentional compromise spanning the ASIC lifecycle and establish a baseline set of protections for chips whose failure or subversion could meaningfully reduce a U.S. government capability.

The NSA developed the guidance with the Department of War’s Joint Federated Assurance Center Hardware Assurance Laboratories, or JFAC HwA, which supports government programs with microelectronics vulnerability detection, analysis and remediation.

Unlike many cybersecurity publications that concentrate on protecting operational networks and software, the new reports move deeper into the technology stack. They examine how attackers could manipulate a chip before it enters service—including by corrupting design requirements, compromising engineering software, modifying third-party intellectual property, tampering with manufacturing processes or replacing devices while they are in transit.

“The reports explain the threats against ASICs and recommend mitigations to reduce risk,” the NSA said in its announcement.

An application-specific integrated circuit is a semiconductor designed to perform a particular function or set of functions. Unlike a general-purpose processor, which can execute many different applications, an ASIC is optimised for a defined workload.

That specialisation can deliver substantial advantages in performance, energy efficiency, size and reliability. ASICs are therefore used in communications systems, cryptographic equipment, signal processing platforms, sensors, artificial-intelligence accelerators, vehicles, industrial systems, weapons platforms and other mission-critical technologies.

The same characteristics that make custom chips valuable also make their integrity especially important. An unwanted function embedded in an ASIC cannot necessarily be removed with an antivirus scan or an operating-system update. If the modification exists in the manufactured circuitry, remediation may require replacing hardware, redesigning the component or producing an entirely new generation of chips.

A malicious change could remain inactive during ordinary acceptance testing and activate only after a particular sequence of inputs, at a predetermined time or under specific environmental conditions. Depending on the alteration, it could disable a system, corrupt calculations, weaken a security control, degrade reliability or provide an attacker with functionality that was never authorised by the designer.

The NSA’s threat catalog concentrates on intentional design deviations affecting digital, single-die ASICs. It considers the lifecycle from the creation of requirements through delivery and acceptance testing, while also accounting for attacks against the design environment and externally developed intellectual-property blocks.

According to the agency, malicious modifications generally seek to change intended behaviour, introduce new and unauthorised behaviour, prevent operation, or gradually degrade the chip’s performance and reliability.

One of the most important messages in the guidance is that hardware assurance cannot be reduced to monitoring the semiconductor foundry.

An ASIC passes through a long chain of processes before becoming a finished component. Engineers first define its requirements and architecture. Developers express its behaviour using a hardware description language. Electronic design automation tools transform that source material into lower-level circuit representations. Third-party intellectual-property blocks may be incorporated, while scripts automate essential parts of synthesis, verification and physical design.

The completed design is then prepared for tapeout, transferred for mask and wafer fabrication, tested, personalised, diced into individual dies, packaged, tested again and transported to the customer.

An adversary does not necessarily need to control the entire chain. Compromise at one sufficiently influential point may be enough to alter the final device.

The NSA’s Level of Assurance 1 model explicitly treats a single available point of access as potentially sufficient. Examples include an internet-connected design network, one compromised employee, personnel at a foreign office with access to part of the project, or individuals linked to a high-threat country who can reach a relevant portion of the supply chain.

The agency also warns that attacks at this level may not require secret or unusually sophisticated technology. Publicly available software, commercial design tools, legitimate debugging features, laboratory equipment and open-source projects could all be repurposed by an attacker.

This assessment mirrors a broader supply-chain concern identified by the National Institute of Standards and Technology. NIST says organisations frequently have limited visibility into how acquired technologies are developed, integrated and deployed, creating exposure to malicious functionality, counterfeit products and weaknesses introduced through inadequate development or manufacturing practices. Its SP 800-161 Revision 1 recommends integrating cybersecurity supply-chain risk management throughout enterprise governance, procurement and the technology lifecycle.

The threat catalog divides intentional ASIC compromise into 18 categories. These begin before engineers write the chip’s design and continue until the finished components and supporting documentation reach the customer.

The first category concerns compromised design requirements. If an adversary can change, remove or ambiguously define an essential requirement, the resulting chip may operate incorrectly even when engineers implement the altered specification perfectly. Manipulating requirements can be particularly difficult to identify because the malicious change may appear to be an authorised design decision.

The second category covers the compromise of information-technology systems used by chip developers. Design repositories, engineering workstations, build servers, authentication systems and shared infrastructure can provide a route for altering files or substituting malicious versions of legitimate project assets.

Electronic design automation software forms the third category. EDA products are fundamental to modern semiconductor development, automating complex processes such as simulation, synthesis, placement, routing and physical verification. A compromised tool or unauthorised update could introduce a modification downstream while leaving the original high-level design apparently intact.

The fourth threat concerns third-party intellectual property, commonly referred to as 3PIP. Modern chip teams frequently license reusable functional blocks rather than designing every component from the beginning. Those blocks may implement processors, memory controllers, interfaces, cryptographic functions or other complex capabilities. If an external IP block contains hidden behaviour, vulnerabilities or undocumented functionality, it can transfer that risk directly into the completed ASIC.

Additional categories address malicious changes to the hardware description language, automation scripts and netlists. The netlist describes the logical components of a design and their connections, making it a critical bridge between the original source code and the physical layout of the chip.

The catalog also considers compromise of the foundry’s physical design kit. A PDK contains process-specific data, models and design rules used to produce a chip for a particular manufacturing technology. Manipulating this information could affect how the design is transformed into manufacturable structures.

Other threats focus on changes to the physical design representation and attacks against tapeout—the point at which the completed design is finalised and sent for fabrication. If the material transmitted to the foundry differs from the design that engineers approved, the manufactured devices may contain circuitry that was absent from internal verification results.

The manufacturing portion of the catalog examines malicious modifications during wafer production, compromise of wafer or package testing, interference with device personalisation, manipulation during wafer dicing, tampering during packaging and intentional physical damage.

The final two categories address devices compromised during delivery and manipulated user documentation. Altered documentation could cause operators or system integrators to configure the chip insecurely, misunderstand its behaviour, disable protections or use a compromised operating procedure.

Taken together, the catalog presents hardware compromise as an end-to-end lifecycle risk rather than an isolated manufacturing problem.

The second report translates the threat catalog into a baseline protection framework called Level of Assurance 1, or LoA1.

The NSA and JFAC are developing three assurance levels for custom microelectronic hardware. Each level is tied to the national-security impact of a system’s failure or subversion and to the importance of the chip within that system.

LoA1 applies where the failure of an ASIC-based design could meaningfully reduce a U.S. government capability or cause harm to American personnel, property or interests, but where the Department would retain its essential operational capabilities.

This does not mean LoA1 is unimportant or intended only for low-risk commercial equipment. Instead, it concentrates on attacks that offer an adversary a relatively attractive balance of cost, opportunity and operational effect.

The model evaluates threats using five characteristics:

• Access considers how much access an adversary needs to conduct the attack.
• Technology measures the technical complexity and capabilities required.
• Investment evaluates the resources and cost needed to prepare and execute the operation.
• Value of effect assesses what the attacker could achieve.
• Targetability considers whether the effect can be predictably directed at a particular device, system or mission.

At LoA1, the assumed attacker may require only one point of access, publicly available technology and relatively limited investment. The resulting attack, however, could still disable or subvert an important capability and may be sufficiently controllable to target a specific system.

Higher assurance levels are intended for systems whose compromise would produce more severe national consequences. The newly issued document is the first ASIC-specific best-practices report in that planned three-level series.

The LoA1 report provides a substantial range of preventive and detective controls rather than proposing a single inspection tool capable of proving that a chip is trustworthy.

Among its core recommendations is the use of cleared personnel in appropriately controlled facilities for sensitive work. Where uncleared employees participate, programs are advised to use structured employment and access protocols.

Role-based access control should limit each employee, contractor and external party to the information and functions necessary for their duties. Repository access should be audited so programs can determine who reached design files and what changes were made.

The agency recommends placing important project material in version-control systems and preserving traceable records of changes. This can make unauthorised modifications easier to identify and allows investigators to compare the final design against previously reviewed versions.

Programs should authenticate software and deliverables with digital signatures and cryptographic hashes. A hash provides a mathematical fingerprint of a file; an unexpected difference can reveal that the file changed after approval or during transfer.

The guidance also calls for encryption of sensitive artifacts in transit, confirmation that foundries received the intended tapeout material, and verification of hashes on both sides of the transfer.

Design environments should be protected according to applicable government security requirements, including NIST SP 800-171 and enhanced safeguards described in SP 800-172 where appropriate. The NSA additionally advises against allowing design tools and third-party IP to perform automatic internet access or uncontrolled updates.

That recommendation reflects the unique risk profile of semiconductor development. An automatic update that would be routine in a general office application can be problematic in a controlled design flow if it silently changes the software used to generate or verify a chip.

Programs are advised to document and audit the exact EDA software versions used, investigate known vulnerabilities in engineering tools, avoid accepting unverified custom patches and protect design flows from unauthorised external communication.

The extensive treatment of third-party intellectual property reflects how dependent modern ASIC development has become on externally created components.

The NSA recommends negotiating assurance requirements before purchasing the IP. This can include access to the technical information, source material and testing evidence needed to evaluate the component.

Attempting to obtain those rights after a licensing agreement has been completed may be more expensive, contractually difficult or impossible. Consequently, hardware assurance is partly an acquisition and governance issue rather than something that can be delegated solely to engineers near the end of the project.

Programs should perform acceptance testing on third-party IP, research known vulnerabilities, verify hashes, prevent uncontrolled updates and examine whether the component behaves as documented.

The report also encourages government programs to reduce the number of external parties involved in development and manufacturing where possible, and to scrutinise the organisations that remain in the chain.

However, reducing supplier count does not eliminate risk. It instead decreases the number of trust relationships that a program must evaluate and continuously manage.

A central technical challenge in ASIC assurance is ensuring that the design remains consistent as it moves from one representation to another.

Engineers may begin with requirements and high-level source code, but fabrication ultimately depends on detailed physical data. Numerous automated transformations occur between those points. An attacker could modify an intermediate artifact without necessarily changing the source reviewed by the development team.

The NSA therefore recommends multiple forms of equivalence and consistency checking. These include verifying the relationship between the hardware description language and other design representations, applying linting checks, enforcing acceptance criteria, testing automation scripts and using high-coverage test suites.

The report refers to techniques such as logic-equivalence checking, layout-versus-schematic comparison and layout-versus-rule verification. These controls help determine whether successive versions of the design remain functionally consistent and whether the physical representation complies with expected structural rules.

Programs should also verify the final physical netlist and protect tapeout artifacts inside a secured design-flow environment.

These checks do not guarantee that every possible hidden function will be found. They nevertheless reduce the opportunity for an adversary to alter one stage while relying on the development team to validate a different representation.

The guidance extends beyond design verification into physical production and logistics.

It recommends device acceptance testing, direct verification of personalisation values where appropriate, testing of expected functions and behaviours, inspection of packaging for evidence of tampering and controlled procedures for storage and shipping.

Personalisation is especially important when a device receives unique configuration data, identifiers, cryptographic material or other settings after fabrication. Compromise at that stage could affect individual devices without requiring the attacker to alter the design shared across an entire production run.

Testing processes are themselves treated as potential targets. An adversary who controls or manipulates a test environment could approve defective or modified components, suppress evidence of malicious behaviour, or damage selected devices while allowing them to pass initial inspection.

Delivery introduces a separate substitution and tampering risk. A properly designed and manufactured chip could still be replaced, physically altered or mishandled before reaching the government program. Chain-of-custody controls, tamper evidence, authenticated records and acceptance testing therefore remain necessary after production has concluded.

The report connects its recommendations to the Defense Microelectronics Activity’s Trusted Supplier Program.

For applicable Category I services, using a DMEA-accredited trusted supplier is considered sufficient to mitigate LoA1 threats when an accredited service is available. Where the entire development and manufacturing process cannot be performed by accredited suppliers, the NSA recommends additional validation to determine whether tampering occurred outside the trusted environment.

This distinction is important because semiconductor production is highly globalised and specialised. A program may control the design but depend on outside companies for intellectual property, engineering tools, mask preparation, wafer fabrication, testing, packaging or logistics.

DARPA previously observed that the economics of the global semiconductor industry have made it difficult for defence and commercial organisations to manufacture advanced chips entirely within environments traditionally regarded as trusted. It has consequently promoted approaches that treat security as a design constraint alongside power, performance and physical area. DARPA has also warned that globalised supply chains create opportunities for the insertion of malicious circuitry and make post-manufacturing detection difficult because hardware Trojans can be designed to remain dormant during testing.

The NSA’s framework acknowledges that practical reality. Its answer is not to assume every external party can be removed, but to identify trust boundaries and add verification wherever complete control is unavailable.

The reports deliberately define a narrower scope than the entire field of semiconductor security.

They address intentional and malicious compromise, not ordinary engineering errors or accidentally introduced vulnerabilities. The principal focus is digital, single-die ASIC design and manufacturing.

Analog, mixed-signal, radio-frequency and optical designs are outside the stated scope. The guidance also does not specifically cover multi-chip modules, three-dimensional packaging or other assemblies containing multiple ASICs, although some recommendations may still overlap with those environments.

Printed-circuit-board assembly is excluded and handled through separate Navy guidance. Firmware and software running on the ASIC are also outside the document’s direct scope.

The reports do not comprehensively address theft of chips, theft of design information, unauthorised overproduction, theft of operational data, reverse engineering or confidentiality except where those issues intersect with hardware assurance. Programs are expected to manage several of those risks through separate protection and anti-tamper plans.

The document is also not a replacement for government policy. It is technical guidance intended to help programs conduct Trusted Systems and Networks analysis, develop repeatable assurance plans and select mitigations appropriate to their circumstances.

The NSA warns that achieving LoA1 should not be treated as a one-time certification that remains valid indefinitely.

Changes to software, suppliers, the host system, underlying technology or the threat environment can affect the assurance of an ASIC after its original evaluation. Newly discovered vulnerabilities in third-party IP or design tools may also alter the risk calculation.

Programs are therefore encouraged to revisit their assurance plans when significant changes occur and determine whether additional validation is necessary.

This lifecycle approach is consistent with NIST’s broader supply-chain risk-management model, which recommends incorporating supply-chain controls into research, development, manufacturing, acquisition, delivery, integration, operation and eventual disposal.

The release arrives as governments and industries become more dependent on specialised silicon for artificial intelligence, telecommunications, cryptography, autonomous systems and advanced sensing.

That dependence increases the potential impact of hardware compromise. A hidden modification in a strategically important ASIC could persist beneath operating systems, endpoint-security products and application-level monitoring. Investigators may initially interpret the consequences as a software defect, component failure or reliability problem rather than deliberate sabotage.

At the same time, custom-chip development routinely relies on globally distributed engineering teams, commercial EDA products, third-party IP and specialised manufacturing services. Each dependency can create a point at which integrity must be established rather than assumed.

The NSA’s new documents attempt to turn that complex problem into a structured assurance process. They map the attack surface across the ASIC lifecycle, rank threats according to access, sophistication, investment, effect and targetability, and connect those threats to concrete controls.

For government program managers and defence contractors, the central implication is that hardware assurance must begin when requirements are written—not after manufactured chips arrive for testing.

Organisations will need to incorporate assurance requirements into contracts, secure the systems used by chip designers, control access to design repositories, authenticate every important artifact, scrutinise third-party IP, monitor transformations between design stages and maintain traceability through fabrication, packaging and delivery.

No individual control can prove that a complex semiconductor is free of malicious functionality. The NSA’s strategy instead relies on layered safeguards that reduce opportunities for compromise and increase the likelihood that an unauthorised change will be detected before the affected hardware enters a mission system.

With LoA2 and LoA3 ASIC guidance still to come, the LoA1 publication establishes the foundation of a broader framework intended to scale protections according to the consequences of failure. For systems at the highest end of the national-security spectrum, those future reports are likely to demand stronger controls, greater independence in verification and more rigorous scrutiny of every participant in the chip supply chain.