Dex
7 min readBy Dean Craftsman

How Dex Go resolves password requests in Microsoft 365

How to automate password resets in Microsoft 365 — under policy, with full audit, no ticket required. A working approach to the most expensive Tier 1 work.

Password resets are the single largest line item in most IT help desks. Industry surveys put the average cost of a password-related ticket between $20 and $70, depending on whether the helpdesk has to call the user back. Multiplied across a 500-employee org with three to five resets per user per year, that's a five- to six-figure spend on a problem the user already knows how to describe in one sentence: "I can't log in."

The technical work is small. The operational overhead is enormous. This is the gap an agentic IT system closes — by handling the request end-to-end, before it becomes a ticket.

The password reset problem in Microsoft 365

In a typical Microsoft 365 environment, "I can't log in" can mean any of seven things:

  • The user forgot their password and has their MFA method available
  • The user forgot their password and lost their MFA method
  • The account is locked after too many failed attempts
  • The user's password expired and the change UI failed
  • A Conditional Access policy is blocking the sign-in (wrong network, unmanaged device)
  • The user is asking for a temporary password to hand off to a contractor (a policy-policy case)
  • The user just typed the wrong password and needs to try again

Entra ID's built-in Self-Service Password Reset (SSPR) handles the first scenario well. For the others, the request lands in the IT queue. A human picks it up, asks the user the same questions an automated system could, performs the action, and closes the ticket. The work is mostly identity verification plus a few admin clicks. None of it requires human judgment — but all of it requires human time.

The cost isn't the reset itself. It's the queue.

What "automating password resets" usually means — and what's missing

The "automate password resets" market is full of products that handle the SSPR-shaped slice and leave everything else for the IT team. Three common patterns:

Vendor portals. Standalone web apps that the user logs into to reset their password. Useful, but they create a second identity flow alongside Entra ID, fragment the audit trail, and don't help when the user can't log in to the portal either.

Helpdesk chatbots. AI assistants embedded in ServiceNow or Zendesk that "help" the user file a better-formatted ticket. They route faster; they don't resolve faster. A copilot is not a deflection.

Scripted automations. Power Automate or similar flows that resolve the simplest cases. They work for what they cover and fail silently on edge cases — and password reset edge cases (MFA loss, lockouts, policy conflicts) are exactly where IT teams need automation most.

None of these handle the full set of seven scenarios. Most don't even handle two.

How Dex Go handles a password request, step by step

Dex Go is the user-facing agent in the Dex platform. It lives natively in Microsoft Teams (and Slack) — the user opens a chat, says what they need, and Dex Go takes it from there. Here's what happens when a user asks Dex Go for a password reset.

Chat · Dex Go
Dex Go online
Hey Dex, I can’t log in to my email.
Sarah Chen · 10:14
Investigating…
  • Sarah Chen, Finance dept
  • Last sign-in: 3 failed attempts
  • Account: locked
Dex Go · 10:14
Quick check — sending an MFA prompt to your Authenticator app. Approve to continue.
Dex Go · 10:14
Approved
Sarah Chen · 10:14
Done. Account unlocked.
A temporary password has been sent to your recovery email. You’ll be prompted to change it on next sign-in.
Audit logged · Policy: Self-Service Reset (Finance dept)
Dex Go · 10:14
Type a message…

Step 1 — investigate. Dex Go identifies the user (department, devices, group memberships) by reading their profile from Entra ID. It checks recent sign-in events to understand the situation: did the password just expire, are there failed sign-in attempts indicating a lockout, has the user already attempted SSPR and failed? This step typically takes a few seconds and surfaces information the user wouldn't think to mention.

Step 2 — verify identity. Before resetting anything, Dex Go confirms the request is legitimate. The verification path depends on the organization's policy — registered MFA challenge, manager confirmation in Teams, Conditional Access challenge, or a combination. The verification step lives in code, not in the agent's prompt: there is no way to talk Dex Go out of asking for verification.

Step 3 — check policy. Every action Dex Go takes must match an explicit, structured policy. For a password reset, the relevant rules include: which accounts can be reset by whom, whether the user is in a sensitive role (privileged admin accounts get manager approval routing), whether the current time falls within a maintenance window, and which password complexity requirements apply. No policy match, no action.

Step 4 — execute. Dex Go performs the reset against Entra ID using delegated permissions — it acts as the requesting user, within the scope that user is allowed under your organization's policy. The reset is real. The new password is communicated to the user through the verified channel established in Step 2 (typically the Teams chat itself, secured by the user's verified Teams identity). If MFA was lost, Dex Go also resets the MFA registration in the same flow.

Step 5 — record + report. Every action is logged in Entra ID's audit trail (as the underlying identity event) and in Dex Go's own activity log (with the reasoning chain, the policy that authorized it, and the verification method used). The user gets confirmation in Teams. IT gets a clean record. No ticket is opened unless the request was routed for approval and the approval was logged as part of the trail.

The whole flow — investigate, verify, check, execute, record — happens in the same Teams conversation, typically inside a minute. No portal. No ticket. No callback.

The guardrails that keep this safe

The most important property of automated password resets isn't speed. It's safety. An agent that can change credentials at scale is one configuration mistake away from being a tool for account takeover.

Dex Go's guardrails live at three layers:

Scope. Dex Go can only act on the requesting user's own account. It cannot reset another employee's password. It cannot reset a privileged admin account on its own — those go through the approval path. The scope boundary is enforced in code, not in instructions to a model, so prompt injection has no effect on it.

MFA. Dex Go never bypasses MFA. If the user's MFA is broken, the policy decides whether Dex Go can recover MFA through an alternate verification path (manager confirmation, recovery email) or whether the request must escalate. Dex Go cannot decide on its own to skip MFA.

Audit. Every action is logged twice — once in the underlying Microsoft 365 audit log (where security teams already monitor) and once in Dex Go's own activity log (with reasoning and policy context). Auditors get the full chain. Compliance teams get the policy that authorized each reset.

For the full security and compliance picture — SOC 2 Type 2, ISO 27001/27017/27018, GDPR, HIPAA — see Dex's security overview. For the architectural deep dive on policy enforcement and delegated permissions, see how it works.

What this changes for IT operations

Once Dex Go is resolving password requests, three things happen.

First, the password reset queue stops being a queue. The work doesn't move faster; it moves to a different system. The IT team isn't picking up tickets; they're getting an audit log entry after the fact.

Second, the Tier 1 metric shifts. "Average time to resolve a password ticket" becomes meaningless when most password requests never become tickets. The metric that replaces it is resolution rate without human involvement — and the target is 90%+, in line with Dex's overall benchmark across customers.

Third, the engineers do engineering. The IT team's day stops being defined by interruption. The work that previously consumed L1 — the seven scenarios above — happens without them.

Cliff DuPuy, Director of IT at Grand Traverse County (an MSP), told us that Dex helped unlock $67,000 in value in a single day. Some of that was password work. Most of it was the work the team got to do once the password queue stopped owning their attention.

Getting started

The fastest way to see this against your own Microsoft 365 environment is the Put Dex to Work offer — three months of full unlimited access with a dedicated onboarding engineer at no cost.

Or, if you want to walk through the policy model and the eight evaluation questions from our working definition of agentic IT first, book a working session and we'll go through them live.

The password queue isn't a hard problem. It's an expensive one. An agentic IT system makes the expense disappear.

Frequently asked

How do you automate password resets in Microsoft 365?
Automating a password reset in Microsoft 365 requires three things: an identity provider (Entra ID), a policy layer that decides who can reset what under which conditions, and an execution layer that performs the reset against the user's account. Most teams use a combination of Entra ID's built-in Self-Service Password Reset (SSPR) for simple cases and an agentic IT system like Dex Go for cases that involve MFA recovery, account unlocks, manager approval routing, or shared mailbox permissions — the work SSPR doesn't cover end-to-end.
What is Self-Service Password Reset (SSPR) and is it enough?
SSPR is Entra ID's built-in flow that lets users reset their own passwords by verifying through MFA, security questions, or email. It works well for the simplest case — a user remembers their MFA method and resets cleanly. It does not handle MFA recovery (the user lost their phone), account lockouts after repeated failed attempts, password resets that require manager approval, or any case that touches policies beyond Entra ID's defaults. For an IT team, SSPR covers maybe half of the password queue.
Can AI safely reset passwords for users?
Only with the right governance model. A safe automated password reset enforces three guardrails in code — not in the AI prompt: (1) the system can only act on the requesting user's own account, never anyone else's; (2) MFA is required and cannot be bypassed by the agent; (3) every reset is logged in both the underlying identity system's audit trail and the agent's own activity log, with the policy that authorized it. Without these, an AI agent that resets passwords is a security incident waiting to happen.
How does Dex Go handle MFA recovery when a user has lost their phone?
Dex Go investigates the request, confirms the user's identity through an alternate verification method (a manager confirmation, a recovery email, or a Conditional Access challenge based on the organization's policy), then resets both the password and the MFA registration in Entra ID — or routes the request for approval if the policy requires a human in the loop. The whole flow happens inside Microsoft Teams. No ticket, no help-desk call.
Does Dex Go work with Microsoft Entra ID?
Yes. Entra ID is the primary identity provider Dex Go operates against. Dex Go uses delegated permissions — it acts as the requesting user, bounded by what the user could do themselves under the organization's policy. It supports password resets, MFA recovery, group membership changes, Conditional Access policy lookups, and the full set of Entra ID operations needed to resolve a Tier 1 identity request end-to-end.