For decades Public Key Infrastructure (PKI) was only a part of enterprise IT ecosystem. But with the recent developments brought along by software defined changes, it has become an integral part of automotive environment.
How did it come into picture?
Well to summarize it in short, the connected functionalities in vehicles expose every endpoint in vehicle systems to multiple cyber risks.
To secure these endpoints a verified cryptographic identity is required. It ensures every message a vehicle sends or receives is legitimate and untampered. And to verify this cryptographic trust, the usage of PKI came into picture. Further, as of July 2022, UN R155 also mandated all OEMs and suppliers to use verified cryptographic identity to secure every vehicle.
While the operating principles of PKI in automotives remain same as in enterprise ecosystem, a different debate about PKI ownership and management often arises. OEMs and suppliers are often confused if they should build their own PKI ecosystem or buy it as a service.
This blog aims to answer this fundamental question. With insights on how PKI as a service operate differently compared to self-hosted PKI and which one is suitable for you.
Understanding Automotive PKI and Its Fundamentals
Before we dive in deeper it’s important to revisit the basics to understand how PKI’s different models operate.
At its core, automotive PKI is a framework of policies, processes, and cryptographic technologies that establishes and manages digital trust. It works through two critical elements:
- Keys
- Certificates
Keys are used for cryptographic operations such as encryption, decryption, digital signing, authentication, and key agreement. On the other hand, certificates act as digital identities issued by a trusted Certificate Authority, or CA. A certificate binds an entity, such as an ECU, backend service, application, or signing authority, to a public key. Together, keys and certificates allow systems to authenticate each other, verify the integrity and origin of data, and establish trusted communication across the automotive ecosystem.
For a deeper breakdown of how certificate authorities, trust hierarchies, and revocation mechanisms work in automotive cybersecurity ecosystem, read our article on: Understanding Certificate Management in Automotive PKIs.
When it comes to operational utilization, the public key infrastructure is generally delivered in two different models. You can either build and operate it internally, where you develop your own PKI ecosystem inhouse (self-hosted PKI) or consume it as a managed service (PKIaaS).
However, in recent years PKIaaS is preferred more by OEMs and suppliers.
The reason? Let’s understand it in detail.
What is PKI as a Service (PKIaaS)? How is it Different from Self-Hosted PKI?
Public Key Infrastructure as a Service (PKIaaS) refers to a cloud-delivered model for PKI services. Like self-hosted PKI, it handles certificate authority operations, key custody, and lifecycle management but the difference is in the ownership. With PKIaaS, these operations are delivered as a managed service provider through a set of APIs.
In an automotive PKIaaS setup:
- The OEM retains policy control, like defining certificate profiles, trust hierarchies, and issuance rules.
- And the operational burden of running certificate authority (CA) infrastructure, managing Hardware Security Modules (HSMs), maintaining uptime, or assembling compliance evidence shifts on the service provider.
For automotive specifically, this distinction matters more than it does in enterprise. To understand why let’s take understand it with an example.
When an OEM prepares an OTA software update, the update package must be signed before any ECU will install it. Instead of exposing private signing keys to development or release teams, the OEM uses PKIaaS as a controlled signing service. The OEM’s release pipeline sends a signing request through the PKIaaS APIs. PKIaaS validates whether the requester is authorized based on their role, applies the correct signing policy, and uses a protected private key stored in an HSM to sign the software package or its hash.
The ECU later verifies the signature using the corresponding certificate and trusted CA chain stored in the vehicle. If the signature is valid and the certificate is trusted, the ECU accepts the update. If the update was modified, or if the certificate is expired, revoked, or untrusted, the ECU rejects it.
Regulatory bodies mandate that this infrastructure should be operational across the entire lifecycle of vehicles. This means the infrastructure that makes it possible must also function without interruption over a vehicle’s lifespan of 10 to 15 years.
To get a clearer picture, lets first understand how it works.
How Automotive-grade PKIaaS Works?
PKIaaS in an automotive is a trust infrastructure layer that integrates directly into the OEM’s manufacturing, development, and delivery workflows. The service operates across two functional areas:
- Certificate and key provisioning across the supply chain
- Integration with CI/CD pipelines
Certificate and Key Provisioning Across the Automotive Supply Chain
At the provisioning layer, PKIaaS manages the full CA hierarchy on behalf of the OEM.
“The OEM’s root CA key lives inside the provider’s FIPS 140-3 validated HSMs. The OEM doesn’t operate this hardware, the provider does. Below it, the provider provisions issuing CAs for each supplier, bound to that supplier’s specific components and manufacturing scope. And the OEM root key never leaves that HSM.â€
When a supplier’s production line requests a certificate for an ECU, the request travels through the provider’s Registration Authority (RA) validation layer and is fulfilled by the scoped issuing CA assigned to that supplier. The resulting certificate carries the OEM’s root trust without the OEM’s root key ever leaving the provider’s HSM boundary.
For a detailed breakdown of how key hierarchies and HSM custody work in automotive PKI, refer to our article on Managing Cryptographic Keys in Automotive PKI.
PKIaaS Integration within CI/CD Pipelines
Note: Certificate issuance throughput at this layer must meet assembly-line speed requirements. A production line cannot wait on certificate issuance latency. Automotive-grade PKIaaS providers geo-distribute their Registration Authority (RA) and CA infrastructure to keep issuance latency within line cycle time tolerances.
Beyond the factory floor, PKIaaS integrates directly into the software development lifecycle and delivery pipelines. It keeps vehicles secure throughout their operational life. The integration point is a unified signing API through which the OEM’s CI/CD toolchain requests signatures without managing the underlying key material directly.
To understand this better, here are some references how we at Embitel integrate our PKI as a service within the development pipeline.
- Over-the-air (OTA) Update Signing
- Secure Boot
- Android Signing for In-vehicle Infotainment (IVI) and Human Machine Interface (HMI) Systems
- Vehicle-to-Everything (V2X) Communication
- Plug and Charge
Every firmware update delivered over-the-air must be signed by a certificate traceable to the OEM’s PKI hierarchy before an ECU will apply it.
PKIaaS manages the firmware signing CA and automates signing key rotation at the service layer. The ECU validates the update signature against its provisioned trust anchor before applying the update, with certificate policy enforcing rollback prevention. This maps directly to UNECE UN R156 (SUMS) and ISO 24089 requirements for software update authorization.
For secure boot, PKIaaS issues and manages the code signing certificates that anchor the secure boot chain.
Each bootloader stage is validated with a certificate issued under the OEM’s PKI hierarchy before the next stage executes. Key rotation for secure boot certificates is handled by the provider, not on the production line, eliminating the need for production-line intervention when certificates approach expiry.
Android IVI and HMI systems require APK signing to ensure security, authenticity and integrity to prevent foreign interferences. For this APK signing certificates are tied to the vehicle’s PKI trust chain.
For this, PKIaaS provisions and rotates these through the same CA hierarchy, keeping signing consistent across the full vehicle software stack. A developer integrating with the signing API does not need to manage separate certificate stores for IVI, ECU firmware, and bootloader signing.
V2X communication security introduces a certificate requirement that has no parallel in standard ECU provisioning. A V2X-enabled vehicle does not communicate under a fixed identity. It uses pseudonym certificates, short-lived credentials that rotate frequently to prevent location tracking while still allowing message authenticity verification.
PKIaaS manages the enrolment and pseudonym CA hierarchy required to issue and rotate these credentials in compliance with IEEE 1609.2. The OEM’s root trust anchors the entire Security Credential Management System (SCMS) hierarchy, with the provider operating the enrolment CA and pseudonym CA layers as part of the same managed service.
Electric vehicles supporting plug and charge under ISO 15118-20 require a contract certificate provisioned into the vehicle at manufacture. When the vehicle connects to a compatible charging station, that certificate authenticates the vehicle and authorises payment automatically, without driver input.
PKIaaS provisions the contract certificate at the factory, manages renewal across the vehicle’s operational life, and handles revocation if the certificate is compromised or the ownership changes. The same CA hierarchy that issues ECU identity certificates at the Tier-1 plant handles Plug and Charge provisioning, keeping the OEM’s trust chain consistent across both use cases.
Moreover, beyond ECU identity certificates, PKIaaS can also manage the signing certificates used to authenticate flash programming tools.
Summary: PKI as a Service (PKIaaS) vs Self-Hosted PKI
With all the essentials covered above about what PKIaaS delivers and how it integrates across automotive workflows if your question still stands: Whether it is the right model?
The table below maps the two delivery models across the multiple dimensions that will help you assess your final judgement.
| Dimension | Self-Hosted PKI | Automotive-Grade PKIaaS |
| Setup Cost | Requires heavy capital expenditure to setup. | The cost burden shifts to service provider. You only pay for the service |
| Security liability | OEM owns root key security, HSM operations, and breach response | Root key custody, HSM operations, and audit responsibility sit with provider |
| Tier-1 sub-CA delegation | OEM builds and operates issuing CAs per supplier.
Root exposure risk on delegation. |
Provider provisions scoped issuing CAs per Tier-1.
Root never leaves provider HSM |
| Compliance and audit | OEM assembles evidence for ISO 21434, UN R155 CSMS, and TISAX audits internally | Audit-ready logs and certificate policy evidence packages provided as part of service |
| CI/CD Integration | OEM team manages signing key rotation, SCMS enrolment CA, contract certificate hierarchy, and revocation independently across each workflow | All signing keys, pseudonym CA, enrolment CA, and contract certificate lifecycle managed at the service layer under a single API and audit trail |
| Time to operational PKI | 6 to 18 months covering HSM procurement, CA configuration, team hire, and policy build | Days to weeks via API access, OEM policy configuration, and first certificate issuance |
However, it is important to note that PKIaaS is not simply about offloading operational burden. The provider must be built for automotive. A general-purpose managed PKI offering may not satisfy automotive-specific requirements
.
Conclusion
For OEMs managing global supply chains, long vehicle lifespans, and UN R155 type-approval, the operational and compliance weight of self-hosted PKI often compounds quickly. PKI as a Service does not eliminate the complexity of certificate management. It moves the infrastructure burden to a provider built to carry it, while keeping policy control with the OEM.
To learn more about how PKI can help your organization consider checking our PKI offerings.
