Why do hardware tokens still fail in large IAM programmes?

Why This Matters for Security Teams

Hardware tokens are often treated as the “strongest” answer to access assurance, but large IAM programmes fail when token operations do not scale with the business. The issue is usually not the cryptography in the device. It is the lifecycle: issuance, renewal, loss handling, replacement, and deprovisioning. Once those steps become manual, exceptions accumulate and the control starts to behave like a paper process with a physical object attached.

That matters because access programmes are judged by what happens during turnover, incident response, and privileged access reviews, not by the token itself. NHIMG’s research on the Guide to the Secret Sprawl Challenge shows how unmanaged credentials tend to multiply when lifecycle ownership is unclear, and the same pattern appears in token programmes when recovery and offboarding are fragmented. The broader governance lesson aligns with the NIST Cybersecurity Framework 2.0: identity controls have to be measurable across their full operating cycle, not just at enrollment.

In practice, many security teams discover token failure only after users are locked out, emergency exceptions are granted, or deprovisioning gaps have already widened the attack surface.

How It Works in Practice

In a mature programme, a hardware token should be one component of a broader identity workflow, not the workflow itself. That means the control needs clear ownership across procurement, issuance, binding to an identity record, periodic validation, replacement, and secure retirement. If any of those steps depend on ad hoc support tickets or a single help desk queue, the token becomes operationally fragile.

The most reliable programmes pair physical tokens with strong identity proofing, role review, and policy-based access decisions. The token authenticates possession, but the IAM platform still decides whether the session should be allowed based on role, device posture, location, and risk. This is where the practical value shows up: reduced reliance on standing exceptions and fewer long-lived bypass paths. NHIMG’s Salesloft OAuth token breach illustrates the danger of treating tokens as durable trust anchors when lifecycle and revocation discipline are weak.

• Use automated provisioning and revocation so token state follows the identity record.
• Require documented recovery paths that do not depend on informal manual approval.
• Separate high-risk access from general workforce access so replacement events do not become broad exceptions.
• Track token age, unused tokens, failed recovery attempts, and orphaned assignments as operational metrics.

Where programmes mature further, teams add phishing-resistant MFA policies, emergency break-glass procedures, and clear offboarding SLAs so token ownership stays aligned with employment status. These controls tend to break down in very large, geographically distributed organisations because replacement logistics, support escalation, and identity data quality are rarely synchronised.

Common Variations and Edge Cases

Tighter token controls often increase user friction and support overhead, so organisations have to balance assurance against operational resilience. That tradeoff is real, especially for contractors, executives, field staff, and users who travel frequently. Best practice is evolving, but current guidance suggests that one-token-per-person models should be avoided when recovery time, device loss, or supply-chain delays can interrupt business-critical access.

Hybrid environments introduce another edge case. A token may be well managed in one directory or region, then silently lose effectiveness when identities are mirrored across multiple IAM stacks. NHIMG’s Guide to the Secret Sprawl Challenge is a useful reminder that fragmented ownership is the real failure mode, not the token format itself. For policy and assurance framing, the NIST CSF 2.0 emphasises governance and access control outcomes rather than device fetishism, which is the right lens for large-scale programmes.

Another common exception is emergency access. Break-glass accounts often bypass normal token enforcement, and if those accounts are not tightly monitored, they become the very exceptions that undermine the control. The operational question is not whether hardware tokens are secure in isolation. It is whether the surrounding IAM process can preserve secure access while handling loss, recovery, and offboarding at enterprise scale. In high-turnover environments with weak asset-to-identity mapping, token programmes tend to fail because the organisation cannot keep state accurate enough to trust the control.

Related resources from NHI Mgmt Group

• Why do access control models still fail in mature IAM programmes?
• Why do IAM programmes still fail even after tool implementation?
• Why do phishing-resistant authenticators still fail in real IAM programmes?
• When should organizations rotate OAuth tokens?