Ask Advisory is a weekly series where we take a real question our team hears from clients, break down the fast fix, and show the change we make so it doesn’t happen again.
The Ask
“Your account has been locked due to too many failed attempts, Google or M365 email.”
You changed your corporate password this morning. Everything seemed fine, until twenty minutes later your email disconnected, Slack asked for credentials again, and you got hit with one of these:
“Your account has been temporarily locked out to prevent unauthorized access.”
Or: “Too many unsuccessful sign-in attempts. Try again in 30 minutes or contact your administrator.”
Repeated account lockouts right after a password change are almost always caused by an old device or app still retrying the cached credential in the background, not an active security threat. Clearing that one stale credential typically resolves it in under two minutes.
You reset the password, get back in, and fifteen minutes later you’re locked out all over again.
The Fix
If you’re stuck in the loop, or a support engineer triaging it live, this usually breaks the cycle fast.
Hunt down ghost sync clients. The most common cause of a repeating lockout right after a password change is an old, cached credential somewhere quietly retrying authentication every sixty seconds until it trips the lockout threshold. Check the native mail app on personal phones or tablets first, since those get missed most often. For local clients like Outlook or Apple Mail, quit the app entirely, remove the account or clear the saved keychain credential, and re-add it. Also check for mapped network drives, printers, or an old VPN client still holding a stored domain credential.
Clear the OS credential vault. On a Mac, open Keychain Access, search for the company domain or email address, and delete any stale Exchange, Google, or Microsoft token. On Windows, open Credential Manager, go to Windows Credentials, and remove anything referencing Office, Outlook, or Google.
Revoke active sessions. Have IT pair an administrative password reset with a “revoke all active sign-in sessions” action in the admin console. That clears every stale token handshake across every device at once, rather than chasing them one by one.
That gets someone unlocked. It doesn’t explain why one password change touched off five separate retry loops in the first place, and it doesn’t stop the next person from hitting the same wall.
The Fix That Sticks
Resetting a password every fifteen minutes treats the symptom. The actual problem is that passwords, and everything that caches them, are inherently fragile. Here’s how we take that fragility out of the system.
Move toward passwordless authentication. Passwords are the root cause of lockout loops, credential stuffing, and a meaningful chunk of helpdesk fatigue. Migrating identity to FIDO2 WebAuthn, Okta FastPass, or Windows Hello for Business removes the memorized, rotatable password entirely, which means the cached-credential conflict that caused this in the first place has nothing left to sync against.
Turn on smart lockout instead of blunt lockout. A legacy lockout policy locks the whole account the moment it sees too many failed attempts, even if the failures are coming from one rogue app or an unfamiliar IP address rather than the actual user. Smart Lockout in Entra ID or Okta ThreatInsight tells the difference. It can lock out just the offending source and leave the employee’s own access untouched.
Give people a real self-service reset. Hardened self-service password reset, tied to a verified authenticator push or hardware key, lets someone unlock their own account in under a minute without a ticket at all.
Retire legacy authentication protocols. Older protocols like IMAP, POP3, SMTP Auth, and Exchange ActiveSync are exactly the kind of thing that breaks quietly during a credential change, because they don’t handle token refresh the way modern OAuth does. Blocking them at the conditional access layer and forcing everything onto modern authentication removes an entire category of these tickets outright.
Same underlying principle as the others: stop asking the system to re-verify a static secret over and over, and instead build something that verifies the device and the session continuously, in the background.
Why It Matters
Password issues routinely account for 20 to 30 percent of IT ticket volume at most companies. Fixing the architecture, not just the individual lockout, frees that time for work that actually moves the business forward.
It’s also a real security upgrade, not just a convenience one. Smart Lockout and modern authentication enforcement stop password-spraying and brute-force attempts from having any real shot at your systems, while legitimate users see zero friction.
And it closes a quieter risk: when login is this frustrating, people find workarounds, personal email, unapproved file-sharing tools, whatever gets the job done. Removing the friction removes the incentive to go around IT in the first place.
If lockouts like this are a recurring theme for your team, and nobody’s connected the dots between your identity provider and your device management layer, that’s a pattern worth surfacing in an environment audit before it costs you more support hours than it needs to.
If that’s an audit you’d want us to run, let’s talk.
