IoT’s Pathway to Security: How PKI Protects Billions of Connected Devices

A smart thermostat, an insulin pump, and a factory floor sensor have nothing in common except one thing: none of them can type in a password. By the end of 2025, more than 21.1 billion of these silent, credential-less devices will be online worldwide, a number growing 14% a year and on pace to reach 39 billion by 2030. Every one of those devices still needs a way to prove what it is, encrypt what it sends, and show that its data hasn’t been tampered with in transit. Public Key Infrastructure (PKI) remains the only security model built to do all three at that scale, and in 2026 it’s being pushed harder than ever by shrinking certificate lifetimes, new IoT regulation, and the start of the post-quantum transition.

Quick Answer: How Does PKI Secure IoT Devices?

Public Key Infrastructure (PKI) secures Internet of Things devices by embedding a unique digital certificate and key pair in each device, replacing passwords with cryptographic proof of identity. This lets devices authenticate to networks and each other, encrypt data in transit, and prove data integrity, without a human entering credentials, which is essential since most IoT devices have no interface for password entry.

Executive Summary

IoT devices cannot authenticate with passwords, so PKI’s certificate-based model- authentication, encryption, and data integrity- remains the default way to secure them at scale. Three forces are reshaping IoT PKI in 2026: publicly trusted certificate lifetimes are shrinking to 47 days by March 2029, the EU Cyber Resilience Act’s vulnerability-reporting deadline lands September 11, 2026, and NIST’s finalized post-quantum standards are becoming the new baseline for constrained devices. Manual certificate issuance survives none of these three changes; automation, crypto agility, and a documented certificate lifecycle program are now operational requirements, not optional upgrades.

Who Should Care About IoT PKI

Securing IoT devices with PKI touches identity, security architecture, platform operations, and compliance. Here is what each role should do.

PKI Administrators

Scale certificate issuance and renewal capacity to match device fleet growth, and automate certificate discovery so no provisioned device goes untracked as validity periods shrink.

Security Architects

Design the IoT-focused certificate authority architecture, on-premises, cloud, or hybrid, and build crypto agility into it now so a future post-quantum algorithm swap doesn’t require swapping hardware in the field.

Platform Teams

Own device provisioning and enrollment tooling (EST, SCEP) so certificate issuance and renewal happen automatically at manufacture or first boot, not through manual tickets.

Compliance Teams

Map certificate issuance, revocation, and rotation evidence to EU Cyber Resilience Act and NIST SP 800-213 requirements so an audit becomes a report export instead of a scramble.

CISOs

Treat IoT device identity as measurable infrastructure risk, and sponsor the shift from manual, ticket-driven certificate issuance to a fully automated certificate lifecycle program before validity periods shrink further.

Why This Matters: Data and Deadlines

According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced a certificate-related outage in the past year, and 18.5% of affected organizations reported losses exceeding $250,000, with 37.5% of those incidents tied specifically to expired certificates. An IoT fleet with millions of embedded certificates and no automated renewal inherits this same operational risk at a much larger scale.

The CA/Browser Forum’s Ballot SC-081v3, approved April 11, 2025, phases maximum public TLS certificate validity down to 200 days starting March 15, 2026, 100 days starting March 15, 2027, and 47 days starting March 15, 2029. That schedule applies directly to publicly trusted certificates rather than the privately issued certificates most IoT fleets use, but it signals where private IoT PKI programs are already heading: shorter certificate lifetimes to limit how long a compromised key stays useful.

NIST finalized its post-quantum cryptography standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA), on August 13, 2024. Because IoT devices provisioned today can remain in the field for a decade or more, any device issued a certificate now may need to support a post-quantum algorithm before it’s retired, making crypto agility a design requirement rather than a future roadmap item.

Current Security Risks of the Internet of Things

Security has to be designed in before IoT devices ship, not patched in afterward. Each device connected through IoT needs its own verifiable identity, typically a certificate embedded at manufacture or provisioning time, because there is no user sitting at a keyboard to type a password when a device boots up in the field.

The risk shows up the moment that identity is missing or weak. If a digital door lock lacks proper certificate-based authentication, an attacker can impersonate it, unlock it, or intercept its traffic. In October 2016, the Mirai botnet turned this theoretical risk into a real one: malware scanned the internet for IoT devices, mostly DVRs and IP cameras, still running factory-default usernames and passwords, then used them to launch a DDoS attack against DNS provider Dyn large enough to knock Twitter, Netflix, Reddit, CNN, and the Guardian offline for hours. Nearly a decade later, Mirai is still the reference case study for IoT security, not because the attack was novel, but because the root cause, devices with no unique, provisioned identity, is still the default state for a large share of connected devices.

Further examples of risk:

• Unsecured web interfaces on device management consoles
• Weak or absent data privacy controls on collected telemetry
• Unencrypted or poorly authenticated network services
• Unsecured mobile app connections to companion devices

What Public Key Infrastructure Actually Offers for IoT

PKI is a security ecosystem that has secured internet-based transactions since the earliest days of the web, through the use of digital certificates. It replaces password policies and shared tokens with direct, cryptographic proof of identity between systems, which is exactly the model IoT needs: no human in the loop, no credential to phish, just a key pair and a certificate a device can present on its own.

PKI combines software, hardware, procedures, and policy to deliver three core services for IoT environments: authentication, encryption, and data integrity.

Authentication

• Embeds certificates that identify devices and establish trust among devices, services, and users.
• Uses short-lived certificates so a compromised key has a short useful life for an attacker.
• Provides strong authentication between users and devices, and device to device, across the IoT fleet.

Encryption

• Provides strong cryptographic encryption to keep device communications private in transit.
• Supports a wide range of IoT device classes, from smart grid sensors to connected vehicles.

Data Integrity

• Confirms that data has not been altered in transit between device and endpoint.
• Enables digital signing of documents, telemetry, and other data types for non-repudiation.
• Increases confidence in device-reported data and in whatever analysis is built on top of it.

The New Constraint: Certificate Lifetimes Are Shrinking Fast

Under CA/Browser Forum Ballot SC-081v3, approved April 11, 2025, the maximum validity period for publicly trusted TLS certificates is on a fixed schedule down to 47 days:

• Through March 14, 2026: 398 days (current maximum)
• March 15, 2026: 200 days
• March 15, 2027: 100 days
• March 15, 2029: 47 days

That schedule technically applies to publicly trusted certificates, not the privately issued certificates most IoT device fleets use for internal device identity. But it matters to IoT for two reasons. First, any device that talks to a cloud endpoint over public TLS inherits the shorter lifetimes upstream in that connection. Second, and more importantly, it signals where the industry is heading: short-lived certificates limit how long a compromised key stays useful, which is exactly the logic IoT security has argued for since the Mirai era. Private PKI programs that issue certificates to device fleets are adopting similarly short lifetimes as a best practice, not because a regulator requires it, but because a billion-device fleet is only as safe as its slowest certificate rotation. At that pace, manual issuance and renewal isn’t a process gap, it’s an outage waiting to happen.

Scaling and Diversity: PKI’s Two Persistent IoT Challenges

PKI predates the Internet of Things by decades, and the IoT era has surfaced two challenges that traditional PKI deployments were never built to absorb.

Scalability

• Traditional PKI databases and issuance workflows weren’t designed for the request volume billions of devices generate.
• IoT deployments increasingly need a dedicated, IoT-focused Certificate Authority rather than a general-purpose enterprise CA.
• Where and how that CA is provisioned, on-premises, cloud, or hybrid, changes the automation and scaling model significantly.
• The CA and its supporting infrastructure must sustain high issuance volume with fast, predictable response times, especially as validity periods shrink.

Device Diversity

• Traditional PKI use cases centered on issuing certificates for user portal access or SSL/TLS on servers, a fairly uniform set of endpoints.
• IoT breaks that uniformity: a connected vehicle, a medical sensor, and a smart meter each have different compute budgets, connectivity patterns, and certificate lifecycles.
• Every device class manufactured for IoT effectively needs its own security and provisioning profile.

Regulation Is Catching Up: What EU CRA and NIST Mean for IoT PKI

IoT security stopped being a best-practice conversation and started being a compliance one. The EU Cyber Resilience Act (CRA) entered into force on December 10, 2024, and applies to hardware and software products with digital elements sold in the EU. Its vulnerability-reporting obligations, requiring manufacturers to report actively exploited vulnerabilities, take effect September 11, 2026, with the Act’s main cybersecurity-by-design obligations applying from December 11, 2027. For any organization shipping connected devices into the EU, that timeline is now a hard deadline, not a roadmap item.

On the federal side, NIST opened a draft revision of its foundational IoT guidance, SP 800-213 Revision 1, for public comment in mid-2026, updating the cybersecurity requirements federal agencies expect from connected device manufacturers. Whether or not an organization sells directly to the U.S. government, SP 800-213 has historically shaped procurement requirements that ripple into the broader IoT supply chain.

Neither framework tells an organization to use PKI by name, but both assume verifiable device identity, encrypted communications, and auditable vulnerability handling, which is precisely what a well-run certificate lifecycle program produces as a byproduct. A certificate lifecycle management (CLM) platform that can show issuance history, revocation status, and rotation compliance across a device fleet turns a CRA or NIST audit from a scramble into a report export.

Getting IoT PKI Ready for Post-Quantum Cryptography

In August 2024, NIST finalized its first three post-quantum cryptography standards: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. These are now the reference algorithms every PKI, including IoT PKI, needs a migration plan toward, since a device provisioned today may still be in the field a decade from now, well past when quantum computers are expected to threaten current public-key algorithms.

IoT adds a wrinkle the enterprise world doesn’t have to the same degree: most of the finalized PQC algorithms are computationally heavier than the ECC most constrained devices use today. NIST’s answer for that gap is SP 800-232, published in 2025, which standardizes Ascon-based lightweight cryptography specifically for constrained devices, exactly the class of hardware that makes up most of the IoT install base.

On the hardware root-of-trust side, FIPS 140-2 module validations sunset on September 21, 2026, making FIPS 140-3 the sole current validation standard for the HSMs that typically anchor an IoT CA’s root and issuing keys. Any IoT PKI program still running on FIPS 140-2 validated hardware needs a transition plan before that date, not after it.

IoT PKI Glossary

Quick, extractable definitions for the terms used throughout this post.

Term	Definition
Public Key Infrastructure (PKI)	The certificates, key pairs, policies, and certificate authority that together establish and verify digital identity for users, servers, and devices.
Certificate Authority (CA)	The trusted entity that issues, signs, and revokes digital certificates, confirming a device’s or user’s identity.
Digital Certificate	A signed, cryptographic file that binds a public key to an identity, used by a device to prove who it is without a password.
Certificate Lifecycle Management (CLM)	The process and tooling used to discover, issue, renew, and revoke certificates automatically across an environment or device fleet.
Crypto Agility	The ability to swap cryptographic algorithms, such as moving to post-quantum algorithms, without replacing the underlying hardware or infrastructure.
EST / SCEP	Enrollment protocols (Enrollment over Secure Transport and Simple Certificate Enrollment Protocol) that let devices request and renew certificates automatically.
Hardware Security Module (HSM)	A dedicated, tamper-resistant hardware device that generates and protects the private keys anchoring a certificate authority’s root of trust.
Post-Quantum Cryptography (PQC)	Cryptographic algorithms, such as NIST’s ML-KEM and ML-DSA, designed to remain secure against attacks from future quantum computers.

IoT PKI Issue Checklist: Impact, Action, and Owner

Issue	Business Impact	Recommended Action	Owner
Manual certificate issuance for device fleet	Renewal backlog grows as validity periods shrink, risking outages	Automate issuance and renewal with EST or SCEP	Platform teams, PKI administrators
No dedicated IoT certificate authority	Enterprise CA cannot absorb device-scale issuance volume	Stand up an IoT-focused CA, on-premises, cloud, or hybrid	Security architects
No crypto-agility plan for PQC migration	Long-lived devices may need algorithm swaps that require a hardware refresh	Build crypto agility into new device provisioning now	Security architects, CISOs
No documented certificate evidence for audits	EU CRA and NIST SP 800-213 audits become manual scrambles	Adopt a CLM platform with issuance, revocation, and rotation reporting	Compliance teams
HSMs still on FIPS 140-2 validation	Root-of-trust hardware falls out of the current validation standard after September 21, 2026	Plan a transition to FIPS 140-3 validated HSMs	PKI administrators, CISOs

What We’d Actually Recommend for IoT PKI in 2026

Reading the risks, the regulation, and the post-quantum timeline together, our recommendation to clients building or rearchitecting IoT PKI is consistent: stop treating certificate issuance as a manual, ticket-driven process. At 21 billion devices and shrinking validity windows, manual issuance is already the bottleneck, and it gets worse every year it isn’t fixed.

• Automate issuance and renewal end to end using protocols like EST or SCEP so devices enroll and rotate certificates without a human in the loop.
• Default to ECC and lightweight algorithms for constrained devices rather than porting server-grade RSA assumptions onto battery-powered hardware.
• Build crypto agility in now, before the post-quantum migration is urgent, so swapping algorithms doesn’t mean swapping hardware in the field.
• Treat compliance evidence as a design requirement, not a report you generate after the fact, given CRA and NIST reporting deadlines are now fixed dates.

Certificate Lifecycle Management and PKI Modernization

Closing the gap this post describes depends on the same certificate discovery and automation capabilities that support any large-scale PKI modernization effort. CertSecure Manager automates certificate discovery, issuance, and renewal across large, diverse device fleets, turning shrinking validity windows into a configuration setting instead of a fire drill.

Organizations that need to scale IoT PKI without operating it entirely in-house can rely on PKI-as-a-Service for a dedicated, cloud-hosted certificate authority sized for device-scale issuance volume. Before a large IoT rollout, it is worth building a machine identity inventory through CBOM Secure and completing a PQC readiness assessment, so certificate discovery for the device fleet also builds crypto agility for the post-quantum transition. Encryption Consulting’s PQC Center of Excellence provides guidance on sequencing these initiatives together.

For more on why certificate automation matters across the environment, see our Education Center articles on the stages in a certificate’s lifecycle and how to avoid certificate outages.

Measuring Success and Ongoing Audits

Track the percentage of the device fleet on automated certificate issuance versus manual provisioning, the number of certificate-related device outages, and whether every issuing CA in a hybrid or multi-CA environment reports into one certificate discovery view. Audit certificate issuance logs, revocation status, and HSM validation levels on a recurring basis, quarterly for policy-driven factors like the CA/Browser Forum validity schedule, and continuously for certificate expiry, so a shrinking validity window never turns into an unplanned device outage.

PKI has anchored internet trust since the earliest days of the web, and nothing about the IoT era has changed that; it has only raised the stakes. The organizations getting IoT security right in 2026 aren’t the ones bolting on point solutions after an incident. They’re the ones that treated certificate-based identity as infrastructure from the start, built for automation, sized for scale, and planned for algorithms that don’t exist in production yet.

At Encryption Consulting, we help organizations design, implement, and operate the PKI that IoT at scale actually requires, choosing the right architecture and the right automation, not just the right vendor.

Frequently Asked Questions

What is the main takeaway from PKI – IoT’s Path to Security?

IoT devices cannot authenticate with passwords, so PKI’s certificate-based model remains the default way to secure device identity, encryption, and data integrity, and in 2026 that model must be automated to survive shrinking certificate lifetimes and new regulation.

Why does this matter for enterprise PKI teams?

PKI teams are directly responsible for scaling certificate issuance and renewal to match device fleet growth, and for building the crypto agility that will be needed for the post-quantum transition.

What risks increase if this topic is handled manually?

Manual certificate issuance for an IoT fleet increases the risk of missed renewals, inconsistent device onboarding, and slower response when a device’s certificate needs to be revoked after a compromise.

Which teams should own this change?

Security architects design the IoT certificate authority architecture, PKI administrators scale issuance and automation, platform teams own device enrollment tooling, and compliance teams verify the program meets EU CRA and NIST requirements.

How does this connect to certificate lifecycle management?

Every IoT device is another certificate that must be issued, renewed, and revoked. Securing IoT with PKI is only sustainable if the device fleet is managed under the same certificate lifecycle management program as every other certificate type in the environment.

How should organizations measure success?

Track the percentage of the device fleet on automated certificate issuance versus manual provisioning, the number of certificate-related device outages, and whether certificate discovery spans every issuing CA in the environment.

What should be audited or monitored regularly?

Regularly audit certificate issuance logs, revocation status, HSM validation levels, and certificate expiry dashboards across the device fleet to catch renewal failures before they cause device outages.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Large IoT deployments often issue certificates from multiple CAs across on-premises and cloud environments; without centralized certificate discovery, devices trusted under one CA can go untracked when the environment shifts to hybrid or multi-CA architecture.

What common mistakes should teams avoid?

Common mistakes include shipping devices with certificates that require manual renewal, using a general-purpose enterprise CA that cannot absorb device-scale issuance volume, and delaying crypto-agility planning until a post-quantum migration is already urgent.

What should be refreshed quarterly?

Review the device fleet inventory for newly provisioned devices needing certificates, confirm certificate validity periods against the current CA/Browser Forum schedule, and re-verify HSM validation levels ahead of the FIPS 140-2 sunset.