A plain definition, a simple picture, and the sentence worth remembering.

Okta is an identity platform. It keeps the official record of who your people are and decides whether each person may open each application. Normally, a person proves who they are by signing in with a password and, often, a second step such as a code or a tap on a phone. Those proofs are called authentication factors.

Sometimes the normal proofs are not available. The password is forgotten. The phone is lost. The account is locked after too many wrong attempts. In those moments the person needs a different path to prove their identity and regain access. A recovery factor is a method that Okta lets a user, or an administrator acting for the user, use to prove identity during that different path. Common examples include a link sent to an email address, a code sent to a phone, a prompt on an enrolled Okta Verify app, a security question, or a decision by a verified help desk agent.

The word “recovery” can mean several related things in Okta. It can mean resetting a forgotten password, unlocking a locked account, replacing a lost authenticator, or re-enrolling after an administrator clears someone’s authenticators. All of them share the same core idea: proving identity without the usual tools.

Why this deserves a whole guide

Most security effort goes into strengthening sign-in. Organizations roll out multi-factor authentication, then phishing-resistant keys, then passwordless. Yet attackers do not need to beat the strongest door if a weaker one is available. Recovery is that weaker door in many organizations. It deserves the same careful design as sign-in itself.

Recovery must solve two opposite problems at once, which is why it is hard.

Problem one: honest people get locked out

People forget passwords. Phones break, get stolen, or are replaced. People change phone numbers. They leave a company email account behind. They mistype a password a few times and trigger a lockout. In a large organization, these events are not rare accidents. They are daily routine. A company with ten thousand employees might see hundreds of recovery requests every week.

If recovery is slow or confusing, the cost is real. Work stops. Help desk queues grow. Frustrated users invent unsafe workarounds, such as sharing accounts or writing passwords on sticky notes. Leaders begin to resent security controls. A secure system that people cannot recover into is a system people will find ways around.

Problem two: attackers love recovery

For an attacker, recovery is an attractive target because it is designed to let someone in without the usual proofs. If the attacker can pass the recovery check, they skip the password, the second factor, and any phishing-resistant key in one move. Several tricks are common.

Impersonating the user. Calling the help desk with stolen personal details and asking for a reset.

Taking over a recovery channel. Hijacking a phone number through a SIM swap, or breaking into a personal email account, so that recovery messages arrive in the attacker’s hands.

Guessing weak answers. Security questions such as a mother’s maiden name or a first pet are often findable on social media or in leaked data.

Abusing automation. Triggering many recovery attempts to exhaust a user, fish for information, or find a weak account.

How recovery grew up, and why each generation was replaced.

The lesson of the history

Each generation of recovery replaced a method that attackers had learned to beat. Security questions were beaten by research. Text messages were beaten by SIM swaps. Help desk voices were beaten by social engineering. The trend is clear: the strongest recovery methods rely on something the person possesses and that is cryptographically bound, or on a human process with real verification, not on facts that can be looked up.

Where Okta fits

Okta’s recovery features have grown along the same path. The platform lets administrators choose which recovery methods are allowed, for which groups, under what conditions. Over time it has added stronger options, such as recovery through enrolled authenticators, notifications to users when sensitive events happen, and integration points for stronger identity verification. The specific names of settings and which features exist vary by Okta engine and release, so always confirm details in the current documentation for your organization.

Ten terms carry the whole topic. Each is explained with what it is, why it exists, and where you will meet it.

Three questions every recovery must answer

Whatever the method, every recovery flow answers three questions. First, who is asking? That is the claim of identity. Second, how do we know? That is the evidence, supplied by recovery factors. Third, what do we hand over? That is the outcome, such as a new password, an unlocked account, or a blank slate for enrolling new authenticators. The more valuable the outcome, the stronger the evidence should be.

They look similar, but mixing them up is the source of many design mistakes.

Authentication asks, “Can this person prove they are the owner right now using the normal tools?” It happens many times a day, for every user, and is built for speed and routine. Recovery asks, “The normal tools are gone, so can this person still prove they are the owner?” It happens rarely, for a few users, and is built for exceptions.

Because recovery is rare, organizations often treat it as a minor feature, configured once and forgotten. But recovery inherits a heavy responsibility: it must produce the same outcome as authentication (access to the account) with fewer tools available. That makes it inherently the more dangerous of the two.

The golden principle of equivalence

The most useful rule in recovery design is the principle of equivalence: recovery should be roughly as strong as the authentication it replaces. If an account needs a phishing-resistant key to sign in, then recovery should not be possible with a text message to a phone number. Otherwise the key is decoration, because an attacker simply takes the weaker road. The rule is easy to say and surprisingly often broken.

An overview of the main options Okta administrators can choose from, before we examine each one closely.

A strength comparison

This table is a simplification, and real strength depends on context and configuration. But it shows the pattern: factors tied to a person’s possession of a protected device sit higher than factors tied to facts, phone numbers, or mailboxes the person does not fully control.

A map of every part involved when someone recovers an account in Okta.

The diagram below shows a simplified model. It is a teaching picture rather than an exact internal blueprint of Okta, but it captures the roles that matter. A user who needs to recover starts at the sign-in page. Okta consults the recovery rules, which decide which factors are allowed. The chosen factor produces proof. If proof is accepted, the user record is updated, notifications are sent, and everything is written to the log, where monitoring tools can watch it.

flowchart LR
  USER["User who needs to recover"] --> SIGNIN["Okta Sign-In Page"]
  SIGNIN --> RULES["Password Policy and Recovery Rules"]
  RULES --> FACTORS["Recovery Factors: Email, Phone, Okta Verify, Security Question"]
  RULES --> ADMIN["Admin and Help Desk Path"]
  FACTORS --> UD["Universal Directory User Record"]
  ADMIN --> UD
  RULES --> NOTIFY["End User Notifications"]
  UD --> LOG["System Log"]
  LOG --> SIEM["Security Monitoring and Alerts"]
    

Walking through the boxes

User. The person who needs to regain access. They might be a real employee, or an attacker pretending to be one. The system cannot assume which.

Sign-in page. The entry point. Self-service options such as a “Forgot password” or “Unlock account” link appear here when rules allow them.

Password policy and recovery rules. The decision center. Administrators define, per group and sometimes per network condition, whether recovery is allowed and which factors may be used. These rules are the main place where security and convenience are balanced.

Recovery factors. The sources of evidence: email, phone, an authenticator, or a security question. Each one produces a proof, such as a link click or a code entry.

Admin and help desk path. The human route. A trained agent with delegated permissions can reset passwords or authenticators after checking identity. This path bypasses the self-service factors, so it must be controlled just as carefully.

Universal Directory. The user store, where the outcome of recovery lands: a new password, an unlocked status, or cleared authenticators.

End-user notifications. Messages sent to the account owner after sensitive changes. These are the safety net that lets a real owner shout “that was not me.”

System Log. The permanent diary. Recovery events are recorded here with who, what, when, and from where.

Security monitoring. Tools or teams that watch the log and raise alerts when recovery behaves unusually.

The most common recovery journey, from clicking “Forgot password” to choosing a new one.

Self-service password reset, often shortened to SSPR, lets users help themselves without calling anyone. It is popular because it is quick for users and removes a large share of the help desk workload. Behind the friendly page, Okta follows a careful sequence.

sequenceDiagram
  participant U as User
  participant O as Okta
  participant F as Recovery Factor such as Email
  U->>O: Select Forgot password
  O->>O: Check the recovery rules for this user and network
  O->>F: Send a time limited proof such as a link or code
  F-->>U: Proof arrives
  U->>O: Present the proof
  O->>O: Verify the proof and apply any extra checks
  O-->>U: Allow choosing a new password
  O-->>U: Send a notification that the password changed
    

Step by step

A quiet detail: not revealing too much

A well-designed recovery page does not reveal whether an account exists. If an attacker types a name and the page says “no such user,” the attacker learns which usernames are real. A better page gives the same neutral message in both cases, such as “If this account exists, instructions have been sent.” This detail protects privacy and slows attackers who are hunting for valid accounts. Check how your org behaves, since settings and product versions influence it.

Two other recovery journeys that look similar from the outside but solve different problems.

Account unlock

To protect against password guessing, Okta can lock an account after too many wrong attempts. Locking is good for security but can strand a real user who simply mistyped. Self-service unlock lets the user prove identity through an allowed factor and regain access without staff. The flow resembles password reset, but the outcome is different. An unlock does not change the password. It only lifts the lock, so the user can try again with the password they remember.

Administrators decide whether self-service unlock is allowed and with which factors. An organization that is worried about attackers triggering lockouts to annoy staff, a trick called a denial-of-service lockout, may prefer smarter lockout rules combined with easy unlock.

Authenticator recovery

The third journey is the one Priya faced in our opening story. She remembers her password. She cannot satisfy the second factor because the device that held her authenticator is gone. She needs a way to replace the authenticator. There are three typical routes.

What happens after a reset

When authenticators are reset, the account is in a delicate moment. For a short time, the account has little or no strong second factor enrolled. Enrollment policies decide what the user must do next. A careful design makes that moment as short and as protected as possible. For example, require that enrollment happen immediately at the next sign-in, from a trusted network, with a notification sent to the user and manager.

The last row deserves special attention. Resetting authenticators can be even more dangerous than resetting a password. A password reset gives the attacker access once. A fresh attacker-controlled authenticator can give them a lasting foothold, because it looks like a normal strong factor afterwards.

The human route is necessary, flexible, and the favorite target of skilled attackers.

Self-service cannot handle everything. People lose every authenticator, lose access to their email, or work for an organization that prohibits self-service for sensitive accounts. For these cases, a human administrator or help desk agent resets the account. In Okta, administrators with the right role can reset passwords, unlock accounts, and reset authenticators for users in the groups they are allowed to manage. Okta lets organizations limit exactly which users an administrator can touch and which actions they can perform, a practice called delegated administration.

flowchart TD
  A["Caller asks for a reset"] --> B["Help desk starts a strong identity check"]
  B --> C{"Identity confirmed by a trusted method?"}
  C -->|"No"| D["Decline and escalate to security"]
  C -->|"Yes"| E{"Privileged account?"}
  E -->|"Yes"| F["Require manager approval and a delay or in person check"]
  E -->|"No"| G["Proceed with a standard reset"]
  F --> G
  G --> H["Reset password or authenticators and record the ticket number"]
  H --> I["Notify the user and the manager"]
    

The identity check is everything

The weakest point of admin-assisted recovery is how the agent decides the caller is genuine. Poor methods include asking for date of birth, employee number, or the manager’s name. These facts are easy to find on professional networking sites, in leaked data, or on the company directory. Better methods rely on something the impostor cannot easily obtain.

Make the agent’s life easier, not harder

Help desk agents are often evaluated on speed and politeness. Attackers exploit that. A good process removes the burden of judgment from the agent. It gives a clear script, a checklist that does not bend, and the authority to say “I cannot do that until the manager confirms.” Pressure tactics such as urgency, anger, or name-dropping should be named in training as warning signs rather than reasons to hurry.

Follow a recovery from the first click to the final log entry, and see what changes along the way.

What data is involved

One lesson stands out. The recovery email address and phone number are themselves valuable. If an attacker can change the recovery email or phone on an account they already half-control, they can set up a permanent route back in. Treat changes to recovery data as security events, not as ordinary profile edits.

What an administrator decides, in plain language, in a sensible order.

Configuring recovery is mostly about making a series of deliberate decisions. The screens you use differ between Okta Identity Engine and Classic Engine and between releases, so this chapter maps the decisions rather than reciting menu names. In general, recovery settings live around the password policy and its rules, around authenticator settings such as email and phone, and around administrator roles and notification settings.

The key settings to understand

Policies are where recovery stops being an idea and becomes enforced behavior.

In Okta, recovery behavior is controlled by policies that contain rules. A policy applies to a set of users, usually chosen by group. Inside the policy, rules are checked in order. The first rule that matches the user and the situation decides what is allowed. This ordering is powerful, because it lets you write a strict rule for sensitive groups at the top and a general rule for everyone else underneath.

What a rule can look at

A sample layering

Notice how the table follows the principle of equivalence. The accounts that are most powerful have the hardest recovery. The accounts that are least risky have the easiest. And a stricter rule applies when the request comes from a place the organization does not recognize.

Do not forget the default rule

Every policy ends with a catch-all rule. If you do not look at it, it may be more permissive than you want. Review the default rule as carefully as the specific ones. A lenient default can undo the care you put into the top rules whenever a user falls through a gap, such as someone not in any of the groups you expected.

The most common recovery factor in the world, with strengths and weaknesses that surprise many teams.

Email is the default recovery factor on most websites. The user asks for recovery, Okta sends a message to the address on file, and the message contains a link or a code. Clicking the link or entering the code proves that the person controls that mailbox.

Why email works well

Almost everyone has email. It needs no special hardware. Messages are quick. Users understand it. For a standard workforce account with ordinary sensitivity, email recovery is often a reasonable foundation when combined with other protections.

Where email goes wrong

The mailbox is the new account. Anyone who controls the recovery mailbox can reset the password. So the security of an Okta account silently depends on the security of the mailbox. If that mailbox is a personal account with a weak password and no strong second factor, the Okta account is only as safe as that.

Company email is a circular trap. If the recovery email goes to the company mailbox, and the company mailbox is itself protected through Okta, then locked-out users cannot read their recovery email. The circle must be broken with an alternate address, another factor, or an assisted path.

Forwarding and delegation. Mail rules that forward messages, or delegates who can read the mailbox, can leak recovery links to people who should not have them.

Stale addresses. People leave old addresses behind. An old personal email that nobody guards can be taken over by a stranger, or even re-registered by someone new after the provider recycles it.

Phishing the link. A criminal can send a fake “reset your password” email that looks like Okta’s, trying to trick users into approving or entering details on a lookalike page.

Making email safer

Convenient, familiar, and increasingly discouraged for anything important.

Phone-based recovery sends a short code to a registered mobile number, either as a text message or as an automated voice call. The user reads the code and types it into the recovery page. It feels modern and personal, since people carry their phones everywhere. Unfortunately, the technology underneath was never designed for strong security.

How attackers beat phone recovery

SIM swapping. An attacker persuades a mobile carrier to move the victim’s phone number to a SIM card the attacker controls, often by impersonating the victim at a store or on a support call, or by bribing an insider. From that moment, calls and texts, including recovery codes, go to the attacker.

Message interception. Text messages travel through telecom systems with weaker protections than modern encrypted apps. Determined attackers have intercepted them through compromised carriers or malware on the phone. In 2018, Reddit publicly reported that attackers had intercepted text-message codes for some employees, which is often cited as an example of this risk.

Number recycling. When a person gives up a number, carriers eventually assign it to someone else. If an old number is still registered as a recovery factor, the new owner may receive recovery codes.

Social engineering the user. A caller pretending to be support may ask the user to read out a code that just arrived, which is actually the real recovery code.

When phone recovery is still acceptable

For low-risk accounts and users who have no better option, phone recovery is far better than no recovery at all, and it is better than nothing for customers who will not install anything. If you keep it, reduce the risk. Add a second proof. Alert users on every use. Restrict it for privileged groups. Ask for number changes to be confirmed. And treat it as a stepping stone toward stronger methods instead of a permanent destination.

Using something the person truly possesses, bound by cryptography, as the proof.

Okta Verify is the authenticator app from Okta. When enrolled on a user’s phone or computer, it can act as a recovery factor: Okta sends a push prompt or asks for a code, and the user confirms using the device. Because the app is tied to a cryptographic key stored on that device, an attacker cannot easily reproduce the proof from a distance. This is a major step up from phone numbers and security questions.

Why device-bound factors help

A device-bound factor shifts the attack from “convince a carrier, a mailbox provider, or a person” to “steal the actual device and defeat its screen lock.” That is a much more expensive and risky attack. It also usually produces clear evidence: the user will notice that their phone is missing.

The catch: recovery needs a second authenticator

Here is the central difficulty. If a user lost the device that held their only authenticator, then that authenticator cannot help them recover. Strong recovery therefore depends on having another credential in reserve: a second device, a hardware security key, or a recovery code stored safely. This is why organizations that care about recovery insist on at least two enrolled authenticators per person.

Other strong options

Hardware security keys and passkeys. A second FIDO2 authenticator is the gold standard of backup, and the standards behind it resist phishing as well. These are discussed in detail in a companion guide on WebAuthn and FIDO2.

Recovery codes. Some systems let users store one-time codes in a safe place, like a safe deposit box or a password manager. Each code works once. They are a last-resort lifeline, but if stored carelessly they become a weak spot.

Verified delegates or sponsors. For contractors or customers, a sponsor who vouches for the person can be a practical recovery factor in some designs.

The oldest self-service factor, and the one most security teams now try to retire.

A security question is a prompt, such as the name of your first pet or the city where you were born, with an answer the user chose in advance. When the user forgets their password, they answer the question to prove identity. The idea is simple and cheap, which explains why it spread so widely.

Why the idea does not hold up

Answers are guessable. Many questions have a small set of likely answers. A guess about a first pet or a favorite color may succeed after a handful of tries.

Answers are findable. Birthplace, school, parents’ names, and pet names often appear on social media, public records, family trees, and old data leaks.

Answers are reused. People pick the same answers for many websites. A leak at one site hands attackers the answers for all the others.

Answers are forgettable. Real users often cannot remember exactly what they typed years ago, such as whether they wrote the full street name or an abbreviation. So the factor frustrates honest users while only slowing determined attackers.

Answers are not secret. Unlike a password, the “secret” is a fact about the person. It cannot be changed when it leaks. You cannot change your birthplace.

If you must keep them

Some organizations still have security questions because of legacy systems or user populations that cannot use anything else. In that case, reduce harm. Use them only as an additional check beside a stronger factor, never alone. Encourage users to treat the answer like a password: a long random phrase that is not a true fact. Disable them for privileged accounts. And plan a retirement path as stronger factors reach more users.

When there is no password to reset and the strongest keys are in use, recovery looks different.

As organizations adopt passwordless sign-in and phishing-resistant authenticators, the classic “forgot password” journey disappears. There is no password to forget. But recovery does not vanish. It changes shape. The question is no longer “how do I reset my password?” It becomes “how do I replace the authenticator I lost?” And because these users are protected by strong methods, their recovery must be strong too, or the whole design is undone.

flowchart TD
  A["User lost their main authenticator"] --> B{"Has a second strong authenticator?"}
  B -->|"Yes"| C["Sign in with it then remove the lost one"]
  B -->|"No"| D{"Standard or privileged user?"}
  D -->|"Standard"| E["Verified help desk reset then fresh enrollment"]
  D -->|"Privileged"| F["Escalated process with approval and strong proofing"]
  C --> G["Enroll a replacement authenticator"]
  E --> G
  F --> G
    

Principles for passwordless recovery

Consider what an attacker sees. If a user signs in with a phishing-resistant key, the attacker has nothing to phish. The attacker pivots to recovery. If recovery is a short email and a text message, they win. If recovery needs a second strong authenticator or a rigorous human check, they have gained nothing. This is why recovery is called the true test of a passwordless program.

The accounts that can change everything need the strictest way back in.

Not all accounts are equal. The account of a casual user can read a few documents. The account of an Okta super administrator can change policies, reset other people’s authenticators, and add new applications. If an attacker takes over an administrator account through recovery, they control the front door of the entire organization. For that reason, privileged accounts deserve a recovery design of their own.

Rules that fit privileged accounts

The break-glass account

A break-glass account is a special emergency administrator account, kept for the day all normal routes fail. Perhaps a policy mistake locked every administrator out, or the usual authentication service is down. The account is protected by multiple hardware keys held in separate safes, and its credentials are never used day to day. Any sign-in at all triggers an immediate alert, because there should be no ordinary reason to use it. Test it regularly, in a planned drill, so you know it works before an emergency.

Separating who can reset from who can be reset

Delegated administration should prevent lower-level agents from resetting higher-level accounts. A help desk agent should be able to reset ordinary staff but not the administrators who manage the help desk itself. Without this separation, attackers who trick a front-line agent could reset a powerful account and climb the ladder in one jump.

A tour of the ways recovery gets attacked, and the defenses that fit each.

Attackers study recovery closely because it is a consistent shortcut. The table below lists the major threats and the matching defenses. Notice how many of them depend on process and people rather than technology alone.

Defense in layers

No single control stops all of these. A practical design stacks layers. Strong factors reduce the chance an impostor passes the check. Policy conditions raise the bar when something looks unusual. Notifications give real owners a chance to object. Delays slow attackers who depend on speed. Logging and alerting catch what the earlier layers miss. And regular drills keep humans sharp.

The human layer

Technology can verify possession of a device, but only people can notice that a caller sounds off. Train agents to expect manipulation. Teach the common tricks: urgency, authority, sympathy, and flattery. Give them tools that do the checking for them, and a culture where a refusal is respected rather than punished.

The most documented way recovery is attacked, and the most preventable with good process.

Social engineering means manipulating people rather than breaking technology. The help desk is a natural target because its purpose is to help, and because it has the power to reset accounts. Attackers prepare carefully. They learn the target’s name, role, and manager from public profiles. They may call from a spoofed number, use urgency such as a looming meeting, and sometimes already hold partial credentials from an earlier phishing campaign.

What public reports have shown

In 2023, security teams, including Okta’s own, publicly warned about a pattern in which attackers phoned IT service desks, impersonated employees, and persuaded agents to reset multi-factor authentication for highly privileged accounts. Okta published guidance describing the tactic and recommending stronger verification for such requests. Around the same period, it was widely reported that a major casino and hospitality company suffered a serious disruption after attackers allegedly impersonated an employee in a call to the help desk. Details differ between reports, so treat these as examples of a pattern and check the original sources.

Anatomy of a typical attempt

Defenses that work

You cannot defend what you cannot see. Make recovery loud.

Recovery is rare for each person but frequent across an organization, and its quiet nature helps attackers. Good monitoring turns hidden attacks into visible events. There are two audiences: the account owner, who needs a notification, and the security team, who needs logs and alerts.

End-user notifications

Okta lets administrators enable messages to users about sensitive account events. Typical examples include a password change, a new authenticator enrollment, an authenticator reset, and a sign-in from a new device. These messages are the cheapest and most effective tripwire in recovery. If a real user receives “your authenticator was reset” and they did not ask for it, they can report it within minutes. Make the message clear and give a simple way to report: a button or an address that goes to the security team.

Events worth watching in the log

Metrics for the program

More numbers worth tracking include the share of users with two or more authenticators, the number of resets on privileged accounts, the number of suspicious recoveries reported by users, and the share of recoveries that used weak factors. A falling use of weak factors and a rising share of self-service recoveries with strong factors are signs of a healthy program.

Getting alerts to people

Send log events to your security monitoring platform and set alerts for the highest-value events above. Okta also provides automation options such as Event Hooks and Workflows, which can open tickets or notify managers when certain events occur, subject to which event types are available in your org. Route alerts to a team channel that someone monitors, not to one person’s inbox.

Reliable shapes that many successful programs share.

How the patterns fit together

The tiered approach sets the shape. The two-authenticator rule keeps most recoveries out of human hands. Equivalence ensures that no door is weaker than the others. Notifications and scripts guard the human path. Cooling-off periods blunt the attacker’s speed. Break-glass accounts and drills prepare the organization for the worst day. Together they form a living program, not a one-time configuration.

Mistakes seen again and again, so you can skip them.

Every recovery design buys something and costs something. Here is the honest ledger.

Trade-offs to think through

Convenience versus assurance. The easiest recovery is the least safe. The safest is the slowest. The craft is choosing the right point for each group of users. A retail customer who forgot a password can tolerate a lighter check than a payroll administrator.

Self-service versus human judgment. Self-service is fast and scalable but cannot notice that something feels wrong. Human help desks can notice, but they can also be fooled. Many designs use self-service for ordinary cases and humans for exceptions.

Privacy versus verification. Strong identity proofing, such as document checks and video, collects personal data. Treat it carefully, limit retention, and tell users what you collect and why.

Speed versus cooling-off. A delay protects against attackers who need to act fast, but irritates genuine users in a hurry. Apply delays where the account is powerful, not everywhere.

Uniform rules versus tailored rules. A single policy is easy to explain and audit. Tailored rules fit the risk better but multiply what you must test and maintain.

A checklist to read before every change and every incident review.

Best practices

• Treat recovery as part of authentication, and review them together.
• Follow the equivalence principle. Recovery should not be weaker than the sign-in it replaces.
• Require two authenticators per person and report regularly on those who have only one.
• Retire security questions and restrict phone codes, especially for privileged groups.
• Use tiered rules by group and network, with the strictest rules for administrators and finance staff.
• Keep recovery tokens short-lived and single-use, and use neutral messages that do not reveal whether an account exists.
• Enable user notifications for password changes, authenticator enrollment, and resets.
• Give the help desk a fixed script, call-backs to known numbers, and a second approver for privileged resets.
• Scope administrator roles tightly so agents cannot reset accounts above their level.
• Protect changes to recovery contact details with strong proof and notifications.
• Monitor the log for resets, post-reset enrollments, and bursts of recovery requests.
• Maintain and test a break-glass account, and drill the help desk with simulated social-engineering calls.
• Review the default rule and all policies at least twice a year.

Common mistakes

Six stories showing how recovery plays out in practice. The designs are illustrative teaching examples. The public incidents are summarized in general terms, so check the original sources for details.

Most recovery trouble falls into a few families. A calm checklist solves most of it.

A simple troubleshooting routine

Short answers to the questions that come up most often.

If you remember nothing else, remember the box below.

Recovery is the quiet half of identity security. Everyone sees the sign-in page, but attackers study the recovery page, the help desk script, and the recovery email address. Okta gives administrators a rich set of recovery factors and controls, from email and phone to enrolled authenticators and delegated help desk roles. The craft lies in choosing the right ones for each group, making recovery as strong as the sign-in it replaces, and making every recovery loud enough that real owners and security teams notice.