Losing access is common, and how it is fixed decides how safe the company stays.

People forget and devices disappear

Every company that uses Okta has people who forget passwords. Passwords can be hard to remember, especially when they are long and unique, and people return from holidays unable to recall the one they chose. Second-step devices are lost just as often. A phone is dropped in water, upgraded to a new model, stolen on a train or simply reset to factory settings. When that happens, the person is locked out of everything that Okta protects: email, chat, the HR system and more. Without a smooth way to recover, work stops and the help desk is flooded with requests.

The recovery process is a favourite target

Attackers know that the easiest way past a strong lock is often to persuade someone to open it. Instead of breaking a password, a criminal may phone the help desk pretending to be a worried employee and ask for a reset. If the help desk resets the password or removes the second factor without checking carefully, the attacker walks in without ever defeating any technology. Security people call this social engineering. So reset processes need to be easy for the real owner and hard for everybody else.

Before resetting either one, understand what each one is for.

The password

A password is a secret that only the person should know. It is the first step in most sign-ins. Okta stores it in a protected form, never as plain readable text, and checks what the person types against that protected form. Resetting a password means replacing the old secret with a new one that the person chooses, so that the old one stops working.

The MFA factor

MFA stands for multifactor authentication. It means proving identity with more than one kind of proof, usually something you know (a password) plus something you have (a phone) or something you are (a fingerprint). In Okta, these extra proofs are called authenticators or factors. Common examples include a push notification in the Okta Verify app, a code sent by text message or phone call, a code sent by email, a security question, a physical security key and a fingerprint or face check built into a device.

Resetting an MFA factor means removing the person’s existing enrolled factor so that they can set up a new one. Usually the person must then enroll again the next time they sign in. The old device or code no longer works.

A small dictionary for the rest of the guide.

The best reset is the one where nobody else needs to be involved.

What it is

Okta calls this feature self-service account recovery. It lets active users reset their own passwords, or unlock their own accounts, without contacting administrator support. Administrators control it with a rule inside the password policy, which decides whether recovery is allowed, which methods can start it and what extra checks are required.

How a typical self-service reset feels to the person

sequenceDiagram
  participant U as User
  participant O as Okta
  participant A as Trusted Authenticator
  U->>O: Forgot password, enters username
  O->>U: Offers allowed recovery methods
  U->>O: Chooses a method
  O->>A: Sends challenge such as push or code
  A-->>U: Challenge appears on trusted device or inbox
  U->>O: Approves or enters the code
  O->>U: Asks for a new password
  U->>O: Sets new password
  O-->>U: Password updated, old one invalid
        

Administrators decide how generous or strict recovery will be.

In the Okta Admin Console, recovery settings are found with the password authenticator, in the area for authenticators under the Security menu, where the password policy can be edited. Menu names can change between releases, so treat the path as a guide and read the labels on your own screen. The password policy contains rules, and one of the key choices in a rule is whether people are allowed to reset their own passwords or unlock their own accounts.

The knobs administrators can turn

Locked accounts

A user whose account is in a locked-out state generally cannot complete a self-service password reset until the lock is cleared. Depending on how your organisation configured things, the person may be able to unlock the account through self-service or may need an administrator. Because the exact behaviour depends on your policy and engine, test it with a pilot user instead of guessing.

When self-service is not possible, a trusted person steps in.

What administrators can do

An administrator or authorised help desk agent can find a person in the Okta Admin Console directory and start a reset from that person’s profile. The common options are easy to understand when you think about the goal: get a new, private password into the hands of the real owner. In practice, the preferred way is to send the person a reset link by email so they choose the new password themselves. Another option is to set a temporary password that the person must change at next sign-in. Administrators can also expire a password so that the person is forced to choose a new one the next time they sign in.

flowchart TD
  A["Person asks help desk for a reset"] --> B["Verify identity using agreed checks"]
  B --> C{"Identity confirmed?"}
  C -->|No| D["Refuse and log the attempt"]
  C -->|Yes| E["Choose safest reset option"]
  E --> F["Send reset link to trusted channel"]
  F --> G["Person sets own new password"]
  G --> H["Record the action in a ticket"]
        

The second step needs its own recovery, because it is the part most often lost with a phone.

What a factor reset really does

When an administrator resets a person’s MFA factor, Okta removes the enrolled authenticator or authenticators from that person’s account. The old phone, app registration or code no longer works. The next time the person signs in, Okta asks them to enroll again, so they can register their new phone or a fresh authenticator. An administrator can usually choose to reset one specific authenticator or all of a person’s authenticators, depending on the situation and the labels shown in the console.

Why this is the riskiest reset

Think carefully about what a factor reset does from an attacker’s point of view. If a criminal already knows a person’s password and can persuade the help desk to remove the second factor, then the criminal can enroll their own device and become the new “second step”. That is exactly the attack the second factor was meant to prevent. For this reason many organisations apply stricter identity checks to MFA resets than to password resets, and sometimes require a manager’s approval or a video call.

The smoothest MFA recovery is the one that never needs the help desk.

A person who has enrolled in more than one authenticator can often recover without help. If the phone is lost but a security key or an email authenticator is still enrolled, the person can use it to sign in and then replace the lost one in their own account settings. This is why security teams encourage everyone to enroll in at least two different authenticators. One acts as the main method and another as a backup.

Choosing safe backups

Not all backups are equally safe. A hardware security key kept in a drawer is excellent. An authenticator app on a second device is good. A security question like “what is your pet’s name” is weak because the answer can often be found on social media. Administrators can limit which authenticators are accepted for recovery, so the weakest choices cannot become the easy path for an attacker.

A peek behind the curtain makes the behaviour easier to predict.

Password reset internals

When a reset begins, Okta checks the person’s account status and the password policy that applies to them. It then generates a short-lived, one-time token and links it to a challenge. Only when the person completes that challenge does Okta allow a new password to be set. The new password is checked against the policy rules for length, complexity and history, and then stored in a protected form. The old password is invalidated, and existing sessions may be handled according to the organisation’s settings.

Factor reset internals

When an authenticator is reset, Okta deletes the stored registration that linked the person’s account to that device or credential. That registration is what let the old phone prove itself, so once it is gone, the device is simply a stranger. The person’s account is then marked as needing enrollment, and the sign-in flow guides them through setting up a new authenticator.

flowchart LR
  A["Reset requested"] --> B["Check account status and policy"]
  B --> C["Issue one-time token or challenge"]
  C --> D["Person completes verification"]
  D --> E["Update password or remove old factor"]
  E --> F["Invalidate old secret or device"]
  F --> G["Write audit event"]
        

One-time and short-lived

Recovery links and codes are designed to work once and to expire quickly. This limits the damage if an email is forwarded or a message is read by the wrong person. If a link has expired or was already used, the person simply starts the process again.

Recovery is the doorway most criminals try first, so lock it carefully.

Fighting help desk impersonation

Help desk impersonation has become a well-known attack pattern. Criminals research a target, call the help desk with convincing details and an urgent story, and push the agent to skip steps. The defence is a firm, written procedure that agents are allowed, and expected, to follow even when the caller is stressed, angry or claims to be a senior executive. A procedure that every agent follows every time protects the agent as well as the company.

User enumeration

Recovery pages should not reveal whether a given username exists. Okta offers protection against user enumeration, so that an attacker cannot use the reset page to test which accounts are real. Keeping this protection on is a good default.

When a reset does not work, most causes are simple.

Numbers worth tracking

A high share of help desk resets usually means people have not enrolled backup methods, which is a training and onboarding problem. A sudden jump in resets, particularly of MFA factors, may point to an attack, so it is worth alerting on.

Teams that do this well share a few habits, and teams that struggle share a few traps.

Patterns that work

Traps to avoid

Put everything together into habits and pictures you can remember.

A short checklist

• Encourage every person to enroll in at least two different authenticators.
• Turn on self-service recovery for ordinary staff, with at least one strong method required.
• Use tighter rules for administrators and sensitive groups.
• Prefer an emailed reset link over setting a temporary password.
• Treat MFA resets as higher risk than password resets and verify more carefully.
• Notify the account owner after every reset.
• Review recovery logs regularly and alert on unusual spikes.
• Test the full recovery experience using a normal, non-administrator account.

Real-world pictures

Both paths have a place, and the best design uses each where it fits.

A sensible design makes self-service the normal path and keeps admin resets as a carefully guarded fallback. The result is fewer tickets, faster recovery and a smaller target for attackers.

Short answers to the questions beginners ask most often.

No. They are separate. Resetting a password changes only the secret you know, while an MFA reset removes enrolled authenticators so you can enroll new ones.

Common reasons are that self-service recovery is turned off for your group, you never enrolled a recovery method, or your account is locked. An administrator can check your policy and status.

If you enrolled a backup authenticator, sign in with it and replace the lost phone. If not, contact your help desk, who will verify your identity and reset the factor so you can enroll again.

It is less safe than an emailed reset link because the temporary password must be shared. If it is unavoidable, share it through a safe channel and force a change at first sign-in.

Some policies require an extra verification step with a different authenticator type, so that compromising a single channel is not enough to take over an account.

Reset links are designed to be single-use and short-lived. If it expired or was already used, request a new one.

They are better than nothing but weaker than push approvals or security keys, because text messages can be intercepted through tricks like SIM swapping. Use stronger methods for sensitive accounts.

By requiring identity verification, notifying the account owner, recording each action in a ticket and reviewing Okta’s System Log for unusual patterns.

Yes. Password policies are assigned to groups, so administrator groups can have stricter recovery requirements than ordinary staff.

Make sure everyone enrolls in at least two authenticators early, allow self-service recovery with strong methods and remind people how the forgot-password flow works.

We started with a building manager who must replace lost keys and fobs without letting a burglar in, and we ended with a clear picture of how Okta handles the same problem. A password reset replaces the secret you know, and an MFA factor reset removes the device or method you have so you can enroll a new one. People can recover on their own through self-service account recovery when they have enrolled suitable methods, and administrators can step in when they cannot. Because every reset deliberately bypasses a normal lock, each one must be verified, logged and, where possible, announced to the account owner. Encourage multiple authenticators, choose strong recovery methods, treat MFA resets with extra care and watch the logs for anything unusual.