Field notes on V2X PQC migration: where the standards leave you stranded

Three standards became deployment-relevant in 2024. NIST finalised FIPS 203, 204, and 205 in August. UNECE R155 went mandatory for all new vehicles produced across 64 contracting parties on 1 July. The combination shifted post-quantum migration in V2X from a problem the standards community would solve to a problem the engineering community has to solve.

A note on what follows. Every engagement Digital North signs is bound by an NDA naming a specific scope of work, and we honour that obligation on our own marketing surface the same way we honour it inside the work. The observations below are composite, synthesised across the engagements we have run rather than reported from any single one. The numbers are representative of the patterns we see consistently, not data from a specific deployment. The shapes are real. The specific values have been generalised to the orders of magnitude rather than any client's exact figures. Where the standards anchor a number (signature sizes from FIPS 204, frame rates from SAE J2735), the number is exact. Everywhere else, what follows is the pattern, not the pilot.

The reader we have in mind is the architect or technical lead at an OEM working on a migration roadmap. The assumption is that you already understand ECDSA P-256 under IEEE 1609.2 and have read enough of FIPS 204 to know what ML-DSA-65 looks like. The rest of this post is what comes after that.

1. The frame budget will not save itself

In one engagement we ran in 2024, during week 3 of pilot deployment, BSM verification throughput at a single RSU-monitored intersection dropped from a baseline of 1,820 ops/sec to 340 ops/sec for a 45-minute window during peak hour. The drop was reproducible on the same intersection on subsequent days. It was not reproducible on any other intersection in the pilot.

The first hypothesis was RF interference from a nearby 5GHz Wi-Fi installation. A spectrum analyser swept the channel during the drop window across two consecutive days and found no interference signature.

The second hypothesis was an ECU firmware bug in the OBU modem. The same firmware on a quiet road segment showed no degradation. The hypothesis did not survive the comparison.

The third hypothesis was cryptographic verification queueing under load. Confirmed via the verifier's queue-depth histogram. At peak, queue depth crossed 50 entries within seconds of vehicle density passing 22 vehicles in range. Verifications older than 8 seconds were being dropped before they completed.

The OBU's HSM datasheet quoted 1,820 verifications per second under ECDSA P-256. Under ML-DSA-65 the same hardware benchmarked at roughly 600 to 700 verifications per second on lab bench, single-threaded. The bench number was already a 60 to 65 percent drop from the ECDSA baseline. The field number at peak intersection load was a further 2x drop on top of that, because the bench measurement was a single-threaded ceiling and the field measurement was queue-managed reality.

The constraint context sits in the standards. Under IEEE 1609.2, ECDSA P-256 produces a 64-byte signature. Under FIPS 204, ML-DSA-65 produces 3,309 bytes, roughly fifty times larger. Vehicles broadcasting BSMs at up to 10 Hz per SAE J2735 on 802.11p channels with roughly 3 Mbit/s typical link rate have less aggregate airtime and verifier headroom to spend on signature payload than the standards conversation tends to assume. The verification math sits on top of that constraint, not separate from it.

The mitigation has two halves. The first is choosing where in the stack to bear the signature cost: at the message layer, at the certificate layer, or by changing the signing cadence below the per-message default. Each choice has different implications for misbehaviour detection and for the verification timing budget. The second half is the actual engineering. We do not publish the configuration we use. It exists.

2. Pseudonym pools have a new problem

In one engagement we ran in 2024, the OTA team flagged that pseudonym pool refresh traffic had grown by approximately 45x over a single algorithm change. The team initially thought the OTA worker had a logic error.

The first hypothesis was a bug in the pseudonym refresh worker. Code review showed the worker was correct. The schedule was configured weekly and the worker was firing weekly.

The second hypothesis was that the SCMS backend was rate-limiting requests. Backend logs showed no rate limits hit. Requests were completing successfully.

The third explanation was the boring one. The pool refresh was completing successfully, but each cert in the pool had grown roughly 45x in size, so each refresh was moving 45x the bytes. Nobody had budgeted for that because the storage assumption under ECDSA was "negligible."

The storage math, made explicit. Per-vehicle pseudonym pool of 200 short-term certificates. Under ECDSA P-256 each cert is approximately 120 bytes. Pool storage: 24 KB per vehicle. Weekly OTA refresh: 24 KB per vehicle per week. For a 50,000-vehicle fleet, total weekly OTA traffic for pseudonym refresh: roughly 1.2 GB.

Under ML-DSA-65 each cert grows to approximately 3,500 bytes. Under a hybrid scheme carrying both ECDSA and ML-DSA, each cert is approximately 5,500 to 6,000 bytes. Pool storage: 1.1 to 1.2 MB per vehicle. Weekly OTA refresh: 1.1 MB per vehicle per week. For the same 50,000-vehicle fleet, total weekly OTA traffic: roughly 55 GB.

Same refresh cadence. 45x the bandwidth cost.

The second-order problem is that the pool refresh interval is not weekly in production. We have seen pools depleting faster than the weekly cadence assumed because vehicles in high-mobility urban driving trigger pseudonym change events 35 to 50 times per week rather than the standards-default reference of 20. Refresh cadence quietly compressed to every 3 to 4 days, then to daily, before the OTA team noticed the SOC alert had been firing for two weeks.

The pseudonym mechanism is defined under ETSI TS 103 097 for the European C-ITS profile and under IEEE 1609.2.1 for the US SCMS. Both standards assume the pool refresh is a solved operations problem. In a real deployment it is not. It is a new operations problem that scales with the algorithm you chose.

3. The HSM you have is not the HSM you need

In one engagement we ran in 2024, the client asked for a migration plan against the deployed vehicle fleet. We asked for the HSM inventory. The client did not have one in the form the migration plan needed. We built it. The build took ten weeks.

For the fleet covering model years 2018 through 2024, the inventory yielded three buckets.

Approximately 15 to 20 percent of the fleet sat in the clean upgrade bucket: HSMs that supported ML-DSA via firmware update with no measurable throughput penalty. These were the newest vehicles, generally model years 2023 and 2024, with HSMs that had been specified with crypto-agility in mind.

Approximately 50 to 55 percent of the fleet sat in the throughput-degraded bucket: HSMs that supported ML-DSA via firmware update but with verification throughput dropping 40 to 60 percent versus their ECDSA performance. These were vehicles where the HSM could do the lattice arithmetic but had not been hardware-optimised for it. The migration was technically possible. The performance envelope was not what the original deployment had budgeted for.

Approximately 25 to 30 percent of the fleet sat in the stranded bucket: HSMs that lacked the lattice arithmetic primitives entirely and could not be brought into compliance through firmware. These vehicles could not be migrated without hardware replacement. For a fleet that included vehicles bought in 2018 with expected service lives running into the 2030s, this was the most significant finding in the entire engagement.

The standards conversation about PQC migration tends to assume the HSM can be updated. The HSM inventories we have built tell a different story. The stranded fraction changes the strategy from "rollout schedule" to "model-year cutoff plus parallel ECDSA support for as long as the stranded vehicles are on the road." That parallel support is a multi-year operational commitment that has to be planned for, budgeted for, and built into type-approval evidence.

4. The certificate chain is not where you think it is

In one engagement we ran in 2024, a regional pilot covered approximately 800 vehicles in a cold-weather market. Through the winter months, vehicles in the pilot were parked unstarted for periods ranging from one to six weeks. When started, roughly 8 percent of vehicles experienced cold-start cert verification failures on first BSM exchange.

The cert chain TTL configured in the OBU's local cache was 7 days. This matched the OTA refresh cadence and the standards-default-ish guidance. In the lab, vehicles ran continuously. In the field, vehicles sat.

Of the 800-vehicle pilot, 22 percent of vehicles exceeded 7-day idle at some point over winter. Of those vehicles, 8 percent relative to total fleet failed cold-start cert verification on first BSM exchange. Mean recovery time on first network contact was 12 to 30 seconds depending on cellular coverage at the start location.

First hypothesis: OBU clock drift causing the cert validity check to fail. NTP sync logs showed clocks within 50ms across the affected vehicles. The hypothesis did not survive the data.

Second hypothesis: the SCMS backend was unreachable from the affected vehicles. Backend logs showed normal availability throughout the failure windows. Hypothesis did not survive.

Third hypothesis: the local cert chain cache had expired during long idle. Confirmed via OBU cache state logs. The cache had been correctly purging entries past TTL. The TTL itself was the bug.

The cache strategy that survives a fleet is not the cache strategy that ships from the bench. In the lab, vehicles run continuously and TTL is a thermal-throttling concern. In the field, vehicles sit and TTL is an availability concern. The mitigation is straightforward, proactive refresh on warm-start, extended TTL with revocation hooks. The mitigation has to be designed into the OTA pipeline, not retrofitted after the first cold winter.

5. The migration is not the migration

The five-year industry conversation about PQC migration treated it as a crypto problem. The four sections above are evidence that it is not. The crypto problem was solved by NIST in August 2024. Everything since is engineering: queue management under verification load, OTA bandwidth budgets that absorb 45x growth, HSM inventories that take ten weeks to build, cache strategies that survive cold winters and long idle.

Crypto-agility, the engineering capability to swap algorithms without re-architecting the systems that use them, is what makes this migration survivable. We have written about this elsewhere. The OEMs we work with that are furthest along on this migration are the ones that recognised, early, that the work is not in the algorithm. It is in everything that touches the algorithm.

---

There are problem classes this post has not covered. Type-approval evidence under R155 deserves its own piece. The misbehaviour detection implications of ML-DSA verification timing deserve another. Both are coming.

If you are working on this migration and any of the above is recognisable, the contact form routes engagement enquiries directly to us. Pick "Explore a business engagement."