Law enforcement and post-quantum cryptography in vehicles: clues toward a framework

A vehicle is involved in an incident. You need data. Telematics traces, vehicle-to-vehicle messages exchanged with neighbouring cars at the time of interest, infotainment activity, emergency call payloads, over-the-air update history, biometric authentication logs if the vehicle has them. Today, you know how this works. You serve a warrant on the OEM. Records signed with ECDSA (the elliptic curve digital signature scheme that has authenticated vehicle data since the 2010s) come back. Chain of custody is straightforward. The signature scheme has twenty years of case law behind it.

Sometime in the next two to three years, this changes. Vehicle fleets are migrating to post-quantum cryptography, a family of cryptographic algorithms designed to resist attack by future quantum computers. NIST finalised the first such algorithms in August 2024. OEMs are working through migration roadmaps now. The headline you have been reading about is that the algorithm changes. The operational reality is that everything touching the algorithm changes: the keys, the certificates, the hardware that signs them, the chain of custody documents, the evidence formats, the timeline for responding to a warrant, the cross-border data picture, and the case law that will be relied on in court.

The documents you would normally consult for guidance on this do not yet address it. The lawful-interception standards that govern handover interfaces between operators and law enforcement were written for a pre-PQC world. The chain-of-custody frameworks that case law relies on assume the signature scheme is mature. The forensics toolchains that validate evidence have not yet been updated for ML-DSA (the post-quantum signature scheme that will replace ECDSA in most vehicle deployments). The standards bodies are working on this. They will not be done in time.

This article is not a standard. It is a structured argument offered as a starting point for the people who will write the standards, the training curricula, and the case-handling procedures for this domain. The reasoning here comes from the OEM PSIRT side of the lawful-access interface, where we work. We have published field notes on the engineering of the migration itself. This article addresses what the migration means for the law enforcement workflow that sits on the other side of the PSIRT handoff.

The patterns we describe are ones we expect to be common across the industry rather than detail from any specific engagement. The architecture we propose is offered for argument, not as authoritative. Where the article identifies open questions, they are open questions because we believe the field has not yet answered them, not because we are withholding answers we have.

1. The data landscape in a PQC fleet

The first thing worth mapping is the territory. A connected vehicle generates and receives more types of cryptographically signed data than a non-specialist often realises, and that data lives in more places than the vehicle itself. Before the question "what changes under PQC" can be addressed usefully, the question "what is there to change" has to be answered.

Eight categories cover most of what an LEA might reasonably request. Telematics is the broad term for vehicle-state data: GPS traces, speed at given moments, brake events, accelerometer data through impacts, and the like. This is the data most commonly subpoenaed today. Vehicle-to-vehicle messages, broadcast typically ten times per second and each signed individually, are the cooperative-driving exchanges between cars in proximity. Vehicle-to-infrastructure messages cover the exchange between vehicles and roadside units, such as signal phase and timing announcements at signalised intersections, or road-condition warnings from infrastructure to passing vehicles. Infotainment activity covers everything that happens inside the cabin's user-facing systems: audio, navigation queries, paired phones, application activity. Emergency call payloads are the structured packages that vehicles send when an airbag deploys or another severe event triggers automatic notification, including a window of pre-impact telemetry. Over-the-air update history records which firmware version is installed on each electronic control unit in the vehicle, when each version was deployed, and which campaigns the vehicle has participated in. Biometric authentication logs, where the vehicle has driver-identification or fingerprint or face-recognition hardware, record who unlocked and operated the vehicle. Diagnostic logs cover the engineering data from engine, transmission, advanced driver-assistance subsystems and other internal components.

The same data lives in three layers, each with different keys and verification paths. The vehicle-local layer covers the electronic control unit memory, the infotainment unit, the telematics control unit, and the ADAS module. The cloud-side layer covers the data that flows back to the OEM, the connectivity provider, the third-party telematics services contracted by the OEM, and the map providers consulted during navigation. The roadside layer covers data held by infrastructure operators, who in different jurisdictions may be public authorities, private contractors, or some combination. A single LEA request often touches all three layers and requires coordination between actors that may not have any standing relationship.

What changes in a PQC fleet is that during the migration window, which we expect to last five to ten years, the vehicles in any given OEM's fleet will be in mixed states. Some vehicles will run only ECDSA. Some will have been migrated to ML-DSA. Some will run hybrid certificates that carry both signatures on the same record, an interim approach used to maintain compatibility while infrastructure on both ends of the link is upgraded. The data is signed by whichever scheme was active on the HSM, the hardware security module that is a tamper-resistant chip storing cryptographic keys, at the time of signing.

The implications for an LEA request that spans a time window during the migration are concrete. A single response may contain data signed under different schemes within the same record set. The metadata identifying which scheme was used to sign each record must travel with the data, or the verification step has nothing to anchor against. The verification process itself differs by scheme: the mathematical operations to verify an ML-DSA signature are not the same as the operations to verify an ECDSA signature, and they are not done by the same tools. The training that LEA forensics teams have today, by and large, does not cover any of this.

The figure above shows the matrix of categories by layers, with the signing-scheme overlay as a third dimension reminder. The cells indicate where each category typically lives. The patterns are not absolute: an OEM may have an unusual architecture that places data differently. But the matrix gives a starting picture of where a thorough request needs to reach.

2. The PSIRT-LEA interface today, and what it must become

Most OEMs have a PSIRT (Product Security Incident Response Team) or an equivalent named function that handles lawful-access requests. Warrants are served on the OEM's registered legal address. The PSIRT team triages the request, identifies the relevant data sources across the vehicle-local, cloud-side, and roadside layers, pulls and packages the data, and returns it within the timelines the warrant specifies. Timelines typically run five to fifteen business days for non-urgent requests, faster for active investigations involving ongoing public-safety concerns.

That description of the current state covers a workflow that is well established for ECDSA-signed records. It does not cover what happens when records are signed under different schemes, when the signing scheme itself is too new to have an established admissibility track record, or when the response has to include cryptographic attestation that did not exist when the original case-handling procedures were written. Three structural changes the PQC migration forces on the PSIRT-LEA interface are worth naming individually.

The first is cryptographic triage. Before the data can be packaged for delivery, the PSIRT team must determine which signing scheme produced the data being requested. This is a metadata lookup against the records, but it adds steps and requires personnel who understand the difference between schemes and the implications of each. A request that returns a mixed set of records may require the PSIRT to organise the response by scheme so that the LEA's downstream verification work can be scheme-aware. None of this is technically difficult; all of it is operationally new.

The second is cryptographic evidence counsel. Where the data is signed under ML-DSA, or under hybrid certificates, the PSIRT team will need to consult counsel familiar with cryptographic evidence law before producing it. The legal precedent for ML-DSA evidence does not yet exist. A PSIRT producing such evidence without legal review may inadvertently advise the LEA in ways that affect downstream admissibility. The role of cryptographic evidence counsel inside a PSIRT does not exist at most OEMs today. It will. The lawyers who will fill that role are not yet identified at most OEMs. They will need to be.

The third is extended attestation. The response format may need to include cryptographic attestation that the signing HSM was firmware-current at the time of signing, that the certificate chain was valid at the time of signing, and that the timestamp authority records, which are separate cryptographic proofs of when each signature was created, are intact and verifiable. None of this documentation existed in the response format for ECDSA-only records because the maturity of the ecosystem made it unnecessary. For ML-DSA records, where the algorithm is new and the implementations are not yet broadly trusted, the attestation is part of what makes the evidence admissible.

What the future interface needs is best expressed as a structured proposal. We suggest that four standard documents need to travel with every LEA response in a PQC-aware fleet.

The first is the data manifest. A structured document, likely in JSON or a similar machine-readable format, listing every record returned, with its signing scheme, the identifier of the signing HSM, the firmware version that HSM was running at the time of signing, the timestamp authority record reference, and a chain-of-custody hash that ties each record to its place in the preservation sequence. The manifest is what the LEA's forensics tooling reads first to know what it is looking at.

The second is the verification report. A statement from the OEM that each record in the manifest has been verified by the OEM before delivery, with the verification method documented per scheme. The LEA will then verify independently as part of its own forensics process. The OEM verification report is not a substitute for that; it is a starting point that documents the OEM's own attestation that the evidence is internally consistent.

The third is the attestation document. A signed statement from the OEM attesting to the integrity of the signing infrastructure at the time the records were created. The attestation covers HSM provenance, including which HSMs in which vehicles or cloud systems signed the records, what firmware those HSMs were running, and that the firmware was the current authorised version at the time of signing. The attestation does for the signing infrastructure what the manifest does for the records themselves.

The fourth is the chain-of-custody summary. A human-readable summary of how the data was preserved between the time of signing and the time of handover, who at the OEM handled it, what processing, if any, was applied during preservation or packaging. The summary is the document that the eventual expert witness will reference when explaining the evidence trail in court.

These four documents would form the spine of a PSIRT-LEA handover in a PQC-aware fleet. We are not aware of a standard that defines them today. We believe the field needs one. Building it is part of the work we hope this article contributes to.

3. Evidence preservation under PQC

Evidence preservation is what the chain-of-custody documents in the previous section describe in compressed form. It is worth treating preservation as its own concern because the PQC transition changes what must be preserved, in what form, and how the hybrid-certificate period complicates the preservation chain.

For each record an LEA may eventually need to verify, six elements must be preserved. The data itself, in the form in which it was signed and not in some altered downstream form. The signature or signatures over that data, noting that the plural matters: hybrid certificates produce two signatures per record, one classical and one post-quantum, and both have to be carried forward. The certificate chain used to verify each signature, back to the OEM's root signing key, because a signature without a verifiable chain to a trusted root is not provably authentic. The HSM attestation for the signing key, which documents that the key material lived in a tamper-resistant environment with known provenance. The timestamp authority records, which establish when each signature was produced and which are themselves cryptographic proofs of separate origin from the signing chain. And the metadata indicating which signing scheme was active and which HSM produced the signature, which is the index into the verification process.

The hybrid-certificate period creates a specific complication that pre-migration documentation templates do not anticipate. During the migration, many vehicles will sign data with hybrid certificates carrying both an ECDSA signature and an ML-DSA signature on the same record. Both signatures have to be preserved with the record. Both have to verify independently as part of any downstream evidence verification. And if one verifies and the other does not, this is itself an evidentiary finding that may affect admissibility, because the inconsistency suggests that one of the two cryptographic pathways was compromised, misconfigured, or operated outside its design assumptions at the time the record was signed. The current chain-of-custody documentation template at most OEMs assumes a single signature scheme. It does not yet have a place to record a hybrid verification where one half succeeds and the other does not.

What an OEM PSIRT can deliver, with the four-document interface from Section 2, is the full picture: data, signatures, chains, attestation, timestamps, and the metadata that ties them all together. Without that interface, what the OEM delivers will vary by vendor, by jurisdiction, and by how recently the OEM's PSIRT process was last refreshed. The LEA will be left to reconstruct the preservation chain from documentation that was not designed to support reconstruction. Reconstruction in those circumstances is possible but expensive, and any expense in evidence preparation that is not borne up front during preservation often becomes a defence-counsel argument later about whether the chain holds.

What the LEA needs to build, or contract for, is the capability to independently verify ML-DSA signatures on the records the OEM produces. This is not yet standard in most digital forensics toolchains. The major forensics tool vendors are working on it, but the timelines vary across vendors, and the verification implementations will differ in ways that may matter at the level of evidence audit. The field needs interoperability testing for ML-DSA verification, conducted across vendors, with published results, before the first major case is tried. We are not aware of a body that has taken on this work in a comprehensive form.

4. Court admissibility and the precedent gap

The case-law dimension is, we believe, the single most consequential change for law enforcement and the one least addressed in current standards work. The reason is that case law is not standardised; it is built case by case, and the cases that build it are the cases that arrive, not the cases anyone would design.

ECDSA has been in court since the early 2000s. Cases involving ECDSA-signed evidence are common across vehicle telematics, financial transactions, telecommunications metadata, and other domains. Defence counsel has tested ECDSA admissibility on every plausible ground over two decades, and the courts have built up a body of precedent that prosecutors can rely on. ML-DSA was finalised in August 2024. The first court case that turns on ML-DSA evidence admissibility will be precedent-setting, regardless of the underlying offence. This is not a problem the standards bodies can solve, because standards bodies do not make case law. Only the courts can solve it, and only by deciding cases.

Defence strategy in the first ML-DSA cases will almost certainly include novelty challenges. The challenge will be along these lines: "The algorithm has been a standard for less than three years. There is no peer-reviewed case law on its admissibility. The prosecution has not demonstrated that this signature can be reliably verified in the way ECDSA signatures have been verified. The expert witness presented does not have the depth of experience with this algorithm that would normally support admissibility in this jurisdiction." These challenges will not always succeed. They will be made. They will succeed in some cases, and the cases where they succeed will set precedent, which subsequent cases will then have to either follow, distinguish, or argue against.

Expert-witness requirements shift correspondingly. Where ECDSA evidence has historically required a relatively standard cryptographic expert, who can usually be sourced from a forensics consultancy or an academic computer-science department with appropriate experience, ML-DSA evidence may require a specialist witness who can speak to lattice-based cryptography, which is the mathematical foundation of ML-DSA, based on the difficulty of certain problems involving high-dimensional geometric lattices. The pool of experts with deep working knowledge of lattice-based cryptography and its real-world deployment characteristics is small globally. LEAs that anticipate ML-DSA-relevant cases should be identifying potential witnesses early and building relationships before the cases arise, not searching for a witness in the weeks before a trial begins.

The first-case risk is worth naming directly. The case that carries ML-DSA admissibility into court first may not be the case that the field would choose to carry it. If the underlying facts of the case are unfavourable to the prosecution on other grounds, an early loss on the cryptographic issue could embed unfavourable precedent for years. The cryptographic admissibility question deserves a strong factual case carrying it, not the case that happens to arrive first because of the order in which investigations conclude. We do not have an answer for how LEAs should coordinate on this; the question is whether they can coordinate at all, across agencies and jurisdictions, in a way that gives the precedential cases the best chance.

The figure above shows the rough shape of the gap. ECDSA case-law density built up across the 2000s and reached saturation by the mid-2010s. ML-DSA was standardised in August 2024. ML-DSA case-law density starts from zero at the time of this article and will accumulate slowly over the next decade. The window in which the first major cases will be tried sits in the middle of the gap, where the algorithm is being deployed at fleet scale but the case law to support admissibility has not yet been built.

There are things we suggest the field needs and does not have. A working group, hosted by a credible body that LEAs and OEMs alike can engage with, that develops expert-witness training materials specifically for ML-DSA and the other PQC schemes that will see deployment. Reference cryptographic verification implementations, with formal validation, that forensics tool vendors can rely on as a baseline when implementing their own ML-DSA verification. A clearinghouse for ML-DSA case-law as it develops, accessible to prosecutors and defence counsel both, so that the first decisions in this space are visible across jurisdictions and not buried in local court records. Engagement between standards bodies and judicial-training organisations on cryptographic evidence, so that judges and magistrates hearing the first cases have a baseline understanding of the technology they are ruling on. None of these existed as of the date of this article. All of them should exist before the first ML-DSA case is tried. The work to bring them into being has to start now to be ready in time.

5. Cross-border data and jurisdictional fragmentation

Cross-border investigations involving vehicle data were already complex before any cryptographic transition. They become significantly more complex during one. The connected-vehicle layer adds OEMs, connectivity providers, and infrastructure operators to a picture that previously involved only national telecommunications operators and bilateral cooperation treaties. The cryptographic-migration layer adds the question of which signing regime applies to which records, and whether the answer is the same in the source jurisdiction and the requesting jurisdiction.

The current cross-border picture is governed by data residency rules, national security frameworks, bilateral treaties, and ad-hoc agreements between specific agencies. These vary widely across jurisdictions and intersect in ways that take experienced cross-border practitioners to navigate. Vehicle investigations have layered on top of this an additional set of actors: the OEM, whose legal address may be in one country and whose data centres in another; the connectivity provider, often a different entity in different markets; the third-party telematics services contracted by the OEM, which may operate in still different jurisdictions; and the roadside infrastructure operators, which are often regional or municipal authorities with their own legal frameworks. A request that involves a vehicle that moved across borders during the time window of interest may involve all of these.

What changes in a PQC fleet is that different jurisdictions are migrating to PQC at different paces and under different compliance regimes. Major automotive markets including the EU, the US, the UK, China, Japan, South Korea, India and others each have their own timelines and certification requirements. The OEM's PKI infrastructure may be deployed in compliance with one country's regime while being subject to lawful-access requests from another country's. Whether the receiving country's courts accept evidence signed under the source country's PQC compliance regime is an open question that has not been tested.

The HSM provenance question deserves separate treatment because it is genuinely new. An LEA request for data signed by an HSM whose firmware was deployed under another country's compliance regime may face challenges on cross-border grounds that did not exist with classical schemes. The signing HSM's provenance, meaning where it was certified, by what authority, and under which compliance scheme, becomes part of the evidence chain. The question of whether evidence signed under one country's PQC regime is admissible in another's courts is open. There is no precedent. The first cross-border PQC case will produce precedent, and the precedent may be jurisdiction-specific in ways that complicate later cases.

Three patterns of fragmentation are worth naming. The first is algorithm fragmentation. Different jurisdictions may mandate or prefer different PQC algorithms. ML-DSA is the NIST standard and will be widely deployed, but other jurisdictions may prefer alternative schemes either for sovereignty reasons or for technical preference reasons. Vehicle fleets that cross borders may sign data under different schemes depending on regional configuration, leaving an evidence trail with mixed signatures even within a single trip.

The second is compliance fragmentation. The same algorithm deployed in different jurisdictions may be certified under different compliance regimes: FIPS in the US, ENISA guidance in the EU, the various regional schemes in Asia. The certification matters for admissibility in some jurisdictions. A signature that is admissible under one compliance certification may face challenges in another jurisdiction where the certification is not recognised. There is no current framework for cross-recognising PQC compliance certifications across major markets.

The third is disclosure fragmentation. Different jurisdictions will have different rules about what must be disclosed about a signing HSM's provenance in the course of admitting evidence. Some jurisdictions may consider HSM provenance national-security-sensitive, particularly where the HSM was certified under that country's regime and the certification involved review of cryptographic implementation details. Others may require full disclosure of provenance for evidence to be admissible. A case that crosses these regimes can find itself in a position where the source jurisdiction prohibits disclosure of detail that the receiving jurisdiction requires for admissibility.

What we suggest the field needs is multilateral. A working group to address cross-border admissibility of PQC-signed vehicle evidence, with participation from the major automotive markets. Standardised HSM provenance documentation in a format that is acceptable across jurisdictions, ideally without disclosing detail that any source jurisdiction would treat as sensitive. Treaty-level work on PQC evidence handling between major automotive markets, anchored in existing mutual legal assistance frameworks but extended to cover the new categories of cryptographic evidence. None of this is happening at scale today. The first cross-border PQC vehicle evidence case will likely produce ad-hoc precedent that the field will then have to live with for the foreseeable future.

6. The training and tooling gap

The operational gap between where LEAs are today and where they need to be when the first PQC case lands is concrete and quantifiable. It is also something the field has barely begun to close.

Training is the largest single gap. The curricula that LEA personnel receive on vehicle forensics today are built around the assumption of ECDSA-signed records and mature verification tooling. There is no current curriculum, that we are aware of, that covers the PQC transition for vehicle forensics in any depth. Building one requires content that does not yet exist in published form: ML-DSA verification procedures appropriate for forensic use, hybrid certificate handling, expert-witness preparation specifically for PQC schemes, cross-border evidence handling under PQC compliance fragmentation. The content needs to be developed by people who understand both the cryptographic substance and the operational reality of LEA workflows. Each side of that understanding is held by different people today, and the people who hold one side often have not worked closely with the people who hold the other.

Tooling is the second gap. The digital forensics tools commonly used in vehicle investigations do not yet support ML-DSA signature verification as a standard feature. The vendors of those tools are working on it. Timelines vary by vendor. More importantly, the verification implementations will differ across vendors in ways that may matter at the level of evidence audit, because two implementations of the same algorithm may handle edge cases differently and may produce slightly different verification outputs on records that fall on or near those edges. The field needs interoperability testing for ML-DSA verification across the major vendors, conducted by an independent party, with published results.

Reference materials are the third gap. There is no equivalent, for ML-DSA-aware vehicle forensics, of the well-established reference documents and case studies that exist for ECDSA-based vehicle forensics. The LEA officer reading this article today, planning to be ready for an investigation in 2028, has no published reference to consult that is comprehensive, current, and operationally focused. The relevant material exists in fragments: in cryptographic standards documents that are not written for forensic users, in OEM PSIRT process documents that are usually confidential, in academic papers that are not focused on evidentiary use, in vendor product documentation that is necessarily product-specific. The synthesis that the working officer needs has not been written.

Workflow templates are the fourth gap. The PSIRT-LEA handover format, by which we mean the four-document structure proposed in Section 2 or something like it, does not yet exist as a published template. Each OEM that has begun to think about PQC-aware lawful-access response is building its own version, informed by its own legal counsel and its own engineering team. Without a shared template, every LEA request to every OEM will be a custom interaction, and every LEA forensics team will receive evidence packages in different formats from different OEMs. The cost of that fragmentation is borne entirely on the LEA side.

Mock-case exercises are the fifth gap. A common and effective training method for LEA personnel is the mock case, in which trainees walk through a simulated investigation end to end. Mock cases involving PQC-signed vehicle evidence do not exist as published training material that we are aware of. They need to be developed. They will need to be updated as case law develops, because the right way to handle a piece of evidence today may differ from the right way once the first decisions on admissibility come down.

What we suggest the field needs is straightforward to state and substantial to deliver. A curriculum working group, ideally jointly between LEAs, OEMs, and academic forensics programs, with content review by both prosecution and defence counsel to ensure the training does not embed prosecution-friendly or defence-friendly assumptions invisibly. Vendor interoperability testing for ML-DSA verification, conducted by an independent body, with published results that LEAs can rely on when selecting tools. A reference document for ML-DSA-aware vehicle forensics, written for the working LEA officer and not for cryptographers. Shared workflow templates for the PSIRT-LEA handover, ideally as the basis for a published standard that all major OEMs can implement.

7. Open questions the field has not yet answered

The previous sections have framed the territory and proposed pieces of architecture. The honest counterpart to that proposal is to name the questions that remain open. We have answers to none of these. We believe the field has answers to almost none of them. The point of listing them here is to make the scope of unanswered work visible.

What is the standardised format for the PSIRT-LEA handover in a PQC fleet? The four-document structure we propose in Section 2 is one shape that format could take. There may be better shapes. What there does not yet exist is a published standard that defines any shape, and without one, every OEM and every LEA will build their own.

What is the minimum attestation an OEM must provide for ML-DSA-signed evidence to be admissible? The attestation we describe in Section 2 includes HSM provenance, firmware compliance at signing time, and certificate-chain validity. The minimum needed for admissibility is a legal question, not a technical one, and the answer will be set by the courts as cases are decided.

How should hybrid-certificate evidence be handled when the two signatures verify inconsistently? The question matters because it is the most likely scenario in which the integrity of the signing infrastructure might be challenged. Today, there is no documented procedure for what an OEM PSIRT should do when a hybrid-signed record produces a clean ECDSA verification and a failing ML-DSA verification, or the reverse. The honest options range from "report both results and let the LEA decide" to "treat the record as unreliable and exclude it from the response."

What expert-witness qualifications are sufficient for ML-DSA admissibility? The standard expert-witness profile for ECDSA admissibility evolved over two decades. There is no equivalent profile for ML-DSA, and the courts that hear the first cases will set the precedent for what a qualified witness looks like. The qualifications that get accepted in the first case will shape the witness pool for years afterward.

How should the precedent gap be navigated for the first major cases? This is partly a strategic question for individual investigations and partly a coordination question for the field as a whole. The strategic question is which legal arguments to advance in the first cases. The coordination question is whether agencies can communicate at all about which cases are coming and which should carry the cryptographic admissibility question first.

How should LEAs coordinate on which case carries ML-DSA admissibility into court first? Coordination across agencies and jurisdictions is difficult in normal circumstances and rare on questions of case strategy. The question may not have an institutional answer. It may require informal communication between practitioners who recognise the stakes.

What cross-border framework should govern PQC-signed evidence between jurisdictions with different PQC compliance regimes? The question covers algorithm fragmentation, compliance fragmentation, and disclosure fragmentation as we described in Section 5. The answer will eventually come from treaty-level work and from accumulated bilateral practice. Neither exists today.

What disclosure obligations apply to HSM provenance in cross-border evidence? Some jurisdictions will treat HSM provenance as security-sensitive. Others will require full provenance disclosure for admissibility. A case caught between these regimes faces a structural problem that the parties cannot resolve. The question is who will define the resolution mechanism, and on what authority.

What is the minimum forensics tooling capability for handling PQC-signed evidence? The question is partly technical and partly procedural. The technical part is what verification operations a forensics tool must support. The procedural part is what documentation a tool must produce to be acceptable in evidence audit. Both parts have to be answered for forensics tools to qualify for use in PQC-relevant cases.

What training curriculum should LEA personnel receive on PQC and vehicle forensics? The curriculum question covers content (what to teach), structure (how to organise it), and accreditation (which bodies should certify completion). None of these has a current answer. The curriculum that emerges will probably be built by a working group that does not yet exist.

What is the role of the OEM in expert-witness preparation for cases involving its data? An OEM may have employees with the deepest practical knowledge of its own signing infrastructure. Whether and how those employees can serve as expert witnesses in cases involving the OEM's data is a question that touches conflict-of-interest concerns, employment-protection concerns, and the OEM's own legal exposure. Most OEMs have not yet thought through this question because the cases that would force the thinking have not yet arrived.

What happens when an HSM that signed historical data is later found to have a flaw? A flaw discovered in deployed HSM firmware after it has signed years of vehicle data raises questions about all the data signed with that HSM. Those questions affect admissibility going forward, and they may reopen settled cases. The procedures for handling such a discovery do not exist today. The OEMs that operate HSM fleets are aware of the risk and have begun to think about it. The LEAs that may eventually have to defend evidence signed under a flawed HSM have, in our experience, not yet been brought into that conversation.

The list is not exhaustive. It is illustrative of the scope. Each question is plausibly addressed by a working group, a piece of standards work, a research effort, or a coordinated policy initiative. Almost none of those bodies of work exist today.

8. A proposed architecture

The previous sections have walked through pieces of the problem. This section pulls those pieces into an architectural shape. It is not a complete design. It is a layered structure that names the responsibilities at each layer and the interfaces between layers, so that working groups in different parts of the field can see how their own work fits and where the dependencies on other layers lie.

Four layers, stacked from the most legally consequential at the top to the most technically detailed at the bottom. Three interfaces connect them, each carrying a specific kind of artefact between layers. The shape is offered as scaffolding for the field's conversation with itself, not as a finished proposal.

The Court and Legal layer at the top is where case law is made, expert-witness pools develop, admissibility decisions are rendered, and precedent-aware case strategy is formed. The responsibilities at this layer sit with judges, prosecutors, defence counsel, judicial training organisations, bar associations, and the academic legal community. The work that needs to happen here is the development of precedent on PQC admissibility, the building of expert-witness pools, and the dissemination of case-law summaries to practitioners. The standards bodies cannot do this work. Only the legal system can, and only by doing cases.

The LEA and Forensics layer below it is where investigations are conducted, evidence is verified, and cases are prepared. The responsibilities at this layer sit with LEA forensics teams, prosecutors' investigative offices, digital forensics tool vendors, and the training organisations that prepare LEA personnel. The work that needs to happen here is the building of independent verification tooling, the development of training curricula and mock cases, the readiness to handle PQC-signed evidence when it arrives, and coordination across jurisdictions on cross-border cases. This layer is where the cost of the field's unreadiness is most directly felt; an LEA whose tooling does not support ML-DSA verification cannot independently audit the evidence it receives.

The PSIRT and OEM layer below that is where evidence is produced and packaged for lawful access. The responsibilities here sit with OEM PSIRT teams, OEM legal counsel, and the OEM's cryptographic operations teams. The work that needs to happen here is the building of cryptographic triage capability, the development of cryptographic evidence counsel as a role, the implementation of the four-document handover format we proposed in Section 2, and the maintenance of HSM provenance documentation in a form that can travel cross-border. This is the layer where Digital North works. We are direct about the limits of our perspective: the work above us depends on legal-system actors we cooperate with but do not direct, and the work below us depends on cryptographic infrastructure we participate in but do not solely own.

The Cryptographic and Infrastructure layer at the bottom is where the signing happens. The responsibilities here sit with the HSM vendors, the PKI operators, the timestamp authority operators, and the cryptographic standards bodies. The work that needs to happen here is the deployment of ML-DSA and the hybrid certificate schemes that bridge the migration, the operation of HSMs that produce reliable attestations, and the certificate-chain infrastructure that makes verification possible. This layer is comparatively mature in pure-cryptographic terms, because the standards are set and the algorithms are stable. It is comparatively immature in operational terms, because the day-to-day operation of PQC-signing infrastructure at fleet scale is still being learned.

The interfaces between layers are where most of the standardisation work needs to happen. Between the Court layer and the LEA layer, the interface is the warrant and the verification report that flows back; this is where the legal request for evidence is matched to the technical proof of evidence integrity. Between the LEA layer and the PSIRT layer, the interface is the four-document handover; this is where the OEM's evidence package meets the LEA's forensics process. Between the PSIRT layer and the Cryptographic layer, the interface is the signed records themselves and the attestation about how they were signed; this is where the cryptographic infrastructure produces the artefacts that everything upstream depends on. Each of these interfaces deserves its own structured definition. None of them has one today that comprehends the PQC transition.

The architecture has gaps. The case-law layer cannot be filled in by anyone other than the courts, and the courts will not move until cases arrive. The training and curriculum work at the LEA layer requires a working group that does not yet exist. The cross-border framework at every layer is multilateral by nature and will move only as fast as the slowest jurisdiction allows. We offer the shape to give the field a place to anchor its own work, not as a claim that the work itself is straightforward.

9. What we are proposing, and what we are not

This article makes its posture explicit so that the reader knows what to do with the material and what not to do with it.

What we are proposing is a starting point. The architecture in Section 8, the four-document handover format in Section 2, the working group recommendations across multiple sections, the open questions in Section 7. These are offered as material for the field to work with. They are not claims of completeness. They are pieces of a shape that we hope the field can refine.

What we are not proposing is a finished standard. The architecture has gaps. The four-document format will need refinement when it meets real cases. The working group recommendations need bodies to host them. The open questions need people to work on them. Nothing in this article is offered as the last word on anything.

What we are offering is clarity about the scope of the work. Our position is that the standards bodies, the regulators, the LEAs, the OEMs, the forensics tool vendors, the courts, and the training organisations are each working on pieces of this problem, but the pieces are not yet visible to each other and the field has not yet converged on a shared mental model. The architecture in this article is one attempt to make the territory visible so that the next attempt, by someone else, can be better.

Where the architecture is wrong, we want to hear about it. Where the open questions are incomplete, we want to add to the list. Where someone is already working on a piece of this, we want to know. The point of writing the article is not to claim ownership of the framework. It is to start the conversation that we believe the field needs to have.

---

The PQC migration in vehicle fleets is happening now. The first major case involving PQC-signed vehicle evidence will be tried within the next two to four years. The standards bodies will not have finished their work by then. The case law will be made by the cases that arrive, not by the cases anyone would choose. The training curricula, the forensics tooling, the cross-border frameworks, and the expert-witness pool will all be incomplete when the first major case lands.

The article is offered as one input to closing that gap. Digital North works on both sides of this interface: with OEMs on PSIRT and lawful-access compliance, and with the cryptographic infrastructure that makes lawful-access response possible. We have written this article because we believe the field is not yet talking to itself in a structured way about this question, and starting that conversation is more useful than waiting for the standards bodies to catch up.