Why our V2X bandwidth budget breaks the moment you add ML-DSA

In August 2024, NIST finalised the first wave of post-quantum cryptographic standards. FIPS 203, 204, and 205. The selection process took eight years. The standards are good. They are also, in their published form, incompatible with how vehicles talk to each other.

This is not a controversial claim inside the V2X engineering community. It is, however, a claim that has not made it into most of the marketing material around post-quantum migration. The standards work. The deployment work is hard. And the part that is hardest, the part that breaks first, is bandwidth.

We have spent the past year working with OEMs on what a real V2X PQC migration looks like, and we keep ending up in the same conversation. Someone proposes substituting ML-DSA for ECDSA in the SCMS or C-ITS CCMS certificate format, the way you would substitute one signing algorithm for another in a TLS handshake. And then a transport engineer in the back of the room raises their hand and asks how the resulting frame fits in 1,400 bytes.

It doesn't. The rest of the post is about what to do about that.

The constraint that does not bend

V2X messages live inside a layer-2 frame budget that is fixed by the radio standard. ETSI ITS-G5, which runs on 802.11p, has an effective payload ceiling near 1,500 bytes once the MAC headers are accounted for. 3GPP V2X PC5, the cellular sidelink, is comparable. DSRC in the US, also comparable. The number we use as a working ceiling for design discussions is 1,400 bytes. It is the number every V2X engineer carries around, and it is the constraint that determines whether your message reaches the next car.

Why does the ceiling matter so much? Because V2X messages are designed to be sent ten times a second, broadcast to anyone in range, and processed in real time. There is no retry. There is no TCP-style reassembly with timeouts measured in seconds. A Basic Safety Message that does not arrive in one frame is, for practical purposes, lost. Fragmentation at the MAC layer makes things worse, not better — multiple frames mean multiple chances to lose part of the message, and the entire payload has to be reconstructed before the application can verify the signature.

A vehicle making a left turn at an intersection is computing whether to brake based on BSMs from cars it cannot see directly. If twenty percent of those messages drop because the cryptographic overhead pushed them past the frame budget, the safety case for V2X collapses. This is not a theoretical concern. It is the reason the C-ITS deployments in Europe ran their certificate sizes through MAC-layer fragmentation analysis before approving anything.

What the numbers actually look like

Today's V2X frame, with ECDSA P-256 signing, looks roughly like this. The numbers vary by deployment but the order of magnitude does not.

The ECDSA frame is about 580 bytes end to end. Most of that is the payload itself — vehicle position, speed, heading, brake status, and so on. The signature is 64 bytes. The certificate is around 120 bytes when implicit certificates are used. There is room left over. The frame fits.

Now substitute ML-DSA-44, the smallest of the FIPS 204 parameter sets. The signature alone is 2,420 bytes. The certificate carrying an ML-DSA public key is around 1,300 bytes. The frame is now about 4,500 bytes. It overflows the budget by more than three kilobytes. MAC-layer fragmentation kicks in. Effective range drops. The safety case starts to come apart.

This is the conversation that breaks rooms. The post-quantum signature scheme that won the NIST competition for general-purpose use is roughly 38 times larger than the ECDSA signature it would replace. The certificate is bigger. The handshake is bigger. The verification time on a constrained ECU is slower. Every one of those is a real problem. The bandwidth one is the most visible.

The naive substitution doesn't work, and that's a feature

Here is the part that is sometimes hard to communicate up the chain. The naive substitution failing is the right outcome. If you could drop ML-DSA into an unmodified V2X stack and have it work, the standards would have failed at their actual job, which is to be cryptographically robust under post-quantum attack. The signatures are big because the security argument requires them to be big. The lattice constructions that resist quantum attacks need that much room to be hard.

The migration cannot be a substitution. It has to be a redesign of the parts of the stack that interact with the cryptography. That includes the certificate format, the message format, the validation pipeline, and in some cases the radio scheduling. The good news is that the standards bodies anticipated this. ETSI TR 103 619 lays out a migration framework. IEEE 1609.2.1 introduces a more flexible certificate format. None of this is a surprise to the working groups. It just hasn't made it into the procurement documents yet.

What we actually ship

The working solution is layered. Each layer trims bytes from the frame. None of them is sufficient alone.

FALCON, not ML-DSA, on the wire

FALCON is the lattice-based signature scheme that NIST selected alongside ML-DSA, intended for size-constrained applications. FIPS 206 is still in draft as of late 2024, but the algorithm itself is stable. The signature is 666 bytes for FALCON-512, about a quarter of an ML-DSA signature. The certificate is correspondingly smaller. The performance hit on verification is real but tolerable for V2X.

The trade-off is implementation difficulty. FALCON signing requires floating-point operations done in a specific order to avoid timing side channels. Doing FALCON correctly on a constrained ECU is harder than doing ML-DSA correctly. Most HSM vendors are still shipping ML-DSA first and FALCON later. For V2X, that ordering is exactly backwards.

Implicit certificates with PQ-friendly chains

Most current V2X deployments use implicit certificates — the public key is derived from the certificate itself rather than transmitted alongside it. Implicit certificates were a clever optimisation for ECC. They translate awkwardly to lattice-based schemes, but a careful redesign can preserve most of the benefit. We have prototype designs that get the post-quantum certificate down to about 900 bytes by combining FALCON-512 with a reworked implicit-cert structure.

Selective signing, not blanket signing

Not every V2X message needs a full signature. Most BSMs are status updates — position, heading, speed — that get re-sent ten times a second. If you sign every tenth message and reference the signed message in the intervening ones, you have a chain of trust without the bandwidth penalty. The receiver verifies one signature and trusts the chain forward for one second. This is a known pattern in the V2X literature, sometimes called tesla-style in reference to the TESLA broadcast authentication protocol. It cuts effective signature overhead by an order of magnitude.

The catch is that selective signing introduces a small window of authenticated-but-stale data. The receiver has to handle that window carefully, because an attacker who replays a signed message within the chain window can inject false data. The mitigation is a freshness counter inside each message, signed as part of the chain. We have implementations that do this in production-grade C and the overhead is manageable.

Hybrid certificates during the transition

For the next several years, the deployed fleet will be a mix of legacy ECC vehicles and new PQ-ready vehicles. A PQ-only certificate is invisible to a legacy vehicle and a legacy certificate is invisible to a PQ-aware regulator. The bridge is the hybrid certificate: a single cert carrying both an ECDSA signature and a post-quantum signature, validatable by either side.

Hybrid certificates are bigger than either pure form, which seems like it would make the bandwidth problem worse. In practice the hybrid certificate is only on the wire when a PQ-aware participant is negotiating with a legacy participant, and the message structure during the transition uses smaller working certificates with the hybrid root cert exchanged out of band. The on-the-wire overhead stays inside the budget.

What this means for an OEM right now

If you are responsible for V2X on a vehicle platform that ships in the next three years, three things are true. The cryptographic standards your platform will deploy are not the ones that look most prominent in the NIST announcement. The deployment design is not a drop-in. The work cannot be deferred until the radio stack is finalised, because the radio stack is finalised — the budget has been fixed for a decade and is not changing.

The work that does need to happen is integration: choosing the algorithm mix (probably FALCON-512 for signing, ML-KEM for key encapsulation), redesigning the certificate format, validating bandwidth on representative traffic patterns, and most importantly, validating with the regulators who will type-approve the resulting platform that this is a path they will accept. None of those steps is technically novel. All of them have to be sequenced correctly, and the lead times on certificate authority infrastructure changes are measured in years, not months.

The vehicles you ship in 2027 will be on the road in 2042. The cryptography in them will need to survive that arc. The bandwidth budget that constrains them will not get bigger. The work is the work.

---

Digital North works with OEMs and Tier 1 suppliers on V2X post-quantum migration, including bandwidth modelling, certificate format design, and conformance with IEEE 1609.2.1 and ETSI TR 103 619. We are an engineering partner, not a consultancy.