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.
What governing device trust really means on legacy and TPM-less devices
Legacy and TPM-less devices can still participate in trust decisions, but the trust anchor is weaker and more operationally fragile. Governance has to treat them as software-derived device identities with a lifecycle, not as permanently trustworthy endpoints. That changes the problem from “can the device prove itself once?” to “who owns its identity material, how is it rotated, and how is trust withdrawn when posture changes?”
On older hardware, the practical control surface is usually certificate-based identity, secure enrollment, and revocation discipline. Teams need to decide whether the device can be attested, whether that attestation is enough for the intended trust domain, and whether the trust policy should be narrower than for hardware-backed devices. Without that discipline, legacy endpoints tend to accumulate exceptions that quietly become production access paths.
device trust also has to align with the business role of the endpoint. A kiosk, lab instrument, contractor laptop, and embedded device may all be TPM-less, but they do not deserve the same trust radius. If the device cannot support strong hardware roots, the governance model should compensate with tighter segmentation, shorter credential lifetimes, and more explicit ownership of recovery and retirement decisions.
How to structure governance for software-derived device trust
The strongest model is to govern device trust the same way you would govern any other machine identity lifecycle. Start by inventorying every device that relies on software-derived trust, then assign a clear owner for provisioning, renewal, rotation, and decommissioning. That owner should be accountable for both the device object and any sealed data or credentials tied to it.
Inventory needs to distinguish between what the device is, what it can prove, and what it is allowed to reach. A legacy endpoint may still be acceptable if the trust policy is explicit about its limitations. For example, you may allow access to a constrained internal segment but deny access to privileged admin workflows, regulated data stores, or environments that require hardware-backed attestation.
Governance should also define the revocation path before rollout. If a device is lost, reimaged, compromised, or simply falls out of compliance, the team should know which certificate to revoke, which trust store to update, and which downstream systems depend on that trust signal. That is where clear device ownership becomes operationally important, because revocation without ownership often fails in practice.
Where legacy trust breaks down in practice
Legacy trust fails when teams confuse authentication with ongoing trust. A successful enrollment does not mean the device remains trustworthy tomorrow. Software-only trust can be copied, exported, or replayed more easily than hardware-backed trust, so policy has to assume that credential compromise is a realistic failure mode and plan for containment accordingly.
Another common weakness is overbroad acceptance criteria. When a device cannot offer TPM-backed attestation, organisations sometimes compensate by widening network access or extending certificate lifetimes. That creates a larger blast radius than the original hardware limitation. A safer pattern is to reduce the device’s authority and pair trust with continuous checks on posture, freshness, and reachability.
This is also where Device and IoT Identity Guide is useful, because it frames device trust as an identity and lifecycle problem, not just a certificate issue. For broader zero trust policy design, Zero Trust Identity Guide helps teams connect device trust decisions to policy enforcement and continuous verification.
Risk and Threat Considerations
Legacy and TPM-less devices introduce trust concentration risk because a weak or exported device identity can become a reusable access path. If the organisation treats that identity as equivalent to hardware-backed trust, an attacker who obtains the software credential can often reuse it until revocation happens.
Failure mechanism: Software-derived identity material can be copied, cloned, or left active after the device is retired, allowing unauthorized reuse of the trust relationship.
Impact: Compromise can lead to persistent access, difficult-to-detect device impersonation, and overexpansion of trust into systems that assumed stronger endpoint assurance.
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 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Device trust exceptions require explicit risk treatment and ownership decisions. |
| PR.AA-05 — Identity Management, Authentication and Access Management | Device trust governs how endpoints are identified, authenticated, and allowed access. | |
| Recommendation — Define risk acceptance for legacy device trust and tie exceptions to review and revocation triggers. Enforce device identity controls before granting access to trust domains. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Software-derived device trust depends on disciplined credential and certificate lifecycle handling. |
| IA-9 — Service Identification and Authentication | Legacy devices often authenticate as non-human endpoints using machine credentials or certificates. | |
| AC-2 — Account Management | Device trust needs ownership, inventory, and deprovisioning of device identities. | |
| Recommendation — Rotate, protect, and revoke device authenticators on a defined lifecycle. Use endpoint-specific authentication controls for devices and other non-human actors. Maintain authoritative inventory and remove device access when trust is withdrawn. | ||
| NIST Zero Trust (SP 800-207) | Section 2 — Zero Trust principles | Device trust on legacy endpoints is a zero trust policy problem requiring continuous verification. |
| Recommendation — Apply least-privilege policy and continuous verification to legacy devices. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Legacy device trust fails when retired devices or their credentials remain usable. |
| NHI-07 — Long-Lived Secrets | TPM-less trust often depends on secrets that last too long and are hard to manage safely. | |
| Recommendation — Revoke and retire device identities when devices leave service. Shorten secret lifetimes and replace long-lived device credentials where possible. | ||
Practitioner Guidance
What to prioritise: Classify every TPM-less device by the trust domain it is allowed into, then set different policy for low-risk access, operational access, and privileged access. Do not let one exception model cover all legacy endpoints.
What to verify: Confirm that each device has a named owner, an inventory record, an issuance path, and a revocation path. If you cannot identify who rotates or withdraws its credentials, the trust model is already too weak for production use.
Common mistake: Teams often accept longer-lived certificates or broader network reach as compensation for weak hardware roots. That usually increases risk more than it improves usability, because it extends the lifetime and blast radius of the trust relationship.
Practitioner takeaway: Legacy device trust should be treated as a bounded exception with lifecycle controls, not as a permanent substitute for hardware-backed assurance.