Notifications
Clear all
Topic starter
25/06/2026 10:42 pm
TL;DR: NanoROOT uses physically unclonable function techniques to derive a device-specific cryptographic context from immutable hardware traits, letting developers create tamper-resistant identities, seal data, and manage keys on devices that lack TPMs or secure elements, according to DigiCert. The governance question is whether software-derived trust can extend device identity without creating a new class of unmanaged machine identities.
NHIMG editorial — based on content published by DigiCert: Meet NanoROOT, a software root of trust for all devices
Questions worth separating out
Q: How should teams govern device identities created by software roots of trust?
A: Teams should govern them like any other machine identity: assign ownership, record lifecycle state, track key material, and define revocation paths.
Q: Why do TPM-less devices create governance risk for identity teams?
A: TPM-less devices are risky because they often sit outside mature trust and lifecycle controls, yet still need authentication, signing, and protected storage.
Q: What breaks if device-derived keys are not tied to lifecycle controls?
A: The main failure is unmanaged persistence.
Practitioner guidance
- Map device trust to an ownership model Assign a business or platform owner to every device identity created with a software root of trust.
- Define lifecycle controls before rollout Set requirements for enrollment, key recovery, reimaging, and decommissioning before enabling device-derived keys in production.
- Test cryptographic agility in brownfield estates Validate that device identity workflows can support algorithm transitions without breaking signing, verification, or sealed data access.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- How NanoROOT uses PUF-based techniques to derive a device-specific cryptographic context
- Which TrustCore SDK APIs support key generation, sealing, unsealing, signing, and verification
- How developers can test and integrate the SDK in brownfield and legacy device environments
- What the article says about RSA, ECDSA, and ML-DSA support for future cryptographic transitions
👉 Read DigiCert's blog post on NanoROOT and software device roots of trust →
NanoROOT and software roots of trust: what changes for device trust?
Explore further
25/06/2026 11:21 pm
Software root of trust turns device integrity into an identity governance problem: Once a device can generate, protect, and use its own cryptographic context, the issue is no longer just platform hardening. The governance challenge becomes who owns that identity, how it is enrolled, and when it is retired. That puts device trust squarely into the same control family as machine identity and lifecycle management. Practitioners should stop treating trust anchors as static technical primitives and start treating them as governed identities.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which is why device identity coverage needs inventory and ownership from day one.
A question worth separating out:
Q: How do software roots of trust affect legacy device modernisation?
A: They let organisations extend cryptographic trust to older fleets without immediate hardware replacement, but they also raise the bar for governance. Teams should modernise inventory, key handling, and retirement processes at the same time, otherwise the new trust layer simply expands the number of managed identities.
👉 Read our full editorial: NanoROOT extends device root of trust to legacy and TPM-less devices
