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.
Why This Matters for Security Teams
Device identities created by software roots of trust are not “special” identities that can be managed informally because they originate in code. They still authenticate systems, establish trust chains, and unlock sensitive operations, which means they need the same discipline as any other machine identity. NIST Cybersecurity Framework 2.0 emphasises governance, inventory, and protection of digital assets, and that applies directly here because the trust anchor may be software-derived but the risk is operational and persistent.
The common mistake is assuming software-based roots of trust reduce the need for lifecycle controls. In reality, they often increase exposure because they can be cloned into virtualised, embedded, and legacy estates faster than teams can track them. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, a useful signal for how weak identity inventory usually is when machine identities multiply. That visibility gap becomes more serious when device credentials are embedded in software distribution, recovery workflows, or imaging pipelines. In practice, many security teams discover these identities only after a failed audit, a compromised build path, or a legacy system is already relying on them.
How It Works in Practice
Governance should start by treating each software-rooted device identity as a managed asset with an owner, a purpose, a lifecycle state, and a revocation path. That means recording where the identity was issued, which software component anchors it, what key material or certificate chain supports it, and what conditions trigger renewal or retirement. The NHIMG lifecycle guidance is clear that inventory without ownership is not governance, because unmanaged identities tend to persist long after the system they were meant to secure has changed.
In practice, teams should build controls around four operating steps:
- Assign a named business and technical owner at issuance, not after deployment.
- Track the identity’s state across creation, activation, rotation, suspension, and retirement.
- Use short-lived keys or certificates where possible, with defined renewal and revocation paths.
- Log every trust-anchor change so recovery and audit teams can reconstruct provenance.
This should be paired with standard machine-identity controls such as secrets management, key rotation, and least privilege. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces asset visibility and protective governance rather than assuming the trust anchor itself is sufficient. For teams building policy, the practical question is not whether the root of trust is software or hardware, but whether the identity can be traced, revoked, and recovered with confidence. NHIMG’s research also shows why this matters: regulatory and audit perspectives increasingly expect evidence of lifecycle control, not just cryptographic existence. These controls tend to break down when software roots of trust are embedded in old device fleets that cannot support centralized revocation or reliable telemetry.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, requiring organisations to balance stronger control against deployment speed and recovery complexity. That tradeoff is most visible when software roots of trust are used in legacy estates, air-gapped environments, or devices that cannot maintain continuous connectivity to a central authority. Best practice is evolving here, and there is no universal standard for every implementation pattern yet.
One edge case is recovery after re-imaging or rollback. If the identity is tied to software state, a rollback can unintentionally resurrect an old trust anchor unless retirement and re-issuance are explicit parts of the process. Another edge case is shared platform images, where an identity placed too early in the build chain can proliferate across many devices before ownership is assigned. Teams should also be careful not to confuse attestation with governance: proof that a device booted from trusted software does not answer who owns the identity, how long it is valid, or how it is revoked.
NHIMG’s Top 10 NHI Issues is a useful reminder that excessive privilege and weak visibility remain common failure modes across machine identities. The governance model should therefore include periodic review of issuance scope, renewal intervals, and offboarding logic, especially where software-derived identity can outlive the device fleet it was created to protect.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers inventory and ownership for machine identities, central to software-rooted device identities. |
| NIST CSF 2.0 | GV.AM-01 | Asset management applies directly to identities created by software roots of trust. |
| NIST AI RMF | Risk governance applies when software-derived trust anchors spread across dynamic environments. |
Establish accountable lifecycle governance and review identity risk continuously as systems change.
