NanoROOT extends device root of trust to legacy and TPM-less devices

At a glance

What this is: NanoROOT is a software root of trust that derives device-specific cryptographic identity from immutable hardware traits, including on TPM-less devices.

Why it matters: It matters because device trust is now part of the same identity governance problem as machine identity, workload access, and lifecycle control across brownfield environments.

👉 Read DigiCert's blog post on NanoROOT and software device roots of trust

Context

A software root of trust gives a device a cryptographic identity anchored in hardware-derived traits rather than a dedicated secure element. That matters for device trust because many embedded and legacy estates still need signing, encryption, verification, and sealed storage without the benefit of TPMs or TEEs.

For IAM, NHI, and device governance teams, the real question is not whether trust can be created in software, but whether that trust remains governable across the device lifecycle. Once a device-derived identity can sign, store, and verify sensitive operations, it starts behaving like a managed machine identity and needs the same visibility, ownership, and offboarding discipline.

For teams modernising brownfield fleets, NanoROOT is a reminder that identity control is increasingly being pushed down into device runtime environments. The governance burden shifts from hardware dependency to assurance, key handling, and lifecycle clarity.

Key questions

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. The fact that the trust anchor is software-derived does not remove the need for inventory, recovery, and retirement controls. If anything, it makes governance more important because the identity can proliferate into legacy estates.

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. When software roots of trust fill that gap, teams must know who owns the device, how credentials are protected, and what happens when the device is retired or compromised.

Q: What breaks if device-derived keys are not tied to lifecycle controls?

A: The main failure is unmanaged persistence. A device can remain trusted after ownership changes, reimaging, or decommissioning if the organisation lacks revocation and inventory discipline. That creates a durable machine identity with no clear offboarding path, which is a familiar non-human identity problem in a new form.

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.

Technical breakdown

Software root of trust on hardware-derived identity

NanoROOT uses physically unclonable function techniques to derive a unique cryptographic context from a device's immutable hardware traits. In practice, that creates an identity anchor without requiring a traditional secure element. The security value comes from binding keys and cryptographic operations to a specific device context, so copied credentials are less useful outside the original hardware. This is not the same as making the device inherently trustworthy. It creates an identity substrate that must still be governed, provisioned, and monitored like any other machine identity.

Practical implication: treat software-derived device identity as a governed machine identity, not as a one-time technical feature.

Device-specific keys, sealing, and signature operations

The SDK exposes APIs for generating, importing, using, sealing, and unsealing keys in a context tied to the originating device. That means secrets can be protected so they are not portable, while signatures and verification can prove an operation came from the expected hardware context. The main architectural shift is that trust moves from a dedicated chip to a cryptographic binding between device traits and key material. This reduces reliance on hardware availability, but it also concentrates assurance on implementation quality, enrollment controls, and recovery procedures.

Practical implication: define enrollment, recovery, and key-binding controls before using device-tied credentials in production.

Legacy device identity in mixed estate environments

The strongest use case is brownfield or legacy fleets that need to participate in modern security ecosystems without hardware refresh. In those environments, software RoT can extend secure identity to devices that otherwise would remain unmanaged or lightly trusted. That said, extending trust into older environments increases the need for inventory accuracy, ownership mapping, and revocation paths when a device is retired or compromised. Without those controls, the new trust layer simply enlarges the population of identities that must be governed.

Practical implication: pair device trust rollout with inventory, ownership, and retirement controls so legacy coverage does not become unmanaged sprawl.

NHI Mgmt Group analysis

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.

Legacy coverage is the real strategic value, not abstraction for its own sake: The importance of NanoROOT is that it extends trust to fleets that cannot practically be rebuilt with TPMs or dedicated secure elements. That makes it relevant to brownfield infrastructure, embedded systems, and distributed device estates where hardware refresh is slow or uneconomic. The field implication is that identity teams now need coverage models for devices that were previously outside the trust perimeter. Practitioners should map where software RoT is a bridge and where it simply postpones a hardware decision.

Key management remains the control plane, even when trust is device-derived: The article describes key generation, import, signing, encryption, and sealing within a device-tied context. Those capabilities only help if the surrounding governance answers who can provision them, how they are recovered, and what happens when a device is lost, reimaged, or decommissioned. This is a classic NHI lesson applied to devices: the cryptography may be stronger than the process around it. Practitioners should evaluate device trust through lifecycle controls, not through cryptographic novelty alone.

Quantum-safe readiness is becoming part of device identity planning: Support for RSA, ECDSA, and ML-DSA signals that device trust is being designed with algorithm transition in mind. That matters because device identity systems are long-lived, and cryptographic agility is now a planning requirement rather than a future enhancement. The practical conclusion is that device trust architectures should be assessed for algorithm transition, not just for current attestation strength. Practitioners should fold crypto agility into device identity roadmaps now.

Device identity without visibility will reproduce the same control gaps seen in other machine populations: If software roots of trust expand coverage without corresponding inventory, ownership, and offboarding, they create a larger class of trusted devices that security teams cannot fully account for. That is the same governance failure pattern seen repeatedly in non-human identity programmes. The concept here is identity coverage without lifecycle control. Practitioners should measure whether every trusted device has a named owner and a revocation path.

From our research:

• 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.
• Software-derived trust should be planned with the same lifecycle discipline as other machine identity programmes, as laid out in Ultimate Guide to NHIs , What are Non-Human Identities.

What this signals

Identity coverage is the immediate issue. Once device trust extends into TPM-less and legacy estates, programme teams need to know which devices now hold cryptographic authority, who owns them, and how they are retired. Without that mapping, software roots of trust will increase the number of identities to govern faster than they improve assurance.

Device trust is converging with the broader machine identity agenda. The same governance questions that apply to service accounts now apply to devices that can sign, encrypt, and unseal data on their own. That means lifecycle, inventory, and revocation controls need to be designed as one programme rather than as separate operational tracks.

Teams that already struggle with non-human identity sprawl should expect the device layer to surface the same failure modes unless ownership and review processes are embedded early. The operational signal to watch is whether every trusted device can be traced to a named owner, a revocation path, and an approved lifecycle state.

For practitioners

• Map device trust to an ownership model Assign a business or platform owner to every device identity created with a software root of trust. Make ownership part of enrollment so the trust anchor is never orphaned when the device changes hands or moves between environments.
• Define lifecycle controls before rollout Set requirements for enrollment, key recovery, reimaging, and decommissioning before enabling device-derived keys in production. A device trust layer without retirement controls will outlive the business need and complicate revocation.
• Test cryptographic agility in brownfield estates Validate that device identity workflows can support algorithm transitions without breaking signing, verification, or sealed data access. Brownfield deployments need an explicit migration path for RSA, ECDSA, and ML-DSA usage.
• Integrate device identity into inventory and access reviews Include software-derived device identities in asset inventory, periodic access review, and exception tracking. If a device can generate trusted operations, it belongs in the same governance cycle as other managed machine identities.

Key takeaways

• NanoROOT extends trust to devices without dedicated secure elements, but governance still has to follow the identity, not just the hardware.
• The main risk is unmanaged persistence: once device-derived keys exist, inventory, ownership, and revocation become mandatory controls.
• Device trust should be modernised as part of machine identity lifecycle management, not as a standalone cryptographic upgrade.

Key terms

• Software Root Of Trust: A software root of trust is a cryptographic starting point that lets a device prove identity and protect secrets without relying on a dedicated hardware secure element. It usually binds keys or operations to device-specific properties, but it still needs lifecycle, ownership, and revocation controls to remain trustworthy.
• Physically Unclonable Function: A physically unclonable function is a hardware-derived property that can be used to create a unique cryptographic context for a device. It is valued because it is difficult to copy exactly, but it is only useful when the surrounding identity and key-management processes are carefully governed.
• Device-Derived Identity: Device-derived identity is a machine identity established from the device's own hardware traits rather than from a separate module or certificate alone. It can support signing, encryption, and protected storage, but it should be treated as a managed identity with clear ownership and offboarding.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by DigiCert: Meet NanoROOT, a software root of trust for all devices. Read the original.