PQSecure™-Boot

Quantum-safe secure boot

PQSecure™-Boot is designed for constrained Root-of-Trust environments, combining verify-only optimization, low footprint, and multi-algorithm quantum-safe authentication and attestation. It is available in both hardware and software implementations.

Start an evaluation PQSecure™-Boot datasheet

Signature algorithms

Standard and role

Module Standard Type
ML-DSA FIPS 204 Lattice
LMS RFC 8554 Stateful hash
SLH-DSA FIPS 205 Stateless hash

The first thing that runs has to be the right thing

Secure boot is the foundation of trust in a connected system. PQSecure™-Boot verifies that only authentic, authorized firmware or operating system images execute at startup, in either software or silicon depending on where the trust anchor lives.

How PQSecure™-Boot authenticates firmware at startup, including its protection against fault injection. PQSecure on YouTube

One job, two places to do it

The same quantum-safe verification, delivered as a software library for existing processors or as hardware IP for a silicon Root-of-Trust. Both support the same three signature algorithms.

Implementations

Form, role, and detail

  • PQSecure™-Boot-SW

    Software libraries for embedded processors, bootloaders, and firmware

    Verified with

    • NIST ACVP certified for all algorithms
    • PSA Certified APIs
    • Fault injection protection

    Implementation

    • C and Rust, under 5 KB RAM
    • ML-DSA, LMS, and SLH-DSA verification flows
    • Deploys on existing processor platforms

    Used for

    • Secure boot and firmware verification
    • Secure update

  • PQSecure™-Boot-HW

    Hardware IP for ASIC, FPGA, SoC, and secure enclave integration

    Verified with

    • FIPS compliant, certified under ACVP
    • Optional fault injection protections

    Implementation

    • Under 35 kGE at 65 nm, above 500 MHz
    • Integrated hashing and flexible memory architectures
    • ML-DSA, LMS, and SLH-DSA

    Deploys on

    • ASIC, FPGA, and SoC platforms
    • Root-of-Trust and secure enclave architectures

Two hardware variants

The hardware IP trades silicon area against verification speed, so the same Root-of-Trust design fits a tightly constrained die or a part that has area to spend.

  • Hardware variant

    Boot-T

    Tiny

    Silicon area
    Smallest, under 35 kGE at 65 nm
    Performance
    Lower than Boot-C
    Frequency
    Above 500 MHz on target technology

  • Hardware variant

    Boot-C

    Compact and fast

    Silicon area
    Larger than Boot-T
    Performance
    Higher verification throughput
    Deploy on
    ASIC, FPGA, and SoC
Diagram comparing the Boot-T and Boot-C hardware variants, with performance rising as silicon usage falls
Boot-T and Boot-C on the area against performance axis.

Verification is the operation that matters

A boot chain verifies far more often than it signs, so PQSecure™-Boot is optimized for the verify path. Measured on a Cortex-M4 at 100 MHz, in under 5 KB.

Bar chart of ML-DSA verification time in milliseconds for libpqsecure against a competitor at parameter sets 44, 65, and 87
ML-DSA verification on a Cortex-M4 at 100 MHz, in milliseconds. Lower is better. The chart is captioned by PQSecure as showing libpqsecure over 28% faster.
Diagram showing a protected boot core verifying a firmware image before it runs on an embedded board, marked as fault-injection protected
Verification sits between the boot core and the image it authorizes.

Where it goes

Built for platforms whose firmware has to stay verifiable for as long as the hardware is in service.

Engineered for

  • Embedded devices and IoT products
  • Secure processors and Root-of-Trust
  • FPGA prototypes and ASIC implementations
  • Defense and aerospace platforms
  • Automotive and industrial systems
  • Long-lifecycle platforms

We combine

  • Multi-algorithm quantum-safe authentication
  • Software and hardware implementations
  • High performance and low latency
  • Ultra-low footprint
  • Fault injection resistance
  • Formally verified

to deliver quantum-safe secure boot from the first instruction.

Trust that starts before the firmware does.

Talk with our team about Root-of-Trust integration, target platforms, and whether the hardware or software path fits your design.

Contact us