Who is accountable when a supported token later becomes unsafe?

Accountability sits with the provider that chose to support the asset and failed to monitor it against its own criteria. The central bank’s model implies that approval and removal are both governed decisions, so risk, compliance, and operational owners must be able to explain why support continued after warning signs emerged.

Why This Matters for Security Teams

When a supported token later becomes unsafe, the real issue is not just exposure. It is governance drift: a decision was made to keep supporting an asset after the risk profile changed. That means accountability should follow the party that owned support criteria, monitored the token, and had the authority to remove it. NIST’s Cybersecurity Framework 2.0 frames this as a lifecycle control problem, not a one-time approval event.

This is especially visible in secret and token programs, where assets are often duplicated, shared, or left active far longer than intended. NHIMG research on the Guide to the Secret Sprawl Challenge shows how quickly credentials spread across systems, people, and workflows once ownership is unclear. In practice, teams often discover the failure only after a breach, not through a deliberate review of support decisions.

How It Works in Practice

Accountability usually sits with the provider, platform owner, or control owner that approved the token for continued use. That party is expected to maintain criteria for support, monitor the token against those criteria, and revoke support when the asset no longer meets policy. If a business unit keeps using a token after a known warning, it may be operationally involved, but it does not replace the provider’s duty to govern support decisions.

Practically, this means the organisation needs a support lifecycle with named owners, review dates, and removal triggers. A strong process usually includes:

• Documented support criteria for age, exposure, misuse, privilege scope, and business criticality.
• Automated detection of stale, duplicated, or exposed tokens across code, tickets, chat, and vaults.
• Just-in-time escalation for review when a token crosses a risk threshold.
• Fast revocation paths that do not depend on informal approvals.
• Evidence retention showing who approved support, who reviewed risk, and who accepted the remaining exposure.

That operating model aligns with the NIST Cybersecurity Framework 2.0 emphasis on continuous risk management, and it reflects the same lesson seen in the Salesloft OAuth token breach: once token governance lags reality, downstream access can persist far beyond what the original approval intended.

NHIMG research also shows why this cannot be treated as a narrow admin task. The 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding, which illustrates how support can outlive the risk it was meant to manage. These controls tend to break down when ownership is split across security, engineering, and procurement because no single team feels accountable for revocation.

Common Variations and Edge Cases

Tighter support governance often increases operational overhead, requiring organisations to balance speed of access against the cost of review and revocation. That tradeoff becomes more visible when the token supports customer-facing services, legacy integrations, or third-party dependencies that cannot be paused without business impact.

There is no universal standard for this yet, but current guidance suggests treating “supported” as a conditional status rather than a durable endorsement. If a token becomes unsafe because of exposure, weak scope hygiene, or abandoned ownership, the question is not whether it once met criteria. The question is whether support should have been withdrawn sooner, and whether the owner can prove why it was not.

This is where edge cases matter. A contractor token, a shared service credential, and an automation token may all look similar in inventory, but the accountability chain differs. In regulated environments, the governance record must show who accepted residual risk, who had revocation authority, and what changed between approval and removal. That distinction is crucial when reviewing incidents that resemble the Dropbox Sign breach, where token-related exposure can turn a support decision into a control failure.

Related resources from NHI Mgmt Group

• Who is accountable when an accepted vulnerability exception later becomes exploitable through AI?
• Who remains accountable when a managed cloud security provider misses an incident?
• Who is accountable when multi-cloud access reviews miss excessive permissions?
• Who is accountable when unnecessary access remains in place?