How to Automate Password Resets and MFA Lockouts in Slack
It’s September 2023, and a phone rings at the MGM Resorts helpdesk in Vegas. The caller claims he’s an employee who has lost his credentials and authentication to a privileged account and says he wants a password reset and MFA reset urgently, he sounds rushed. The agent helps, because helping is the job. Ten minutes later, give or take, Scattered Spider is inside the Okta tenant, and the intrusion chain that follows takes down slot machines, hotel room keys, and reservation systems across some of the most famous properties in Las Vegas.
The same thing would happen one more time in 2023 to Caesars by the very same Scattered Spider, and in both cases the human agent did nothing wrong. They were doing their job which was designed to help people, and that’s exactly the problem.
I get your question. Why are we talking about a security exploit here, because most posts on the topic open on a cost saving statistic. While the number is real, if you want to automate password resets and MFA resets just to save money, I don’t believe that’s the right approach.
The bigger story is that a help desk agent who can be persuaded is a vulnerability, and no amount of awareness training will fix a person whose job is to be helpful. The fix is removing human discretion from the reset path and replacing it with a verification the caller/requester can’t talk past.
Why did the help desk become the attack surface?
Both MGM and Caesars reported huge financial losses due to the exploits in 2023. MGM estimated a negative impact of approximately $100 million to Adjusted Property EBITDAR in a Form 8-K filed with the SEC. Caesars reportedly paid roughly $15 million, about half the attackers’ initial $30 million demand, per Wall Street Journal reporting.
This shows that attacks through help desks are not edge cases. The CISA and FBI joint advisory AA23-320A on Scattered Spider documents help desk social engineering to reset passwords and MFA tokens, and it tells organizations, in plain terms, to verify identity before resetting passwords or adding MFA devices. The Verizon 2025 DBIR puts credential abuse at the top of the initial access list at 22% of breaches, with 88% of basic web application attacks involving stolen credentials and 60% of breaches involving a human element. Even NIST has weighed in: SP 800-63B treats account recovery as a more sensitive transaction than routine authentication, and it restricts phone-based out-of-band verification because of SIM swap risk.
Why didn’t self-service password reset solve it?
Every major IdP already ships self service password resets; then why does password reset requests never seem to come through the self-service portal?
There are two things that keep this request alive. The first is the chicken-and-egg problem; a locked-out user often can’t authenticate into the portal that would let them recover, because the portal is guarded by the same credentials they just lost. The second is behavioral, and you might have seen it in your own queue. Employees don’t remember the portal exists, the same way they don’t use the service catalog and instead DM the person with the admin button. People go where the work already happens, and at most mid-market companies, that’s Slack.
So the request lands in Slack anyway. The question is what happens next.
What does a well-designed reset path look like?
A good automated flow runs in this order: the request arrives in Slack, the intent is recognized, identity is verified through a deterministic channel, risk is assessed, the IdP executes the reset, confirmation comes back in-thread, and the whole event gets logged.
One boundary matters here, so let me be precise about it. Ravenna is not an identity provider, and it never touches a credential. Your IdP, whether that’s Okta, Entra, Google Workspace, OneLogin, or JumpCloud, executes every password and MFA action through its own API. Ravenna recognizes the request in Slack, verifies the requester, triggers the IdP, routes any approval, and logs the result. That distinction is the architecture that makes the security claim hold.
The verification step is where the argument gets concrete. With Okta, Ravenna’s Verify Identity with Push action sends an Okta Verify push to the device already registered to that user and waits for an approve or deny, then branches the workflow with if/else. An attacker on the phone can be charming, urgent, well-prepared. He can’t approve a push on a phone he’s not holding. That single step closes the exact gap Scattered Spider exploited.
Should every request be automated the same way?
No, and honestly, this is where the design earns your trust. In Ravenna, every tool can be set to auto-execute, require confirmation, or require approval; writes and deletes default to confirmation. We see teams set it up like this:
Lookups and status checks auto-execute, because they change nothing.
A standard employee password reset, after a successful push verification, runs on confirmation.
An MFA reset requires an approval, not a confirmation, because wiping someone’s authenticators is a bigger deal than resetting a password.
A privileged or admin account reset never auto-executes. Full stop. It goes to a human with elevated verification, every time.
The IdPs also differ in what they let you trigger, and the differences matter for policy. In Google Workspace, the Reset MFA/Password action offers Force Reset at Next Login or Generate Temporary Password, and the user still has to change the temp password at next sign-in.
Microsoft Entra splits the work into two separate actions, Reset Password and Reset MFA, both requiring the Privileged Authentication Administrator role. OneLogin documents Generate Password Reset Token and Set User Password, but no MFA reset action, so don’t assume parity there. And JumpCloud is the only IdP with a dedicated Unlock User action, which matters more than it sounds, because a lockout from failed login attempts and a forgotten password are different problems that get conflated constantly. One needs an unlock, the other needs a reset, and treating them as the same ticket is how bad resets happen.
How do you automate password resets and MFA lockouts in Slack?
Hook up your IdP and pick your Slack channel
Integrate your source of truth, Okta, Entra, or Google, to Ravenna. Then, decide which Slack channel will handle the requests. Ravenna manages the chat, but your IdP still does the heavy lifting for the actual password or MFA changes.
Grab just the essentials
Ask only for what’s necessary: who’s asking, what they need to recover, and if they have their phone. Spotting a missing device early keeps the whole process from hitting a brick wall later.
Run a quick sanity check
Let automation do the boring stuff. Confirm they’re actually in your directory and flag any VIP or admin accounts that need a human touch. This is where you decide if the request can stay on the fast track.
Verify the identity
If they have their phone, send a push. It’s a simple "yes/no" that takes the guesswork out of it. An attacker can be as persuasive as they want, but they can’t hit "approve" on a phone they don’t have.
Match the response to the risk
Set the right gates: a standard password reset might just need a confirmation, but wiping MFA authenticators is a big deal and should require an admin's approval. Admins should always get human eyes on their requests.
Hand off sensitive asks to a human
Don’t try to automate everything. If a phone is lost or someone is locked out of Slack, send them straight to a manual path. Automation handles the easy wins and let human judgment handle the weird stuff where attackers hide.
Log every single step automatically
Swap vague ticket notes for bulletproof proof. Everything from the first Slack message to the final IdP fix is recorded. It’s the exact audit trail you need for SOC 2 or NIST without anyone having to lift a finger.
What can’t automation solve?
Any vendor who skips this section is selling you something. There are real cases automation doesn’t cover, and you should design for them on day one.
The user locked out of Slack itself. Ravenna is chat-first, so if the lockout cascades to the chat platform, the user can’t self-initiate there. Fallbacks are Teams, the portal, or email-to-ticket, but a total lockout still needs an out-of-band path.
A lost or stolen phone. Push verification is unavailable, which is exactly the point of push verification. These escalate to a human.
A new hire not yet enrolled in MFA. There’s no registered device to push to. That’s a provisioning problem, not a reset problem.
Privileged accounts. Already said it, worth repeating: these route to a person with elevated verification every time, no exceptions.
Notice the pattern. Automation handles the routine volume; judgment handles the exceptions. And the exceptions are exactly where the attackers live.
What does your auditor see?
Every automated reset produces a record: who asked, what verification occurred, who approved, and what the IdP did in response. That’s precisely the evidence an auditor wants for access control and account recovery under SOC 2, and it lines up with how NIST 800-63B expects the authenticator lifecycle to be managed. Ravenna logs each of those steps as the flow runs, so the record exists by default; nobody has to write it down. A phone call leaves none of that. It leaves a ticket note saying “verified user,” written by the person who just got talked into the reset.
The agent in Las Vegas was doing the job the way the job was designed. Redesign the job.
If you want to see the redesigned version in your Slack workspace, we’re happy to show you, or you can poke around the docs first.
FAQs
How do you verify identity before resetting a password?
The strongest practical method is a push notification to a device already registered to that user in your IdP, like an Okta Verify push. Nothing executes until the requester approves it, which proves possession of the enrolled device in real time. Knowledge-based answers and caller ID don’t hold up against a prepared attacker, and NIST 800-63B restricts phone-based verification because of SIM swap risk.
Can MFA resets be automated safely?
Yes, with stricter gating than password resets. Clearing someone’s authenticators is a higher-impact action, so it should require an approval step rather than a simple confirmation, and it should only run after deterministic identity verification. A privileged account MFA reset should never auto-execute at all.
Is automating password resets secure?
Done right, it’s more secure than the manual alternative. A human agent can be socially engineered; a workflow that requires a push approval on an enrolled device can’t be talked past. You also get a complete audit trail of who asked, how they were verified, who approved, and what the IdP did, which a phone call never gives you.
