Every connected device is a potential attack vector. Digital certificates give machines a cryptographic identity, enabling them to authenticate, encrypt communications, and prove their integrity without human intervention.
There are now far more machines connected to the internet than people. Industrial sensors on factory floors, medical devices in hospitals, smart meters in utility networks, connected vehicles on highways, surveillance cameras in cities. The number of IoT devices worldwide is projected to exceed 30 billion by 2030. Each one of these devices needs a machine identity.
Without a verifiable identity, a device cannot prove that it's genuine hardware from a legitimate manufacturer, that its firmware hasn't been tampered with, or that the data it sends can be trusted. Hardcoded passwords and shared API keys, still disturbingly common in IoT, are trivially easy to extract, clone, or brute-force. Once one device is compromised, the same credentials often grant access to every device in the fleet.
Digital certificates solve this by giving each device a unique, cryptographically bound identity. Issued by a trusted Certificate Authority, a device certificate contains the device's public key and identifying information (its serial number, model, manufacturer, or any attribute that distinguishes it). The corresponding private key is stored in the device's secure element or TPM, ensuring it can't be extracted or cloned.
Certificates provide three fundamental capabilities that are essential for any connected device operating in a production environment:
A certificate proves the device is what it claims to be. When a sensor connects to a cloud platform, or a medical device joins a hospital network, the receiving system can verify the device's identity cryptographically, without relying on a shared password that could be intercepted or guessed.
Certificates enable TLS-encrypted channels between devices and backend systems. This ensures that sensor readings, telemetry data, and commands in transit can't be eavesdropped on or altered. This is critical for industrial control systems, healthcare devices, and any environment where data integrity matters.
Certificates can verify that firmware updates are authentic before installation, preventing supply chain attacks where malicious code is pushed to devices. They also enable secure boot chains, where each component in the boot process is cryptographically verified before execution.
Certificate attributes (organization, device type, location) can drive fine-grained access policies. A temperature sensor might be allowed to publish data to a specific MQTT topic but not subscribe to control channels, all enforced based on the certificate's fields, with no additional credential management needed.
Unlike user certificates managed through IT workflows, device certificates must accommodate manufacturing processes, field conditions, and potentially decades-long hardware lifespans. The lifecycle has three distinct phases:
The ideal time to provision a device certificate is during manufacturing, when the device's secure element or TPM generates a key pair and the public key is sent to the CA for certification. This birth certificate, sometimes called an Initial Device Identifier (IDevID), is baked into the device before it ever ships. It provides a root of trust that persists for the device's entire lifetime, regardless of where it's deployed or who owns it.
Certificates expire, and device certificates are no exception. A smart meter installed for a 20-year deployment will need its operational certificates renewed multiple times. This must happen automatically, without a technician visiting the device. The device uses its current valid certificate (or its IDevID as a bootstrap credential) to authenticate to the CA and request a new certificate through enrollment protocols like EST or CMP.
When a device reaches end of life, is sold, or is compromised, its certificates must be revoked to prevent further use. This is especially important in industrial environments where decommissioned devices might be resold or repurposed. A revoked certificate ensures the device can no longer authenticate to any system that checks revocation status, effectively disconnecting it from the trusted network.
Devices can't fill out a web form to request a certificate. They need machine-to-machine enrollment protocols that are designed for automated, unattended operation. Three protocols dominate the landscape:
Enrollment over Secure Transport is the modern standard for device certificate enrollment. It runs over HTTPS, supports certificate-based and username/password authentication for the initial request, and handles re-enrollment natively. EST is the recommended protocol for new deployments and is widely supported by modern IoT platforms and PKI solutions.
Simple Certificate Enrollment Protocol has been the workhorse of device enrollment for over two decades. Originally developed by Cisco, it uses HTTP and a challenge password for initial authentication. While showing its age (it lacks native TLS protection and has limited renewal capabilities), SCEP remains essential because millions of deployed devices and MDM platforms depend on it.
Certificate Management Protocol is a comprehensive protocol that covers the entire certificate lifecycle, from initial request through updates, revocation, and key recovery. It's particularly prevalent in telecom and industrial environments. CMP supports complex PKI topologies with Registration Authorities and is mandated by several industry standards including 3GPP for mobile networks.
While best known for web server certificates (via Let's Encrypt), ACME is increasingly being adopted for device enrollment in cloud-native IoT platforms. Its automation-first design and widespread tooling support make it attractive for environments where devices are managed through modern DevOps practices.
Managing certificates for a handful of servers is one thing. Managing them for millions of IoT devices introduces challenges that are fundamentally different in nature:
A utility company might deploy 5 million smart meters. An automotive manufacturer might produce 10 million vehicles a year, each with multiple connected modules. The CA infrastructure must handle burst enrollment (tens of thousands of certificates during a manufacturing run) and sustained renewal traffic, all while maintaining low latency and high availability. Traditional PKI architectures weren't designed for this throughput.
Many IoT devices have limited CPU, memory, and storage. A tiny microcontroller running a sensor might have only 256 KB of flash and 64 KB of RAM. Full X.509 certificate chains and complex TLS handshakes can strain these resources. Lightweight profiles, elliptic curve cryptography (ECC), and optimized protocol implementations become essential to make certificates viable on constrained hardware.
Devices deployed in remote locations (agricultural sensors, pipeline monitors, offshore equipment) may only connect sporadically. Certificate renewal must be resilient to connectivity gaps, with devices able to request new certificates well before expiration and retry gracefully if the CA is temporarily unreachable. Offline provisioning models and certificate pre-staging are sometimes necessary for devices that operate in fully disconnected environments.
These constraints make certificate discovery and inventory even more critical in IoT environments. You can't renew what you can't see, and a single expired certificate on a critical industrial controller can halt an entire production line.
Several industry standards and frameworks now mandate or strongly recommend certificate-based device identity. Understanding these is essential for compliance and interoperability:
The primary cybersecurity standard for industrial control systems (ICS) and operational technology (OT). IEC 62443 defines security levels that increasingly require certificate-based authentication between components. At higher security levels, mutual authentication using X.509 certificates is mandatory for all network communications between zones and conduits.
The Matter standard (backed by Apple, Google, Amazon, and Samsung) requires every smart home device to carry a Device Attestation Certificate (DAC) that proves it's a genuine, certified product. This certificate is verified during commissioning before the device joins the home network, eliminating the counterfeit device problem that plagued earlier smart home ecosystems.
The GSMA's IoT SAFE (SIM Applet For Secure End-to-End Communication) specification leverages the SIM card as a secure element for storing device certificates and performing cryptographic operations. This allows mobile-connected IoT devices to establish TLS sessions using certificates stored in the tamper-resistant SIM, providing carrier-grade security without additional hardware.
High-throughput PKI for IoT: Evertrust PKI is built to handle the enrollment volumes that IoT demands. Whether you're provisioning certificates during a manufacturing run or renewing millions of device certificates in the field, the platform scales to meet your throughput requirements via EST, SCEP, CMP, and ACME.
Complete device inventory: Evertrust CLM maintains a real-time inventory of every device certificate across your fleet. Discovery scans find certificates you didn't know existed, while dashboards show expiration timelines, compliance status, and algorithm distribution at a glance.
Protocol flexibility: Not all devices speak the same protocol. Evertrust supports EST, SCEP, CMP, and ACME simultaneously, so legacy devices and modern platforms can coexist under a single certificate management infrastructure without compromise.
Policy enforcement at scale: Define certificate templates that enforce key algorithms, validity periods, and naming conventions specific to each device type. Evertrust ensures every issued certificate complies with your organizational policies and industry standards, from PKI architecture requirements to IEC 62443 mandates.
