There's a satisfying story that the security industry likes to tell about modern computers. It goes like this: your machine boots, the TPM measures everything, Secure Boot verifies the chain, and by the time your OS loads, you have cryptographic proof that nothing has been tampered with. Clean. Mathematical. Safe.
The story is mostly true. It's also built on a foundation you're not allowed to inspect.
Every security model has a bottom — a layer that everything above it trusts unconditionally, not because it's been verified, but because there's nothing beneath it left to do the verifying. On paper, that layer is the TPM. In practice, the TPM doesn't come online until well after your processor has already been executing code for several seconds. Code running in layers you didn't write, can't read, and in some cases can't even meaningfully audit.
This is the rabbit hole. Welcome to it.
What "Root of Trust" Means
Before examining where the root of trust actually lives on a modern PC, it helps to be precise about what the term means — because it gets used loosely enough that the underlying concept sometimes gets lost.
In security architecture, a root of trust is the first component in a system that must be assumed trustworthy without external verification. Everything above it can be checked. The root of trust itself cannot be, by definition — there is no prior layer with the authority or visibility to do so. This is not a flaw in the design; it is an inherent property of any chain of trust. Every chain has to start somewhere.
The practical implication is that a root of trust is not merely the most trusted component in a system. It is the component whose compromise would silently invalidate every security guarantee built above it. A corrupted link higher in the chain can, in principle, be detected. A corrupted root of trust can make detection impossible, because the very mechanisms used to detect tampering are themselves downstream of it.
In a typical PC boot sequence, the chain looks roughly like this:
CPU executes firmware
↓
Firmware measures bootloader
↓
Bootloader measures kernel
↓
Kernel unlocks diskEach stage vouches for the next. The TPM serves as the cryptographic ledger — recording measurements at each transition so that a later audit can confirm the chain was clean. In most security documentation, the TPM is described as the root of trust for this reason.
The problem, as the following sections will explore, is that this description is incomplete. The chain shown above does not begin at the firmware. It begins considerably earlier.
The Real Boot Sequence
The boot diagram that appears in most platform security documentation is accurate as far as it goes. The issue is how much it omits from the beginning.
The sequence typically shown starts with firmware. What it leaves out is everything that has already happened by the time firmware begins executing. A more complete picture of a modern PC boot looks like this:
CPU internal ROM
↓
CPU microcode
↓
Platform firmware (UEFI)
↓
TPM measurements begin
↓
Bootloader
↓
KernelThe critical observation here is not subtle: the TPM does not exist as an active participant when the processor first starts executing code. It comes online later, after the firmware has already initialized hardware, configured memory, and established the environment in which everything else will run. By the time the TPM begins recording measurements, multiple prior stages have already completed — unobserved and unattested by the very component that is supposed to anchor system integrity.
This is not an oversight in TPM design. The TPM is a discrete component with a defined role, and it performs that role well. But its measurements can only reflect what it is told by the firmware layer handing off to it. If something earlier in the sequence has manipulated the environment — or the measurement process itself — the TPM has no independent means of knowing.
Understanding this gap is the foundation for everything that follows. The sections ahead examine each of those earlier layers in turn: what they do, what visibility you have into them, and why their position in the boot sequence makes them more architecturally significant than the TPM they precede.
The Hidden First Stage — CPU Microcode
Modern processors do not execute the instruction set they advertise directly in hardware. Between the instructions your software issues and the transistors that carry them out sits an additional layer: microcode.
Microcode is firmware that runs inside the processor itself. Its primary function is translation — converting the complex, high-level instructions of an architecture like x86 into simpler internal operations the physical hardware can execute. Beyond that core function, microcode also implements hardware errata fixes, applies security mitigations, and manages low-level processor behavior that would be impractical or impossible to handle in silicon alone. When Intel or AMD release a patch for a speculative execution vulnerability, they are, in most cases, shipping a microcode update.
This layer has several properties that are relevant to any discussion of trust.
First, it executes before everything else. Microcode is initialized from the processor's internal ROM at power-on, before any external firmware is loaded. Updates to microcode are applied during the early boot process, meaning the processor's effective behavior can be modified on each boot cycle.
Second, it is opaque. Microcode is proprietary and not publicly documented at the implementation level. Independent verification of what a given microcode version actually does is not a realistic option for most organizations, and even for well-resourced researchers it is an exceptionally difficult undertaking.
Third, it operates with absolute privilege. Because microcode mediates every instruction the processor executes, a modification at this level could, in principle, alter memory contents, intercept cryptographic operations, or interfere with the measurement process before the TPM has any opportunity to observe it.
The trust chain, followed to this point, now reads:
TPM trusts firmware
↓
Firmware trusts CPU behavior
↓
CPU behavior is defined by microcode
↓
Microcode trusts nothing above itThat last line is the point. Microcode is not paranoia — it is architecture. It exists because modern processors require it. But its position at the base of the execution stack means that the integrity of everything above it is contingent on the integrity of something most practitioners never directly consider.
Why Researchers Are Concerned About Microcode
The properties described in the previous section — opacity, early execution, and absolute privilege — would draw scrutiny to any software component. That they describe something operating at the base of every modern PC's execution stack is what makes microcode a recurring subject of serious security research.
The concern is not primarily that microcode has been weaponized in any widely documented, real-world attack against consumer hardware. It is that the architecture creates a class of vulnerability that conventional security tooling is structurally blind to.
Consider what a malicious or compromised microcode update could theoretically accomplish. Because microcode mediates instruction execution, it could selectively misreport memory contents — returning expected values to integrity-checking routines while serving different data to the rest of the system. It could intercept or weaken cryptographic operations at the point of execution, before results are passed back to software. It could manipulate the measurement values that firmware hands to the TPM, ensuring that a compromised environment produces a clean attestation. Each of these possibilities shares a common characteristic: the interference would occur below the visibility horizon of any software-based detection mechanism, because those mechanisms depend on the same instruction execution layer they would be attempting to audit.
It is worth being direct about the threat model here. Delivering a malicious microcode update requires either compromising the CPU vendor's signing infrastructure or gaining the level of system access needed to deploy unofficial microcode — neither of which is a trivial capability. AMD and Intel both cryptographically sign microcode updates, and processors verify those signatures before applying them. This is a meaningful and important control.
What it means, however, is that the security of the entire platform is partly contingent on the integrity of CPU vendor signing keys and the internal processes that protect them. For most organizations, that is an acceptable dependency. It is simply worth being clear-eyed that it is a dependency — one that sits below the layer most security documentation begins its analysis.
The practical takeaway for practitioners is not to treat microcode as an active threat vector in routine threat modeling. It is to understand that when security documentation describes the TPM as the root of trust, that description reflects a defined architectural role, not an absolute claim about where trust ultimately originates.
Firmware as a Trust Anchor
Sitting just above microcode in the boot sequence, and significantly more accessible to attackers, is platform firmware. On virtually all modern PCs this means UEFI — the Unified Extensible Firmware Interface — which replaced the legacy BIOS standard and brought with it a substantially expanded attack surface.
Firmware's role in the boot process is extensive. Before the operating system loads, UEFI is responsible for initializing hardware, configuring memory, enumerating PCI devices, establishing the runtime environment, and ultimately handing control to the bootloader. It is, in functional terms, a small operating system that runs before your operating system — with broad hardware access and no OS-level security controls above it to impose constraints.
From a security perspective, this creates a position of considerable structural power. Firmware that has been compromised can interact with hardware directly, before any OS-level monitoring is active. It can manipulate the values passed to the TPM during the measurement phase, presenting a record of a clean boot while the actual environment has been altered. It can inject code into the kernel loading process. It can intercept disk encryption keys at the point where the OS requests them. And because it operates below the OS, none of these actions are visible to the endpoint detection tools, integrity monitors, or audit logs that would catch the same behavior higher in the stack.
There is also the persistence question. Firmware lives on a dedicated flash chip on the motherboard, entirely separate from the system's storage drives. This means that an attacker who achieves firmware persistence survives OS reinstallation. It means they survive drive replacement. In some cases they survive firmware update procedures, depending on how the update mechanism is implemented and whether the malicious modification has been designed to reapply itself.
This is not a theoretical concern. Firmware-resident malware has been documented in the wild, deployed by sophisticated threat actors against real targets. The next section examines those cases directly.
Firmware Attacks in the Wild
The threat model outlined in the previous section is not speculative. Firmware-resident malware has been documented, analyzed, and attributed to real threat actors operating against real targets. Two cases in particular are worth examining in detail, both because of what they accomplished and because of what they demonstrated about detection and remediation.
LoJax, discovered and documented by ESET researchers in 2018, was the first publicly confirmed UEFI rootkit observed in active use. It was attributed to APT28, the Russian state-sponsored threat group also known as Fancy Bear. LoJax worked by modifying the UEFI firmware stored on the target system's SPI flash chip, embedding a malicious module that would execute each time the machine booted. That module's function was persistence — ensuring that the group's remote access tooling would be reinstalled on the operating system even if the victim detected the infection and wiped the drive. Because the malicious code lived in firmware rather than on the OS partition, a full OS reinstall changed nothing. The implant simply rewrote what it needed on the next boot.
MoonBounce, reported by Kaspersky researchers in early 2022, represented a technical escalation from LoJax. Where LoJax added a new module to UEFI firmware storage, MoonBounce modified an existing component of the UEFI firmware itself — specifically the CORE_DXE module, which is loaded early in the boot process and present in essentially all modern UEFI implementations. Attribution pointed to APT41, a Chinese state-sponsored group. The modification was subtle enough that it had apparently persisted on the targeted system through at least one firmware update cycle, suggesting the implant was designed with update survival in mind.
Both cases share instructive common characteristics. Neither was detectable by conventional endpoint security tools. Neither was remediated by reinstalling the operating system. Both required firmware-level analysis to discover and firmware reflashing to remove — and in both cases, the affected organizations likely had no indication anything was wrong during the period of active compromise.
The practical implication for security practitioners is that firmware integrity verification cannot be treated as a solved problem by virtue of Secure Boot being enabled. Secure Boot validates what loads from firmware. It does not validate the firmware itself during normal operation. Detecting firmware compromise requires dedicated tooling, firmware measurement baselines established before compromise occurs, and in many environments, hardware-level controls that most organizations have not implemented.
Intel's Management Engine and the Ring -3 Problem
For systems built on Intel processors, the firmware and microcode layers described in previous sections do not represent the bottom of the privilege hierarchy. Below them sits an additional subsystem that predates the main CPU's boot process entirely: the Intel Management Engine.
The Management Engine — ME — is a separate microcontroller embedded within the Intel Platform Controller Hub, integrated directly into the chipset. It runs its own dedicated operating system, historically based on MINIX, on its own processor core. It has direct access to system memory via DMA. On platforms with vPro support it has network access, operable even when the main system is powered off, provided the machine has standby power. It operates independently of the main CPU and is not under the control of the operating system running on it.
Crucially, the Management Engine initializes before the main processor begins its boot sequence. This means it is active, with full hardware access, before microcode loads, before UEFI executes, before TPM measurements begin, and before any component the OS or security stack will ever interact with has come online.
Security researchers have used the informal designation "ring -3" to describe this privilege level — a sardonic extension of the processor privilege ring model, which bottoms out at ring 0 for the OS kernel. Hypervisors operating below the kernel occupy what some frameworks call ring -1. Firmware sits at ring -2. The Management Engine, operating on entirely separate hardware with independent memory access before any of these layers exist, occupies a category that the conventional model has no clean place for.
The full control hierarchy on an Intel platform looks like this:
Intel Management Engine
↓
CPU microcode
↓
Platform firmware (UEFI)
↓
TPM measurements begin
↓
Hypervisor (if present)
↓
Operating system kernel
↓
UserspaceAMD platforms have a comparable subsystem, the Platform Security Processor, with a similar architectural position and similar implications.
The ME has been the subject of sustained scrutiny from the security research community. In 2017, a critical vulnerability in the Management Engine's firmware was disclosed — CVE-2017-5689 — affecting a broad range of Intel platforms and allowing unauthenticated remote access via the AMT interface on vulnerable systems. The vulnerability required a firmware update to remediate, as no OS-level patch could address something operating at that layer. Researchers at Positive Technologies subsequently demonstrated methods for executing unsigned code within the ME environment, further illustrating that the subsystem's isolation from the main OS does not translate to isolation from compromise.
The existence of the Management Engine is not, in itself, a security failure. It serves legitimate platform management functions that enterprise environments depend on. The relevant observation for this discussion is architectural: any security model that describes the TPM as the foundational trust anchor is implicitly treating the Management Engine, and the layers beneath it, as out of scope. For most threat models, that is a defensible simplification. It is worth understanding that it is a simplification.
The Security Paradox
The preceding sections have traced the actual chain of execution on a modern PC from the bottom up — Management Engine, microcode, firmware, TPM, bootloader, kernel. Each layer depends on the integrity of the one below it. None of those lower layers can be verified by the TPM that is nominally responsible for anchoring system trust. This creates a structural tension that is worth stating plainly before examining why it does not, in practice, render TPM-based security meaningless.
The paradox is this: the TPM is designed to provide cryptographic assurance that a system booted with its configuration intact and untampered. To do this, it records measurements of each stage in the boot process. But those measurements are reported to the TPM by the firmware layer — the same firmware layer whose integrity the TPM is supposed to be helping guarantee. If the firmware has been compromised, it controls both the environment being measured and the measurement process itself. A TPM receiving falsified measurements from compromised firmware will produce attestation results that appear entirely clean. The instrument designed to detect the problem is downstream of the problem.
Follow the dependency chain to its conclusion and the trust hierarchy resolves to this:
CPU vendor integrity
↓
Firmware vendor integrity
↓
TPM measurement accuracy
↓
Secure Boot enforcement
↓
OS security
↓
Application securityWhat this means is that the security guarantees available to an operating system or application ultimately rest not on cryptographic proofs alone, but on the institutional integrity of chip manufacturers, firmware vendors, and the supply chains that connect them to the hardware in a given machine. Cryptography can verify a signature. It cannot verify that the component presenting that signature is behaving as its documentation describes.
This is not unique to computing. Every security architecture has a layer at which verification stops and trust begins. The relevant question is not whether such a layer exists — it always does — but whether its position is well understood, whether the assumptions it requires are explicit, and whether the threat actors relevant to a given environment have the capability to operate at that depth.
For the overwhelming majority of organizations, the answer to that last question is no. The practical consequence of this paradox is not that TPM-based security is compromised. It is that its guarantees are scoped — strong against the threats they were designed to address, and structurally silent about a class of threats that require capabilities far beyond what most adversaries possess.
That distinction is the subject of the next section.
Why This Is Still Acceptable
A security model with acknowledged gaps at its foundation might appear, on first reading, to be a security model with a serious problem. The argument here is the opposite: understanding where the gaps are is precisely what makes a security model useful. A system whose limitations are well-characterized can be deployed appropriately. One whose limitations are poorly understood tends to be either over-trusted or dismissed — both of which produce worse security outcomes than an accurate assessment.
TPM-based platform security, evaluated against the threats that actually face most organizations, remains a robust and well-justified architectural choice. The reason comes down to the practical requirements of attacking the layers beneath it.
Compromising CPU microcode in a meaningful way requires either penetrating a CPU vendor's signing infrastructure — a target protected by some of the most mature security programs in the industry — or finding and exploiting a vulnerability in the signature verification process itself. Compromising firmware to the degree demonstrated by LoJax and MoonBounce required the resources, access, and technical depth of nation-state intelligence operations. These are not capabilities available to the ransomware groups, opportunistic intrusion operators, and commodity malware campaigns that constitute the realistic threat environment for the vast majority of organizations. For those threat actors, a properly configured system with TPM-backed measured boot, Secure Boot enforcement, and full disk encryption presents a barrier that is, for practical purposes, insurmountable by attacks targeting the boot stack.
The attacks that TPM-based security is designed to defeat are also the attacks most commonly attempted. Physical theft of hardware. Offline attacks against encrypted storage. Bootloader tampering by an attacker who has gained OS-level access and is attempting to establish persistence below it. Evil maid attacks against unattended hardware. These are documented, recurring, operationally relevant threats — and TPM-based platform integrity controls address them effectively.
The appropriate framing is therefore not "TPM security is undermined by deeper layers" but rather "TPM security operates within a defined scope, and that scope covers the relevant threat landscape for most environments." Security architecture is always a function of threat model. An organization whose threat model genuinely includes nation-state adversaries with firmware implantation capabilities needs additional controls beyond what a TPM provides — and those controls exist, which the following section addresses. For everyone else, the TPM represents a well-engineered, cryptographically sound control at exactly the layer where practical attacks occur.
Acknowledging the layers beneath the TPM is not an argument against using it. It is an argument for understanding what you are using it for.
What High-Security Systems Do
For environments where the threat model extends beyond commodity attackers — critical infrastructure, defense contractors, intelligence-adjacent organizations, high-value research institutions — the architectural gaps described in this article are not academic concerns. They are operational risks that require deliberate mitigations. A mature set of approaches has developed around this problem, ranging from measurement and attestation practices to fundamental changes in the firmware stack itself.
Measured Boot with Remote Attestation
Measured boot, on its own, records what happened during the boot sequence. Remote attestation takes that a step further: the TPM's measurements are transmitted to an external attestation server, which compares them against a known-good baseline and makes an access decision before the endpoint is permitted to connect to sensitive resources. This architecture means that a device whose boot measurements deviate from baseline — whether due to firmware modification, bootloader tampering, or any other change — is flagged and potentially quarantined before it reaches the network. The limitation, consistent with everything discussed in previous sections, is that the measurements themselves originate from firmware. Attestation is only as reliable as the measurement process that feeds it.
Firmware Integrity Monitoring
Some organizations implement dedicated tooling to periodically read and hash the contents of firmware flash storage and compare results against verified baselines. This does not prevent firmware compromise but can detect it — provided the baseline was established on a clean system and the monitoring process itself has not been compromised. Hardware-based implementations of this approach, where the firmware flash is read by a separate trusted component rather than by software running on the main CPU, are more reliable than software-only equivalents for reasons that should be apparent from the preceding discussion.
Open Firmware Stacks
Projects such as coreboot, and the Heads firmware project built on top of it, address the opacity problem at its source by replacing proprietary UEFI firmware with open, auditable alternatives. Where conventional UEFI is a closed binary whose behavior must be taken on trust, coreboot is fully source-available and, for supported platforms, reproducibly buildable — meaning an organization can verify that the firmware running on their hardware corresponds to a specific, reviewed codebase. Heads extends this with a measured boot implementation designed around tamper-evident transparency rather than simply blocking unauthorized changes. These projects are not drop-in solutions for enterprise environments and support a narrower range of hardware platforms than proprietary firmware, but they represent the most technically thorough response currently available to the firmware trust problem.
Reproducible Builds
The principle of reproducible builds — ensuring that a given source codebase, compiled under defined conditions, always produces a bit-for-bit identical binary — matters here because it enables independent verification of the software supply chain. If firmware, bootloaders, and kernels can be reproducibly built and their hashes publicly verified, then compromise introduced during the build or distribution process becomes detectable. The Debian project and others have made significant progress on reproducible builds for OS components; firmware reproducibility remains more limited but is an active area of development.
Physical Security and Hardware Controls
At the highest sensitivity levels, physical controls remain an essential complement to software-based integrity measures. Tamper-evident seals, chassis intrusion detection, hardware security modules for key storage, and physically controlled hardware provisioning pipelines all serve to raise the cost of the supply chain and physical access attacks that the deeper architectural vulnerabilities depend on. Some high-assurance environments also implement hardware-based write protection for firmware flash, making firmware modification impossible without physical disassembly regardless of software-level access.
Taken together, these approaches do not eliminate the fundamental dependency structure traced in this article. They compress the attack surface at each layer, increase the detection probability for compromise that does occur, and raise the practical cost of exploitation to levels that defeat all but the most capable and motivated adversaries. In high-stakes environments, that is the realistic objective — not the elimination of trust assumptions, but their reduction to a minimum and their explicit acknowledgment.
The Slightly Unsettling Truth
Security documentation tends toward completeness within its defined scope and silence about what lies outside it. This is a reasonable editorial choice in most contexts — a practical guide to TPM configuration does not need to address transistor-level hardware trojans. But it does produce a cumulative effect in which the picture presented to practitioners is more self-contained and more certain than the underlying architecture actually warrants. This article has attempted to fill in some of what is typically left out. It is worth being direct about what that picture looks like when assembled.
Every modern PC operates on a stack of components, each trusting the one below it, bottoming out at layers that cannot be independently verified by the system running on top of them. The TPM is a well-designed and genuinely useful component occupying a specific position in that stack — not the bottom. Below it sit firmware, microcode, and in Intel and AMD platforms, dedicated management subsystems with hardware-level access and independent execution environments. Below those, if one follows the chain to its logical conclusion, sits the chip fabrication process itself — the physical implementation of the hardware whose behavior everything above it depends on. Supply chain integrity at the silicon level, including the theoretical possibility of hardware trojans introduced during fabrication, is an active area of research in high-assurance computing and a documented concern in sensitive government procurement. It is also well outside the scope of what any software or firmware control can address.
A remark sometimes attributed to the security research community captures the practical upshot concisely: Secure Boot means you know who compromised your system. The observation is sardonic but not dismissive — it correctly identifies both the value and the scope of the control. Secure Boot meaningfully constrains the attacker population. It does not constrain attackers operating beneath it.
The reassuring counterpoint, and it is a genuine one, is that the depth of access required to exploit these lower layers scales inversely with the size of the attacker population capable of attempting it. Microcode compromise at scale requires capabilities that exist in perhaps a handful of organizations worldwide. Firmware implantation at the sophistication of MoonBounce has been documented in targeted operations against specific high-value entities, not in broad campaigns against general enterprise environments. The gap between what is theoretically possible at these layers and what is operationally relevant for most organizations remains very wide.
What changes when you understand the full stack is not your immediate security posture. What changes is your clarity about what your security posture is actually guaranteeing — and where, if your threat model ever requires it, the next layer of work begins.
Supplement: Below the Silicon — Fabrication, Supply Chain, and the Limits of Verification
The chain of trust examined in this article has, at each stage, resolved downward to something smaller, more opaque, and harder to verify. Microcode sits beneath firmware. Management subsystems sit beneath microcode. At the bottom of that descent sits something that no software tool, no attestation server, and no open-source firmware project can address: the physical hardware itself, and the process by which it was manufactured.
This is not a commonly discussed layer in enterprise security literature, and for operational purposes in most environments it does not need to be. But for a complete account of where trust ultimately originates in a computing platform, the fabrication layer cannot be ignored. Some researchers argue, with technical justification, that it is the only genuine root of trust — the point at which the behavior of everything above it is permanently and irrevocably determined.
What Fabrication-Level Compromise Looks Like
A hardware trojan, in the research literature, refers to a malicious modification introduced into an integrated circuit during the design or fabrication process. Unlike software malware, which must be delivered after manufacture and leaves forensic traces in the software environment, a hardware trojan is expressed in the physical structure of the chip itself — in the arrangement of transistors and logic gates that implement the circuit's behavior. It executes not as code but as physics.
The range of possible implementations is broad. At the simple end, a hardware trojan might be a small additional circuit that monitors for a specific trigger condition — a particular instruction sequence, a date, an external signal — and alters the chip's behavior when that condition is met. At the sophisticated end, it might involve subtle modifications to existing logic that create statistical biases in cryptographic output, weaken random number generation, or introduce timing vulnerabilities exploitable only under specific conditions. Because the modification exists in silicon rather than software, it produces no binary artifact to scan, no file to hash, and no process to observe.
The Research Basis
Academic work on hardware trojans is well-established. Karri, Rajendran, Rosenfeld, and Tehranipoor, ("Trustworthy Hardware: Identifying and Classifying Hardware Trojans", published October 2010 in IEEE Computer), in a paper frequently cited as foundational in the field, systematically characterized trojan types, trigger mechanisms, and detection challenges. DARPA's Trusted Integrated Circuits program, launched around the same period, represented the U.S. government's formal acknowledgment that fabrication-level integrity was a national security concern requiring active research investment. The program produced a body of work on hardware verification techniques and supply chain assurance that continues to inform procurement policy for sensitive systems.
In 2012, researchers at the University of Cambridge published a paper claiming to have identified a potential backdoor mechanism in a specific military-grade FPGA manufactured by Microsemi, accessible via a previously undocumented interface. The claim was contested, and subsequent analysis suggested the feature in question was more plausibly an unintentional design artifact than an intentional backdoor. The episode was instructive regardless of its resolution: it demonstrated both that hardware-level anomalies of this type can exist in production silicon and that definitively distinguishing intentional backdoor from design error is, in practice, extremely difficult.
Why Verification Is So Hard
The verification problem at the fabrication layer is qualitatively different from software verification, and harder in ways that do not yield to straightforward engineering solutions.
A modern processor contains tens of billions of transistors. Physically inspecting a chip at the transistor level requires destructive delayering — chemically removing successive layers of the die and imaging each one with an electron microscope. This process destroys the chip being inspected, requires specialized equipment, consumes significant time, and even then covers only the specific unit examined. Statistical sampling across a production batch is possible but provides probabilistic rather than certain assurance, and a sufficiently targeted modification in a sufficiently large design space may not appear in any sampled unit.
Non-destructive verification techniques exist and are an active area of research — side-channel analysis, functional testing, formal verification of hardware designs — but each has limitations. Side-channel analysis can detect behavioral anomalies but cannot always localize or characterize their source. Functional testing can only cover states that the test designer anticipates. Formal verification of hardware designs addresses the specification-to-layout correspondence but cannot by itself verify that the manufactured device matches the verified design.
The asymmetry between attack and defense is significant. Introducing a subtle modification into a billion-transistor design requires access to the fabrication process at one point in a complex supply chain. Detecting that modification requires comprehensive inspection of the physical artifact after the fact, against a verification problem that scales with the complexity of the device.
The Supply Chain Dimension
Modern semiconductor fabrication is geographically and organizationally distributed in ways that compound the verification challenge. The design of a processor chip typically originates with one company. The physical fabrication is contracted to a foundry — often in a different country — that manufactures the wafers. Packaging and testing may occur at additional facilities. Each transition in this chain represents a point at which an adversary with sufficient access could potentially introduce modifications, whether through compromise of a specific facility, manipulation of design files in transit, or influence over a fabrication process.
This is not a theoretical concern in policy circles. Export controls on advanced semiconductor manufacturing equipment, restrictions on technology transfer, and ongoing debates about the security implications of geographic concentration in leading-edge chip fabrication all reflect governmental acknowledgment that the supply chain for computing hardware has strategic security dimensions that extend well beyond what any software or firmware control can address.
What High-Assurance Environments Do
For the small set of applications where fabrication-level integrity is a genuine operational requirement — certain defense and intelligence systems, nuclear command and control infrastructure, cryptographic key generation for critical national systems — mitigations exist, though none are complete solutions.
Trusted foundry programs, such as the U.S. Department of Defense's Trusted Foundry program administered through DMEA, attempt to establish chain-of-custody assurance for the fabrication of sensitive components by restricting production to facilities that have been vetted and certified under controlled conditions. These programs reduce exposure to supply chain insertion but operate at significant cost and with limited throughput, making them impractical for general commercial use.
Custom silicon developed with security as a primary design objective — where the chip designer also controls or closely audits the fabrication process — represents the highest assurance posture currently achievable. Google's Titan chip, used for secure boot and cryptographic operations in their infrastructure, and Apple's Secure Enclave are examples of vertically integrated approaches to this problem, though neither was designed to address adversarial foundry compromise specifically.
For most organizations, and for most threat models, none of this is operationally relevant. The point of tracing the trust chain to the fabrication layer is not to suggest that general enterprise security planning should account for transistor-level trojans. It is to complete the picture honestly — to identify where the chain actually ends, and what the assumptions look like at that terminus.
The Honest Conclusion
Security is, at its foundation, a property of physical reality. Cryptographic protocols, firmware measurements, and attestation servers are abstractions built on top of hardware whose behavior is ultimately determined by physics and by the integrity of the human processes that produced it. Those human processes — design, fabrication, supply chain, distribution — are subject to the full range of pressures, incentives, and failure modes that affect any complex human undertaking.
The computing security stack is remarkably well-engineered at the layers most practitioners interact with. It rests, at its base, on trust in institutions, supply chains, and manufacturing processes that are not fully transparent and cannot be completely verified. For almost all purposes, that is an entirely acceptable foundation. It is worth knowing that it is, in the end, a foundation of trust rather than proof.
Sources Referenced
Boutin, Jean-Ian, Alexis Dorais-Joncas, Frédéric Vachon, Zuzana Hromcová, Tomáš Gardoň, and Filip Kafka. LoJax: First UEFI Rootkit Found in the Wild, Courtesy of the Sednit Group. White paper. Bratislava: ESET, September 2018. https://web-assets.esetstatic.com/wls/2018/09/ESET-LoJax.pdf.
Ermolov, Mark, and Maxim Goryachy. "How to Hack a Turned-Off Computer, or Running Unsigned Code in Intel Management Engine." Paper presented at Black Hat Europe, London, December 2017. https://blackhat.com/docs/eu-17/materials/eu-17-Goryachy-How-To-Hack-A-Turned-Off-Computer-Or-Running-Unsigned-Code-In-Intel-Management-Engine-wp.pdf.
Intel Corporation. "Intel Active Management Technology, Intel Small Business Technology, and Intel Standard Manageability Escalation of Privilege." Security Advisory INTEL-SA-00075. May 1, 2017. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00075.html.
Intel Corporation. "Intel Management Engine Critical Firmware Update." Security Advisory INTEL-SA-00086. November 20, 2017. https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html.
Karri, Ramesh, Jeyavijayan Rajendran, Kurt Rosenfeld, and Mohammad Tehranipoor. "Trustworthy Hardware: Identifying and Classifying Hardware Trojans." IEEE Computer 43, no. 10 (October 2010): 39–46. https://doi.org/10.1109/MC.2010.299.
Lechtik, Mark, Vasily Berdnikov, Denis Legezo, and Ilya Borisov. "MoonBounce: The Dark Side of UEFI Firmware." Kaspersky Securelist, January 20, 2022. https://securelist.com/moonbounce-the-dark-side-of-uefi-firmware/105468/.
Skorobogatov, Sergei, and Christopher Woods. "Breakthrough Silicon Scanning Discovers Backdoor in Military Chip." In Cryptographic Hardware and Embedded Systems — CHES 2012, edited by Emmanuel Prouff and Patrick Schaumont. Lecture Notes in Computer Science, vol. 7428, 23–40. Berlin and Heidelberg: Springer, 2012. https://doi.org/10.1007/978-3-642-33027-8_2.
United States. Defense Advanced Research Projects Agency. "Trusted Integrated Circuits (TRUST)." Program overview. Arlington, VA: DARPA, 2007. https://www.darpa.mil/program/trusted-integrated-circuits.
United States. Department of Defense. Defense Microelectronics Activity. "Trusted Supplier Program." Sacramento, CA: DMEA. https://www.dmea.osd.mil/trustedic.html.
Supplementary Project References
The coreboot Project. coreboot: Fast and Flexible Open Source Firmware. https://www.coreboot.org.
Heads Firmware Project. Heads: Measured Boot and Tamper-Evident Firmware for Laptops and Servers. https://osresearch.net.
Member discussion: