PKIaaS for IoT and Device Identity at Scale

The Palo Alto Networks 2026 Identity Security Landscape report (May 14, 2026) found a 109:1 ratio of machine identities to human identities in enterprise environments. Most of those machine identities are devices: connected sensors, industrial controllers, medical equipment, vehicles, building management systems, and network infrastructure. Every one of them needs a cryptographic identity if it is going to authenticate to a network, communicate securely with a cloud service, receive firmware updates without accepting spoofed packages, or be trusted by the systems it connects to.

PKI for IoT is not a new idea, but the scale at which it must operate and the operational constraints of the devices involved create specific challenges that enterprise IT certificate management was not designed to address. A device with 256 KB of flash storage and no real-time clock cannot run a full ACME client. A factory floor shipping 50,000 devices per day cannot use a manually triggered certificate issuance process. A medical device deployed for 10 to 15 years will outlive several certificate validity periods and several rounds of PKI infrastructure changes.

This post covers how PKI as a Service addresses each of these challenges: device identity provisioning at manufacturing time, enrollment protocols for constrained devices, lifecycle management across operational lifetimes measured in years, ownership transfer and re-provisioning, secure boot integration, device-to-cloud authentication, revocation at fleet scale, and post-quantum readiness for devices that will still be operating in 2030.

Quick Answer: What Does PKIaaS Do for IoT Device Identity?

PKIaaS provides the CA infrastructure that issues, manages, and revokes certificates for IoT devices across their full operational lifecycle: from factory-floor certificate provisioning before the device ships, through initial deployment and ownership transfer, through years of operational certificate renewals, to end-of-life revocation when the device is decommissioned. PKIaaS scales to the certificate volumes that IoT deployments require (millions of devices, automated issuance) and supports the enrollment protocols that constrained IoT devices can use (CMP for ultra-constrained, EST for moderate-resource devices, SCEP for legacy platforms). The result is a device fleet where every device has a verifiable cryptographic identity, issued under a documented certificate policy, with a revocation status that can be checked by any system the device connects to.

Key Takeaways

• The machine-to-human identity ratio in enterprise environments is 109:1 (Palo Alto Networks, May 2026). IoT devices are the primary driver in manufacturing, healthcare, and industrial environments. Manual certificate management at this ratio is operationally impossible. Automated PKIaaS is the only viable infrastructure model.
• IEEE 802.1AR defines the foundational model for IoT device identity: an Initial Device Identifier (IDevID) issued at manufacturing time by the manufacturer’s CA, and a Locally Significant Device Identifier (LDevID) issued by the device’s operator. IDevIDs enable zero-touch provisioning and ownership transfer; LDevIDs reflect operational identity in the deployed environment. PKIaaS serves both roles depending on whether the PKIaaS operator is the device manufacturer or the device operator.
• Protocol selection for IoT certificate enrollment must match device constraints. CMP (RFC 4210) is the correct protocol for highly constrained devices (limited RAM, no full TLS stack, intermittent connectivity). EST (RFC 7030) is appropriate for devices with TLS capability. SCEP serves legacy OT platforms. ACME serves cloud-connected IoT devices with adequate resources. Selecting the wrong protocol for a device class results in enrollment failures that cannot be resolved without a device firmware update.
• Secure boot and firmware signing use the same PKI root as device identity certificates. The manufacturer’s PKIaaS CA signs both device identity certificates and firmware images; the device hardware trust anchor contains the CA certificate used to verify both. This produces a unified trust root for the device that covers both identity and code integrity.
• Ownership transfer is a PKI operation, not just a logistics operation. When a device moves from manufacturer to distributor to operator, the IEEE 802.1AR IDevID stays with the device as proof of provenance. The IETF BRSKI protocol (RFC 8995) uses the IDevID to bootstrap a new operational certificate (LDevID) from the operator’s PKIaaS without requiring manual configuration of each device.

Why IoT Device Identity Is Hard

Enterprise IT certificate management assumes devices that can run a full TLS stack, have reliable network connectivity, have access to an NTP server for accurate time, and are managed by an IT team that can respond to certificate expiry alerts. IoT devices violate most of these assumptions simultaneously.

Scale: A single IoT deployment can involve millions of devices. A connected vehicle platform may have hundreds of millions of ECU certificates across the fleet. Manual processes that work for 10,000 enterprise servers do not scale to 10,000,000 IoT sensors. Every certificate operation (issuance, renewal, revocation) must be automated end to end.

Resource constraints: Many IoT devices have severely limited memory, processing power, and storage. A microcontroller with 64 KB of RAM cannot run a standard TLS 1.3 stack efficiently. Some devices have no reliable real-time clock, making certificate expiry validation unreliable without external time sources. Enrollment protocols must be lightweight and tolerant of these constraints.

Operational lifetime: IoT devices in industrial, medical, and infrastructure deployments have operational lifetimes of 10 to 20 years. Enterprise IT certificates are typically planned for 1 to 3 year validity periods. An IoT device deployed in 2025 may need to receive certificate renewals, accept firmware updates, and authenticate to cloud services continuously until 2040. The PKI infrastructure used to provision it at manufacturing time may have been replaced multiple times by then.

Intermittent connectivity: Industrial IoT devices in factories, oil and gas installations, agricultural deployments, and remote infrastructure may be offline for extended periods. Certificate renewal processes that assume continuous network connectivity fail in these environments. Certificate management for intermittently connected devices requires designs that tolerate extended offline periods, including certificates with longer validity periods in offline segments and manual or batch renewal mechanisms for devices that return to connectivity after extended absence.

Physical access limitations: Unlike IT infrastructure, IoT devices are often physically inaccessible after deployment (embedded in sealed equipment, installed in remote locations, deployed underwater or underground). A certificate renewal operation that requires physical access to the device, or a firmware update that cannot be delivered over-the-air with cryptographic verification, is operationally infeasible for most IoT deployments.

IEEE 802.1AR: The Foundation of IoT Device Identity

IEEE 802.1AR (Secure Device Identity) defines the IDevID/LDevID framework that is the basis for cryptographic device identity in standards-compliant IoT deployments. Understanding this framework is essential for manufacturers and product security teams designing device identity programs.

IDevID: Manufacturer-Issued Initial Device Identity

An Initial Device Identifier (IDevID) is a certificate issued to a device at the time of manufacture. It is signed by the device manufacturer’s CA (which can be a PKIaaS issuing CA operated by the manufacturer) and is typically stored in a secure element, TPM (Trusted Platform Module), or protected flash storage on the device. The IDevID has several defining properties:

• It contains a globally unique identifier for the device (serial number, hardware ID, or a UUID generated at manufacture) in the Subject or Subject Alternative Name.
• It has a validity period that spans the device’s entire expected operational lifetime (often set to a far-future date or configured as “no expiry” in the notAfter field, per the IEEE 802.1AR recommendation for IDevIDs).
• The private key corresponding to the IDevID is generated on the device and never leaves the device’s secure storage. The manufacturer does not have custody of the IDevID private key, only of the IDevID certificate it signed.
• It is immutable throughout the device’s lifetime. The IDevID is not renewed or replaced; it is the permanent proof of the device’s origin from a specific manufacturer.

PKIaaS serves as the IDevID CA for device manufacturers. The manufacturer’s PKIaaS issuing CA signs IDevID certificates for each device produced, at manufacturing scale (thousands to millions of certificates per manufacturing run), through the PKIaaS REST API integrated with the manufacturing execution system (MES) or test station. Each device presents its hardware-generated public key to the PKIaaS API during the production test phase; the PKIaaS CA signs the certificate and returns it for storage on the device before it ships.

LDevID: Operator-Issued Locally Significant Device Identity

A Locally Significant Device Identifier (LDevID) is issued by the device’s current owner or operator, not by the manufacturer. The LDevID reflects the device’s operational identity in the deployed environment: the organization that owns it, the operational role it serves, the network segment it belongs to, and the access permissions it carries in that operator’s environment.

LDevIDs are what most organizations’ device identity programs manage on an ongoing basis. They have standard validity periods aligned to the operator’s certificate policy, are renewed before expiry like other managed certificates, and are revoked when the device is decommissioned, transferred, or reported compromised. The LDevID issuance process uses the IDevID as proof of device provenance: the device presents its IDevID to the operator’s enrollment server, the enrollment server validates the IDevID against the manufacturer’s CA trust bundle, and upon validation, issues the LDevID from the operator’s PKIaaS CA.

Enrollment Protocol Selection for IoT Devices

Choosing the wrong enrollment protocol for an IoT device class is a design decision that cannot be changed without a firmware update. Protocol selection must happen during product design, not after deployment.

Protocol	RFC / Standard	Transport	Best fit	IoT constraint level
CMP	RFC 4210	HTTP, CoAP, or direct (can run over UDP)	Highly constrained devices: industrial PLCs, smart meters, eSIM, V2G, embedded M2M	Ultra-constrained (32-64 KB RAM acceptable)
EST	RFC 7030	HTTPS (TLS required)	Devices with full TLS stack: gateways, edge servers, industrial IoT nodes, connected appliances	Moderate (full TLS capability required)
SCEP	Informational	HTTP	Legacy OT platforms, network equipment, MDM-managed mobile devices	Low (HTTP only, widely supported in legacy stacks)
ACME	RFC 8555	HTTPS	Cloud-connected IoT devices with adequate resources, developer boards, edge computing nodes	Low (full HTTP/HTTPS client required)
REST API (batch)	PKIaaS proprietary	HTTPS	Manufacturing-time provisioning, batch certificate generation for devices without on-device key generation	None (executed by manufacturing system, not the device)

CMP for ultra-constrained devices: CMP is specified in RFC 4210 and is the certificate management protocol recommended by ETSI and 3GPP for eSIM (GSMA SGP.02), V2G (vehicle-to-grid, ISO 15118-20), and industrial IoT deployments where full TLS is not feasible. CMP messages are ASN.1 DER-encoded and can be carried over HTTP, CoAP (Constrained Application Protocol, RFC 7252, designed for devices with limited memory), or direct binary transport. CMP supports certificate request, renewal, revocation, key update, and CA certificate retrieval in a single protocol, making it comprehensive for constrained device certificate management. PKIaaS providers that support CMP enable manufacturers and operators to provision certificates to ultra-constrained devices without requiring a full TLS implementation on the device.

EST for standard IoT devices: EST (RFC 7030) is the preferred modern enrollment protocol for IoT devices that have a TLS stack (microcontrollers with hardware TLS acceleration, IoT gateways, edge servers). EST uses HTTPS and supports SimpleEnroll (initial certificate request), SimpleReenroll (renewal), CACerts (CA certificate retrieval), and CSRAttrs (certificate attributes query). EST with mutual TLS authentication (where the device authenticates to the EST server using its IDevID before receiving its LDevID) is the clean IEEE 802.1AR-aligned enrollment flow for devices that can support it.

Manufacturing-Time Certificate Provisioning

Manufacturing-time certificate provisioning is the process of injecting a device’s initial cryptographic identity (IDevID) into the device before it leaves the factory. This is the highest-assurance provisioning model: the certificate is issued under controlled conditions, at a specific facility, for a specific device serial number, and stored in hardware that protects the corresponding private key from extraction.

On-Device Key Generation (Preferred)

The preferred manufacturing provisioning model generates the device’s key pair on the device’s own hardware during the production test phase. The private key is generated inside the device’s secure element, TPM, or hardware security enclave and never leaves that boundary. The device exports only the public key (as part of a CSR or directly as a public key structure) to the manufacturing system, which submits it to the PKIaaS CA API. The PKIaaS CA signs the certificate and returns it to the manufacturing system, which delivers it to the device over the production test interface. The device stores the certificate in non-volatile storage. The private key was never on any system other than the device itself.

This model requires integration between the PKIaaS REST API and the manufacturer’s manufacturing execution system (MES) or automated test equipment (ATE). A typical high-volume implementation submits CSRs to the PKIaaS API in batches during the production test phase, with each device receiving its signed IDevID within seconds of completing the key generation step on the production line. PKIaaS at manufacturing scale must support sustained issuance rates aligned to production line throughput: a production line shipping 50,000 devices per day requires a PKIaaS deployment that can sustain approximately 35 certificate issuances per minute continuously without rate limiting.

Injected Certificate Model

For devices that do not have secure on-device key generation (lower-cost devices without a secure element or TPM), an alternative is to generate key pairs in an HSM at the manufacturer’s facility and inject both the certificate and the private key into the device over a secure production interface. This model is less secure than on-device key generation (the private key exists briefly outside the device), but it is appropriate for lower-assurance use cases where the device’s hardware cannot generate keys securely.

For any injected key model, the key generation must occur in a FIPS 140-2 or 140-3 Level 3 validated HSM, the private key must be encrypted for transport to the device, and the injection procedure must be logged and audited. The PKIaaS provider’s HSM infrastructure can serve as the key generation facility in an injected key model, with key material delivered to the device over a secured production network segment.

Secure Boot and Firmware Signing

Secure boot is a mechanism that ensures a device only executes cryptographically verified firmware. The trust chain for secure boot begins with an immutable hardware root of trust (a public key or CA certificate stored in one-time-programmable fuses or a secure element at manufacturing time) and extends through each stage of the boot sequence, with each stage verifying the next stage’s signature before execution.

PKIaaS serves the manufacturer CA role in the secure boot trust chain. The manufacturer’s PKIaaS CA is the root of trust for firmware signing: firmware images and bootloaders are signed with a code signing certificate issued by the PKIaaS CA, and the device’s hardware trust anchor is programmed with the PKIaaS CA certificate (or the corresponding public key). At boot time, the device verifies each firmware component’s signature against the PKIaaS CA certificate stored in its trust anchor.

The relationship between device identity certificates (IDevIDs) and firmware signing certificates is important to understand: they typically use separate issuing CAs within the same PKIaaS hierarchy, but they share the same root of trust. The IDevID CA issues device identity certificates; the firmware signing CA issues code signing certificates used to sign firmware. Both CAs are subordinate to the same PKIaaS root. This means a single PKIaaS root CA certificate stored in the device’s hardware trust anchor is sufficient to establish trust for both device identity operations and firmware verification operations.

Firmware signing key management is one of the highest-consequence key management operations in a product’s lifecycle. If the firmware signing private key is compromised, an attacker can sign malicious firmware that will pass secure boot verification on every device that trusts the corresponding CA. PKIaaS with FIPS 140-3 Level 3 HSM-backed code signing keys, M-of-N access controls for signing operations, and a complete audit log of every signing event provides the governance model that protects this key material. Encryption Consulting’s code signing capabilities are discussed in detail at our CodeSign Secure offering page.

Device-to-Cloud Authentication

When an IoT device connects to a cloud platform (AWS IoT Core, Azure IoT Hub, GCP IoT Core, or a private MQTT broker), the connection must be mutually authenticated: the device must verify the cloud endpoint’s certificate, and the cloud endpoint must verify the device’s certificate. PKIaaS provides the device certificates for this mutual authentication.

mTLS for Device-to-Cloud Connections

Device-to-cloud mTLS uses the device’s LDevID (or a dedicated device TLS client certificate issued by the operator’s PKIaaS CA) as the client certificate in the TLS handshake. The cloud platform’s MQTT broker or HTTPS endpoint requires the device to present a certificate signed by a CA in the platform’s trust store. For private cloud deployments, this CA is the operator’s PKIaaS issuing CA. For public cloud IoT platforms, the operator registers their PKIaaS CA certificate with the cloud platform as a custom CA, enabling the platform to trust certificates issued by the operator’s PKIaaS rather than requiring the use of platform-issued certificates.

AWS IoT Core, Azure IoT Hub, and GCP IoT Core all support custom CA registration for mTLS device authentication. The operator uploads their PKIaaS CA certificate to the cloud platform’s certificate trust store; the platform then accepts client certificates signed by that CA for device authentication. New devices are registered in the cloud IoT platform with their PKIaaS-issued certificate, and the platform uses the certificate’s Common Name or Subject Alternative Name as the device identity for policy and routing decisions.

Just-in-Time Registration

Cloud IoT platforms support just-in-time registration (JITR) and just-in-time provisioning (JITP), where a device that connects with a valid PKIaaS-issued certificate is automatically registered in the cloud platform on first connection, without requiring the operator to pre-register each device individually. This is essential for manufacturing-time provisioning: the device receives its PKIaaS-issued certificate at the factory, and when it first connects to the cloud service in the field, the cloud platform validates the certificate against the registered PKIaaS CA and automatically creates the device’s cloud registry entry. Manual pre-registration of millions of devices is eliminated.

Ownership Transfer and Re-Provisioning

IoT devices frequently change ownership: from manufacturer to distributor, from distributor to enterprise customer, from one business unit to another, or when hardware is refurbished and resold. Each ownership transfer requires the device’s operational identity to be updated to reflect the new owner’s PKI and access policies.

The IETF BRSKI (Bootstrap Zero Touch Provisioning using ANIMA, RFC 8995) protocol defines a standardized automated ownership transfer procedure for IEEE 802.1AR-compliant devices. BRSKI uses the device’s IDevID as the enrollment proof: the device presents its IDevID to the new owner’s BRSKI registrar, the registrar contacts the manufacturer’s MASA (Manufacturer Authorized Signing Authority) to obtain a signed ownership voucher, and upon validating the voucher, issues the device a new domain certificate (LDevID equivalent) from the new owner’s PKI. The entire process is automated and requires no manual configuration of the device.

For organizations deploying PKIaaS as the operator CA in a BRSKI-compliant workflow, the PKIaaS CA issues the LDevID (domain certificate) after the BRSKI registrar validates the device’s ownership. The PKIaaS issuance policy for BRSKI-enrolled devices can enforce constraints appropriate to the device type: validity periods, key algorithm requirements, Subject DN structure, and SAN allowlists that reflect the operator’s security policy for the device class.

For organizations that are not yet implementing BRSKI, a simpler ownership transfer procedure is manual: the previous owner provides the new owner with the device’s IDevID certificate (as proof of provenance and device specifications), the new owner uses the IDevID’s Subject information to pre-populate the LDevID enrollment request, and an operator authenticates the enrollment through the PKIaaS management console or API. Manual ownership transfer is operationally feasible for small device fleets; BRSKI automation is required at scale.

Certificate Lifecycle Management for IoT Fleets

IoT certificate lifecycle management differs from enterprise IT CLM in three key dimensions: the number of certificates is orders of magnitude larger, the devices have limited ability to participate in renewal operations, and the operational consequences of a certificate expiry on a deployed device can be severe (a medical device going offline, a safety-critical industrial controller losing network access, a connected vehicle losing connectivity to the cloud platform).

Certificate Validity Period Strategy

IoT certificate validity periods require a deliberate strategy that balances security (shorter validity is more secure, as a compromised certificate expires sooner) against operational risk (a certificate that expires while the device is offline causes an outage when the device reconnects).

For devices with reliable, continuous network connectivity and automated renewal capability (cloud-connected IoT with ACME or EST clients), shorter validity periods (1 to 3 years) are appropriate. Renewal is automated and the risk of an expiry-related outage is low. For intermittently connected devices, longer validity periods (3 to 5 years) reduce the frequency of renewal operations and the window during which a device returning from an extended offline period might be attempting to renew with an already-expired certificate. For IDevIDs, the IEEE 802.1AR recommendation is a notAfter date far in the future (often represented as 99991231235959Z, the maximum X.509 validity date) because IDevIDs are permanent identity credentials that should outlive the device.

Renewal Mechanisms for Constrained Devices

CMP and EST both support certificate renewal (re-enrollment before expiry using the existing certificate for authentication). For constrained IoT devices, the renewal trigger should be implemented as a proactive renewal well before the certificate’s expiry, to create a buffer for devices that are intermittently offline. A device with a 3-year certificate should begin attempting renewal 180 days before expiry; if it is offline during that window and misses the first renewal attempt, it has 180 more days to succeed before the certificate actually expires.

For devices that cannot self-renew (firmware does not include a certificate management client), an alternative is a device management platform that renews certificates on behalf of the device: the management platform connects to the device over a management interface (NETCONF, TR-069, proprietary API), requests the device’s current certificate, submits a renewal request to the PKIaaS API, and delivers the renewed certificate back to the device over the management channel. This separates the certificate management function from the device firmware, enabling certificate lifecycle management for devices that were not designed with certificate management in mind.

Revocation at IoT Fleet Scale

Revoking certificates for a fleet of millions of devices requires different operational approaches than revoking a handful of enterprise server certificates.

Individual device revocation: A single device is reported stolen, compromised, or decommissioned. The PKIaaS bulk revocation API accepts the certificate serial number or the device identifier, updates the CA database, and publishes the revocation status to the CRL and OCSP responder. Systems the device connects to can detect the revocation through OCSP on next connection attempt. This is the standard revocation model and works well for individual device events.

Fleet-level revocation: A vulnerability in device firmware affects an entire device class, or a CA key compromise requires revoking all certificates issued by a specific CA. PKIaaS bulk revocation capabilities allow the operator to revoke all certificates issued by a specific issuing CA, all certificates associated with a specific certificate profile, or all certificates issued within a date range, in a single operation. The resulting CRL for a large-scale revocation event may be large; confirm with the PKIaaS provider that the CRL infrastructure can handle the size and distribution requirements of a fleet-scale revocation before an incident occurs.

Revocation checking for constrained devices: A device with 64 KB of RAM cannot download and parse a CRL containing millions of entries. OCSP is more appropriate for constrained devices (a single UDP or HTTP request returns the status of one certificate), but requires network connectivity at the time of the check. For offline scenarios, OCSP stapling (where the server caches a recent OCSP response and delivers it to the client as part of the TLS handshake) reduces the real-time connectivity requirement for revocation checking on the device side. For the most constrained offline devices, revocation relies on the device’s management system revoking at the operator side rather than the device detecting its own revocation.

Sector-Specific Considerations

Automotive and V2X

Connected vehicles have strict PKI requirements driven by ISO 15118 (vehicle-to-grid communication), IEEE 1609.2 (V2X security), and SAE J3061 (automotive cybersecurity guidebook). Vehicle ECUs require device identity certificates for secure communication with the backend, over-the-air firmware update authentication, and V2X communication. V2G (Vehicle-to-Grid) applications use CMP for certificate enrollment, as specified in ISO 15118-20. An automotive manufacturer shipping 500,000 vehicles per year with 10 ECUs per vehicle that each need a certificate requires a PKIaaS deployment capable of issuing 5 million certificates per year at manufacturing throughput rates. PKIaaS with REST API batch provisioning and CMP support is the appropriate infrastructure for this scale.

Industrial OT and IIoT

Industrial OT environments covered by IEC 62443 require cryptographic authentication for ICS components and secure communication between OT network zones. PLCs, DCS components, SCADA servers, and industrial sensors that implement IEC 62443-3-3 security levels require device certificates for inter-zone communication authentication. CMP is specified in IEC 62443-3-3 as a supported enrollment protocol. For industrial environments with constrained devices and partially air-gapped network segments, a local registration authority (RA) deployed within the industrial network segment can collect enrollment requests from constrained devices and batch-submit them to the PKIaaS CA over the more limited connectivity available through the industrial DMZ.

Healthcare IoT

Connected medical devices (infusion pumps, patient monitors, imaging systems, implantable devices with wireless interfaces) require certificate-based authentication to hospital networks to prevent spoofing and unauthorized access. HIPAA Technical Safeguards require access controls and transmission security for ePHI-handling systems, which medical device certificates satisfy. The 21st Century Cures Act interoperability requirements for FHIR APIs add TLS certificate requirements for medical device communication with health information exchanges. Medical device certificates issued by a HIPAA-aligned PKIaaS provider (with SOC 2 Type II, FIPS-validated HSMs, and BAA availability) provide the technical evidence for HIPAA compliance and the audit trail that supports FDA cybersecurity guidance for medical device manufacturers.

Post-Quantum Readiness for Long-Lived IoT Devices

The post-quantum transition creates a specific and urgent challenge for IoT: devices being manufactured today and deployed for 10 to 15 years will be operating in 2035 to 2040, well past NIST IR 8547’s 2035 date for disallowing RSA and ECC. A connected vehicle manufactured in 2026 with RSA-2048 device certificates will be using cryptography that is disallowed by 2035. An industrial controller deployed in 2025 with a 15-year operational life will need PQC-capable certificates before it reaches end of life.

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. For IoT devices, the PQC migration has three dimensions:

Algorithm support on constrained devices: ML-DSA (FIPS 204) produces larger signatures and public keys than ECDSA. For ultra-constrained devices, ML-DSA signature verification may exceed available memory or processing time constraints. SLH-DSA (FIPS 205) has different size characteristics (smaller keys but larger signatures) that may be more appropriate for some constrained device profiles. Hardware PQC acceleration is becoming available in newer microcontroller families; product security teams designing hardware that will ship in 2026 and operate into the 2030s should confirm that the target microcontroller or secure element supports at least one of the NIST-finalized PQC algorithms.

Hybrid certificates as migration bridge: For devices that will be deployed across a period spanning both classical and post-quantum eras, hybrid certificates (combining ECDSA and ML-DSA in a single certificate) allow the device to authenticate using the classical algorithm with systems that do not yet support PQC, while the same certificate includes a PQC component that PQC-capable verifying systems can use. PKIaaS providers that support hybrid certificate issuance enable this migration bridge for IoT fleets.

Firmware update path for algorithm migration: Devices that need to migrate from ECDSA to ML-DSA certificates after deployment require a firmware update that adds ML-DSA algorithm support, along with a certificate update delivered over the existing secure update channel. This underscores the importance of a robust OTA (over-the-air) update mechanism secured by the same PKIaaS firmware signing infrastructure: the firmware update that enables PQC on the device must itself be verifiable. Encryption Consulting’s PQC Readiness service and PQC Center of Excellence provide IoT-specific PQC readiness assessments for manufacturers and operators.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering supports IoT device identity at manufacturing scale through the REST API batch provisioning interface, CMP for ultra-constrained device enrollment, EST for moderate-resource devices, and SCEP for legacy OT platforms. The PKIaaS CA hierarchy supports IDevID and LDevID issuing CA configurations aligned to IEEE 802.1AR, with FIPS 140-3 Level 3 HSM-backed CA keys and M-of-N ceremony documentation. Contact us at Encryption Consulting to discuss your IoT device identity program.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides IoT fleet CLM: certificate discovery and inventory across the deployed device estate, expiry monitoring at fleet scale with batch renewal automation, policy compliance checking (flagging devices with certificates below minimum key size or approaching expiry without a scheduled renewal), and SIEM integration for continuous fleet-level certificate visibility.
• PKI Assessment Service: For manufacturers designing an IoT device identity program from scratch, or for operators assessing an existing IoT PKI program against NIST IR 8228 (Considerations for Managing IoT Cybersecurity and Privacy Risks), Encryption Consulting’s PKI Assessment Service evaluates the current or planned PKI architecture against the IoT-specific requirements of the applicable standards and produces a gap analysis and implementation roadmap.
• HSM as a Service: For manufacturers that need FIPS 140-3 Level 3 HSM capacity for IDevID CA key protection and firmware signing key protection without managing the hardware, Encryption Consulting’s HSM as a Service provides dedicated HSM capacity with the M-of-N controls and audit logging that manufacturing-scale PKI governance requires.
• PQC Advisory Services: For manufacturers and operators planning the PQC migration path for long-lived IoT device fleets, Encryption Consulting’s PQC Advisory Services provide per-device-family assessments of PQC algorithm support feasibility, hybrid certificate migration planning, and OTA update security architecture for the migration program.

Conclusion

IoT device identity at scale is one of the most technically demanding PKI use cases, and one of the highest-consequence ones: a compromised device identity in a medical device fleet, a connected vehicle platform, or an industrial control network is not an IT incident with a business impact. It is a safety and operational risk with physical consequences.

PKIaaS is the right infrastructure choice for IoT device identity because it scales to manufacturing volumes, supports the enrollment protocols that constrained devices can actually use, provides the governance and audit trail that regulated-industry compliance requires, and can serve as both the manufacturer CA (for IDevIDs) and the operator CA (for LDevIDs) within a single PKI hierarchy. The alternative, a self-managed on-premises CA that a manufacturer’s IT team operates alongside their other infrastructure, cannot sustain the issuance rates, the protocol diversity, or the governance depth that serious IoT programs require.

The post-quantum dimension adds urgency. Devices being designed and manufactured today will be operating in 2035. Product security teams that embed PQC algorithm support in their hardware designs now, and work with PKIaaS providers that support hybrid certificate issuance today, are building the migration path into the product rather than leaving it as a retrofit problem for future operators.

If your organization is building an IoT device identity program, evaluating your current program against IEEE 802.1AR requirements, or planning a PQC migration for a deployed device fleet, reach out to Encryption Consulting. We have designed PKI programs for device manufacturers and fleet operators across automotive, industrial, healthcare, and consumer electronics sectors.

This post is reviewed on a six-month cadence and when NIST IR 8228, IEEE 802.1AR, IETF BRSKI (RFC 8995), ISO 15118, or IEC 62443 publish material updates, or when NIST PQC migration timelines relevant to constrained devices change.

Frequently Asked Questions

What is IEEE 802.1AR and why does it matter for IoT device identity?

IEEE 802.1AR defines the IDevID/LDevID framework for cryptographic device identity. An IDevID is a manufacturer-issued certificate providing permanent, globally unique device identity stored in hardware. An LDevID is an operator-issued certificate reflecting operational identity in the deployed environment. IDevIDs enable zero-touch provisioning and ownership transfer; LDevIDs enable access control and revocation in the operational environment. PKIaaS serves as the IDevID CA for manufacturers and the LDevID CA for operators.

What enrollment protocols does PKIaaS support for constrained IoT devices?

CMP (RFC 4210) for ultra-constrained devices (PLCs, smart meters, eSIM, V2G); EST (RFC 7030) for devices with TLS capability; SCEP for legacy OT platforms and MDM-managed devices; ACME (RFC 8555) for cloud-connected IoT with adequate resources; and REST API batch provisioning for manufacturing-time certificate injection. Protocol selection must match the device’s hardware capabilities and is a design-time decision.

How does PKIaaS handle device ownership transfer?

The IETF BRSKI protocol (RFC 8995) defines automated ownership transfer for IEEE 802.1AR-compliant devices: the device presents its IDevID to the new owner’s BRSKI registrar, the registrar validates it against the manufacturer’s MASA, and issues a new LDevID from the operator’s PKIaaS. The IDevID remains unchanged; only the operational LDevID changes with ownership. For non-BRSKI environments, manual ownership transfer uses the IDevID as the provenance document for the LDevID issuance request.

How does PKI support secure boot for IoT devices?

The manufacturer’s PKIaaS CA signs firmware images and bootloaders with code signing certificates. The device’s hardware trust anchor is programmed with the PKIaaS CA certificate at manufacturing time. At boot, each stage verifies the next stage’s firmware signature against the hardware trust anchor. A firmware image not signed by the PKIaaS CA fails verification and the device halts before executing it. The IDevID CA and firmware signing CA are typically separate issuing CAs under the same PKIaaS root.

How do you revoke a certificate for a fleet of millions of IoT devices?

Individual device revocation uses the PKIaaS API with the certificate serial number or device identifier; OCSP reflects the revocation in real time. Fleet-level revocation (firmware vulnerability affecting an entire device class, or a CA key compromise) uses PKIaaS bulk revocation to revoke all certificates associated with a specific CA, profile, or issuance date range in a single operation. For constrained devices, OCSP (not CRL) is recommended for revocation checking due to CRL size limitations.

What is the machine-to-human identity ratio in enterprise environments?

The Palo Alto Networks 2026 Identity Security Landscape report (May 14, 2026) found a 109:1 ratio of machine identities to human identities in enterprise environments. IoT devices are the primary driver of this ratio in manufacturing, healthcare, and industrial environments. Managing 109 machine identities per human identity manually is operationally infeasible; PKIaaS with automated certificate provisioning and lifecycle management is the only practical infrastructure model at this scale.