I’ve always found it frustrating when users get locked out of their accounts because they lost access to their authenticator app. It’s a security feature that backfires, turning MFA from a protective measure into a barrier to legitimate access. AWS Cognito just addressed this pain point with a seemingly small but genuinely useful API addition: the AdminDeleteSoftwareToken operation.
Let me be direct: this is the kind of incremental improvement that matters in production systems. It’s not flashy, but it solves a real problem that affects support teams and users at scale.
The Real Problem with TOTP Recovery
Time-based one-time passwords (TOTP) are excellent for security. They’re phishing-resistant, not dependent on SMS infrastructure, and widely supported by authenticator apps. But they have a weakness: if a user loses their phone, deletes their authenticator app, or forgets which device they enrolled, they’re stuck.
Previously, your options were limited. You could:
- Disable MFA entirely (security nightmare)
- Force account recreation (user nightmare)
- Use backup codes if you’d implemented them (if the user remembered them)
- Build custom recovery workflows (engineering overhead)
None of these are great. Option two especially is a band-aid that creates more problems than it solves. You’re essentially admitting your system can’t recover from a common, predictable failure mode.
What Changed
The AdminDeleteSoftwareToken API operation now lets administrators remove a user’s TOTP association without nuking their entire account. The user can then re-enroll with a new device on their next login attempt.
The implementation is straightforward. Via CLI, SDK, or direct API call, admins can invoke this operation and users regain access. No account migration, no data loss, no security compromise. MFA enforcement stays in place, but the recovery path exists.
This is available across all AWS regions where Cognito operates, which means no special configuration or regional workarounds needed.
Why This Matters More Than It Appears
I think this reflects a maturation in how cloud providers think about security UX. Real security isn’t about making systems harder to access; it’s about making them secure and usable. When users can’t recover from legitimate lockouts, they work around your security measures. They share passwords, disable MFA, or switch to less secure alternatives.
This feature acknowledges that reality. It says: “We can enforce strong authentication while still providing operators with recovery tools.” That’s the right balance.
For developers building on Cognito, this removes a gnawing edge case from your mental model. You no longer need to either accept support burden or accept that some percentage of your users will become permanently locked out. You can recommend users use authenticator apps without the guilt of knowing there’s no recovery path.
Implementation Considerations
If you’re using Cognito for authentication, here’s what I’d think about:
First, audit your current MFA recovery flows. If you’re still handling TOTP resets manually or with workarounds, this API can simplify that. Second, consider your administrative workflows. Who should have permission to call AdminDeleteSoftwareToken? You’ll want to restrict this to appropriate support or security personnel, not every admin user. Third, think about whether you want to document this for your users. Knowing recovery is possible might increase MFA adoption in your product.
The API is available through the standard AWS mechanisms: CLI, Python boto3, Node.js SDK, and others. Check the developer guide for language-specific examples and permission requirements.
The Broader Pattern
This ties into a larger conversation I’ve been thinking about in authentication and access-control systems. The best security mechanisms are ones that don’t fight legitimate user needs. When your security layer and your usability layer conflict, users lose. They either circumvent security or abandon the system entirely.
AWS seems to be listening to that feedback. Adding pragmatic recovery mechanisms to strong authentication is smart infrastructure design. It’s also worth considering when evaluating other identity providers or building custom authentication systems. If your system can’t gracefully recover from device loss or MFA misconfiguration, you’ve designed a trap, not a feature.
The question isn’t whether users will lose access to their MFA devices. They will. The question is whether your system handles that gracefully or forces everyone to suffer for it.
How are you currently handling TOTP recovery in your applications, and does this AWS addition align with what you’ve been building?