Pico FIDO Passkey Firmware for Raspberry Pi and ESP32

Pico FIDO's Local Passkey Boundary

Pico FIDO addresses a specific hardware constraint: a passkey authenticator can be built into a low-cost microcontroller rather than supplied as a dedicated security key. Supported targets include Raspberry Pi Pico boards based on RP2040 or RP2350 and ESP32 boards, with ESP32-S3 receiving particular attention for secure boot and secure lock support. The result presents itself through USB as a standard FIDO authenticator, which the README says allows operating systems, browsers and applications to detect it through the HID driver.

The intended audience includes developers who work with WebAuthn, U2F, CTAP, credential storage and hardware firmware. It may also appeal to users who want control over authenticator policy, physical user-presence checks and credential backups. Pico FIDO supports CTAP 2.3 and CTAP 1, WebAuthn, U2F, discoverable credentials and PIN-based user verification. The listed cryptographic algorithms include ECDSA and EDDSA across several named curves.

This project also extends beyond ordinary FIDO authentication. The README lists OATH, TOTP, HOTP, challenge-response generation, an emulated keyboard interface and compatibility with named management tools. Those extras broaden its scope, so evaluating it as only a WebAuthn adapter would miss much of the firmware. At the same time, the hardware choice determines whether its strongest protection is meaningful. On RP2040, the documentation explicitly warns that private and master keys can be read from flash after theft.

CTAP Commands Over the USB HID Boundary

The documented data path begins with a WebAuthn or U2F application issuing an authentication request to the connected Pico FIDO device. Pico FIDO receives it through its USB HID interface, which the README says is available across operating systems. It then acts as the FIDO authenticator, applying its configured credential and verification rules before returning the authentication result. The HID approach means the device can appear to applications in the same general class as a normal USB security key rather than requiring a separate device driver.

User presence is tied to a physical button. That is separate from PIN-based user verification, which addresses a different condition. Applications can therefore distinguish an operation requiring physical confirmation from one that also requires the authenticator's PIN. The LED provides an observable state channel: the README documents a near-continuous pattern while waiting for a button press, a mostly off idle pattern, four blinks per second when active and twenty blinks per second while processing. Processing means the authenticator cannot accept another command until the current one completes.

Credential handling includes discoverable credentials, expiration and revocation metadata, credential management and configurable restrictions on creating resident credentials. Extensions include HMAC-Secret, CredProtect, `minPinLength`, self-attestation, enterprise attestation, `credBlobs` and `largeBlobKey`. Large blobs are documented with a 2048-byte maximum. Authenticated import and export uses the open-source Pico Vault and is described in a linked proposal and implementation notes under `docs/vault`. The README does not provide enough implementation detail to claim more about that protocol than those documents state.

Building the Raspberry Pi Firmware Locally

The README describes a CMake build for Raspberry Pi boards. It first requires an installed Pico toolchain and a Pico SDK located on the drive. The documented clone and submodule setup is:

git clone https://github.com/polhenarejos/pico-fido
git submodule update --init --recursive
cd pico-fido
mkdir build
cd build

These commands create the local repository, initialize its submodules recursively and create the build directory. Configure the build by setting `PICO_SDK_PATH` to the actual SDK location. The three CMake options shown by the README are optional, and the documented command is:

PICO_SDK_PATH=/path/to/pico-sdk cmake .. -DPICO_BOARD=board_type -DUSB_VID=0x1234 -DUSB_PID=0x5678

Without those options, the build uses the `pico` board and VID/PID `FEFF:FCFD`. The README also documents a `VIDPID=value` parameter with supported identifiers including `NitroFIDO2`, `Yubikey5`, `Gnuk` and `GnuPG`. Such identifiers affect USB identity; the documentation warns not to distribute a binary with a VID/PID the distributor does not own.

Compile with the documented command:

make

The README states that this produces `pico_fido.uf2`. To load it, hold `BOOTSEL` while connecting the board, wait for the USB mass-storage device, and copy that UF2 file to it. The storage device should disconnect and the board should reset. A blinking LED then indicates readiness. That is the first useful state to check before attempting registration or login in a WebAuthn-compatible application.

Flashing ESP32-S3 and Selecting the Correct Image

Pico FIDO is not installed with a package manager. For a purchased ESP32-S3 board, the README directs users to the ESP32 Flasher on the project's website. For Raspberry Pi Pico boards using RP2040 or RP2350, it directs users to the Download page, where they select the vendor and model, or to the GitHub Release page for a board-specific UF2 file.

That selection step matters because the hardware security boundary changes by MCU. RP2350 and ESP32-S3 can use Secure Boot and Secure Lock. According to the README, an MKEK can be stored in one-time programmable memory that is inaccessible from outside secure code. That master key encrypts the device's private and secret keys, including resident keys and seeds, which helps protect against flash-memory extraction. One-time programming is used to store the master key itself.

RP2040 does not provide the same mechanism. The README says that encryption of a master key is not feasible on that chip because the master key would remain readable in flash. Consequently, the firmware may still function as a FIDO authenticator on RP2040, but theft of the device can expose its stored keys. Secure Boot and Secure Lock should therefore be treated as hardware selection requirements for a serious deployment, not optional descriptions independent of the board.

Released UF2 files use a Raspberry Pi VID/PID, documented as `2E8A:10FE`. Tools such as OpenSC may need that identifier added to the CCID driver's `Info.plist`. The README instead favors PicoKey App for firmware handling. It does not document an automated command for flashing ESP32-S3, so no ESP32 build or flashing command should be inferred from the Raspberry Pi tutorial.

RP2040 Exposure, Recovery and Policy Trade-offs

The clearest limitation is physical compromise of an RP2040 device. Unlike RP2350 and ESP32-S3, it cannot protect a master key from a flash dump. A user may still use PIN verification, physical-button confirmation and credential policies, but those controls do not remove the README's stated risk that stored private or secret keys may be exposed after theft. If the credential's exposure would affect an account or system beyond the owner, RP2040 is the wrong hardware choice.

Recovery is another operational concern. Pico FIDO includes a Rescue interface intended to recover a device that becomes unresponsive or undetectable. The README does not describe the complete rescue procedure, its prerequisites or whether every failure mode is covered. That omission should be checked in the project documentation before relying on rescue as part of an operational plan. Similarly, the README lists 24-word backup but does not give a complete backup and restoration tutorial.

Policy configuration creates deliberate trade-offs. Administrators can deny creation of resident or discoverable credentials, which is useful when broad credential creation is undesirable. PIN complexity policy, credential expiration and revocation metadata provide additional controls. At the same time, locked-down policies can prevent workflows that depend on discoverable credentials. A PIN-protected authenticator is not automatically a backup strategy, and the project's credential export mechanism should be evaluated separately from the hardware encryption claims.

Pico FIDO Versus Pico FIDO2 and Dedicated Keys

The repository itself identifies `polhenarejos/pico-fido2` as the relevant alternative when the requirement is OpenPGP plus FIDO. That is a concrete functional difference. Pico FIDO concentrates on passkeys, CTAP, U2F, OATH, credential management and authenticator policy. Pico FIDO2 is presented as the OpenPGP and FIDO option, and the README says it is available through PicoKey App. Users who require an OpenPGP credential workflow should not assume that adding OpenPGP to this firmware's requirements can be satisfied by its listed FIDO features.

A commercial dedicated security key is another different approach because Pico FIDO depends on a general-purpose microcontroller platform and custom firmware. The README does not provide a feature-by-feature comparison with named commercial models, so such a comparison would require outside evidence. Its documented differentiators are source availability, support for Pico and ESP32 targets, vendor-specific flashing paths, Pico Vault import and export, configurable policy and an emulated keyboard interface.

Those capabilities also increase configuration scope. Dedicated keys normally arrive as integrated products, whereas Pico FIDO requires selecting the right board and firmware image, considering its VID/PID, and deciding whether OTP-backed key protection is required. The trade is control over firmware and hardware against the need to manage those choices correctly.

AGPL-3.0 and the Cost of Pico FIDO Upgrades

Pico FIDO is distributed under AGPL-3.0. The repository contains `LICENSE`, `CONTRIBUTING.md`, `SECURITY.md` and `ENTERPRISE.md`, but the README does not explain licensing exceptions or distribution procedures. Anyone modifying and distributing the software, or incorporating it into a product, should review the actual `LICENSE` text with qualified counsel. This article does not interpret what a particular deployment legally requires.

Maintenance activity is recent. The repository is not archived, and the last push was on 2026-09-30. Version `v8.0` was released on 2026-08-23, while the listed nightly-main and nightly-development releases date from 2024-09-25. These dates show that stable and nightly artifacts have different recency histories, but they do not establish how frequently users should expect updates.

Upgrade cost depends on firmware format and hardware. A Raspberry Pi board can receive `pico_fido.uf2` through its mass-storage boot process, while ESP32-S3 users are directed to a separate flasher. A board-specific binary and USB identity must remain correct. Changes to secure storage can also affect recovery, backup and enrolled credentials, although the README does not document a rollback procedure or migration guarantees. Before replacing firmware, an operator would need to verify the board model, release artifact, Secure Boot and Secure Lock state, available backup and documented recovery behavior.

Editorial conclusion

Adopt Pico FIDO if you need a programmable USB passkey authenticator and can select an RP2350 or ESP32-S3 board with Secure Boot and Secure Lock. Do not choose RP2040 for credentials whose exposure would have serious consequences, because its flash can expose stored keys. Before deployment, verify the exact MCU model, recovery procedure, VID/PID policy, resident-credential policy and firmware provenance against the intended use.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. polhenarejos/pico-fido on GitHub
3. Project website
4. README
5. Releases