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.
Editorial analysis by NHI Mgmt Group, based on content published by DigiCert: “Meet NanoROOT: A Software Root of Trust for All Devices”.
Key questions
Q: How should teams govern device trust on legacy and TPM-less devices?
A: Teams should govern software-derived device trust as a machine identity lifecycle problem, not just a cryptography feature.
Q: Why does software root of trust create new governance risk for brownfield devices?
A: It creates risk because the organisation may extend identity and key protection to devices that were never designed for strong lifecycle control.
Q: What should security teams do when device keys are bound to a software-derived context?
A: They should treat the keys as device-bound credentials and apply explicit lifecycle controls to them.
Practitioner guidance
- Inventory devices that will rely on software-derived trust Classify legacy and TPM-less devices that would use a software root of trust, and record where device-specific identities, keys, and sealed data will live across the fleet.
- Define lifecycle ownership for device-bound credentials Assign clear owners for generation, rotation, revocation, and retirement of keys that are tied to device-derived cryptographic contexts, especially in brownfield environments.
- Separate eligible and ineligible device classes Document which device categories can safely participate in modern trust ecosystems through software-derived identity, and which should remain excluded until stronger controls exist.
Bottom line: Software-derived roots of trust can extend device identity to legacy and TPM-less hardware, but that extension is a governance decision as much as a technical one.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 11:21 pm
Software-derived device trust expands the NHI problem space rather than shrinking it: once a legacy device can generate a device-bound identity, it becomes part of the machine identity estate whether or not it has a TPM. That means the governance burden shifts from hardware presence to identity lifecycle, ownership, and revocation. Practitioners should treat these devices as governed NHIs, not as exceptions to the model.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: Should organisations allow legacy devices into modern security ecosystems through software trust?
A: Only when the device class is clearly defined, the identity model is documented, and revocation is enforceable. Software trust can widen coverage, but it should not be used to hide gaps in asset ownership, cryptographic governance, or end-of-life control.
👉 Read our full editorial: NanoROOT extends device root of trust to legacy and TPM-less devices