Hardware-Rooted Trust-Part 1: Foundations of Hardware Security

1. Introduction – The Challenge: Trust Doesn’t Scale by Software Alone

Every connected system ultimately confronts the same fundamental question: How do we know a device, user, or service is genuinely who it claims to be?

In small, controlled environments, software certificates or encrypted tokens may provide adequate assurance. But as IoT deployments scale to thousands of edge controllers, gateways, and remote devices, purely software-based trust reveals critical weaknesses. Private keys stored on disk can be copied without leaving traces. Digital certificates can be spoofed with sufficient effort. Firmware can be compromised months before any detection occurs. These vulnerabilities become increasingly expensive to address as fleets grow.

Modern security architectures solve this by anchoring identity and cryptographic operations in hardware, leveraging specialized chips and appliances that were purpose-built to protect secrets against both logical and physical attacks.

Two complementary technologies enable this approach:

• The Trusted Platform Module 2.0 (TPM 2.0): a cryptographic module that binds secrets to specific devices and verifies firmware integrity through measured boot
• The Hardware Security Module (HSM): a hardened, tamper-resistant appliance (deployed on-premises or in the cloud) that safeguards enterprise-scale cryptographic operations and key management

Connecting these two is PKCS #11, a standardized interface that allows any software, from OpenSSL to AWS Greengrass, to communicate with these secure tokens using a consistent, vendor-neutral API.

This comprehensive guide is divided into three parts to provide you with a complete understanding of hardware-rooted security in IoT systems. Part 1 establishes the foundational concepts, explaining why hardware security matters and introducing the core technologies: TPM 2.0 for device-level security, HSM for enterprise-scale cryptographic operations, and PKCS #11 as the universal interface that connects them. Part 2 bridges theory and practice, demonstrating how PKCS #11 abstraction enables identical code to run across development (SoftHSM) and production (TPM) environments, and walks through the complete setup process for both. Part 3 brings everything together with real-world implementation, showing you how to provision AWS IoT certificates, establish mTLS connections, integrate with AWS IoT Greengrass, and verify end-to-end security, all while maintaining code portability across environments.

2. Why Hardware-Anchored Security Matters

Consider a typical IoT deployment: thousands of edge controllers communicate with backend services over MQTT or HTTPS. For true security each device must authenticate using a private key to establish mutual TLS connections.

The core vulnerability: if that private key lives unprotected in the file system and shared across devices, any successful breach, whether through supply-chain compromise, stolen firmware, or local system access, exposes not just one device but every credential derived from the master keys.

Hardware anchored security modules address three critical gaps that software-only approaches cannot:

Key Isolation
Private keys cannot be read or exported from the secure boundary of the chip. Only cryptographic operations (sign, verify, decrypt) are permitted. The key material never enters system RAM or volatile memory. This architectural property means an attacker cannot exfiltrate keys even with kernel-level access.

Integrity Measurement
Bootloader firmware, application code, and configuration data can be cryptographically “measured” and recorded, creating an immutable chain of evidence. This enables measured boot, where each firmware stage hashes and extends the measurement of the next stage. Devices can later provide cryptographic proofs of their boot state, ensuring  that only approved firmware is launched on the device. 

Tamper Evidence
Physical attacks on the hardware (drilling, desoldering, voltage manipulation) trigger security responses, chip resets, key erasure, or operational halt. Some modules actively detect and respond to temperature anomalies, radiation, or side-channel attacks. This raises the bar for extracting secrets to levels prohibitive for most adversaries.

These properties work together to make “identity theft” and credential compromise physically and logically improbable, transforming security from a software-only concern into a verifiable hardware property.

Beyond preventing breaches, this architecture simplifies compliance with regulatory frameworks such as FIPS 140-3 (U.S. Federal cryptographic standards), ISO 27001 (information security management), and IEC 62443 (industrial control system security). Auditors can verify that keys reside in certified hardware rather than relying on code review and access controls.

3. The Trusted Platform Module 2.0 (TPM 2.0)

3.1 Purpose and Origin

The TPM specification, maintained by the Trusted Computing Group (TCG), defines a secure coprocessor responsible for storing cryptographic keys and performing sensitive operations without exposing key material to the host system. Functionally, a TPM acts as a trusted witness to the state and integrity of a device.

Almost every modern PC or laptop motherboard or embedded system-on-chips (SoC), includes a TPM 2.0. Deployment varies: discrete physical chips (common in servers), integrated into the SoC (typical in modern mobile and IoT devices), or firmware-based implementations (prevalent in some cloud environments). For developers, the key point is that the TPM is always present, always available, and configured by the device manufacturer or firmware vendor.

3.2 Core Components

To understand how TPMs secure IoT systems, you need to know four key abstractions:

Endorsement Key (EK)
An asymmetric key pair (typically RSA-2048 or ECC) burned into non-volatile memory during  manufacturing. The EK is unique per device and serves as the immutable identity anchor. It cannot be changed or regenerated. Cloud systems use the EK to prove that a particular hardware chip is who it claims to be, analogous to a machine’s serial number, but cryptographically verifiable.

Storage Root Key (SRK)
The root of an owner hierarchy key structure. All other keys generated by the device are encrypted and stored under the SRK. This creates a key derivation chain: if an attacker cannot extract the SRK, they cannot access subordinate keys. The SRK is generated during TPM initialization and typically sealed to the TPM’s firmware configuration.

Platform Configuration Registers (PCRs)
Tamper-proof memory locations that store cryptographic hashes of boot components. During boot, firmware stages hash themselves and extend the PCR values. For example, the BIOS calculates the hash of  the bootloader and extends PCR0. The bootloader hashes the OS kernel and extends PCR0 again. This creates a chain where the final PCR value represents a compressed, verifiable record of the entire boot chain. If any component is altered, the PCR changes, breaking any cryptographic signatures or attestation proofs.

Non-Volatile Storage
Persistent memory where the TPM stores certificates, counters, and audit logs. This survives power cycles and reboots, enabling device policy enforcement and historical verification.

3.3 How TPM-Based Device Security Works

The typical workflow involves several phases:

1. Manufacturing Phase
The device firmware generates or retrieves the Endorsement Key (EK) from the TPM. An enterprise CA certifies this EK, binding it to a device identifier. This certificate is stored in the TPM’s non-volatile memory. The device now has a cryptographically verifiable identity rooted in hardware.

2. Boot Integrity Measurement
During device startup, each firmware stage calculates the hash of the next stage and extends a Platform Configuration Register. By the time the OS kernel loads, the PCRs contain a cryptographic fingerprint of the entire boot chain. The operating system can query these registers at runtime to confirm that approved code executed.

3. Key Sealing
Application-generated keys can be sealed to specific PCR values. This means a key is encrypted in such a way that it can only be decrypted if the TPM’s PCRs match the values recorded during sealing. If the firmware changes, the PCRs change, and the key cannot be unsealed. This prevents cloning: even if an attacker copies the TPM contents, the key remains inaccessible on different hardware with different boot measurements.

4. Runtime Attestation
The device can generate a signed quote containing current PCR values and system time. This quote is cryptographically signed by the TPM and can be verified by the cloud using the device’s EK certificate. The cloud system inspects the quote, checks that PCR values match known-good values, and confirms the device is in a trusted state.

3.4 Real-World Use Cases

Device Authentication for IoT Gateways
Device generates asymmetric key pair under owner hierarchy protected by Storage Root Key (SRK). The device generates a certificate signing request (CSR) from the public key of the generated key pair. The CSR is used as part of provisioning requests to AWS IoT Core. AWS IoT Core issues a new x509 certificate based on the CSR message and assigns certificate policies, specifying allowed operation. The device receives the x509 certificate and can use it for establishing encrypted mTLS MQTT connection to the cloud. That way the x509 certificate is used for the device authentication and for traffic encryption, ensuring that traffic can be decrypted only using the private key residing in TPM 2.0. 

Secure Credential Storage for Operating System Logins
Linux systems can use TPM to seal user passwords or encryption keys to a specific boot state. When the system starts, it automatically unseals credentials only if PCRs match. If an attacker modifies the bootloader, PCRs change, credentials fail to unseal, and the system enters a lockdown state.

Integrity Reporting for AI/ML Model Protection
Edge devices running AI inference models can seal model decryption keys to a known-good firmware state. The model executes only if the device can unseal its key, proving firmware integrity. If the firmware is modified (even minimally), the key remains locked.

TPM-backed Full Disk Encryption

It is possible to encrypt volumes using keys securely stored in the TPM. This approach ensures that your drives remain locked unless the TPM is present and specific conditions are met, such as the integrity of the firmware or Secure Boot state. This provides strong protection if the drive is removed from the computer with the TPM.

TPM 2.0 provides a device-level root of trust: if a device can cryptographically prove its identity and firmware integrity, every application and service built on that foundation inherits that trust assurance.

4. The Hardware Security Module (HSM)

4.1 Role and Scope

While a TPM secures a single device, an HSM serves an organization’s cryptographic needs at scale. An HSM is a high-performance, tamper-resistant appliance designed for secure key generation, storage, and cryptographic operations across many client applications.

Think of a TPM as a device’s personal security guard, whereas an HSM is an enterprise’s vault. Where a TPM typically handles a few signatures per second, an HSM can execute thousands of RSA, ECDSA, or AES operations per second, sufficient to support entire public-key infrastructures (PKIs), payment authorization systems, or authentication servers.

4.2 Core Characteristics

All HSMs, whether physical appliances like Thales Luna or YubiHSM, or cloud services like AWS CloudHSM, share common properties:

FIPS-Certified Hardware Boundary
HSMs are validated against FIPS 140-3 (or higher), a U.S. government standard for cryptographic module security. This certification means the hardware has undergone rigorous testing for cryptographic correctness, physical tamper resistance, and secure design. For regulated industries (finance, healthcare, government), FIPS certification is often a compliance requirement.

Hardware-Based Random Number Generator
HSMs include dedicated entropy sources (thermal noise, oscillator jitter) that feed cryptographically strong random number generators. This is crucial for generating unpredictable key material. Unlike software-based generators that may be influenced by system state, hardware RNGs provide true entropy.

Comprehensive Audit Logging
Every cryptographic operation, key generation, signing, decryption, is logged with timestamps and user information. Logs are stored within the HSM’s tamper-proof boundary and can be exported only in authenticated, encrypted form. This creates an irrefutable audit trail for compliance and forensics.

Multi-Tenancy Support
Enterprise HSMs support partitions or virtual devices, allowing multiple users or applications to share the same physical hardware while maintaining cryptographic isolation. Each partition has its own PINs, keys, and audit logs. One tenant cannot access another’s keys or operations.

4.3 HSM Examples

AWS CloudHSM
A managed HSM service running in AWS datacenters. You instantiate a CloudHSM cluster in a region, and AWS provides dedicated (single-tenant) hardware. Your application connects via a client library, authenticates with a PIN, and performs operations. AWS handles physical security, firmware updates, and redundancy. Your keys never leave the HSM; only encrypted operations are performed.

YubiHSM 2
A compact USB device from Yubico containing cryptographic hardware. It offers superior cost effective security and easy deployment making it accessible for every organization. It offers a higher level of security for cryptographic digital key generation, storage, and management, for organizations. 

YubiHSM is ideal for on-premises key management, firmware signing, or distributed deployments where a cloud service is not feasible.

Swissbit iShield HSM
An embedded HSM in microSD or USB form factor, designed for compact IoT or edge gateways. It provides the same FIPS protections as larger HSMs but in a footprint suitable for industrial controllers.

4.4 Comparing TPM 2.0 and HSM

The two technologies serve different roles:

Aspect	TPM 2.0	HSM
Location	On the device (motherboard, SoC, or firmware)	Data center, cloud, or premises (separate appliance)
Primary Use Case	Device identity, boot integrity, local credential sealing	Enterprise key management, PKI operations, centralized signing
Performance	~100–200 ms per RSA-2048 signature	Thousands of operations per second
Accessibility	Via OS drivers (TPM 2.0 resource manager) or direct SPI/I²C	Network API (PKCS #11, REST, or proprietary)
Scale	One per device	Shared across many applications and thousands of clients
Key Exportability	Keys cannot be exported; operations only	Keys cannot be exported, but HSMs allow backups and uniting multiple HSMs into clusters for achieving redundancy, High Availability and failure recovery
Typical Cost	Included in hardware; no additional cost	CloudHSM (~$2–3 per hour); YubiHSM ($1–2k per unit)

In practice, some organizations deploy both: TPMs anchor device identity at the edge, while HSMs centralize enterprise trust and handle high-volume PKI operations. Together, they form a complete security architecture.

5. PKCS #11 — The Common Language of Cryptographic Devices

5.1 What Is PKCS #11?

PKCS #11 (Public-Key Cryptography Standard #11) is a vendor-neutral, standardized interface for interacting with cryptographic devices. Maintained by OASIS (Organization for the Advancement of Structured Information Standards), PKCS #11 defines a set of C functions, data structures, and workflows that any cryptographic device can implement.

The profound advantage: whether your secure hardware is a TPM chip on a laptop, a USB security token, or a CloudHSM cluster in the cloud, your code interacts using identical PKCS #11 calls. You can switch vendors, change deployment models, or upgrade hardware by updating only configuration, your application logic remains unchanged.

Without PKCS #11, vendors would each define proprietary APIs, forcing developers to rewrite code for each hardware platform. PKCS #11 solves this by establishing a common contract.

5.2 Core Abstractions

To use PKCS #11 effectively, understand these key concepts:

PKCS#11 Modules

Library file (.so / dll) containing implementation of PKCS#11 specification for the specific hardware. This library is typically provided by a hardware vendor and can be downloaded from the vendor’s website in the technical support section (example for YubiHSM 2 v2.4).

Slots
A logical connection point representing a cryptographic device or token. On a computer with a TPM and a USB security token, you have two slots. Slots are identified numerically or by label. Your code opens a session to a specific slot to access its cryptographic capabilities.

Tokens
The cryptographic device itself, either physical (USB token, HSM) or logical (software module, TPM interface). A token provides cryptographic services: key generation, signing, and verification. Tokens have names, PINs, and configuration policies.

How PKCS#11 entities relate to each other 

Objects
Any data item stored in the token’s memory: private keys, public keys, X.509 certificates, or vendor-defined opaque data. Objects are identified by attributes like label (name) and type (private key, certificate, etc.). 

Object type can be

• Key object
  • Asymmetric public / private key
  • Symmetric key 
• X509 certificate object
• Data object
  • Any byte array typically used by application needs. 

Sessions
An authenticated channel opened between your application and the token. Sessions maintain state: the current user, login status, and open handles. You must open a session to perform operations; closing a session cleans up resources.

Roles
Tokens support two authenticDifferent types of PKCS#11 objectsation roles: Security Officer (SO) for administrative tasks (initialize tokens, set PINs) and User for cryptographic operations (sign, verify). Each role has a separate PIN, ensuring that administrative access is compartmentalized from runtime access.

5.3 A Typical PKCS #11 Workflow

Most applications follow this pattern:

C_Initialize()            // Load the PKCS #11 implementation library
C_GetSlotList()            // Discover available tokens/slots
C_OpenSession()             // Connect to a specific slot
C_Login()                         // Authenticate with PIN (User role)
C_Sign() / C_Encrypt() / C_Decrypt() // Perform a cryptographic operation
C_Logout()           // Logout 
C_CloseSession()     // Close session
C_Finalize()                 // Clean up and close

Each function is thread-safe and stateless. Your application can manage multiple sessions in parallel, each potentially connected to different tokens.

5.4 The Power of PKCS #11 URIs

PKCS #11 defines a URI scheme that unambiguously identifies objects within a token:

pkcs11:token=test_sofhhsm2_token;
            manufacturer=SoftHSM2;
            model=2.0;
            object=my_test_certificate;
            type=cert;
            id=%69%95%3E%5C%F4%BD%EC%91;
            ?pin-source=file:/etc/token_pin
            ?module-path=/usr/lib/softhsm/libsofthsm2.so

This format specifies: on a token named “test_softhsm2_token” manufactured by SoftHSM2 refer object “my_test_certificate” of type “cert” and ID `…` . Use the PKCS11 implementation library located in the `module-path` location and use `pin-source` as authentication value for the User role . PKCS #11 URIs are directly supported by modern tools and libraries:

• OpenSSL 3 / pkcs11-provider – provider extension allows refer keys and certificates as PKCS#11 URIs 
• Curl – can establish TLS with hardware-backed certificates
• AWS Greengrass – configures device identity via PKCS #11 URIs
• Paho-mqtt / AWS IoT Device SDK – MQTT connection libraries support connection encryption using keys from PKCS#11 store
• PyKCS11 – python wrapper library for making PKCS#11 library calls from python  

This standardization means your configuration is portable. Changing from a TPM to a CloudHSM requires updating only the URI prefix, not rewriting application code.

5.5 Benefits of a Unified API

Portability
Develop on SoftHSM (a software emulator), test on a physical YubiHSM, and deploy against AWS CloudHSM, all using identical code. Vendors become interchangeable.

Abstraction
Developers focus on cryptographic logic and security policies, not low-level hardware details. The PKCS #11 provider handles the translation between high-level operations and device-specific commands.

Security
Credentials remain sealed within the cryptographic module. Your application never sees plaintext keys. Even if the application process is compromised, private keys remain protected inside the token.

Compliance
Many regulatory frameworks require auditable, hardware-protected key operations. PKCS #11 devices provide cryptographic operation logs and verifiable key storage, simplifying compliance demonstrations.

6. How PKCS #11 Connects TPMs and HSMs

The practical power of PKCS #11 becomes clear when you realize that both TPMs and HSMs can implement the same standard. This creates a symmetry:

Examples of common configurations:

Environment	Hardware	PKCS #11 Module
Developer Laptop	SoftHSM v2 (emulated)	/usr/lib/softhsm/libsofthsm2.so Installed as part of softhsm2 and libsofthsm2 packages
Edge IoT Device	TPM 2.0 chip	/usr/lib/libtpm2_pkcs11.soInstalled as part of libtpm2-pkcs11-1
On-Premises Server	YubiHSM 2 (USB)	/opt/yubihsm/lib/libyubihsm_pkcs11.soCan be downloaded from YubiHSM technical support website
Cloud Backend	AWS CloudHSM	/opt/cloudhsm/lib/libcloudhsm_pkcs11.soCan be downloaded by link from AWS CloudHSM documentation

The same OpenSSL commands, Greengrass configurations, or custom code work across all these environments. Only the PKCS #11 module path changes, a one-line configuration update.

This symmetry enables powerful deployment patterns:

1. Developers write and test code against SoftHSM on their laptops
2. CI/CD pipelines test against physical TPMs in a test lab
3. Production deployments run against CloudHSM in the cloud
4. A single codebase powers all three environments

Without PKCS #11, each environment would require custom integration code, testing would be fragmented, and production deployments would harbor untested code paths.

7. Security Benefits in Layered Architectures

When you integrate TPMs and HSMs into an IoT architecture, you gain multiple security properties that compound:

Key Non-Exportability
Private keys cannot be read, copied, or exported from the secure module, not even by administrators. Only cryptographic operations are allowed. If an attacker steals a device or cloud VM, the keys remain inaccessible. This is fundamentally different from file-based keys, which can be copied with filesystem access.

Hardware-Based Randomness
Key generation relies on the device’s hardware RNG, which produces entropy from physical phenomena (thermal noise, oscillator jitter). This is more trustworthy than software-based pseudo-random generators, which can be influenced by system state or predictable seeding.

Tamper-Aware Policy Enforcement
Access control logic (PINs, rate limits, operation quotas) runs in firmware inside the secure boundary. Attackers cannot bypass these policies even with kernel-level access. If an attacker attempts to force operations without proper authentication, the device responds, logging the incident, halting operations, or erasing keys.

Attestation and Non-Repudiation
Cryptographic operations can include proof of device identity and, when configured, firmware state. When an IoT device signs telemetry data, it can also attach a TPM-generated attestation quote proving “I am device XYZ with firmware version ABC.” The cloud system verifies both signature and if attestation is present, the reported firmware version. Later, if a breach is suspected, you can audit which devices signed which data, with cryptographic proof.

Operational Audit Trails
HSMs and TPMs log every operation: who accessed what, when, and what was the outcome. This audit trail is stored in tamper-proof storage, creating an undoubted record for compliance investigations.

8. Real-World Example: Building an End-to-End Device Trust Chain

To make these concepts concrete, consider a practical IoT deployment:

Manufacturing Phase
Each edge controller is produced with a TPM 2.0 chip. During factory provisioning, the device’s Endorsement Key (EK) is extracted. The manufacturing service submits a Certificate Signing Request (CSR) to an enterprise Certificate Authority (CA) hosted on an HSM in a secure data center. The HSM signs the CSR and issues a device certificate, binding the device’s EK to its serial number.

Field Deployment
The device is shipped with its certificate installed in TPM non-volatile memory. Upon first boot, the device writes the hash of its firmware into PCRs, then connects to AWS IoT Core using mutual TLS. The device presents its certificate (signed by the enterprise CA); the cloud verifies the signature using the CA’s private key. Both sides confirm they’re communicating with authenticated partners.

One of the key things in this process is that mutual TLS is performed using the public key known to AWS Cloud through the device certificate, while the corresponding private key remains protected inside the TPM storage.

Runtime Operations
Throughout operation, the device uses its TPM to encrypt and decrypt data transferred over a network MQTT connection (sensor data, system events, and status messages, etc.). During the initial TLS handshake, the cloud verifies the device’s certificate and signatures, confirming the connection originates from an authenticated device. After that, all MQTT traffic is protected by the established TLS session. If a device’s PCRs indicate firmware tampering, the boot process halts, preventing non-compliant software from running, therefore, no messages are ever sent to the cloud from that device.

Key Rotation and Renewal
When the device certificate nears expiration, the device generates a new key inside its TPM and submits a CSR to the enterprise CA. The HSM signs the new certificate. The device transitions to the new key without ever exposing the private key outside the TPM.

This creates an unbroken chain of cryptographic trust from manufacturing through field operations: every identity verification, every data signature, every access decision is rooted in hardware that cannot be tampered with or cloned.

9. Operational Considerations

9.1 Provisioning Workflows

TPMs must be initialized during manufacturing or first boot. Initialization involves:

• Setting the TPM owner authorization (SO PIN)
• Creating a Storage Root Key (SRK)
• Generating application keys
• Issuing and installing device certificates

This is typically automated via manufacturing services and on-device provisioning agents. Cloud workflows (e.g. AWS Lambda functions, custom provisioning scripts) coordinate the process, while the agent on the device interacts with the TPM through standard APIs/tools ( tpm2-tools, PKCS #11). The provisioning process must be secure: if a provisioning server is compromised, all subsequently provisioned devices inherit that compromise.

9.2 Performance Implications

TPMs are optimized for security, not raw throughput. A typical RSA-2048 signature takes 100–200 ms on a TPM, whereas a software-based operation completes in milliseconds. This is acceptable for device authentication (which happens infrequently) but prohibitive for bulk signing operations.

For IoT deployments, the typical pattern is:

• Use TPM to sign connection setup and authentication flows (infrequent)
• For high-volume operations (bulk data signing, encryption), use symmetric keys stored in TPM but operated via software accelerators

HSMs, by contrast, handle thousands of operations per second and are suitable for enterprise PKI, certificate authority operations, and high-throughput signing pipelines.

9.3 Backup and Disaster Recovery

TPM:
Keys cannot be cloned from a TPM. If a TPM fails, the keys are lost. This requires careful planning: ensure devices have redundant TPMs, use key hierarchies that allow key regeneration, or employ multi-device redundancy where keys are distributed across multiple devices.

HSM:
Cloud HSM services support encrypted key export and multi-node clustering. Keys can be securely shared across multiple HSM instances for high availability. On-premises HSMs typically support key replication via secure channels.

10. Clarifying Common Misconceptions

Several myths persist in the hardware security space. Let’s address them:

“Hardware security is overkill for most IoT deployments”
In reality, hardware security costs have fallen dramatically. TPMs are standard components; CloudHSM pricing is competitive with compliance risks. Any deployment with regulatory requirements (finance, healthcare, industrial control) benefits from hardware roots of trust.

“I must choose between TPM and HSM, they’re competing technologies”
False. TPM and HSM are complementary. TPMs secure individual devices; HSMs secure centralized services. Best practice is to deploy both.

“PKCS #11 is outdated and replaced by modern standards”
PKCS #11 is actively maintained by OASIS and continuously updated. Modern algorithms (ECC, EdDSA) are fully supported. The most commonly adopted v2.40 specification became approved by OASIS on 04/2015. The latest version is v3.1 approved on 07/2023It remains the industry standard for cryptographic device interfaces.

“Hardware-backed keys require significant code changes”
With PKCS #11, changes are minimal. You update configuration (module path, PIN) and add URIs to specify key locations. Existing code using OpenSSL or standard crypto libraries works unchanged. Many platforms, AWS FreeRTOS include native PKCS#11 support out of the box, allowing applications to use hardware protected keys with no additional integration effort.

11. Future Outlook and Emerging Trends

The hardware security landscape is rapidly evolving:

Remote Attestation Frameworks
Standards like RATS (Remote Attestation Procedures) are standardizing how devices prove their state to distant cloud systems. Expect tighter integration between TPM attestation, cloud policy engines, and automated device provisioning.

Confidential Computing
Hardware enclaves (AWS Nitro Enclaves, Intel SGX, ARM TrustZone) extend hardware protection to virtualized workloads. The boundary between TPM-protected devices and enclave-protected cloud applications is blurring, enabling end-to-end cryptographic pipelines.

Standardized Cryptographic URIs
JSON Web Signatures (JWS) and other standards are incorporating PKCS #11 URIs, making hardware-backed cryptography a first-class citizen in modern API design.

Decentralized Identity (DID) on Hardware
Blockchain and decentralized identity frameworks increasingly leverage TPMs and HSMs for key management, bringing verifiable identity to peer-to-peer networks.

12. Conclusion: Understanding the Foundation of Hardware Trust

The Challenge:

Traditional IoT deployments rely on software-stored private keys, creating fundamental vulnerabilities: keys can be copied without detection, certificates can be forged with sufficient effort, and firmware can be compromised long before discovery. As device fleets scale to thousands of endpoints, managing and auditing these software-based credentials becomes operationally impossible. Modern compliance frameworks demand hardware-rooted security, but fragmented vendor implementations and proprietary APIs have made adoption complex and expensive.

What We’ve Established:

In this first part of our series, we’ve laid the conceptual groundwork for understanding how hardware security transforms IoT deployments. We’ve explored three interconnected technologies that work together to create verifiable trust:

• TPM 2.0 provides immutable device identity through hardware-protected keys and measured boot, ensuring each device can cryptographically prove who it is and what firmware it’s running
• HSM centralizes enterprise-scale cryptographic operations in tamper-resistant appliances, handling certificate authorities, key management, and high-volume signing operations
• PKCS #11 serves as the universal interface that allows any application to interact with either technology using identical code, eliminating vendor lock-in

The Architecture of Trust:

Together, these technologies create a layered security model where:

• Every device possesses an immutable hardware identity that cannot be cloned
• Every cryptographic operation can be traced to a specific authenticated chip
• Every key operation can be logged and audited for compliance
• Every vendor’s hardware can be managed through a single standard interface

This isn’t just about adding security features, it’s about fundamentally changing where trust is anchored in your system, moving it from easily compromised software into tamper-resistant hardware.

What’s Next:

Understanding these concepts is essential, but implementing them requires bridging the gap between development and production environments. In Part 2, we’ll move from theory to practice, showing you how to set up both SoftHSM (for development) and TPM (for production) environments. You’ll learn how PKCS #11 abstraction enables you to write code once and deploy it seamlessly across both environments, and we’ll walk through the complete configuration process that prepares your systems for secure IoT deployments. The architectural principles we’ve established here will become concrete, working implementations.

By Mohammad Shirazi, Portfolio Manager, Klika Tech and Maxim Maltsev, Edge Computing Solution Architect, Klika Tech