Hardware-Encrypted USB Drives and Recovery Sticks: FIPS 140-3 Explained

A USB stick has two security jobs worth paying for. A hardware-encrypted drive carries sensitive files and does its own encryption on the device, so losing it should not mean losing the data. A bootable recovery stick lets you repair, reinstall or rescue a machine that will not start. Buy the first with a FIPS 140-3 certificate you have actually looked up, and build the second only from official images whose checksums and signatures you have verified.

This guide covers both jobs, including what the September 2026 move of FIPS 140-2 certificates to the Historical list means for purchases.

Key takeaways

• Hardware encryption means the drive's own controller holds the key and does the encryption, usually unlocked with a keypad PIN or a small host app. Software encryption (BitLocker To Go, LUKS, an encrypted APFS volume) works on any ordinary stick but depends on the host operating system to unlock it.
• FIPS 140-3, published 22 March 2019, is the current US and Canadian standard for cryptographic modules; the CMVP began accepting 140-3 submissions on 22 September 2020.
• FIPS 140-2 certificates moved to the Historical list in September 2026. Historical modules may be used for existing systems, not new ones.
• "FIPS validated" applies to a specific module, at specific hardware and firmware versions, at a specific level. Look it up in the CMVP search.
• Recovery media goes stale. Microsoft recommends recreating a Windows recovery drive every year, and its Secure Boot revocation guidance says older boot media may stop working once the mitigations are applied.
• Verify every image before you write it. Ubuntu and Fedora publish signed checksum files; Microsoft publishes SHA256 hashes for its Windows 11 ISOs.

Two jobs, two sticks

Most people own one stick and use it for everything. That habit causes most of the problems below. A drive that carries sensitive data should stay locked and away from untrusted machines; a drive that boots computers will almost certainly meet an untrusted machine, because that is when you reach for it. Keep at least two, labelled: the carrier (encrypted, for files, never used to boot anything) and the recovery stick (official, verified boot images and no personal data or secrets).

What is the difference between hardware-encrypted and software-encrypted USB drives?

Both kinds scramble the data on the flash chips so that someone who pulls them out sees noise. The difference is where the key lives and who does the work.

Software encryption

With software encryption, the stick is an ordinary USB mass storage device. The operating system on the host computer encrypts data before writing it and decrypts it after reading it. Common examples:

• BitLocker To Go on Windows. Microsoft's BitLocker FAQ describes it as BitLocker Drive Encryption on removable data drives, covering USB flash drives, SD cards and external hard disks formatted with NTFS, FAT16, FAT32 or exFAT. Removable drives can be unlocked with a password or a smart card, and standard users (not only administrators) can turn it on for removable data drives.
• LUKS on Linux, managed with cryptsetup.
• An encrypted APFS volume on macOS, created in Disk Utility.

NIST SP 800-111 (November 2007) sorts these into full disk, volume and virtual disk, and file and folder encryption; most removable media setups are volume encryption.

The strengths are cost and policy. Any stick works, the code gets operating system updates, and Microsoft's FAQ notes that a policy can make Windows mount any data drive that is not BitLocker protected as read only.

The weaknesses are portability and the host. A BitLocker To Go drive is awkward on Linux and macOS; a LUKS volume is awkward on Windows. More important, the password is typed into the host and the key sits in host memory while the drive is open, so a compromised host defeats it.

Hardware encryption

A hardware-encrypted drive has a controller that holds the encryption key and performs the encryption itself. The key never leaves the device. You unlock it in one of two common ways:

• A keypad on the drive. You type a PIN on the stick before plugging it in (or while it is plugged in, depending on the design). The host sees nothing until the drive is unlocked, and then sees an ordinary storage device.
• A host unlock application. The drive first presents a small read only partition with an unlock tool. You run it, type a password, and the controller exposes the encrypted partition.

The advantages are that the host operating system does not matter, the key is not in host memory, and the drive can enforce rules the host cannot override, such as wiping itself after too many wrong PINs. The disadvantages are cost and closed firmware you cannot inspect. You are trusting that the controller really encrypts and really wipes, which is the gap an independent FIPS 140-3 validation narrows.

Which one should you use?

If every machine is managed and runs one operating system, policy enforced software encryption is usually enough. If the drive meets unknown machines or third parties, a keypad drive keeps the host out of the unlock.

What does FIPS 140-3 validation cover, and how do you check a certificate?

FIPS 140-3, "Security Requirements for Cryptographic Modules", is a US federal standard that Canada also uses through the joint Cryptographic Module Validation Program. NIST's publication page records it as published on 22 March 2019, superseding FIPS 140-2 (3 December 2002). It adopts two international standards, ISO/IEC 19790 for the requirements and ISO/IEC 24759 for the test methods. NIST's transition page says it became effective on 22 September 2019.

What the standard actually tests

FIPS 140-3 tests a cryptographic module: the hardware, firmware or software that performs approved cryptographic functions inside a defined boundary. Its areas include the module specification, its interfaces, how operators authenticate, software and firmware security, physical security and self tests. It defines four security levels that NIST describes as increasing, qualitative levels of security. In broad terms, the higher levels add stronger physical security and stronger operator authentication.

What validation does not tell you:

• It does not certify the whole product. It covers the module inside the boundary drawn in the certificate. The plastic case, the USB connector and the host app may be outside it.
• It does not cover versions that were not tested. A certificate lists hardware and firmware versions. A drive shipping with newer firmware is not covered by an older certificate unless the certificate is updated.
• It does not prove there are no bugs. It proves the module passed a defined set of tests at an accredited lab.

How to look up a certificate, step by step

NIST's CMVP search lets you filter by certificate number, vendor, module name, standard, module type, status (Active, Historical or Revoked), level and versions. A basic search covers only the Active list; the advanced search shows Historical and Revoked modules.

1. Find the certificate number on the drive's packaging or datasheet. A real claim names a number. Treat "FIPS compliant", "FIPS ready" or "designed to FIPS standards" as marketing until a number appears.
2. Search by certificate number on the CMVP validated modules search page. Use advanced search if nothing appears.
3. Check the standard field. For new purchases in 2026, you want FIPS 140-3.
4. Check the status. Active means the certificate is current. Historical means agencies may use it only for existing systems. Revoked means do not rely on it.
5. Check the level and module type. A hardware module with physical security requirements is what you expect for an encrypted drive.
6. Open the security policy document linked from the certificate and read the tested hardware and firmware versions and the module boundary.
7. Compare versions with the drive in your hand. If the vendor ships a firmware update, check whether the certificate lists the new version before you apply it in a regulated environment.
8. Record the certificate number and the versions in your asset register next to the drive's serial number.

What happens to FIPS 140-2 certificates in 2026?

The dates, as NIST's CMVP and transition pages give them:

The CMVP page says federal agencies in both countries could keep accepting FIPS 140-2 modules through 21 September 2026, after which CMVP places them on the Historical list. NIST's pages differ by a day (one schedule line says 22 September). Either way, the date has passed.

What this means in practice:

• Buying new drives: if your policy or contract requires FIPS validation, require an Active FIPS 140-3 certificate. A drive whose only certificate is 140-2 no longer meets a requirement for new systems.
• Drives you already own: a 140-2 drive does not stop encrypting on 22 September. Whether "existing systems" covers your use depends on your contract or regulator; plan replacement on your normal cycle.
• Firmware updates: a firmware update on a 140-3 drive can take it outside its certificate if the new version is not listed. In regulated settings, update only to versions named in an Active certificate or its updates.

What features matter on an encrypted drive?

Categories to look for, ideally described in the drive's validated security policy rather than only on the box.

Brute force protection

The drive counts wrong PIN or password attempts and, after a set number, either locks for increasing periods or erases its key, which makes the data unrecoverable. Check the threshold, whether it is configurable, and whether a wipe destroys the key (fast and final) or tries to overwrite the flash (slow, and less certain on flash memory). The trade off: anyone can also wipe your only copy, so keep a backup elsewhere.

Separate admin and user credentials

Some drives support an administrator PIN that can reset a user PIN without wiping data. Decide who holds that second credential and where. Our guide on where to store recovery keys for encrypted laptops applies directly.

Read only mode

A switch or a setting that unlocks the drive in read only mode. It stops an untrusted host from changing the contents. A physical switch the host cannot override is stronger than a software setting the host could change.

Tamper evidence and tamper resistance

Physical measures such as epoxy filled cases, tamper evident seals and coatings over the controller. These are where higher FIPS levels differ. Tamper evidence tells you after the fact that someone opened the drive; tamper resistance makes it hard to reach the key at all.

Signed firmware

The controller accepts only firmware signed by the manufacturer. This matters because of BadUSB (covered below): a controller that will run any firmware someone writes to it can be turned into a different device entirely. A drive that verifies a signature before running firmware is the main defence at the hardware level. Ask whether firmware is signed and whether field updates are allowed at all.

Keypad and boot behaviour

Keypad wear can reveal which digits a PIN uses, so pick a longer PIN that is not a date. A keypad drive unlocks before the host sees it, so some can even carry a bootable image; a drive that needs a host unlock app cannot boot.

How do you create a Windows recovery drive and installation media?

Windows has three kinds of USB boot media, and they do different things.

Recovery drive

Microsoft's support article lists the steps:

1. Search for "Recovery Drive" from Start, or run recoverydrive.exe.
2. Keep "Back up system files to the recovery drive" selected, then choose Next.
3. Connect a USB drive, select it, and choose Next.
4. Choose Create.

Warning: creating a recovery drive erases everything on the selected USB drive. Microsoft says to use an empty drive. Before step 3, check the drive letter in File Explorer and unplug every other removable drive so you cannot pick the wrong one.

With system files included, the drive contains built in Windows files, installed updates and any manufacturer customizations. It does not include personal files; back those up separately. Microsoft recommends recreating the recovery drive every year so it includes the latest updates.

Installation media

Microsoft's Windows 11 download page offers the Media Creation Tool, which needs a USB flash drive of at least 8 GB, administrator rights and an x64 PC (it does not build media for Arm based PCs). The page warns that any content on the flash drive will be deleted. It also offers a direct ISO download and describes checking the file with PowerShell:

# Verify a downloaded Windows 11 ISO before writing it anywhere
Get-FileHash .\Win11_English_x64.iso -Algorithm SHA256
# Compare the output with the SHA256 value Microsoft lists for your language

The download links expire after 24 hours, so record the published hash at the time you download.

WinPE for IT teams

Microsoft describes Windows PE as a small operating system for installing, deploying and repairing Windows, including recovering data from unbootable machines. It is an add on to the Windows ADK. Limits that matter:

• It is licensed only for deployment and recovery, not as a general operating system.
• It restarts automatically after a period of continuous use: 240 hours on Windows 10 version 1803 and later.
• The default installation uses FAT32, with a 4 GB maximum file size and a 32 GB maximum drive size.
• For Windows 11 setup from WinPE, include the WinPE-WMI and WinPE-SecureStartup optional components.

With the ADK and WinPE add on installed, the usual commands run from the "Deployment and Imaging Tools Environment" prompt:

:: Create a working copy of WinPE files
copype amd64 C:\WinPE_amd64

Warning: the next command formats the target drive. Run diskpart, then list disk and list volume, and confirm the drive letter belongs to the USB stick by its size and label before continuing. Replace P: with that letter.

:: Write WinPE to the USB drive (erases it)
MakeWinPEMedia /UFD C:\WinPE_amd64 P:

The Secure Boot catch: old media may stop booting

Microsoft's guidance on Windows Boot Manager revocations for CVE-2023-24932 says recovery and install media "will need to be updated" to work with a device that has the mitigations applied. It says older external media built before January 2025 can be invalidated once updates from April 2026 or later are deployed and the revocations are enabled. Microsoft's advice is to create updated media using the Recovery Drive app on a device that already has the latest updates and the certificate database update applied, and to create a recovery drive before applying the revocation step.

As of 23 October 2026, Microsoft's article still lists no start date for the enforcement phase; it says the phase would not begin before January 2026 and that Microsoft would give at least six months of notice. Practical upshot: rebuild your Windows recovery and install sticks after your fleet takes the 2026 boot updates, and test that the new stick boots on a machine with the mitigations applied.

How do you create a bootable macOS installer?

Apple's support article "Create a bootable installer for macOS" covers this:

• A 32 GB drive is enough for any macOS installer; 16 GB is enough for most earlier versions.
• Rename the drive to MyVolume before running the command. The tool erases it and formats it as Mac OS Extended (Journaled).
• Download the installer app from Apple first; it lands in /Applications.

Warning: createinstallmedia erases the target volume. Before you run it, run diskutil list external and confirm that the volume named MyVolume is the USB stick you intend to erase, by size and by device identifier.

# Confirm which external disk holds MyVolume
diskutil list external

# macOS Tahoe 26 example from Apple's article
sudo /Applications/Install\ macOS\ Tahoe.app/Contents/Resources/createinstallmedia --volume /Volumes/MyVolume

To boot from it, on Apple silicon hold the power button until startup options appear; on Intel Macs hold Option. On Intel Macs with the T2 Security Chip, if the Mac will not start from the installer, check that Startup Security Utility allows booting from external or removable media. Apple also notes the Mac must be connected to the internet during installation so the installer can get firmware for that model.

Get the installer app from Apple's own channels, never from a copy someone shares.

How do you verify a Linux live image?

Linux distributions publish a checksum file and a signature over that file. Verifying both proves two things: the image matches the checksum (it was not corrupted or swapped), and the checksum file came from the distribution (it was not swapped alongside the image).

Ubuntu

Ubuntu's "How to verify your Ubuntu download" tutorial uses SHA256SUMS and SHA256SUMS.gpg from the release directory:

# 1. Check the signature on the checksum file
gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

# If gpg reports "No public key", import Ubuntu's signing keys
gpg --keyid-format long --keyserver hkp://keyserver.ubuntu.com \
  --recv-keys 0x46181433FBB75451 0xD94AA3F0EFE21092

# Check the fingerprints against the ones published by Ubuntu
gpg --keyid-format long --list-keys --with-fingerprint \
  0x46181433FBB75451 0xD94AA3F0EFE21092

# 2. Check the ISO against the verified checksum file
sha256sum -c SHA256SUMS 2>&1 | grep OK

The tutorial lists the expected fingerprints, including 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092 for the RSA 4096 key. A "Good signature" line is what you want. Ubuntu notes that the "not certified with a trusted signature" warning is expected, because you have not personally signed Ubuntu's key. No output from the second command means the ISO does not match; download it again.

Fedora

Fedora's security page uses a downloaded OpenPGP certificate and gpgv:

# Download Fedora's signing certificate
curl -O https://fedoraproject.org/fedora.gpg

# Compare the fingerprint with the values on fedoraproject.org/security
gpg --with-fingerprint --show-keys --keyid-format long fedora.gpg

# Verify the signed CHECKSUM file and check images in this directory
for file in *-CHECKSUM; do
  gpgv --keyring ./fedora.gpg --output - "$file" \
    | sha256sum -c --ignore-missing
done

Writing the verified image to a stick

Warning: dd overwrites the target device completely and does not ask for confirmation. One wrong letter can erase your system disk. Before every run, list devices, unplug other removable drives, plug in the stick, list again, and confirm the new device by size and model.

On Linux:

# Before and after plugging in the stick: find the new device
lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS

# Unmount any partitions the desktop auto-mounted (replace sdX)
sudo umount /dev/sdX?* 2>/dev/null

# Write the verified image (replace sdX with the device you confirmed)
sudo dd if=ubuntu-desktop-amd64.iso of=/dev/sdX bs=4M status=progress conv=fsync

On macOS:

# Find the stick: look for "external, physical" and the right size
diskutil list external

# Unmount it (replace N with the disk number you confirmed)
diskutil unmountDisk /dev/diskN

# Write the verified image to the raw device
sudo dd if=ubuntu-desktop-amd64.iso of=/dev/rdiskN bs=4m

Check the stick, not only the download

A step people skip: after writing, confirm the stick holds exactly what you verified. For images written byte for byte with dd, read back the same number of bytes and hash them:

ISO=ubuntu-desktop-amd64.iso
SIZE=$(stat -c %s "$ISO")          # on macOS: stat -f %z "$ISO"
sudo head -c "$SIZE" /dev/sdX | sha256sum
sha256sum "$ISO"
# The two hashes should match

Repeat this check whenever the stick comes back from an untrusted machine. It is a cheap way to know whether the boot image has changed.

What should a recovery kit stick contain, and how often should you refresh it?

A sensible kit:

Things that do not belong on a recovery stick: recovery keys, password manager exports, SSH or signing keys, API tokens, or a copy of your home directory. Losing a recovery stick should cost you a stick and nothing else.

Keep a written list of each stick's image filename, hash and build date, test boot quarterly on a machine with current boot updates, and keep a second copy elsewhere.

For staff who travel, pair this with the advice in setting up a loaner laptop for travel and what actually protects data in a hotel room.

How do you stop a recovery stick from becoming a malware carrier?

MITRE ATT&CK technique T1091, Replication Through Removable Media, describes adversaries copying malicious files to removable media and relying on Autorun or user action to run them when the media is inserted elsewhere, including on disconnected networks. The mitigations MITRE lists are plain: disable Autorun where it is not needed, restrict removable media by policy, and block unsigned or untrusted executables from running off USB drives.

For a recovery stick specifically:

1. Use read only where you can. A stick with a physical write protect switch, or a keypad drive set to read only, stops a compromised host from changing it.
2. Do not add persistence or a data partition to the recovery stick.
3. Re-image after exposure. If the stick was plugged into a machine you suspect is compromised, wipe and rewrite it from your verified image, then hash check it.
4. Never copy files back from a broken machine to the recovery stick. Recover data to a separate carrier.
5. Keep it physically controlled and labelled, stored where you keep spare keys.

For data that leaves the building on USB, MITRE's exfiltration view is in our post on MITRE ATT&CK T1052.001, exfiltration over USB.

What does BadUSB mean for drives with reprogrammable controllers?

Every USB stick has a small controller chip running firmware. That firmware decides how the device describes itself to the host: as storage, as a keyboard, as a network adapter, or as several at once. In 2014, security researchers publicly demonstrated that the firmware on many common USB controllers could be rewritten from the host, and named the result BadUSB. A reprogrammed stick can still look like storage while also announcing itself as a keyboard and typing commands, or as a network adapter that redirects traffic. Because the change is in the controller firmware, reformatting the stick does nothing, and scanning its files finds nothing, since the behaviour does not live in the files.

MITRE ATT&CK's Hardware Additions technique (T1200) covers the broader family: devices plugged into a computer or network that offer capabilities such as keystroke injection or reading memory over DMA.

What this means for the two jobs in this guide:

• For the carrier: prefer drives whose controller accepts only signed firmware, and buy from a supply channel you trust.
• For the recovery stick: never use a stick of unknown origin, including conference giveaways. Buy new sticks from a known channel for recovery use.
• For hosts: restrict which USB device classes can be added, especially new keyboard and network devices, through your device management tooling.

Step by step: build a verified recovery kit in an afternoon

1. Buy new sticks from a channel you trust, and fully update the build machines, including 2026 Secure Boot updates.
2. Build and verify each stick with the commands above: hash or signature check before writing, target check before writing, read back hash after writing.
3. Test boot each stick with Secure Boot on, record image name, hash and date, and store a second set elsewhere.
4. Encrypt the carrier. For a software approach on Windows:

Warning: turning on BitLocker To Go does not erase data, but if you lose the password and the recovery key, the data is gone. Save the recovery key somewhere other than the drive itself, and confirm the drive letter with manage-bde -status before you start.

:: Show BitLocker status for all volumes; confirm E: is the USB stick
manage-bde -status

:: Turn on BitLocker To Go with a password protector
manage-bde -on E: -pw

:: Lock the drive when finished (from Microsoft's FAQ)
manage-bde E: -lock

On Linux, LUKS does the same job:

Warning: cryptsetup luksFormat destroys all data on the target partition. Run lsblk -o NAME,SIZE,MODEL,TRAN with only the intended stick attached and confirm the partition name before running it.

lsblk -o NAME,SIZE,MODEL,TRAN
sudo cryptsetup luksFormat /dev/sdX1
sudo cryptsetup open /dev/sdX1 carrier
sudo mkfs.exfat /dev/mapper/carrier
sudo cryptsetup close carrier

Common mistakes

• Trusting "FIPS" on the box without a certificate number. Only a CMVP certificate, with matching versions, is a validation.
• Buying a 140-2 only drive for a new system in late 2026. Those certificates are now on the Historical list.
• Updating firmware on a validated drive without checking the certificate. The new version may not be covered.
• Keeping one stick for everything.
• Building recovery media once and forgetting it. Microsoft advises a yearly rebuild, and 2026 boot changes can stop old media from starting at all.
• Checking the ISO hash but not the signature. The signature ties the checksum to the distribution.
• Storing recovery keys on the recovery stick. Microsoft's BitLocker FAQ advises against keeping a startup key and recovery key on the same USB drive, and by default does not let you save a removable drive's recovery key on a removable drive.
• Leaving no backup of data on a drive with brute force wipe. Ten wrong guesses can be the end of the only copy.

Fix it without waiting for upstream

A USB stick is not a software project, but the machine you rebuild from it is, and that machine pulls package managers, SDKs and dependencies again the first time it builds anything. The boot tools, drivers and firmware on the stick are also built from open source components, so knowing what you reinstall and whether a fixed version exists still matters, even though the fit here is indirect.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits, honestly

Safeguard does not encrypt USB drives, validate drive firmware, scan removable media for malware or manage devices. The fit is narrower and comes after recovery. A developer laptop rebuilt from a recovery stick is part of your software supply chain again the moment it clones a repository and runs an install. Rebuild from lockfiles and a known SBOM, and scan restored projects before you trust them. The Safeguard CLI's local runner runs scans on your own machine using outbound connections only, and its offline vulnerability database import is plan dependent, so confirm availability first. If a component turns up in a rebuilt project, the platform shows which other projects carry the same version; our post on SBOM driven incident response walks through that flow.

FAQ

Are hardware-encrypted USB drives better than BitLocker To Go?

Neither is better in general. Hardware encryption keeps the key and password entry off the host and can wipe after failed attempts, which suits travel. BitLocker To Go is cheaper and policy enforced, which suits managed Windows fleets.

What does FIPS 140-3 Level 3 mean on a USB drive?

It means the drive's cryptographic module was validated at Level 3 of the four FIPS 140-3 levels, which adds more demanding requirements than Level 2, particularly around physical security and operator authentication. The security policy shows exactly what was tested.

How do I check if a USB drive is really FIPS validated?

Find the certificate number on the datasheet, search for it in NIST's CMVP validated modules search, and check that the standard is FIPS 140-3, the status is Active, and the hardware and firmware versions in the security policy match your drive.

Can I still use my FIPS 140-2 encrypted USB drive after September 2026?

The drive still works. Its certificate is now on the Historical list, and NIST says Historical modules may be used for existing systems but not new ones. Check your contract or regulator and plan a 140-3 replacement.

How big does a USB drive need to be for a Windows 11 or macOS installer?

Microsoft's Media Creation Tool needs at least 8 GB for Windows 11. Apple says 32 GB is enough for any macOS installer and 16 GB for most earlier versions.

Why won't my old Windows recovery USB boot anymore?

The most likely reason in 2026 is Secure Boot. Microsoft's guidance on Boot Manager revocations says media built before January 2025 can stop working once the revocations are applied. Rebuild the recovery drive on a fully updated PC.

Can a USB drive be infected even after formatting?

Files can be removed by formatting, but a BadUSB style attack lives in the controller firmware, which formatting does not touch. Signed firmware, trusted supply channels and host USB device rules address it.

How often should I update my recovery USB?

Microsoft recommends recreating a Windows recovery drive every year. Also rebuild after major boot updates and new OS releases.

See how Safeguard would help

These demos show the software side of a rebuild, not anything to do with USB hardware. To try them on your own machine, download Safeguard and follow the CLI docs.

This first demo is a real CLI session. You install the CLI, open the interactive terminal with safeguard, and ask it to "fix the lodash CVE in this repo"; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. After a rebuild, the same flow brings a restored project back to fixed versions with a person approving each step.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. On a freshly rebuilt machine, this keeps scanning on hardware you control, with source code staying local, before that machine goes back to building and shipping code.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST: FIPS 140-3, Security Requirements for Cryptographic Modules
• NIST: Cryptographic Module Validation Program
• NIST: FIPS 140-3 Transition Effort
• NIST CMVP: Validated Modules Search
• NIST SP 800-111: Guide to Storage Encryption Technologies for End User Devices
• Microsoft Support: Create a recovery drive
• Microsoft Support: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• Microsoft: Download Windows 11
• Microsoft Learn: Windows PE (WinPE)
• Microsoft Learn: BitLocker FAQ
• Apple Support: Create a bootable installer for macOS
• Ubuntu: How to verify your Ubuntu download
• Fedora: Security, verifying downloads
• MITRE ATT&CK: T1091 Replication Through Removable Media
• MITRE ATT&CK: T1200 Hardware Additions
• Safeguard: How the local runner and offline mode work

Last reviewed: 23 October 2026.