Espressif has published esp-pqc, an ESP-IDF component that adds two NIST-standardised post-quantum algorithms to its SoCs: ML-KEM for key exchange and ML-DSA for signatures. The company introduced it in a developer blog post on 14 October 2026. The code is open source under the Apache-2.0 licence and is available now on Espressif's official GitHub organisation. The repository was created on 20 August 2026 and last pushed on 5 October 2026. Espressif is also clear about its status. The README says: "esp-pqc is for experimentation and evaluation only. It is not a production solution."
The component covers two uses. The first is hybrid TLS 1.3, which pairs the X25519MLKEM768 key exchange with ML-DSA-65 certificates. The second is an experimental verify-only ML-DSA-65 signature check in the second-stage bootloader, which runs ahead of the classical Secure Boot V2 check.
How it is built
esp-pqc runs entirely in software. It is built on an Espressif fork of liboqs and an mbedTLS override, and it does not change core ESP-IDF files. Applications get the liboqs-style OQS_KEM_* and OQS_SIG_* APIs. The mbedTLS override is selected by CONFIG_MBEDTLS_USE_BUNDLED_PQC, which defaults to y. Randomness comes from the SoC's hardware RNG through esp_fill_random.
The component requires ESP-IDF v6.0 or later. Espressif describes it as supporting all its SoCs, and the README names ten supported targets: ESP32, ESP32-C2, ESP32-C3, ESP32-C5, ESP32-C6, ESP32-C61, ESP32-H2, ESP32-P4, ESP32-S2 and ESP32-S3. Two features have narrower support:
- The TLS examples need Wi-Fi and 4 MB flash.
- Bootloader verification supports only the ESP32-C3, ESP32-C5 and ESP32-C6.
The repository includes four examples: kem_basic, signature_basic, esp_hybrid_tls and pqc_boot_verify.
The standards underneath
NIST published FIPS 203 on 13 August 2024. It defines ML-KEM, a module-lattice-based key-encapsulation mechanism for establishing a shared secret key over a public channel. ML-KEM-768 is the post-quantum half of the X25519MLKEM768 hybrid key exchange that esp-pqc implements. The companion standard, FIPS 204, defines the ML-DSA signature scheme. Espressif says future SoCs will integrate dedicated post-quantum hardware acceleration and built-in PQC secure boot verification; esp-pqc is its way to evaluate the algorithms on current silicon in the meantime.
Hybrid TLS 1.3: larger messages
Post-quantum public keys, ciphertexts and signatures are larger than classical ones, which Espressif notes matters on metered, low-bandwidth or frequently connected networks. Its post compares the classical and post-quantum objects:
| Item | Classical | Post-quantum / hybrid |
|---|---|---|
| Key share | X25519: 32 bytes | X25519MLKEM768: 1,216 bytes |
| Public key | ECDSA-P256: ~64 bytes | ML-DSA-65: 1,952 bytes |
| Signature | ECDSA-P256: ~64 bytes | ML-DSA-65: 3,309 bytes |
Espressif tested the hybrid handshake on an ESP32-C5. It negotiated TLS1-3-AES-256-GCM-SHA384 and completed in approximately 300 ms, including local network round trips. Espressif notes that actual latency depends on network round-trip time, packet loss and certificate-chain depth.
Post-quantum Secure Boot check
The pqc_boot_verify example adds an ML-DSA-65 check to the second-stage bootloader. It does not replace Secure Boot V2. The firmware image carries both signatures: a 4 KB Secure Boot V2 sector plus an 8 KB PQC block, for 12 KB appended in total.
Espressif measured the boot-time cost on "an ESP32-C5 running at 80 MHz", with RSA-3072 as the classical algorithm:
- SHA-256 over image and classical sector (hardware): ~30 ms (2,465,694 cycles)
- ML-DSA-65 verify (software): ~44 ms (3,533,980 cycles)
- RSA-PSS-3072 verify (hardware): ~13 ms (1,095,604 cycles)
- Total hybrid boot verification: ~91 ms (7,328,597 cycles)
Espressif sums up the result as: "Post-quantum verification adds only ~78 ms to boot time and 8 KB of flash overhead." The same ML-DSA-65 verify takes about 22 ms in the signature_basic FreeRTOS example, compared with about 44 ms in the bootloader.
What is missing
The README sets clear limits. Espressif silicon has no hardware support for post-quantum cryptography yet, so the algorithms run in software on the CPU. Post-quantum keys have no eFuse-backed storage, and there is no hardware key revocation for them. The README also labels pqc_boot_verify experimental, and warns that side-channel resistance depends on the upstream liboqs and mbedTLS implementations and on how they are used, so a risk assessment is needed before any production use. Espressif's post adds that the ML-DSA private key is as important as the Secure Boot V2 private key: a lost or compromised key prevents trusted firmware updates.
What It Means for Makers
esp-pqc is for developers who want to try post-quantum TLS or signed-firmware workflows on Espressif parts now. Espressif positions pqc_boot_verify as a way to measure boot latency, flash overhead and memory use of post-quantum verification within an existing boot flow, and the README points to esp_hybrid_tls as the starting point for an HTTPS client, an OTA download or a telemetry uplink. It is not meant for shipping products.
Practical notes:
- Projects on IDF releases older than v6.0 have to upgrade before adding the component.
- The README warns that the APIs and Kconfig option names can still change between releases; pin a release tag for a fixed base, or track
mainfor the newest work. - The TLS example talks to an OpenSSL server, and post-quantum certificates need larger TLS I/O buffers and more SRAM than classical ones.
- Keys and certificates under
examples/are for testing only, andpqc_boot_verifyships no keys, so developers generate their own.
The component and its four examples are available now from the espressif/esp-pqc repository. Espressif's blog post explains the design and the measurement setup.
