Regulatory landscape
This is a structural problem. Cryptographic governance typically sits across multiple functions, including security architecture, supply chain, DevOps, and operations, and in most organisations, no single function holds a complete picture. The result is regulatory documentation that accurately describes a compliance position that cannot, in practice, be demonstrated or defended.
NIS2 Article 21 requires appropriate technical measures for the protection of network and information systems. The Cyber Resilience Act requires secure-by-default design and security maintained throughout a product's lifecycle. ISO/SAE 21434 sets out detailed requirements for cybersecurity in the automotive supply chain. All three frameworks, when applied seriously, resolve to the same underlying question: can the organisation account for its key estate, and can it demonstrate that cryptographic controls operate as documented?
For most manufacturers, the honest answer is not fully. What follows is an examination of where the gaps typically sit and what a regulator or auditor will ask at each layer.
The silicon layer: root of trust provenance
Every vehicle software architecture starts with a root of trust provisioned in silicon. Most modern automotive silicon has one. An important aspect to consider is whether the organisation can account for its provenance: who generated the key material, under what ceremony, where the corresponding private key is held, and whether the certificate chain traces to a root the organisation controls.
In practice, silicon-layer trust in complex OEM estates is rarely uniform. Different SoC vendors provision roots under different models. Some key material is held in the vendor's HSM infrastructure. Some was generated in factory environments where ceremony records are incomplete or unavailable. Some certificate chains trace to intermediates the OEM neither controls nor has a revocation path for.
Regulatory frameworks do not prescribe HSM grades in statutory text. But when NIS2 asks for appropriate technical measures and CRA requires security to be maintained across the product lifecycle, the implied obligation is this: the organisation must be able to articulate and defend the governance of its software trust chain from the silicon root upward. Most manufacturers can describe the architecture. Fewer can demonstrate the governance.
The firmware layer: multi-supplier signing and the gap between policy and practice
The gap between documented policy and operational practice is most pronounced at the firmware layer. Assigning policy may correctly state that all firmware must be signed before integration. What such policies rarely address is the practical reality of enforcing that requirement across a supply chain comprising twenty or thirty software suppliers, each operating its own build environment, CI/CD pipeline, and interpretation of what a compliant signing practice looks like.
When KT Secure established cryptographic governance at a Tier 1 British automotive manufacturer, one of the first tasks was mapping what was actually being signed, by whom, with what keys, and under what controls. The policy was clear, but the operational picture required significant remediation before a defensible compliance position could be established. Some suppliers were signing with self-generated, self-managed keys with no ceremony documentation. Some we are resigning within CI pipelines where key material was accessible to any engineer with pipeline credentials. One integration path had its signing step disabled following a certificate failure, with a remediation note that had gone unactioned for eighteen months.
None of these gaps were the result of negligence in any individual function. All of them were invisible to the compliance team, because compliance assurance was based on policy attestation from suppliers rather than verification of actual practice. ISO/SAE21434 is explicit about cybersecurity requirements in the supply chain, but those requirements are only as strong as the organisation's ability to verify that supplier practice matches agreed policy. In most estates, that verification is not systematic.
The device layer: key lifecycle in the field
Once a vehicle enters service, the relevant cryptographic questions shift from provisioning to lifecycle management. What keys are present on the device? What are their validity periods? What is the revocation mechanism in the event of compromise? How does a device verify the legitimacy of an update received seven years after manufacture, when the signing infrastructure in use at the time of provisioning may have rotated multiple times?
The CRA requires vendors to maintain security throughout a product's expected lifetime. For automotive, this obligation is operationally demanding: vehicles sold today will receive software updates well into the next decade. The signing architecture must be designed for that horizon, with documented key rotation schedules, tested rollover procedures, and a clear mechanism for updating device trust anchors without creating windows of vulnerability.
The audit question focuses on whether the PKI governance model is adequate for the full device lifetime. Certificate expiry within an OTA signing chain is an operational risk that infrequently underestimated. When it materialises, it grounds update pipelines, creates service continuity failures, and generates the kind of visible incident that draws regulatory attention.
The cloud and API layer: where governance commonly falls short
The trust chain does not end at the device. In a standard OTA architecture, the cloud-side update service is acritical trust point. The infrastructure that packages and distributes firmware operates under credentials. API endpoints used by devices to verify and retrieve updates are authenticated through specific mechanisms. The pipeline that moves software from supplier build environments to OEM distribution infrastructure carries trust relationships at every handoff.
Cloud-layer governance tends to be the least systematically managed. Credentials provisioned for proof-of-concept deployments that became production systems. API key rotation schedules that exist on paper but not in practice. Trust handoffs between build and distribution environments that were agreed informally and never formalised into policy. These gaps are typically invisible to compliance functions because they do not appear in the control frameworks being assessed.
A rigorous audit will not limit its scope to the compliance documentation. It will test whether the operational controls described in that documentation are actually in place and functioning. In our experience, the divergence between documented and operational governance is consistently widest at the cloud layer, where infrastructure evolved rapidly and governance frameworks were applied retrospectively.
What sound cryptographic readiness requires
The compliance frameworks are substantive, and the organisations investing in them are taking compliance seriously. The gap is not in the quality of the documentation. It is in the absence of a cryptographic inventory that gives the documentation evidential weight.
Any organisation that cannot answer the following questions without significant research effort has a readiness gap that formal compliance documentation will not close:
These questions establish the evidential floor for any credible compliance position under NIS2, CRA, or ISO/SAE 21434. Addressing them requires methodical work: mapping the key estate across the full stack, identifying gaps between documented and actual practice, and building governance that keeps pace with supply chain change and extended device lifecycles.
A compliance document describes a cryptographic posture. Only a verified inventory can demonstrate one.
Let's talk