Altera Ships ML-DSA Secure Boot on Agilex FPGAs – PQC Reaches the Silicon Root of Trust

September 8, 2026 – Altera Corporation announced post-quantum cryptography support for its Agilex 3 and Agilex 5 field-programmable gate arrays, with PQC-enabled secure boot shipping in current production devices. The implementation uses ML-DSA (FIPS 204) for firmware authentication during the boot sequence.

Altera described the Agilex family as the first commercial FPGA product line with post-quantum secure boot as a shipping feature. Quartus Prime Pro Edition 26.1.1 provides the supporting software flow for customers to implement PQC secure boot protections.

“Customers building long-life systems need confidence that the hardware they choose today can adapt to tomorrow’s security requirements,” said Mike Fitton, vice president of product and corporate marketing at Altera.

The Agilex Secure Device Manager also provides bitstream encryption for IP protection, physical anti-tamper support, key management, physically unclonable function keys, embedded cryptographic cores, and platform attestation. Altera stated that its PQC-enabled FPGAs are designed to support additional software and firmware security enhancements as post-quantum requirements evolve.

Altera, the former Intel Programmable Solutions Group, became an independent FPGA company in January 2025 after Intel spun off the division. Silver Lake subsequently acquired a majority stake. The company is headquartered in San Jose, California, and describes itself as the world’s largest pure-play FPGA solutions provider.

Agilex 3 and 5 are system-on-chip FPGAs with integrated ARM processor subsystems, designed for embedded and edge applications across telecommunications, defense, aerospace, industrial automation, and data center markets. The devices’ reprogrammable architecture enables field updates as security requirements and cryptographic standards change.

My Analysis

The press release is short and lightly detailed. Altera names ML-DSA and the two Agilex families, and it says the feature is “shipping today.” Most PQC hardware news concerns roadmap pledges for future products, whereas Altera’s feature is already in production devices.

What Altera Actually Shipped

Secure boot is the hardware root of trust. It is the first code that runs when a device powers on, and its job is to verify that every subsequent layer of firmware and configuration is authentic before execution. A compromised secure boot chain means the device is compromised before the operating system, the application, or any network-layer defense has a chance to intervene.

In FPGAs, this is especially consequential. An FPGA’s defining feature is that its logic is reconfigurable – the “bitstream” loaded at boot defines what the device does. A forged bitstream is not just malware; it is a complete replacement of the device’s function. The Secure Device Manager in the Agilex family authenticates that bitstream using a digital signature, and as of September 8, that signature can use ML-DSA.

The Trust Now, Forge Later threat – where a quantum adversary forges a signature to inject malicious firmware that passes verification – is the specific attack vector this addresses. TNFL is the integrity-side analog of Harvest Now, Decrypt Later, and in firmware-signing contexts, it is the harder problem to remediate after the fact. Moving a device that ships with a classical-only root of trust to PQC requires a firmware update. The device must verify that update with the existing quantum-vulnerable mechanism. In the CNI/OT extension of my PQC Migration Framework, I identify this circular dependency as one of the sector’s defining challenges.

By shipping ML-DSA in the Secure Device Manager from the factory, Altera eliminates the circular dependency for new deployments. The device arrives with a PQC-capable trust anchor. That is a different starting position from an FPGA that ships with RSA-2048 or ECDSA secure boot and a vendor promise to deliver PQC “in a future firmware update.”

What the Press Release Does Not Say

Altera does not disclose the ML-DSA parameter set. FIPS 204 defines three: ML-DSA-44, ML-DSA-65, and ML-DSA-87. CNSA 2.0 requires ML-DSA-87 for National Security Systems. To evaluate Agilex for an NSS application, a defense procurement officer needs to know whether the Secure Device Manager supports ML-DSA-87. The press release does not say.

The announcement also omits any mention of LMS or XMSS (SP 800-208), the stateful hash-based signature schemes that CNSA 2.0 specifically designates for software and firmware signing. NSA’s guidance recommends beginning the firmware-signing transition with LMS and XMSS, not ML-DSA, for precisely the use case Altera is advertising. ML-DSA is the general-purpose signature algorithm; LMS is the firmware-signing algorithm in the CNSA 2.0 architecture. Whether the Agilex SDM also supports SP 800-208 signatures, or whether ML-DSA is the only PQC option, is unstated.

There is no mention of FIPS 140-3 validation. The September 21, 2026 sunset of FIPS 140-2 just passed – every remaining FIPS 140-2 certificate moved to the Historical list. For federal procurement of new systems, only FIPS 140-3 validated modules qualify. Whether the Agilex SDM’s cryptographic implementation is undergoing FIPS 140-3 validation, or whether Altera expects to pursue it, is not addressed. For commercial deployments, this may not be a blocking issue. For defense and federal applications, it is a procurement gate.

And the announcement does not describe hybrid signing – dual-signature verification with both classical and PQC algorithms. My own framework, and multiple national guidelines including ANSSI’s 2024 position and BSI’s standing recommendation, specify hybrid mechanisms for the transition period. Whether PQC secure boot replaces classical authentication entirely or runs alongside it as a hybrid is an architectural detail the press release leaves open.

[EDITOR: Verify – contact Altera PR to confirm: (1) ML-DSA parameter set supported, (2) SP 800-208 / LMS support status, (3) FIPS 140-3 validation status, (4) hybrid classical+PQC boot option]

The Competitive Landscape Is Narrower Than It Appears

Altera’s “first” claim requires precision. Lattice Semiconductor announced the MachXO5-NX TDQ in October 2025 as the first CNSA 2.0-compliant PQC-ready FPGA with a hardware root of trust, supporting ML-DSA, ML-KEM, LMS, and XMSS. Lattice also demonstrated a PQC-secured FPGA bitstream authentication at Embedded World 2026, in partnership with SEALSQ’s QVault TPM. And on September 16 – eight days after Altera’s announcement – Lattice unveiled the Mach-N2 with full CNSA 2.0 support, which Lattice positioned explicitly against Altera’s Agilex 3 and 5.

But these are different product categories. The MachXO5-NX TDQ and Mach-N2 are secure control FPGAs – small, low-power devices whose primary function is platform management: securing the boot of other components on a board, managing firmware updates, and monitoring system integrity. They are the watchdog, not the workhorse. The Lattice-SEALSQ demonstration used an external TPM as the PQC trust anchor, with the FPGA as the execution layer.

Agilex 3 and 5 are general-purpose SoC FPGAs – the devices that run the actual workload in a 5G radio unit, a defense signal-processing system, an industrial controller, or a financial-services acceleration platform. PQC secure boot in a general-purpose FPGA means the device that processes the data, not just the chip that watches over it, authenticates its own firmware with post-quantum signatures.

Because Lattice’s PQC devices are secure control FPGAs, Altera’s “first” claim is defensible for general-purpose FPGAs. At the secure-control layer, however, Lattice leads, and its CNSA 2.0 algorithm coverage – including LMS and XMSS – is broader than what Altera has disclosed.

Microchip, the third major FPGA vendor since acquiring Microsemi, published a blog in March 2026 on PQC implementation for its FPGAs but has not announced a shipping PQC secure boot feature. AMD (which acquired Xilinx) has made no public PQC secure boot announcement for its Versal or Artix product lines.

Why the Timing Is a Procurement Signal

The CNSA 2.0 acquisition gate takes effect on January 1, 2027. From that date, new procurement for National Security Systems must support CNSA 2.0 algorithms. Defense acquisition programs run 18 to 36 months from requirements definition to delivery. A program defining requirements today for a 2028 delivery must already specify CNSA 2.0-capable components.

For software and firmware signing specifically, CNSA 2.0 set an even earlier signal: support and prefer PQC by 2025, exclusive use by 2030. The FIPS 140-2 sunset on September 21, 2026 sharpened this further by eliminating older validated modules from new federal procurement.

Altera announced PQC secure boot 13 days before the FIPS 140-2 sunset and less than four months before the CNSA 2.0 acquisition gate. An FPGA specified into a defense, critical infrastructure, or telecom platform today will be in service for 10 to 20 years. If PQC-enabled secure boot silicon is commercially available now, procurement teams need to justify specifying devices without it – not the other way around.

This is the procurement-forcing dynamic I have written about in the context of Q-Day deadlines. The exact arrival date of a cryptographically relevant quantum computer remains uncertain. The procurement deadlines, by contrast, are published and binding, with the next one on January 1, 2027. Silicon vendors who can demonstrate shipping PQC capability ahead of those deadlines gain a specification advantage that is difficult for competitors to close retroactively.

What This Means for PQC Migration Programs

For organizations running PQC migration programs that include FPGA-intensive infrastructure – telecommunications operators, defense integrators, industrial automation companies, financial services firms with FPGA-accelerated trading platforms – Altera’s announcement has three immediate implications.

First, it validates that PQC at the silicon root-of-trust layer is a production reality, not a 2028 aspiration. Migration plans that assumed PQC secure boot would not be available in general-purpose FPGAs until a later hardware generation need to be updated. The hardware has moved.

Second, it creates a procurement evaluation criterion that did not exist a month ago. Every FPGA vendor evaluation for long-lifecycle infrastructure should now include PQC secure boot capability as a line item. Evaluators should confirm the specific algorithms, parameter sets, validation status, and hybrid support in each vendor’s technical documentation.

Third, and most consequentially, it demonstrates that PQC migration is not happening in the sequence most enterprise programs planned. The common assumption was that software and protocol layers would migrate first, with hardware catching up later. Instead, silicon vendors are shipping PQC in production devices while many enterprises are still inventorying their cryptographic dependencies. The hardware is moving faster than the enterprise migration plans it depends on.