They should treat token lifetime as a control variable, not a convenience setting. If a token can still issue device commands long after the user interaction that created it, the access path outlives its intended purpose. Short expiry, revocation, and device-scoped permissions reduce the window in which stolen or reused session material can be abused.
Why long-lived tokens become a control problem in connected-device estates
In connected-device environments, the issue is not just whether a token works, it is how long it remains usable relative to the device’s trust context. A token that outlives the user action, maintenance window, or onboarding event that created it becomes a standing access path. That turns bearer material into an operational dependency, not a temporary authorisation artifact.
When devices stay online for months or years, the main exposure is replay and reuse. A token copied from firmware, logs, support tooling, or a compromised endpoint can keep authenticating long after the original need has ended. That is why token lifetime has to be treated as part of device risk management, especially where command-and-control or API access can trigger physical or business impact.
Connected-device access also tends to be more distributed than traditional human access. Tokens may be embedded in apps, gateways, installers, edge appliances, or provisioning workflows, which makes expiry and revocation harder to observe. NHI lifecycle governance matters here because the same control weakness, credentials that remain valid beyond their intended use, affects service-style and device-style access patterns alike.
Which token controls matter most for connected devices
The first control objective is to narrow the token’s blast radius. That means short expiry, audience restriction, and permissions that apply only to the specific device, tenant, or function the token was issued for. API key lifecycle management is useful here because the same discipline applies whether the token is called an API key, access token, or device credential.
The second control objective is revocation that actually works in practice. If a token can only expire, but not be invalidated when the device is decommissioned, stolen, or reassigned, then expiry alone is too weak. Token and session security becomes most relevant when teams need to decide whether a token should be bearer-only, sender-constrained, or tied to a specific device trust factor.
The third control objective is stronger initial authentication and better scoping at issuance. Devices and connected systems should not receive broad tokens just because that is operationally easier. NHI authentication patterns such as client credentials, mTLS, workload identity federation, and constrained tokens help reduce the value of any one stolen token.
How teams should operationalise expiry, rotation, and revocation
Security teams should start by classifying each token by what it can do, how long it should exist, and whether its use should survive device replacement or redeployment. Tokens tied to provisioning, diagnostics, or maintenance should usually be shorter-lived than tokens used for ordinary telemetry, and production command tokens should be the hardest to obtain and the easiest to revoke.
Rotation challenges for non-human identities are especially relevant when devices are numerous or intermittently connected. In those environments, rotation policy must account for offline windows, cached credentials, and the time it takes for fleets to pick up new material. If revocation depends on perfect connectivity, the control is weaker than it appears.
Teams should also design for the failure case where a token is exposed outside the device boundary. OAuth token theft incidents show why token lifetime and scope matter together: a token that is stolen, replayed, and valid for too long becomes an easy persistence mechanism. Token exposure and delayed rotation can also let an attacker return after the first compromise has been detected.
Risk and Threat Considerations
Long-lived device tokens create a durable attack path when theft, leakage, or reuse occurs. In connected-device estates, that risk is amplified by poor visibility, delayed patch cycles, shared tooling, and the tendency to embed credentials in operational workflows that are hard to inventory.
Failure mechanism: A token remains valid after the original device state, user session, or provisioning event has changed, so stolen material can keep issuing commands or accessing services until expiry or manual intervention.
Impact: Attackers can persist in the environment, replay commands, expand access across devices, or retain control over systems that should already have been retired or re-scoped.
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 OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | Long-lived device tokens create the same stale-access exposure as long-lived secrets. |
| NHI-05 — Overprivileged NHI | Connected-device tokens often fail through excessive command scope and stale access. | |
| NHI-01 — Improper Offboarding | Retired or reassigned devices need token revocation to prevent lingering access. | |
| Recommendation — Set short token lifetimes and enforce revocation for device credentials. Scope device tokens to the minimum commands and resources required. Revoke and replace tokens when devices are decommissioned or repurposed. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token expiry, rotation, and revocation are authenticator lifecycle controls. |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Connected devices and machine-style access require authenticating non-human actors. | |
| AC-6 — Least Privilege | Device tokens should be limited to only the commands and data they need. | |
| Recommendation — Enforce lifecycle management for device tokens and other authenticators. Apply constrained authentication controls for device-to-service access. Reduce token privileges to the minimum required for each device. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen or long-lived device tokens function as a replayable authentication weakness. |
| API5 — Broken Function Level Authorization | Device tokens must not confer broader command authority than intended. | |
| Recommendation — Use sender-constrained, short-lived tokens and validate replay resistance. Restrict token access to approved device functions only. | ||
Practitioner Guidance
What to verify: Confirm that every device token has a defined owner, explicit scope, and revocation path, not just an expiry date. If you cannot identify who can revoke it and under what trigger, it is already too durable for a connected-device environment.
Decision rule: If the token can authenticate to production devices, treat it as high-value bearer material and prioritise short TTLs, audience restriction, and revocation testing before you optimise for operational convenience. If the device can function with narrower permissions or a shorter renewal window, take that option.
Common mistake: Teams often secure the initial enrollment flow but leave maintenance and command tokens effectively permanent. That creates a hidden gap where the device is “managed” but still reachable through stale access material.
Practitioner takeaway: The right question is not whether a device token is convenient to issue, but whether you can prove it stops being useful soon enough to matter when it is stolen, copied, or forgotten.
Related resources from NHI Mgmt Group
- How should security teams handle long-lived GitHub tokens in AI workflows?
- How should security teams reduce risk from long-lived API keys and personal access tokens in GitHub environments?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities in cloud environments?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org