Security Playbook: What the FU100 Fingerprint Drive Failure Means for USB Data Protection

By James Hartley, IT Insights — ItInsightsWorld Security. A fingerprint sensor can make a USB drive appear like a hardware-security boundary, while the actual data boundary is much weaker. The disclosures around FU100 and TSD303 are useful because they convert an abstract encryption claim into concrete operational checks: where the key lives, whether the password leaves the device, and what an administrator should do when a storage product is physically exposed. Enterprise security teams need a practical playbook, not a product review.

What the research revealed in plain operational terms

Last year, security researcher Xusheng Li disassembled FU100. At one meeting in March of this year, Li described the finding: the fingerprint feature only controlled the USB connection, while files stored on the SD card remained in plaintext. That is the core lesson — the biometric gate did not protect the medium. Li called FU100 “an SD card in a fancy shell,” and argued that the case shows how some hardware security claims may function more like marketing than as a defense.

Lenovo later published remediation for FU100, FU200, TU800 USB drives and TSD303 portable SSD. The official path runs through Lenovo’s China remediation workflow, allowing affected users to choose between returning the drive for replacement or waiting for on-site firmware upgrading. Lenovo recommends backing up important data first and strongly advises erasing the device before sending it. That warning is important: if the product did not protect data at rest, mailing it away may create a second exposure.

Why the vulnerability description matters to administrators

Lenovo rated the related security announcement high. The remediation summary covers three vulnerabilities. One of them involves the configuration software and may allow a local authenticated user to bypass device authentication and register an unauthorized fingerprint. In practice, this means the control plane around the device may be as dangerous as the storage plane. A stolen laptop or a shared workstation could let a logged-in attacker manipulate trusted fingerprints without breaking the outer shell.

Lenovo’s official advisory LEN-210545, dated January 13, 2026, further maps the issues to CVE-2025-13453, CVE-2025-13454, and CVE-2025-13455, and credits Xusheng Li of Vector 35 Inc. The advisory framing helps organizations move beyond rumor-level summaries: it identifies affected ThinkPlus products, a high-level severity rating, and the specific configuration-software bypass behavior that enterprise patch teams should track.

The second Lenovo finding: password handling, not only data encryption

Li also identified another vulnerability in TSD303. Unlike FU100, TSD303 encrypted its stored data, yet the drive previously transmitted the correct password over the USB connection in plaintext so that host software could compare it. Anyone able to monitor that interface or inspect the verification software could potentially capture the password. The risk is therefore not only whether the disk is encrypted, but whether the secret ever leaves the device where it is supposed to stay.

The repair history is instructive. About three months after the vulnerability report, the first remediation package was introduced. Researchers later found that the encryption key used by that fix could be derived from a timestamp-like value, so a stolen device still had weak protection. A later fix released later last year changed the verification model: the drive itself checks the user-entered password, and the correct password no longer leaves the device. This sequence gives security teams a repeatable acceptance test for future hardware purchases.

SDK reuse expands the incident beyond one product

The same SDK was reportedly used by nine additional devices from other makers, and many of those products may leak passwords to attackers with sufficient technical skill. Researchers also found two additional devices that stored unencrypted data on microSD. The vendor names were obscured in the slides, which is a reminder that product-level diligence cannot be delegated to a brand name alone.

AI-assisted review and the wider device cluster

Recently, one AI-assisted follow-up project broadened the assessment. Li used OpenAI’s Codex, combined with a reverse-engineering tool developed by the employer, to test other vendors’ storage products and protection software. This approach is not a replacement for full product validation, but it shows how quickly a capable team can identify implementation flaws when the target is a narrow, documented code path.

Codex breached one Netac tool in about 7 minutes. The reported findings include an embedded fixed key and user passwords written to a diagnostic log. At the time of Li’s March presentation this year, Netac had not published a patch, and the report did not state whether the product had been fixed afterward.

The same project reviewed two file copy protection products. Such products let recipients open files while attempting to prevent content from being copied. Codex reconstructed the password generated by KakaSoft USB Copy Protection in about 26 minutes and decrypted one test file without the user password. Nexcopy’s Copy Secure was broken in about 10 minutes.

SecZure’s YutianDun was also examined. Li found two hidden accounts with weak passwords. The report described those accounts as a backdoor, while noting that this description does not prove malicious intent from the vendor. Li said he did not notify KakaSoft, Nexcopy, or SecZure before disclosure, because a USB drive already in an attacker’s hands is difficult to recall or update.

A design example that points in a better direction

Li contrasted the failures with one open-source USB flash drive. It also uses microSD, but it correctly implements encryption and derives the key from the user password. If an attacker reads only the storage card, the data is not available as plaintext. The difference is not the card type; it is whether the architecture protects the secret material.

Security control matrix for fingerprint and encrypted storage devices

Device pattern	What appears protected	What may be exposed	Control that should be required
FU100-style biometric gate	USB link opens after fingerprint validation	SD card contents remain readable in plaintext	Media-level encryption, independent verification, physical-tamper testing
TSD303 early password model	Stored data is encrypted	Correct password travels over USB or is handled by host software	Device-local password verification and protected transport
Timestamp-derived key model	Password is no longer sent as plaintext	Encryption key may be predictable	Strong random key generation, non-derivable key storage, review after fix
Open-source microSD model	Encryption key derived from user password	Security depends on code review and key handling quality	Peer review, threat model, lockout, audit, tested recovery flow

Operational checklist for IT and security teams

1. Build a removable-device register. Capture make, model, serial number, firmware version, owner, classification, and companion software for every fingerprint drive, encrypted SSD, and USB copy-control device.
2. Separate access controls from confidentiality controls. Ask what happens after the case is opened, not only what happens after a finger touches the sensor.
3. Confirm the data-at-rest state. For SD card, microSD, M.2, or flash-based designs, require evidence that stored content is encrypted rather than merely gated by a biometric interface.
4. Review the key lifecycle. Determine who generates the key, where it is stored, whether it depends on a user password, and whether an attacker can predict it from timestamps or embedded constants.
5. Test password movement. If host software verifies the password, inspect whether the correct value is transmitted over USB, logged, cached, or reused across products built on the same SDK.
6. Check the software control plane. Configuration utilities can create local authenticated-user risks, including fingerprint registration or sensitive device information exposure.
7. Apply firmware remediation carefully. Confirm device eligibility, preserve a safe handling chain, and follow backup plus data-erasure guidance before shipping a drive for replacement or on-site upgrading.
8. Update enterprise removable-media rules. High-risk files should move through managed endpoints, encrypted transfer, access logging, and DLP rather than personal security gadgets.
9. Document incident assumptions. Treat lost devices as potentially readable until verified otherwise, and define breach-notification, remote wipe, key rotation, and evidence-preservation steps.
10. Require acceptance criteria in procurement. Ask vendors for published advisories, CVE references, independent tests, and response timelines for physical-attack scenarios.

Common misconceptions that keep risks alive

• A fingerprint is equivalent to encryption. It may only be a permission gate for a connection, not a cryptographic envelope for files.
• Marketing wording proves architecture. Claims about hardware security need testable evidence, especially for portable devices handled by many people.
• Fixing one product fixes the ecosystem. Reused software stacks can spread password-leakage or weak-key behavior to other makers.
• Password protection equals password secrecy. The TSD303 lesson shows that data can be encrypted while the secret still leaks through an interface.
• Physical size means low risk. A small USB drive can carry the same confidentiality exposure as a laptop, with a weaker recovery model.

Action recommendations for the first 30 days

1. Inventory and quarantine. Identify all fingerprint and encrypted USB assets, then pause business use of any device whose data-at-rest state cannot be verified.
2. Map official remediation status. Track Lenovo’s China workflow and related vendor notices for FU100, FU200, TU800, and TSD303, and document each device’s repair choice: replacement, on-site firmware upgrading, retirement, or approved exception.
3. Run a key-custody review. For each device family, ask whether keys are generated by the device, derived from user passwords, embedded in software, predictable from time values, or exposed through logs.
4. Raise procurement bars. Require vendors to explain the storage medium, encryption path, authentication boundary, SDK reuse, firmware update method, and disclosure policy.
5. Train owners with concrete language. Tell users that biometric unlock is not a substitute for encryption, and tell them to contact IT Insights at contact@itinsights.com when a device is lost, upgraded, or replaced.

FAQ: practical questions security teams ask first

Should we stop using every fingerprint USB drive?

The safer answer is to stop using any device that cannot prove it encrypts the data itself. Fingerprint recognition should be treated as one control layer, not as proof that files are confidential. For regulated or sensitive data, require tested storage encryption, documented key handling, and an owner accountable for remediation.

Does a firmware fix automatically make the device trustworthy?

No. The FU100 and TSD303 cases show that a first remediation can change one weakness while leaving another, such as a predictable key. Administrators should compare the fix description against the original attack model: does the key stay secret, does the password stay local, and does the configuration software still allow unauthorized fingerprint registration?

Can open-source hardware be considered safer?

Openness helps only when the design is reviewed and the encryption path is implemented correctly. The positive example in the disclosures is not openness by itself; it is the combination of microSD storage, key derivation from the user password, and the inability to obtain plaintext data by reading the card alone.

What is the quickest risk-reduction step for small teams?

Create a two-minute inventory: model, serial number, firmware state, data category, and backup status. Then decide whether to keep, replace, or stop using the device. For high-risk data, migrate to managed endpoints or encrypted file transfer with logging; for personal USB tokens, retire or restrict them.

Who should own this type of issue?

It is a shared control between security operations, endpoint management, procurement, and data owners. Security operations defines the threat model, endpoint teams enforce firmware and configuration, procurement prevents weak claims from becoming standard purchases, and data owners decide whether the residual exposure is acceptable.