Request a demo

The unlock button should come after verification.

Provider permissions determine who can unlock an account. They do not verify the employee asking for that action on the phone.

By Fctr Identity 3 minute read

The important question is not whether the helpdesk can click Unlock. It is whether the correct employee was verified, the operator is permitted to act, and the outcome remains connected to the request.

Permission to unlock is not proof of the caller

Microsoft Entra ID and Okta both define roles and permissions for password reset, account unlock, and related user-management actions. Those controls matter. They limit which operators or applications can change a user's access and, in some cases, which users they can manage.

But an authorized helpdesk agent can still receive an unlock request from an impersonator. Provider permission answers whether the operator may act. It does not prove that the person asking for the action is the employee.

This distinction shaped how we built Fctr Portal:

  • Verification: Is the person participating in this support interaction the selected employee?
  • Authorization: May this operator perform this action on this target under current policy?

Both answers should be present before the unlock control becomes available.

How should a helpdesk verify users before unlocking accounts?

Find the employee in the trusted directory, verify them using an approved enrolled factor, and check the agent's authority before making the unlock available. Knowing the employee's personal details is not a substitute for this identity check.

Our product rule is deliberately restrictive. For a supported account-unlock request, the workflow should:

  1. retrieve the employee from the configured Microsoft Entra ID or Okta tenant;
  2. verify that selected employee through an organization-managed enrolled factor;
  3. evaluate the operator, target, requested action, and applicable policy;
  4. make the unlock action available only when those checks pass; and
  5. record the verification, decision, action, and outcome without exposing unnecessary personal data.

The verification result is for this request. It should be short-lived, should not create a Microsoft 365 or Okta session for the caller, and should not grant general administrative access.

If the caller cannot use an approved factor, stop the standard unlock flow and use the organization's recovery process. Our helpdesk caller-verification checklist explains why falling back to personal questions does not resolve that gap.

Why put the workflow in one place?

Helpdesk operators often have to move among a directory, a verification step, an administrative console, and a ticket. Those handoffs make it easier for a weak phone script to become the justification for a sensitive action.

Fctr Portal keeps the selected employee, caller verification, policy-approved action, and record together. Microsoft Entra ID or Okta still governs the underlying account and permissions; Fctr connects the caller-verification decision to the supported action.

We do not think an account unlock should begin with the unlock button. It should begin by verifying the employee asking for it.

Sources