up:: In the Protocols MOC

NIST SP 800-193

NIST SP 800-193, “Platform Firmware Resiliency Guidelines,” is a NIST Special Publication, published in May 2018, that tells platform and device makers how to build systems whose firmware can survive a destructive attack, through three capabilities working together: protecting firmware and its critical data from unauthorized change, detecting corruption when it happens, and recovering the device to a known-good state. All three rest on a hardware root of trust, a small, tamper-resistant component the rest of the system can rely on because it is built to always behave as expected and its misbehavior can’t be caught by anything above it.

The reason SP 800-193 lands in a post-quantum guide is the mechanism at its center. The document requires that firmware updates be authenticated with a digital signature, verified by a root of trust that holds a signature-verification algorithm and the publisher’s public key. Those signatures are the same classical, quantum-vulnerable code signing that Shor’s algorithm breaks, and because firmware roots of trust are burned into hardware that ships and then runs untouched for a decade or more, they are one of the first signing surfaces the transition has to move.

The short version:

1. SP 800-193 is a NIST Special Publication (guidance, not a mandatory FIPS) that sets voluntary guidelines for making platform firmware resilient to destructive attacks.
2. It’s built on three principles: Protection (keep firmware from being corrupted), Detection (notice when it has been), and Recovery (restore it to a known-good state).
3. Every capability is anchored in a root of trust: the Root of Trust for Update (RTU), the Root of Trust for Detection (RTD), and the Root of Trust for Recovery (RTRec), each of which can extend into a chain of trust.
4. The RTU authenticates firmware updates with a digital signature, holding a signature-verification algorithm and a key store with the publisher’s public key, and the document requires an approved algorithm from FIPS 186-4 at a security strength of at least 112 bits.
5. Those approved classical signatures (RSA, ECDSA) are exactly what a quantum computer forges, so the long-lived firmware roots SP 800-193 defines are a priority migration to conservative hash-based signatures (LMS and XMSS, SLH-DSA) per CNSA 2.0.

Think of a bank vault that also has to protect its own door mechanism. Protection is the hardened lock that keeps the wrong hands off the mechanism. Detection is the tamper sensor that trips if someone gets to it anyway. Recovery is the sealed compartment holding a spare, verified mechanism that can be swapped in when the sensor trips, so a sabotaged door doesn’t leave the vault permanently jammed. SP 800-193 is the blueprint for building all three into a computer’s firmware instead of a vault door. And the whole blueprint hangs on one trusted part that checks a signature before it accepts a new mechanism, which is exactly the part a quantum computer learns to forge.

What is NIST SP 800-193?

NIST SP 800-193 is a NIST Special Publication that specifies technical guidelines for the resiliency of platform firmware and its critical data against destructive attacks. Its full title is “Platform Firmware Resiliency Guidelines,” it was published in May 2018, and it was authored by Andrew Regenscheid of NIST. It sits in the Special Publication 800 series (NIST’s computer-security guidance line), which is a recommendation instrument rather than a Federal Information Processing Standard like FIPS 203. The guidelines are voluntary, targeted at developers and engineers at original equipment manufacturers (OEMs) and component suppliers who build the low-level firmware in clients, servers, and networking devices.

The problem it addresses is that firmware sits below the operating system and is highly privileged, so a successful attack on it can render a system inoperable, “perhaps permanently or requiring reprogramming by the original manufacturer,” which turns an ordinary compromise into destructive, hard-to-undo damage. To counter that, the document does three things: it defines what resilient firmware means, it organizes the requirement into three security principles, and it grounds every one of those principles in a root of trust. It expands on the older SP 800-147 BIOS Protection Guidelines by widening the scope from the BIOS to the broader set of firmware and configuration data across the whole platform.

Source: NIST, “Platform Firmware Resiliency Guidelines,” SP 800-193, May 2018, NIST SP 800-193.

What are the three principles of firmware resiliency?

SP 800-193 is organized around three principles that a resilient platform provides together: protection, detection, and recovery. The document states each one as a class of mechanisms, and it stacks them so that where protection can’t fully prevent an attack, detection and recovery can still discover and remediate it.

Principle	What it means	The mechanism
Protection	Keeping firmware code and critical data in a state of integrity, guarded from corruption	The authenticated update process that ensures the authenticity and integrity of every firmware update
Detection	Noticing when firmware code or critical data has been corrupted or changed from an authorized state	Verification of firmware against a known-good reference, anchored in the detection root of trust
Recovery	Restoring firmware code and critical data to a state of integrity once corruption is detected	Rebuilding from a protected backup image or a secure local update, anchored in the recovery root of trust

The document turns those three principles into three graded resiliency properties a platform can claim. A platform is Protected if all its critical devices meet the protection guidelines, Recoverable if they can also detect and recover from corruption, and Resilient if they meet all of the guidelines in the standard. “Critical platform devices” is a load-bearing phrase: it’s the set of devices needed to minimally restore and reasonably operate the system, and losing even one of them can render the whole platform permanently inoperable, so those are the devices that must be made resilient.

Source: NIST, “Platform Firmware Resiliency Guidelines,” SP 800-193, §3.1 and §3.2, May 2018, NIST SP 800-193.

What is a root of trust, and what are the RTU, RTD, and RTRec?

A root of trust in SP 800-193 is an element that forms the basis of one or more security-specific functions and that must always behave as expected, because its correct functioning is essential and its misbehavior can’t be detected by anything above it. It’s the anchor. A root of trust is typically the first element in a chain of trust, where each successive element is verified by an earlier one before it runs, so the small trusted anchor can extend into more complex functionality without extending the trust blindly. The document defines three roots of trust, one per principle, plus a chain of trust for each:

Root of trust	Acronym	Chain	What it’s responsible for
Root of Trust for Update	RTU	CTU	Authenticating firmware updates and critical-data changes before they’re applied
Root of Trust for Detection	RTD	CTD	Detecting when firmware or critical data has been corrupted
Root of Trust for Recovery	RTRec	CTRec	Recovering firmware and critical data when corruption is detected, or when an administrator forces it

A small naming detail matters for anyone reading the standard: the recovery root is written RTRec, not RTR, because RTR is already the conventional abbreviation for Root of Trust for Reporting in the Trusted Computing Group’s vocabulary, so NIST disambiguated. These are logical components rather than necessarily separate chips; in practice they often live inside the same low-level platform firmware and share hardware with one another. Some devices can’t host their own roots of trust at all, so SP 800-193 defines symbiont devices that lean on a host device to jointly meet the guidelines.

Source: NIST, “Platform Firmware Resiliency Guidelines,” SP 800-193, §3.3, §3.4, and §4.1, May 2018, NIST SP 800-193.

How does SP 800-193 authenticate a firmware update?

It requires an authenticated update mechanism that employs digital signatures, and this is the piece that connects the whole document to the quantum problem. The document’s central protection tenet is that only authentic and authorized firmware images may ever be applied to a device. An image is authentic when both its source and its integrity can be verified, and the verification runs through the RTU:

1. The RTU holds the verifier. The Root of Trust for Update contains a signature-verification algorithm and a key store that includes the public key needed to verify the signature on a firmware update image (or a hash of that public key, when the key travels with the image). The key store and the verification algorithm are stored in a protected way and can only change through an authenticated or secure-local update.
2. The image must be signed by an approved algorithm. SP 800-193 requires that firmware update images be signed using an approved digital signature algorithm as specified in FIPS 186-4, the Digital Signature Standard, with a security strength of at least 112 bits in line with SP 800-57 Part 1.
3. Verification happens before the update sticks. The digital signature of a new or recovery image must be verified by the RTU or its chain of trust before the update is committed to non-volatile storage, so an unverified image can never become the running firmware.
4. The signing key is a known single point of failure. The document explicitly flags that if the private key behind the key store is stolen, an attacker can sign malicious firmware the device will accept, which is why recovery from key compromise (key hierarchies, refreshing the key store during recovery) is part of doing this correctly.

That fourth point is the hinge. SP 800-193’s own threat model already treats “the attacker holds a valid signing key” as the catastrophic case, and a quantum computer is a way to reach that exact state without ever stealing anything.

Source: NIST, “Platform Firmware Resiliency Guidelines,” SP 800-193, §3.5 and §4.2, May 2018, NIST SP 800-193.

What firmware and devices does SP 800-193 cover?

SP 800-193 applies to any platform device that contains firmware, from the main system BIOS down to the controllers buried inside individual components, and that breadth is what makes firmware resiliency a whole-estate problem rather than a single-chip one. The document writes its guidelines for individual devices precisely so they generalize across the many independently manufactured components inside a modern machine. The devices it names or covers include:

1. The host platform firmware. The BIOS or UEFI and the boot firmware that brings the system up.
2. Storage controllers. The microcontroller and firmware inside a hard drive or SSD that runs the actual read and write operations.
3. Network and management controllers. Network interface controllers and baseboard management controllers, which have their own privileged firmware.
4. Power and low-level logic. Battery-management logic and firmware, and glue logic such as CPLDs and FPGAs.
5. Other embedded controllers. Any device with mutable firmware that plays a role in booting or operating the platform.

The consequence of that scope is the “weakest component” reality familiar from the rest of applied cryptography: a system is only as resilient as its least resilient critical device, because a single corrupted controller can brick the whole machine. It’s the firmware analogue of the rule that a protocol is only as quantum-safe as its weakest deployed endpoint, and it means a firmware-signing migration has to reach every device’s root of trust across the whole platform.

Source: NIST, “Platform Firmware Resiliency Guidelines,” SP 800-193, §3, May 2018, NIST SP 800-193.

Why is SP 800-193 a post-quantum problem?

Because the root of trust it builds everything on verifies firmware with a classical digital signature, and those signatures are forgeable once a quantum computer exists. SP 800-193 requires the approved signature algorithms of FIPS 186-4, which in practice means RSA and ECDSA. Both rest on math (integer factorization for RSA, the discrete logarithm problem for ECDSA) that a cryptographically relevant quantum computer running Shor’s algorithm solves efficiently. Shor’s algorithm takes the publisher’s public key, which the RTU key store already holds and every device already carries, and recovers the private signing key from it. At that point an attacker can sign firmware the RTU accepts as genuine, which is the precise “compromised private key” scenario SP 800-193 names as the disaster to guard against.

Three properties of firmware resiliency make this sharper than most signing surfaces:

1. The verifier is frozen in hardware. The RTU’s key store and verification algorithm are stored so they can only change through an authenticated update, and on many devices they’re effectively burned in for the service life of the hardware. A device shipped today may run untouched for ten or fifteen years, so its firmware root of trust has to stay unforgeable that entire time.
2. The attack needs nothing recorded. This is a forgery-side threat, not a harvesting one. Nothing is captured now to decrypt later; the attacker simply waits until the quantum computer exists, then forges a firmware update that every device in the field trusts. The material they need (the public key) is already public by design.
3. The blast radius is the platform itself. A forged firmware update sits below the operating system with total control of the machine and can be made destructive. Forging the signing key that underwrites a whole device population is close to arbitrary control over all of it, which is why the collapse of a signing root is the worst case for firmware.

The reason this is a present-day problem, even though the machine is years out, is Mosca’s theorem: the years a firmware signature has to stay trustworthy, plus the time it takes to re-key roots of trust and roll new verification code to devices already deployed, both have to fit before the quantum computer arrives. For firmware, both of those numbers are large, so the clock is already running.

Source: P. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Computing, 1997, quant-ph/9508027.

What replaces the signatures a firmware root of trust relies on?

The classical signatures that SP 800-193’s roots of trust verify get replaced with post-quantum signatures, and firmware is one of the few surfaces where the standards bodies point at the conservative hash-based family rather than the general-purpose lattice default. CNSA 2.0 names the stateful hash-based schemes LMS and XMSS specifically for signing software and firmware, and NIST standardized them early for exactly this job in SP 800-208.

Replacement	Standard	Basis	Fit for firmware roots of trust
XMSS	SP 800-208	Hash-based, stateful	The CNSA 2.0 named choice for firmware and software signing, done inside a hardware module where signing volume is low and trust is long-lived
SLH-DSA	FIPS 205	Hash-based, stateless	The same conservative hash foundation without the state-management hazard, at the cost of much larger signatures
ML-DSA	FIPS 204	Lattice	Higher-volume, general-purpose signing where compact, fast signatures matter more than a maximally conservative assumption

The pattern is that the deeper and longer-lived the trust, the more conservative the choice. A firmware root of trust is the longest-lived, lowest-volume, least-swappable signing in the estate, so it earns the hash-based family, whose security rests only on a hash function, the oldest and best-studied assumption in cryptography, with no algebraic structure for Shor’s algorithm to attack. The full mechanics of migrating firmware signing (the size increase, the hardware-signing requirement for the stateful schemes, and the sequencing) live in the code-signing note, since SP 800-193 is the guideline that requires the signature and code signing is the surface being migrated.

Sources: NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” September 2022, CNSA 2.0.

NIST, “Recommendation for Stateful Hash-Based Signature Schemes,” SP 800-208, October 2020, NIST SP 800-208.

Is SP 800-193 mandatory?

No. SP 800-193 is a set of voluntary technical guidelines, not a binding standard. It’s a NIST Special Publication rather than a Federal Information Processing Standard, so it functions as a recommendation and a design reference for platform and device makers rather than a compliance mandate in itself. Its guidelines are written in “shall” language that makes them a clear conformance target for a vendor that chooses to claim resiliency, but the document doesn’t compel anyone to adopt it.

In practice it carries real weight anyway. It’s a widely referenced baseline for platform-security procurement, it underpins how OEMs describe the resiliency of their firmware, and its root-of-trust model shaped later platform-security expectations. For the post-quantum question specifically, the binding deadlines don’t come from SP 800-193 at all; they come from the signing mandates it depends on. CNSA 2.0 sets an exclusive-use date of 2030 for software and firmware signing in national-security systems, the earliest in its schedule, and NIST IR 8547 disallows classical public-key signatures for federal use by 2035. Those are what put a clock on the signatures inside every SP 800-193 root of trust.

Source: NIST, “Platform Firmware Resiliency Guidelines,” SP 800-193, §1, May 2018, NIST SP 800-193.

Common misconceptions

1. “SP 800-193 is about encrypting firmware.” It isn’t. Its subject is integrity and authenticity, proving firmware wasn’t tampered with and came from an authorized source, plus recovering it when it’s damaged. Firmware isn’t secret; the risk it addresses is corruption and forgery, which is why the fix is a stronger signature rather than encryption.
2. “It only covers the BIOS.” SP 800-193 deliberately widened the older SP 800-147 BIOS scope to any platform device with mutable firmware: storage controllers, network cards, management controllers, and more. A single corrupted critical device can brick the whole platform, so resiliency is a whole-estate property.
3. “Secure boot already handles this, so there’s nothing new.” Secure boot is one protection mechanism. SP 800-193 adds detection and recovery on top, so a device that’s been corrupted despite protection can still be noticed and restored to a known-good state rather than being permanently bricked.
4. “SP 800-193 is quantum-safe because it’s a security standard.” The opposite. It requires FIPS 186-4 signatures, which are the classical RSA and ECDSA that Shor’s algorithm breaks. The framework is sound; the signature algorithms inside its roots of trust are exactly what has to migrate.
5. “A firmware update can wait to migrate because updates are signed each time.” Firmware roots of trust are long-lived and often frozen in hardware, and a device signed today has to stay verifiable for its whole service life. That longevity is precisely why firmware signing is near the front of the migration, not the back.
6. “SP 800-193 is a mandate I have to comply with.” It’s voluntary guidance. The binding post-quantum deadlines for firmware signing come from CNSA 2.0 and NIST IR 8547, not from SP 800-193 itself.

Questions people ask

What does SP 800-193 actually require? That platform firmware and its critical data be protected from corruption, that corruption be detectable, and that a device be recoverable to a known-good state, with all three anchored in roots of trust. Firmware updates must be authenticated with a digital signature verified by the Root of Trust for Update before the update is committed.

What’s the difference between the RTU, RTD, and RTRec? They’re the three roots of trust, one per principle. The RTU authenticates updates before they’re applied, the RTD detects corruption after the fact, and the RTRec restores a corrupted device to a known-good image. They’re logical roles that often share the same underlying hardware.

Which signature algorithms does SP 800-193 use? It requires an approved digital signature algorithm from FIPS 186-4 at a security strength of at least 112 bits, which in deployment means RSA and ECDSA. Both are quantum-vulnerable, so those are the algorithms a firmware root of trust has to migrate off.

Is SP 800-193 a mandatory standard? No. It’s a voluntary NIST Special Publication, a guideline and design reference rather than a compliance mandate. Its “shall” language is a conformance target for vendors that adopt it, and its post-quantum deadlines are set elsewhere by CNSA 2.0 and NIST IR 8547.

What should firmware signing move to? CNSA 2.0 names the stateful hash-based schemes LMS and XMSS for firmware and software signing, run inside a hardware module. The stateless SLH-DSA removes their state-management hazard, and the lattice-based ML-DSA fits higher-volume general signing.

Why is firmware signing more urgent than most signatures? Because firmware roots of trust are long-lived and frozen. A signing key protecting a device for ten or fifteen years, often burned into hardware that can’t be re-architected in the field, has to stay unforgeable across the entire arrival of quantum computing, so by Mosca’s theorem the migration has to start early.

Does SP 800-193 relate to secure boot? Yes. Secure boot is a protection mechanism that verifies firmware and boot code with a signature before it runs, and that verification is anchored in a root of trust exactly like the one SP 800-193 formalizes. SP 800-193 generalizes and extends that idea across the whole platform and adds detection and recovery on top.

Is my firmware exposed today? Not to a quantum attack, because a cryptographically relevant quantum computer doesn’t exist yet. The exposure is that firmware signed with classical algorithms now, in devices meant to run for a decade, becomes forgeable once such a machine arrives, which is why the roots of trust are re-keyed onto quantum-safe algorithms before that point.

---

Everything here is the map, given freely. When your team needs its own firmware roots of trust found across every device in the estate, the classical signatures inside them sequenced onto a post-quantum path, and the update mechanisms re-anchored before the machine arrives, that’s the work I do. Request an alignment briefing.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.