V2X PQC FAQ

These are different layers and they solve different problems. ML-DSA-87 sits on the backend telemetry envelope: vehicle edge ECU to ingestion gateway, gateway to detection pipeline, detection to archival storage. The signature sizes around 4.6 KB are acceptable on this path because the transport is TCP or QUIC over cellular or Ethernet, not bandwidth-constrained V2X broadcast. FALCON-512 sits on the V2X broadcast path: BSM and DENM messages over PC5 sidelink or ITS-G5. The signature is around 666 bytes, which is the smallest of the NIST PQC signature schemes and the only one with a realistic path to fitting V2X frame budgets. Mixing these up leads to the objection that ML-DSA-87 cannot fit a BSM, which is true and which is also not something we propose.

Not on its own, and not on legacy ITS-G5. A FALCON-512 envelope with an explicit certificate runs to around 2,200 bytes against an ITS-G5 / DSRC MTU of 1,400 bytes. It fits 5G-V2X PC5 sidelink, which has a larger MTU. For legacy ITS-G5, fitting the budget requires layered mitigations: selective signing across BSM and DENM streams during the legacy ITS-G5 phase, fragment-aware MAC handling, implicit certificate chains where the structure is mature enough to deploy, and hybrid cert handling out of band rather than on every frame. No single mitigation is sufficient; the deployed solution combines several. Our roadmap targets full per-message signing on DENM event messages as 5G-V2X PC5 deployment and bandwidth optimisations mature.

Not yet. Implicit certificates over elliptic curves (ECQV) rely on properties of the discrete log group that do not have clean analogues in lattice-based cryptography. Active research is exploring constructions that recover most of the size benefit, but none of them are standardised today, and the constructions that exist in the literature have not been peer-reviewed at the level production V2X demands. The 900-byte figure is a target our internal prototypes are working toward; it is not a deployable artefact today. Production deployments through 2027 will use explicit FALCON or ML-DSA certificates with the larger byte cost. We will update this answer as the field matures.

Real-time signature verification is not threatened by future quantum attack: a packet a gateway has already verified today is not unverified later. The wording refers to a different case: signed telemetry records held in long-term archival storage for regulatory disclosure, incident reconstruction, and forensic chain of custody. A record signed with ECDSA in 2027 and produced as evidence in a 2034 regulatory dispute can be repudiated or forged if ECDSA has fallen by then. That is a real HNDL-equivalent threat for signatures on archived records, and it is why the cryptographic envelope on the VSOC page specifies ML-DSA-87 for record signing and SLH-DSA for long-term archive. The page wording has been tightened to make this distinction explicit rather than implied.

Size. FALCON-512 signatures are around four times smaller than ML-DSA-44 and seven times smaller than ML-DSA-87. On a bandwidth-constrained broadcast channel, signature size is the dominant constraint and FALCON is the only NIST PQC signature scheme that gets within reach of V2X budgets. FALCON is harder to implement correctly because signing requires constant-time floating-point operations to avoid side-channel leakage, and bare-metal automotive ECUs are not natively constant-time on floating-point. The implementation challenge is real and we are not minimising it. Researchers have proposed integer-only FALCON variants that sidestep the floating-point problem; these are at varying stages of maturity and have not yet been measured by us on automotive silicon in a way we would cite. Production FALCON in automotive contexts today depends on either hardware-assisted signing with documented side-channel properties, or signing offloaded to a hardware security module that handles the floating-point in isolated silicon. The upcoming benchmark programme measures FALCON timing on a representative automotive M7 board and reports which path is viable in practice.

The concern is legitimate and we want to be direct about where we currently sit. The selective signing scheme we describe applies across the V2X message stream including DENM event messages, not only periodic BSMs. This reflects the bandwidth reality on legacy ITS-G5: full per-message signing with PQC envelopes on every DENM exceeds channel capacity in dense scenarios, and the deployed industry trade-off today is the same one we describe.

The latency window this creates is the right thing for a reviewer to challenge. A hard-braking event arriving on an unsigned interim packet either gets acted on without full authentication, weakening the security argument, or waits for the next signed packet in the chain, adding latency to an ADAS control loop. Neither side of that trade is comfortable.

The path to full per-message signing on DENMs is mapped in our internal technical roadmap. It requires moving from legacy ITS-G5 to 5G-V2X PC5 for the larger MTU, combined with implicit certificate chains mature enough to deploy, hybrid certificate handling out of band rather than on every frame, and FALCON signing fast enough on the target ECU to meet the message cadence without selective shortcuts. The upcoming benchmark programme measures whether these conditions can be met on representative automotive silicon, which is the first concrete step on that roadmap. Execution beyond the benchmark depends on the same engineering capacity that the V2X PQC market broadly is competing for; we will publish progress as conditions and resourcing allow.

Until then, the selective signing scheme with freshness counter is what we deploy. Reviewers asking about hard-braking latency are asking the right question; the answer is that the industry trade-off is currently selective signing for everyone, and the engineering work to change that is in progress.

We treat it as an open implementation problem rather than a solved one. The deployment paths under consideration are: a hardware FPU with documented side-channel properties (some automotive M7 and above parts qualify, others do not), an integer-only FALCON variant (proposed in the research literature, not yet measured by us on automotive silicon), or signing offloaded to a hardware security module that handles the floating-point in isolated silicon. Which path is right depends on the specific ECU, the HSM strategy, and the threat model. The upcoming benchmark programme measures FALCON signing on a representative automotive M7 development board and publishes the measured timing variance, which is the empirical question underneath the constant-time concern.

For a BSM with a FALCON-512 envelope: payload 200 to 400 bytes, FALCON-512 signature 666 bytes, FALCON public key in the certificate around 900 bytes, 1609.2 security headers around 100 bytes. Total roughly 1,800 to 2,000 bytes. This exceeds the 1,400-byte ITS-G5 MTU and fits the larger 5G-V2X PC5 MTU. For a BSM with an ML-DSA-44 envelope: payload 200 to 400 bytes, ML-DSA-44 signature 2,420 bytes, certificate around 1,300 bytes, headers. Total roughly 4,000 to 4,500 bytes, which exceeds both. For a BSM with an ML-DSA-87 envelope: total roughly 8,000 to 9,000 bytes, which is incompatible with V2X broadcast and is not proposed for that path. The diagram on the V2X PQC page shows these comparisons.

The language is being tightened. "What we ship" referred to our recommended deployment design and the cryptographic schemes we recommend OEMs adopt today for new platform development. It did not claim that every component is in field deployment at scale. Production V2X PQC deployment is in pilot and early-deployment phase across the industry as of 2026; nobody is shipping at fleet scale yet. Our deployment design is what we recommend platforms be architected for, with the explicit understanding that some components (lattice-based implicit certs, FALCON on bare-metal at scale, hybrid cert handling) are still maturing. The published site copy has been updated to reflect this distinction.

The numbers on the current site are drawn from specifications, standards documents, and the available and viable measurement work from the field. A benchmark programme is underway to produce our own measurements on automotive grade NXP silicon, covering bandwidth and on-air frame sizes, FALCON and ML-DSA signing and verification timing, constant-time behaviour, and selective signing end-to-end latency. Timeline is four to six weeks from kick-off. The methodology, results, and raw data will be published as a technical note on this site. Where the measurements force a correction to current claims, the corrections will be made openly.