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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: Software-derived roots of trust can extend cryptographic identity and key protection to legacy and TPM-less devices.
Why it matters: It matters because IAM and device trust programmes must govern more than modern hardware-backed endpoints, especially when brownfield devices are brought into security ecosystems through software identity patterns.
Context
A software root of trust is a device trust mechanism that derives cryptographic assurance from device-specific characteristics instead of depending on a TPM, TEE, or dedicated secure element. In this article, the governance issue is not whether the mechanism exists, but how identity and key protection work when trust is being created for devices that previously lacked hardware anchors.
For IAM and device security teams, the key question is whether software-derived trust can safely extend coverage to brownfield fleets without creating weakly governed machine identities. The article frames NanoROOT as a way to add device identity, key handling, and sealed storage to legacy deployments, which makes lifecycle control and provenance more important, not less.
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. That means inventorying the devices, assigning ownership for keys and sealed data, and defining revocation paths before the devices are allowed into production trust domains.
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. If ownership, rotation, and offboarding remain vague, software trust becomes a way to scale unmanaged machine identities instead of reducing exposure.
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. The practical test is whether the organisation can prove who owns the device, where its trust anchor lives, and how that identity is retired when the device leaves service.
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.
Technical breakdown
How a PUF-based software root of trust works
NanoROOT uses physically unclonable function, or PUF, techniques to derive a unique cryptographic context from immutable hardware traits. That context is device-specific rather than stored as a portable secret, which means the trust anchor is recreated from the device itself when needed. In practice, this lets software perform identity, signing, and encryption operations without a discrete TPM or secure element. The mechanism is attractive for legacy environments because it extends device trust to hardware that was not designed for modern attestation patterns. The downside is that the trust model now depends on how reliably the software can recreate and protect that context across device states.
Practical implication: Treat software-derived device trust as an identity control that still needs inventory, ownership, and offboarding discipline.
Device-specific keys and sealed data on TPM-less endpoints
The article says NanoROOT can generate, import, and use keys in a context tied to the originating device, and can seal and unseal data so that only that device can access it. That is a machine identity pattern, even when the hardware lacks dedicated security modules. The value is not simply encryption, but binding cryptographic operations to one physical device so copied credentials are less useful elsewhere. This matters for workload-adjacent devices, brownfield controllers, and embedded systems where secrets often end up shared or reused. If the cryptographic context is mishandled, the environment can still accumulate identities that behave like credentials without being governed like them.
Practical implication: Bind provisioning, rotation, and revocation to the device lifecycle, not to the application layer alone.
Why legacy device trust changes the governance boundary
When trust moves from hardware-backed modules to software-derived roots of trust, the governance boundary shifts from provisioning a secure device to continuously proving that the device-derived identity remains trustworthy. That widens the scope of identity governance because legacy devices can now participate in modern security ecosystems, but their trust chain may be harder to inspect and standardise. The article also points to support for RSA, ECDSA, and ML-DSA, which signals a forward-looking cryptographic posture rather than a narrow point solution. For practitioners, the issue is not just enabling old devices, but deciding which controls must follow them into the trust model.
Practical implication: Re-evaluate which legacy device classes are allowed to hold cryptographic identity at all.
NHI Mgmt Group analysis
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.
Origin-bound keys are only as safe as the lifecycle surrounding them: the article’s emphasis on keys tied to a device-derived context shows why cloned credentials matter less than cloned governance. If the device can create, store, and use cryptographic material without strong inventory and offboarding, the organisation has extended trust without extending control. The implication is that device trust programmes must classify software-derived identities explicitly.
Brownfield coverage is the real strategic value, and the real governance risk: the article is most relevant where modern identity controls have historically failed to reach embedded, industrial, or otherwise non-standard endpoints. That makes the named concept here an identity coverage gap, where devices are operationally important but governance-light. The practitioner conclusion is simple: coverage gains only matter if they come with enforceable ownership and revocation.
Quantum-safe readiness belongs in device trust planning, not as a separate roadmap item: support for RSA, ECDSA, and ML-DSA shows that cryptographic agility is becoming part of device identity design. That does not solve trust by itself, but it does mean legacy device onboarding now intersects with algorithm transition planning. Identity teams should stop treating device trust and cryptographic migration as unrelated projects.
Software roots of trust do not eliminate the need for assurance boundaries: a software-derived trust anchor can extend protection to devices without dedicated secure elements, but it also moves assurance into a layer that is easier to overlook during architecture reviews. The governance implication is that device identity cannot be assumed just because a device can sign or seal data. Practitioners should insist on explicit identity ownership and recovery paths.
From our research library:
- 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.
- Read next: Zero Trust Identity Guide
What this signals
Identity coverage gap: software roots of trust are most useful when they close a practical coverage problem, but they also create a new governance boundary around devices that were previously outside strong identity controls. That boundary has to be explicit, or the organisation simply relocates trust risk from hardware to software.
Brownfield device trust should now be evaluated with the same seriousness as workload identity and service-account governance, because the key question is not whether the device can cryptographically act, but whether its lifecycle is owned, revocable, and auditable.
For practitioners
- 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.
- Plan cryptographic agility alongside onboarding Map legacy device onboarding to algorithm transition planning so that RSA, ECDSA, and ML-DSA support is governed as part of the broader trust model.
Key takeaways
- 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.
- The operational risk is unmanaged machine identity growth, especially when device-bound keys and sealed data are introduced without clear ownership and revocation paths.
- Practitioners should treat brownfield device trust as part of the broader identity lifecycle, including inventory, cryptographic agility, and end-of-life control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Device-bound identities need lifecycle control so trust does not turn into unmanaged privilege. |
| NHI-07 — Long-Lived Secrets | Software-derived keys still need rotation and retirement discipline if they persist across device use. | |
| Recommendation — Apply NHI-05 to constrain device credentials to the minimum scope needed for each device class. Inventory device secrets and shorten their lifetime wherever the trust model allows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Keys used as device authenticators require lifecycle management and revocation controls. |
| Recommendation — Use IA-5 to govern issuance, storage, rotation, and invalidation of device authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Device-derived identities still need bounded permissions and explicit authorisation. |
| Recommendation — Align device identity permissions to PR.AA-05 so each device has only the access it needs. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Compromising device-bound identity material would enable credential access against the trust layer. |
| Recommendation — Map device trust exposure to TA0006 and monitor for attempts to extract or reuse device credentials. | ||
Key terms
- Hardware Root Of Trust: A hardware root of trust is a device-level trust anchor, often backed by a TPM or similar mechanism, that proves a system is what it claims to be. It helps infrastructure enroll without relying on static bootstrap secrets and gives identity systems a more durable basis for issuance and attestation.
- 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-bound Credential: A device-bound credential is a key or token that can only be used from an approved device or authenticator. In practice, it reduces replay and theft risk, but it also raises the stakes of enrollment, attestation, and revocation because the credential can act repeatedly until invalidated.
- Sealed Data: Sealed data is information encrypted or protected so that only a specific device or trust context can later unseal it. The control is useful for limiting portability, but it shifts the governance challenge to proving that the bound device remains legitimate and can be retired cleanly.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org