Who is accountable for securing TOTP seeds, recovery keys, and other backup secrets?

Why This Matters for Security Teams

TOTP seeds, recovery keys, and backup secrets are not ordinary user artifacts. They are alternate authentication paths that can defeat normal reset, step-up, and help desk controls if they are copied, shared, or stored loosely. Accountability therefore belongs to the teams that govern authentication, privileged access, and security operations, with clear ownership for storage, retrieval, and revocation. That ownership needs to map to formal policy and review cycles, not informal admin habits. The OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 both reinforce that identity-adjacent secrets require explicit governance, accountability, and monitoring.

NHIMG research on The State of Secrets in AppSec shows why this matters operationally: organisations report strong confidence in secrets management, yet leaked secrets still take an average of 27 days to remediate. That gap matters because recovery secrets are high impact by design. If they are exposed, an attacker may not need to break primary authentication at all. In practice, many security teams discover uncontrolled recovery paths only after an account takeover or help desk abuse has already occurred, rather than through intentional review.

How It Works in Practice

Accountability should be split by function, but not blurred by convenience. Authentication governance should define which backup secrets exist, when they are allowed, and what recovery paths are acceptable. Privileged access teams should control the vault, approval workflow, and break-glass handling. Security operations should monitor access, detect anomalous retrieval, and verify revocation when a secret is rotated or retired. That division makes it possible to answer three questions quickly: who approved the secret, who can retrieve it, and who can prove it was used properly.

In a mature model, backup secrets are held in a governed vault with strong access controls, short-lived retrieval privileges, and tamper-evident logging. Retrieval should be time bound, attributable to a named operator, and tied to an approved ticket or incident. Where possible, use step-up approval and dual control for the most sensitive recovery keys. For broader secrets hygiene, the NHIMG Guide to the Secret Sprawl Challenge is useful because it shows how quickly uncontrolled copies spread across tools and teams. Current guidance also aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement, auditability, and least privilege are concerned.

• Store seeds and recovery keys in a centrally governed vault, not in mailboxes, tickets, or spreadsheets.
• Make retrieval time bound, approved, and logged with operator identity and purpose.
• Rotate or invalidate backup secrets after use, role change, or incident response.
• Review access periodically and treat recovery paths as privileged access, not convenience features.

These controls tend to break down when help desk teams are allowed to bypass vault workflow for “urgent” resets, because urgency becomes a standing exception rather than a managed event.

Common Variations and Edge Cases

Tighter recovery control often increases reset friction, so organisations must balance resilience against operational speed. That tradeoff becomes sharper for executives, shared service accounts, and high-availability systems where locked-out access can halt critical work. Best practice is evolving, but there is no universal standard for which backup paths should exist in every environment. The safest default is to minimize the number of recovery methods and keep the remaining ones tightly governed.

One common edge case is when business continuity teams want offline copies of recovery material. That may be justified, but it should still use sealed storage, dual custody, and documented retrieval criteria. Another is delegated administration, where regional IT or outsourced support teams need temporary access. In those cases, the accountable owner remains the central authentication or privileged access function, even if execution is delegated. The NHIMG 52 NHI Breaches Analysis is a strong reminder that uncontrolled credentials and weak recovery governance often travel together. For audit teams, the practical test is simple: if a backup secret can be used outside normal policy without a named, reviewed, and revocable trail, the control is incomplete.

Related resources from NHI Mgmt Group

• Who should be accountable for securing disconnected applications when access is managed through custom API automation?
• Why do collaboration tools create such a large secrets risk?
• Why do leaked secrets remain such a persistent NHI risk?
• What makes idle secrets such a serious NHI risk?