PUF vs. HSM? Why It's Not Either/Or for IoT Compliance

By ICTK
October 6, 2026

Regulators won't tell you which chip to use. They will ask you to prove your devices can protect their keys.

IoT security used to be a best practice. In more and more markets, it's now a legal requirement. The UK has enforced baseline security rules for consumer connectable products since April 2024. The EU Cyber Resilience Act (CRA) started requiring manufacturers to report actively exploited vulnerabilities in September 2026, and its full requirements take effect in December 2027. Both point to the same question for hardware teams: where do the device's secrets live, and how do you protect them?

That question often gets framed as "PUF vs. HSM," as if physically unclonable functions (PUFs) and hardware security modules (HSMs) were two competing options. They aren't. A PUF is a technology for creating and protecting keys. An HSM is a type of device built to manage keys. A PUF can sit inside an IoT chip, and it can sit inside an HSM. Here are eight questions that clear up the confusion and connect it to what regulators actually ask for.

Q1. What's the difference between a PUF and an HSM?

A PUF and an HSM aren't the same kind of thing, so they don't compete. A PUF is a circuit-level technology that derives a unique secret from tiny, random manufacturing variations in a chip, so the key doesn't have to be stored. An HSM is a dedicated, tamper-resistant device (an appliance, a PCIe card, or a cloud service) built to generate, store, and use cryptographic keys at scale.

Think of it this way: a PUF is a way of making a lock that can't be copied, and an HSM is a vault. You can put that kind of lock on a single front door, which is the IoT device. You can also build it into the vault itself.

  PUF HSM
What it is A technology (a security primitive built into silicon) A product category (a dedicated key management device)
What it does Derives a device-unique secret on demand instead of storing it Generates, protects, and uses keys for many systems and devices
Where you find it IoT SoCs and MCUs, secure elements, and HSMs themselves Data centers, factories, cloud services, sometimes gateways
Typical assurance Evaluated as part of the chip or module that contains it Commonly validated under FIPS 140-3 as a cryptographic module

Q2. Can an HSM use a PUF?

Yes. An HSM has to protect its own most critical secrets, such as the master key that wraps every other key it holds. A PUF is one way to do that: instead of keeping the master key in memory, the HSM regenerates it from the physical characteristics of its own silicon when needed.

Conventional HSM designs typically keep keys in protected memory inside a tamper-resistant boundary and erase them if tampering is detected. A PUF-based design approaches the same goal differently, by not keeping the root secret at rest in the first place. Both are legitimate engineering choices. What matters for compliance is how well the design is implemented and independently evaluated.

Q3. What do IoT security regulations actually require from hardware?

None of the major frameworks requires a PUF, and none requires an HSM. They're written in terms of outcomes: devices need a protected identity, stored secrets need to stay confidential and tamper-proof, and updates need to be trustworthy. Hardware is how you meet those outcomes reliably.

Here's how three of the most cited frameworks frame it:

  • EU Cyber Resilience Act (Annex I): Products must protect against unauthorized access through appropriate controls such as authentication and identity management. They must also protect the confidentiality and integrity of stored and transmitted data using state-of-the-art mechanisms such as encryption.
  • ETSI EN 303 645: This European consumer IoT standard says sensitive security parameters in persistent storage shall be stored securely (provision 5.4-1). Where a device uses a hard-coded unique identity for security purposes, that identity has to resist tampering by physical, electrical, or software means (provision 5.4-2).
  • NIST IR 8259A: NIST's core baseline for IoT devices lists device identification and data protection among the capabilities a device should support. That means a device should be uniquely identifiable and should protect the data it stores and transmits.

Because these rules are technology-neutral, the right question isn't "PUF or HSM?" It's "where do our keys live, and can we show, with evidence, that each of those places is protected?"

Q4. When do the EU Cyber Resilience Act requirements take effect?

The CRA entered into force on December 10, 2024. Vulnerability and incident reporting obligations have applied since September 11, 2026, and the regulation's main obligations, including the essential cybersecurity requirements and CE marking, apply from December 11, 2027.

The reporting obligations also cover products already on the EU market, not just new ones. For hardware teams, the 2027 date is closer than it looks. A chip or module going into a product that ships in late 2027 is often being selected or designed today, so root-of-trust decisions made now will be judged against the CRA's requirements later.

Outside the EU, the UK's Product Security and Telecommunications Infrastructure (PSTI) regime has been in force since April 29, 2024. Its baseline requirements, which draw on ETSI EN 303 645, include a ban on universal default passwords and a requirement to publish how long a product will receive security support.

Q5. Where does a hardware root of trust need to live in an IoT system?

In at least two places: on every device, and in the back-end infrastructure that vouches for those devices. A root of trust isn't a product. It's the point where a chain of trust begins, and a connected product depends on more than one chain.

A typical device lifecycle shows both:

  1. Manufacturing: The device gets a unique key pair, ideally generated inside its own chip so the private key never leaves it.
  2. Enrollment: A certificate authority (CA), whose signing keys are protected in an HSM, issues a certificate binding that public key to the device's identity.
  3. Field operation: The device proves its identity with its private key, and the service checks the certificate chain back to the protected CA root.
  4. Updates: Firmware is signed with a key held in an HSM, and the device verifies that signature before running new code.

The device side covers identity and local data protection. The infrastructure side covers certificates and updates. The CRA expects both to hold up.

Q6. What does a PUF bring to IoT devices?

On the device side, a PUF gives each unit a unique, hard-to-extract identity without storing the key in memory. Because the key is regenerated from the chip's physical characteristics, there's no stored key for an attacker to read out of a captured device.

That's especially useful when:

  • Devices are physically exposed. Sensors, meters, trackers, and industrial controllers often sit in places where an attacker can get hands-on access.
  • Volume and unit cost are high priorities. A PUF-based root of trust can be integrated into the device's own silicon instead of adding a separate component.
  • Key injection is a supply chain concern. If the device creates its own unique secret, you don't need to inject a pre-generated private key during manufacturing, which removes one place where keys could be exposed.

PUFs aren't all the same, though. Stability across temperature and aging, resistance to modeling attacks, and the quality of independent evaluation vary between designs, so these deserve close attention during selection.

Q7. What does an HSM bring to the infrastructure side?

An HSM protects the small number of high-value keys that an entire fleet depends on, and it provides the access control, audit logging, and key lifecycle management those keys need. Those are capabilities a single endpoint chip isn't designed to provide.

Common roles include:

  • CA root and issuing keys that sign every device's certificate
  • Firmware and code-signing keys. Under the CRA's security update requirements, a compromised signing key could let an attacker push malicious "updates" to an entire fleet.
  • Back-end services that perform large volumes of encryption, decryption, or signing for cloud platforms and payment systems
  • Gateways and edge servers that need certified key protection close to the devices they manage

How the HSM protects its own root secret is a separate design decision, and that's where a PUF can come in again (see Q2). So the same technology can anchor trust on the device and inside the HSM that vouches for it.

Q8. How should we evaluate a hardware root of trust for compliance?

Start with evidence, not product categories. Map where every critical key lives across its full lifecycle, then confirm that each location has independent certification and a documented process behind it.

A practical checklist:

  • Key lifecycle: Where is each key generated, stored, used, rotated, and retired? Is any private key ever exposed in plaintext, including during manufacturing?
  • Root secret protection: Inside each component, device chip and HSM alike, is the root secret stored in protected memory or derived on demand, for example from a PUF? How was that mechanism evaluated?
  • Certification evidence: Can the supplier show relevant certifications, such as FIPS 140-3 validation for cryptographic modules or Common Criteria evaluation for secure hardware? Auditors will ask for certificates, not datasheets.
  • Update integrity: Are firmware-signing keys protected, and does the device verify signatures from a root anchored in hardware? NIST SP 800-193 is a useful reference for firmware protection, detection, and recovery.
  • Vulnerability handling and crypto agility: Can your suppliers support coordinated disclosure and timely fixes under the CRA's reporting obligations? And since NIST finalized its first post-quantum cryptography standards in 2024, do long-lived devices and HSMs have a credible path to support them?

The bottom line

"PUF vs. HSM" is a framing that doesn't hold up. A PUF is a way to create and protect keys without storing them. An HSM is a device for managing keys at scale. The first can live inside the second, and it can also live in every IoT chip in the field. Regulations like the CRA, ETSI EN 303 645, and NIST's IoT baseline don't prescribe either one. They ask manufacturers to protect device identities, stored secrets, and update channels, and to prove it. The better question is where each key lives and how that place is protected, from the device to the HSM.

Explore ICTK IP:

References

Explore further

ICTK applies its PUF technology on both sides of the chain of trust, from security IP for device silicon to PUF-based hardware security modules for infrastructure keys.

☑️ Explore the VIA PUF™ Security IP

☑️ Explore ICTK Security Modules

☑️ Talk to our team about your compliance roadmap

ICTK IP Selector PQC IP Selector

Related Semiconductor IP

Related Blogs

Latest Blogs

×
Semiconductor IP