What should organisations do when their AI accounts rely on password reset or SMS recovery?

Why This Matters for Security Teams

Password reset and SMS recovery are acceptable for low-risk consumer use, but they are weak recovery paths for AI accounts that can invoke tools, touch data stores, or trigger automated workflows. If the login factor is phishing-resistant but the recovery path is not, attackers will target the recovery process instead of the primary sign-in. NHI Management Group’s DeepSeek breach coverage illustrates how exposed credentials and weak control boundaries can become an operational security problem, not just an authentication issue.

This is especially important for organisations using agents, service accounts, or AI assistants with delegated access. A reset link, help-desk exception, or SMS code can become a hidden privilege escalation path if it is easier to obtain than the original credential. Current guidance suggests treating recovery as part of the attack surface, not as an administrative afterthought. In practice, many security teams encounter account takeovers through recovery flows only after an attacker has already bypassed the stronger login controls.

How It Works in Practice

For high-consequence AI accounts, the safer pattern is to remove password reset and SMS recovery entirely and replace them with recovery methods that are device-bound, identity-bound, and auditable. That usually means a second registered authenticator, verified admin intervention, or a hardware-backed recovery process tied to the account owner’s trusted device or workload identity. For machine accounts, the better primitive is not a password at all, but cryptographic workload identity and short-lived access.

Practitioners should design recovery with the same rigor as privileged access management. A practical flow often includes:

• pre-registered recovery devices or admin-approved recovery contacts
• time-limited, one-time recovery approvals with mandatory logging
• step-up verification through a separate channel, not SMS alone
• automatic revocation of standing sessions after recovery events
• review of any tool access or tokens issued before the reset

This aligns with the NIST Cybersecurity Framework 2.0 emphasis on protecting identities and recovering safely, and with NHI guidance that recovery channels must be governed as privileged pathways. NHI Management Group’s The State of Secrets in AppSec research also shows how fragile secrets handling becomes when operational processes are fragmented. For AI accounts, recovery should trigger session review, secret rotation, and access reconciliation before the account is returned to service. These controls tend to break down in shared-service environments where one recovery action can restore access to multiple downstream systems because the account has broad inherited permissions.

Common Variations and Edge Cases

Tighter recovery controls often increase support overhead, requiring organisations to balance account safety against user friction and operational speed. That tradeoff is real, especially for executive assistants, incident-response bots, and production agents that cannot simply wait for a manual callback. Best practice is evolving, but there is no universal standard for this yet: the recovery path should match the account’s blast radius, not the user’s convenience.

For lower-risk AI tools, limited recovery options may still be acceptable if the account cannot access sensitive data or invoke privileged actions. For high-consequence accounts, though, SMS should be considered a fallback of last resort, not a primary recovery mechanism. Organisations should also avoid mixing human and machine recovery rules, because a service account does not need the same help-desk experience as a person. Where regulatory or business constraints force exceptions, those exceptions should be documented, time-bound, and monitored for abuse. Current guidance also suggests reviewing recovery events as security incidents, since recovery abuse often precedes lateral movement or token theft.

Related resources from NHI Mgmt Group

• What breaks when organisations rely on weak account recovery and reset processes for digital services?
• What breaks when organisations rely on service desk recovery to protect high-risk accounts?
• Why do help desk recovery flows become a major risk in AI-enabled attacks?
• Why do non-human identities create more audit risk than human accounts?