Capability

Help-desk verification

What it does: Callers prove who they are before any reset or enrollment.

WIC

In short

Help-desk verification means the help desk confirms who is calling before it resets a password or adds a new MFA factor. Without it, a convincing phone call can undo strong sign-in controls. MFA enrollment policies and phishing-resistant authenticators in Okta define what a recovery enrollment must meet.12

Book a callHow Okta does it ↓
4
attack types it helps against

What it is, and the attacks it stops

Strong MFA protects the sign-in, but the help desk can become the way around it. A caller who sounds confident and knows a few personal details can ask for a reset, and a rushed agent may say yes.

Help-desk verification puts a fixed identity check in front of every reset or enrollment. The check does not depend on how convincing the caller sounds.

That check makes attacks such as these harder:

1

Impersonating an employee

A caller says they are a user who lost their phone and asks for a new factor to be added. A fixed check means the story alone is not enough.

2

Impersonating a manager or an executive

A caller pulls rank and pressures the agent to skip the steps. The check applies to every caller, whatever their title.

3

Answers taken from public information

Questions such as a birth date or an employee number can be found online or in earlier breaches. A check that relies on them can be passed by an attacker.

4

Urgency and pretexts

A caller claims to be traveling, locked out before a meeting or on a deadline. Urgency is a reason to follow the process, not to skip it.

Before and after rollout

Without
With
WithoutA confident caller with a few personal details gets a reset.
WithEvery caller passes the same identity check before a reset or a new factor is added.2
WithoutThe agent decides case by case whether the caller sounds genuine.
WithA written process decides - the agent does not have to judge the caller.
WithoutNobody can tell afterwards why a reset was approved.
WithEach reset follows the same steps, so the team can review what was checked.

How Okta does it

Help-desk verification is a process backed by Okta configuration. Okta sets which factors users enroll in, and your help desk follows the check before it changes anything.

1

A user contacts the help desk

A user reports a lost device, a forgotten password or a locked account.

2

The agent verifies the caller

The agent completes the agreed identity check before touching the account. The check should rely on something the caller has, not only on something they know.

3

The user re-enrolls a factor

The user enrolls a new factor under the MFA enrollment policy that applies to their group.2

4

Policy sets the level

Okta supports phishing-resistant factors such as Okta FastPass and FIDO2 (WebAuthn). Where the risk justifies it, require those for the new enrollment.13

WIC
Who it protectsStaff, contractors, admins
MFA enrollment policiesThese policies, configured in Okta, dictate which MFA factors the user must enroll in, depending on the group they are assigned.2
Okta Verify and FastPassOkta Verify on the user's device supports Okta FastPass when app sign-in policies allow it, which can be used as a strong factor when a user re-enrolls.3
Phishing-resistant authenticatorsCurrently, FIDO2 (WebAuthn) and Okta FastPass are Okta's phishing-resistant MFA factors.1
Admin configuration in OktaAdmins configure recovery, enrollment and authentication settings in the Okta Admin Console, as described in the Okta Help Center.12

How Zelto implements it

The technology behind Okta is the ready and proven half - Zelto defines the process your help desk follows. We write the identity check with your team and plan roll outs in groups to minimize risk/impact. We start with the accounts attackers want most.

Typical rollout

  1. Map how the help desk resets access today

    We list the requests the help desk handles, the tools agents use and the checks they run.

  2. Define the identity check

    For maximum protection, we agree on checks that do not rely on information an attacker can find. We write them as a short script that fits your help desk tools.

  3. Align Okta enrollment with the process

    We configure the MFA enrollment policies in Okta so that a reset ends with a new factor that meets your policy.

  4. Train and pilot with one group

    We start with a group of admins or IT. Before wider use, we agree on an owner on your side and run call scenarios with the help desk. We also agree when to switch over and when to roll back.

  5. Review and tighten

    We review a sample of resets and the exceptions on a schedule, and reduce the exceptions as much as possible.

Pitfalls we plan for

A caller says they are an executive and need access right now.

−The agent skips the check because the caller is senior or the request sounds urgent.

+The same check applies to every caller, and the agent has a clear way to escalate without being blamed for saying no.

A caller asks for a new factor to be added to their account.

−The agent adds a factor after a few questions on the phone, and the caller keeps access afterwards.

+The agent completes the identity check first, and the user enrolls the new factor themselves under the MFA enrollment policy.

The check relies on questions about the user.

−Use a birth date, an employee number or a manager's name, which an attacker can often find.

+Use a check that relies on something the caller has or that another person confirms, as agreed with your team.

Admin and privileged accounts call the help desk.

−Treat them like any other user, although they are the accounts attackers want most.

+Add a stronger check for these accounts, for example confirmation by a second person, and review those resets first.

Want a help desk that cannot be talked into a reset, without a rollout that stalls?

We review how your help desk handles resets today. Then we tell you what to change first.

Book a call30 minutes, no slides. We look at how your help desk verifies callers today.

Sources

Official Okta and Auth0 documentation and primary legal sources.

  1. 1Phishing-resistant authenticationOkta Help Center
  2. 2About MFA enrollment policiesOkta Help Center
  3. 3Okta Verify and Okta FastPassOkta Help Center