Ask any IT manager where their team's MFA codes are stored, and the most common answer is some variation of: "On people's phones, I think."
This is understandable. When organizations set up MFA, they follow the path of least resistance: employees scan a QR code with Google Authenticator or Authy on their personal phones, and authentication works. Nobody thinks too hard about what happens next.
What happens next, eventually, is a problem.
The Fundamental Issue
Personal phones are personal. They belong to the employee, not the organization. Anything stored on them — including OTP secrets for company accounts — is effectively outside organizational control.
This creates a category of security risk that's distinct from other credential risks. A password can be reset. An SSH key can be revoked. But an OTP secret stored on an ex-employee's phone continues to generate valid codes indefinitely, unless the entire MFA enrollment for that account is reset.
Seven Specific Risks of Phone-Based OTP Storage
1. The departing employee problem
When an employee leaves, they take their phone. If their phone holds OTP secrets for company accounts — AWS, GitHub, Cloudflare, Stripe — those secrets leave with them. The person no longer works for you, but they can still generate valid authentication codes.
Most organizations respond to this by rotating credentials and regenerating MFA enrollments for departing employees. This works, but it's manual, error-prone, and depends on IT catching every account.
2. The device loss problem
Phones get lost, stolen, or broken. When the device that holds the authenticator app is unavailable, the team loses access to any account where that was the sole MFA enrollment. Recovery requires going through account recovery flows — which vary wildly in speed and reliability across different services.
3. The availability problem
If the person who holds the MFA code is unavailable — on vacation, sick, in a meeting, in a different timezone — everyone else who needs access to that account has a problem. For business-critical systems, this is a significant operational risk.
4. The BYOD security gap
In BYOD environments, the organization has limited visibility into the security posture of the device holding the OTP secret. Is the phone encrypted? Does it have a lock screen? Is the authenticator app protected by biometrics? You don't know. The secret is there, on a device you don't manage.
5. The audit trail gap
Personal authenticator apps don't log access. There's no record of who generated an OTP code, when, or for which account. When a security incident occurs and you need to determine what happened, this gap is significant.
6. The no-revocation problem
Unlike passwords or API keys, individual OTP secrets cannot be "deactivated" without re-enrolling MFA for the account. If you discover that an OTP secret has been compromised — or that an ex-employee still has it — your only option is to disable and re-enroll MFA entirely.
7. The proliferation problem
Shared accounts often lead to multiple copies of the same OTP secret on multiple personal phones. Each copy is a potential breach surface. Over time, nobody knows exactly which phones hold which secrets, and there's no authoritative record.
The Organizational vs. Personal Device Problem
The core issue is that organizations are using personal devices to store organizational secrets. These are fundamentally incompatible:
| Personal device | Organizational need | |---|---| | Belongs to the employee | Belongs to the organization | | Follows employee when they leave | Stays with the organization | | Not subject to IT policy | Subject to security policy | | No audit trail | Full audit required | | No revocation mechanism | Immediate revocation required |
The solution is to store organizational OTP secrets in an organizational system — a team MFA vault — not on personal devices.
What to Do Instead
A shared MFA vault is the organizational equivalent of a personal authenticator app. The same TOTP protocol, the same standards-based implementation, but designed for team use:
- Centralized storage: secrets live in the vault, not on phones
- Access control: decide who can generate OTPs for each code
- Audit logging: every access event is recorded
- Instant revocation: remove someone's access in seconds
- Device independence: anyone with permission can access codes from any device
Organizations like IT departments and MSPs should use a vault like Gatera for all work-related OTP codes, rather than routing them through personal phones.
Migrating from Phone-Based to Vault-Based OTP
The migration process is straightforward for most services:
- Go to the security settings of each affected account
- Remove the existing TOTP enrollment
- Re-enroll using your team vault (scan the QR code into Gatera, not into your phone)
- Verify the new enrollment works
- Update access permissions to control who can use the code
Most services allow this without any downtime. The vault becomes the authoritative authenticator, and personal phones are removed from the equation.
Conclusion
Storing work OTP codes on personal phones is a convenience that creates organizational security risks. Departing employees, lost devices, and lack of audit trails are not edge cases — they're predictable consequences of putting organizational secrets on personal devices.
The solution is simple: move OTP secrets into a team vault where you control access, can audit usage, and can revoke permissions instantly.
Try Gatera free → — the team MFA vault built to replace personal phone authentication.