In one sentence: it is a rule that says which sign-in methods a group of people can or must set up in Okta.

Let us take the words one at a time. Authentication means proving you are who you claim to be. An authenticator is a thing you use to prove it, such as a password, a code on your phone, a physical security key, or a fingerprint scan. When a company asks people to use more than one kind of proof, we call it multi-factor authentication, or MFA.

Enrollment is the one-time setup of an authenticator. Think of getting a new bank card: before you can use it, you must activate it and choose a secret number. In the same way, before you can approve a sign-in on your phone, you must first enroll your phone with Okta by installing an app and linking it to your account.

A policy is a bundle of rules. An authenticator enrollment policy is therefore a bundle of rules about enrollment. It does not decide when you are asked to prove yourself. It decides which proofs you are allowed or required to set up.

The three settings you will see again and again

For each authenticator, an enrollment policy lets you pick one of three settings. They are simple, and they carry most of the meaning of the whole feature.

Why this matters so much

A company that gets enrollment right ends up with people who all have strong, working ways to prove who they are, plus a backup if a phone is lost. A company that gets it wrong ends up with people who cannot set up anything at 8:55 on a Monday morning, or with a mixture of weak methods that attackers love. Enrollment is the foundation. Every later security rule stands on the authenticators that people actually have.

A short tour of the vocabulary. Every term here comes back later in the guide.

Two flavors of Okta

You will hear about the Okta Classic Engine and the newer Okta Identity Engine, often shortened to OIE. They are two generations of the sign-in brain inside Okta. The idea of an enrollment policy exists in both, but the screens and names differ. In the Classic Engine you may see this feature called a multifactor enrollment policy and talk about “factors.” In the Identity Engine the feature is called an authenticator enrollment policy and the talk is about “authenticators.” This guide uses the newer words and points out differences where they matter.

Where enrollment fits in a person’s day

Most people meet enrollment only twice: on their first day, and the day a policy changes or a phone is replaced. In between, they simply use the authenticators they already set up. That rarity is exactly why enrollment feels confusing. Nobody practices it. A clear, friendly enrollment experience, backed by a sensible policy, is one of the best things an identity team can build.

The most common beginner mistake is mixing up the different kinds of Okta policies. Here is how to keep them straight.

When someone signs in to an application through Okta, several different rulebooks take part. Each one answers a different question. Imagine a theme park. One office decides which wristbands each ticket type may receive. Another decides which rides require showing the wristband. A third decides how long the wristband stays valid before it must be renewed. These are three separate jobs, even though they all involve the same wristband.

flowchart TD
  A["Person signs in to an app"] --> B["Global session policy - Is there a valid session?"]
  B --> C["Authentication policy for the app - What proof is needed?"]
  C --> D{"Does the person have an eligible authenticator enrolled?"}
  D -- Yes --> E["Challenge the authenticator"]
  D -- No --> F["Authenticator enrollment policy - What may or must be set up?"]
  F --> G["Person enrolls an allowed authenticator"]
  G --> E
  E --> H["Access granted"]
    

Reading the diagram

The sign-in starts at the session layer, which checks whether the person is already signed in. Next, the application’s own authentication policy says what kind of proof it wants. If the person already has a suitable authenticator, Okta simply challenges it. If not, Okta consults the enrollment policy to see what the person is allowed to set up, and invites them to do so. Only after that does access open.

Only a few moving parts are involved. Knowing their names lets you reason about almost any situation.

The picture below is a simplified mental model, not a literal map of Okta’s insides. It shows how the pieces relate. On the left are the people and groups. In the middle is the set of enrollment policies. On the right is the catalog of authenticators your organization has turned on, and underneath is the record of what each person has actually enrolled.

flowchart LR
  subgraph People["People and Groups"]
    U1["User"]
    G1["Group - Everyone"]
    G2["Group - Admins"]
    G3["Group - Contractors"]
  end
  subgraph Policies["Enrollment Policies - checked in priority order"]
    P1["Policy 1 - Admins"]
    P2["Policy 2 - Contractors"]
    P3["Default Policy"]
  end
  subgraph Catalog["Authenticator Catalog"]
    A1["Okta Verify"]
    A2["Phone"]
    A3["Email"]
    A4["Security Key or Biometric"]
    A5["Password"]
  end
  E[("Per-user Enrollment Records")]
  U1 --> G1
  U1 --> G2
  G2 --> P1
  G3 --> P2
  G1 --> P3
  P1 --> A1
  P1 --> A4
  P2 --> A1
  P3 --> A1
  P3 --> A2
  P3 --> A3
  P3 --> A5
  A1 --> E
  A2 --> E
  A3 --> E
  A4 --> E
  A5 --> E
    

The parts, one at a time

Why the default policy deserves extra care

The default policy is the safety net underneath everything. If someone is not covered by any other policy, the default policy applies. That means a careless change to it can affect nearly every person in the company at once. Treat it the way a building manager treats the master key: use it deliberately, review it regularly, and never leave it lax simply because “special” policies sit above it.

Okta supports many kinds of authenticators. Each has its own strengths, weaknesses, and best uses.

The list of available authenticators grows over time, and some depend on your plan. The ones below are the most common. For each, think about three questions: how easy is it for people, how strong is it against attackers, and what happens when the person loses their device?

Strength is a spectrum

Open a policy and you will find a short list of ingredients. Here is what each one means.

An authenticator enrollment policy is built from a handful of parts. Once you can name them, the Admin Console will no longer look intimidating.

What the three settings really mean

One policy, many people

A single policy covers everyone in its assigned groups. This means that an edit to a policy is an edit for every person it covers. Before you change a popular policy, ask yourself how many people will feel it and whether you have told them. A change that takes thirty seconds to make can create thirty thousand support questions.

When a person belongs to several groups, Okta must pick exactly one policy. Here is the rule it follows.

Okta reads the list of enrollment policies from the top, in priority order. For each policy, it asks, “Is this person in one of the groups assigned to this policy?” The first policy that answers yes is the winner, and Okta stops looking. The default policy sits at the bottom and answers yes for everyone, so somebody always wins.

flowchart TD
  S["Person needs enrollment settings"] --> Q1{"In a group of Policy 1?"}
  Q1 -- Yes --> W1["Apply Policy 1 and stop"]
  Q1 -- No --> Q2{"In a group of Policy 2?"}
  Q2 -- Yes --> W2["Apply Policy 2 and stop"]
  Q2 -- No --> Q3{"In a group of Policy 3?"}
  Q3 -- Yes --> W3["Apply Policy 3 and stop"]
  Q3 -- No --> D["Apply the Default Policy"]
    

An example in words

Suppose Meera is a systems administrator who also belongs to the “Everyone” group. The list has three policies in this order: “Administrators,” then “Contractors,” then the default. Okta checks the first policy and finds that Meera is in the Administrators group. It applies the Administrators policy and never even looks at the others. If the order were reversed, with a policy for “Everyone” above “Administrators,” Meera would be matched by the broader policy first, and the stricter administrator rules would never reach her.

Groups do not nest in Okta

In many systems, putting a small group inside a big group lets the big group’s rules flow down. Okta’s own groups do not work that way. If “Contractors” is a group inside “Everyone,” that does not make contractors members of “Everyone” for the purpose of policy matching. If you need a person to be covered, they must be a direct member of an assigned group. Group rules, which add people to groups automatically based on their profile, are the usual way to keep this tidy.

Follow one new employee, Kavya, as she meets her enrollment policy on her very first morning.

Kavya’s account was created by the company the day before. Her profile places her in the “Employees” group, and the policy for that group says that Okta Verify is Required, the email authenticator is Optional, and security questions are Disabled. Here is what happens when she signs in for the first time.

sequenceDiagram
  participant U as Kavya
  participant O as Okta Sign-in
  participant P as Enrollment Policy
  participant V as Okta Verify App
  U->>O: Signs in with her first password
  O->>P: Which authenticators apply to this person
  P-->>O: Okta Verify required and email optional
  O->>U: Please set up Okta Verify
  U->>V: Installs the app and scans the setup code
  V->>O: Confirms the link between the app and the account
  O->>U: Setup complete and access continues
    

What is different for existing employees

When a company changes a policy, people who already work there meet the change at their next opportunity. If a new Required authenticator is added to the policy, an employee who has not enrolled it is guided through setup the next time they sign in. If an authenticator is moved to Disabled, people will stop being offered it, and any rules that depended on it may need updating.

Setup methods you will see

People can often set up the same authenticator in more than one way. For Okta Verify, for example, a person on a computer may scan a code with their phone’s camera, or may ask Okta to send a setup link to their email or phone when they cannot scan. Offering more than one path makes enrollment friendlier, especially for people who work from a single device.

For most companies, Okta Verify is the star of the show. It earns its own chapter.

Okta Verify is a free app that runs on phones, tablets, and some computers. After a person links it to their account, it can do several jobs. The enrollment policy controls whether the app is required, and the authenticator’s own settings control which of these jobs are available.

The problem of “push fatigue”

Attackers sometimes steal a password and then send sign-in attempts over and over, hoping the real person will get tired of the alerts and tap “approve” just to stop them. This is called push fatigue or an MFA bombing attack. A number challenge helps because the person must actively match a number shown on the screen they are really using, which a distant attacker cannot see. For people with powerful access, many companies also move away from simple push to methods that cannot be approved by accident.

Why Required is usual for Okta Verify

Because Okta Verify supports so many methods, it fits as the single Required authenticator for most employees. The enrollment policy then adds one or two Optional backups, and the authentication policies decide which Okta Verify methods each application will accept. This keeps the setup short for the person while leaving security teams plenty of control.

These older and simpler authenticators are easy for everyone, which is both their charm and their weakness.

Phone: text message and voice call

Okta sends a short code to a phone number, either by text message or by an automated voice call. Nearly everyone has a phone that can receive these, so enrollment is simple and the cost of explaining it is small. The weakness is that phone numbers can be taken over. In a trick called a SIM swap, an attacker convinces a phone company to move your number to their own device and then receives your codes. Messages can also be intercepted in some situations, and fake websites can trick a person into typing the code into the wrong place.

Because of these risks, many companies keep the phone authenticator as Optional for general staff, use it only as a backup, or phase it out for high-risk groups. Voice calls are especially helpful for people whose phones cannot run apps.

Email

An email authenticator sends a code or link to an address. It is excellent as a recovery method, because almost everyone has an inbox, and it works from any device. Its strength is only as good as the mailbox. If someone’s email account is weakly protected, then anyone who breaks in there can reach their Okta account too. A company-owned work mailbox that is itself protected by strong sign-in is a reasonable choice. A personal free email address is a riskier one.

Security question

A security question asks something like “What was the name of your first school?” The trouble is that many answers can be found on social media or guessed by an attacker who knows a little about you. For this reason, many security teams set this authenticator to Disabled. If it must be used, it belongs in the lowest tier, never as the only proof for a valuable account.

Some authenticators are built so that a fake website cannot fool them. For your most valuable accounts, these are the ones to prefer.

A phishing attack tricks a person into handing secrets to a fake website that looks real. Most proofs, including passwords and typed codes, can be given away this way. A phishing-resistant authenticator solves the problem differently: it checks the real address of the website before it responds. If the site is a fake, the authenticator simply refuses, and the person cannot be tricked even if they want to be.

Why not simply require them for everyone?

Strong methods have real costs. Hardware keys must be bought, shipped, and replaced. Built-in biometrics need compatible devices. People who share computers, work on old machines, or use only a basic phone may not be able to use them. A good policy therefore matches strength to risk. The people who could cause the most harm if their accounts were stolen, such as administrators, executives, and finance approvers, get the strongest methods first. Others follow as hardware and habits allow.

One size does not fit all. Smart companies build a small number of policies, each shaped for a clear group of people.

The best way to start is to list the kinds of people in your company, then decide for each kind what they need. Aim for fewer policies rather than more. Every extra policy is one more thing to explain, test, and keep tidy.

Principles that keep designs healthy

Changing an enrollment policy touches real people. A calm rollout is mostly good preparation and kind communication.

A policy change is simple to make and hard to undo gracefully. If you make something Required for everyone in one afternoon, the help desk will be flooded, executives will be annoyed, and people will find workarounds that weaken your security. A staged rollout avoids these problems.

flowchart LR
  A["Inventory what people use today"] --> B["Design target policies"]
  B --> C["Pilot with a small friendly group"]
  C --> D["Wave one - one department"]
  D --> E["Wave two - more departments"]
  E --> F["Update the default policy for everyone"]
  F --> G["Review and tune"]
  C -- "Problems found" --> B
    

Turning off an old method is harder than adding a new one, because people have come to rely on it.

Many companies begin their journey with text messages or security questions and later want to move to stronger methods. The danger is that if you simply flip a method to Disabled, people who rely on it may be locked out of their own accounts. A careful retirement takes time and follows a clear order.

Phones get lost, dropped in lakes, and upgraded. A good enrollment policy plans for the day the main authenticator disappears.

Imagine that your only house key falls down a drain. If you have a spare with a neighbour, you are fine. If you do not, you need a locksmith, a lot of proof that you live there, and an expensive afternoon. Authenticators work the same way. The best protection against lockouts is simple: make sure every person has more than one way in.

flowchart TD
  L["Person loses their phone"] --> Q{"Another authenticator enrolled?"}
  Q -- Yes --> U["Sign in with the other authenticator"]
  U --> N["Enroll the new phone and remove the old one"]
  Q -- No --> H["Contact the help desk"]
  H --> V["Help desk verifies identity with a strong process"]
  V --> R["Administrator resets the person's authenticators"]
  R --> E["Person signs in and enrolls again"]
  E --> N
    

Make the backup path the easy path

The right-hand side of the diagram, the help desk path, is slow, costly, and risky. Each help desk reset is also a chance for an attacker to trick a tired support agent. The goal of a good enrollment policy is to push as many people as possible down the left-hand path, where the person helps themselves safely.

Reset versus replace

When someone gets a new phone, there are two paths. If they still have the old device, they can usually enroll the new one while signed in, then remove the old one. This is clean and needs no administrator. If the old device is gone, an administrator must reset the person’s enrolled authenticators so the person can enroll again from scratch. Administrators should treat a reset as a serious act, because it removes the very protection the account depends on.

Diagrams are tidy. Real companies are not. These awkward situations show up sooner or later.

People without smartphones

Some employees do not own a smartphone, are not allowed to bring one to work, or work in places where phones are forbidden. For them, an app-based authenticator is not an option. Provide an alternative, such as a hardware security key, a built-in biometric on a company laptop, or a phone voice call. Do not simply make the app Required for everyone and hope for the best.

Shared computers and kiosks

When several people share one computer, device-based authenticators and browser-stored passkeys become confusing, because the credential might belong to the device rather than the person. In such settings, a hardware key carried by each person, or a phone-based approval, often works better. Decide deliberately how shared stations will work before you require a method they cannot use.

Travelers and limited connections

A traveler may land in a country where their phone has no signal, their text messages do not arrive, or push notifications are slow. Methods that work offline, such as a one-time code shown in the app, become valuable. Make sure travelers know about them before they go.

Accessibility

People who are blind, have limited use of their hands, or have other disabilities may find certain methods hard. A fingerprint scanner can be impossible for some users, and a code on a tiny screen can be unreadable for others. A good policy offers more than one accessible path and tests the enrollment screens with assistive tools. Accessible design is not a bonus. It is part of whether the policy works at all.

Contractors and short-term staff

Contractors often use their own devices, may be employed by another company, and might leave in a few weeks. Give them a dedicated group and policy with methods that work on personal devices. Make sure their accounts expire or deactivate when the contract ends, so their enrolled authenticators do not linger.

Rehires and name changes

When a person returns to the company, they may have an old account with old authenticators still attached. Decide whether to clear those enrollments before reactivation. When a person changes their name or email address, check that their authenticators still work and that the person knows how to update them.

The instant when a person sets up a new authenticator is when an attacker has the best chance to slip one in.

Think about what enrollment means: Okta is about to trust a new device or method as proof of identity. If an attacker can enroll their own phone on someone else’s account, they hold a permanent, legitimate-looking key. So enrollment itself must be protected, not only the sign-in that follows it.

The main risks

Defensive habits

You cannot manage what you cannot see. A few simple measures show whether your policies are working.

Okta keeps a diary called the System Log. It records many things, including when a person enrolls an authenticator, when one is removed, when an administrator resets a person’s authenticators, and when a policy is created or changed. Each entry says who did what, when, from where, and with what result. This diary is your main source of truth for enrollment questions.

Events worth watching

Numbers worth tracking

Alerts that earn their keep

Raise an alert when an administrator account enrolls or removes an authenticator, when several resets happen within a short time, when an authenticator is added immediately after a password reset, or when someone changes a policy for a large group. Write a short guide for each alert that says what it means and what to check first.

Clicking through the console works for a few policies. Larger teams reach for automation.

Okta provides programming interfaces, called APIs, that let software read and change policies and authenticators. An API is a menu of requests one program can send another. Through these interfaces, a team can list all enrollment policies, read each policy’s settings, see which authenticators exist in the catalog, and create or update policies from a script. The common reasons for doing this are consistency, speed, and review.

What people commonly automate

Teams often write scripts to export the current policies for audit, to compare policies between a test org and the live org, to count how many people in each group have enrolled each authenticator, and to remind people who have not yet enrolled. A configuration tool, such as the Okta provider for Terraform, can describe policies in files and apply them. Whichever route you choose, keep the credentials for these tools in a secrets vault and grant them only the permissions they need.

Experienced teams keep reaching for the same shapes, and avoiding the same traps.

Anti-patterns to avoid

A quick checklist, followed by the errors that appear in nearly every organization at least once.

Mistakes that appear again and again

When someone says “I cannot set up my authenticator,” a calm, step-by-step check finds the cause quickly.

Troubleshooting enrollment is like tracing a leak in a pipe: start at the tap and follow the water back. Ask what the person sees, which policy applies to them, what that policy allows, and what the application demands.

Common symptoms and likely causes

Here are typical situations where enrollment policies do real work, described as everyday scenarios.

Every design choice trades one thing for another. Here is the honest picture of enrollment policies.

Trade-offs to weigh

Auditors do not only ask whether the system works. They ask who is in charge, who can change it, and how you know.

Governance means the habits and rules by which an organization keeps important systems under control. Enrollment policies are an important system, because they decide how strong everybody’s sign-in will be. A policy without governance may work today and be broken tomorrow, with nobody knowing why.

Questions an auditor is likely to ask

Separation of duties

The principle of separation of duties says that no single person should be able to make and approve a sensitive change alone. A common arrangement is that the identity team proposes policy changes, the security team reviews them, and a change approver authorizes the date. If one person holds all three roles, a mistake or a bad decision has no second pair of eyes.

A simple change routine

Technology does not run itself. A clear owner for every part keeps small issues from becoming big ones.

Enrollment policies sit between several teams: identity engineers who build them, security teams who set the strength, the help desk who support people, and communications staff who explain changes. Without a plan, each team can assume another is handling a problem. A good operating model puts a name next to every responsibility.

Keeping up with change

Okta regularly adds authenticators, renames screens, and retires older options. Subscribe to Okta’s release notes, set a regular time to review what has changed, and test updates in a preview org. Also review your own policies at least twice a year: roles change, devices change, and what felt right last year may feel clumsy or weak today.

Thinking honestly about cost

The Okta feature itself may be included in your plan, but strong authenticators have costs elsewhere. Hardware keys must be bought and replaced. Text messages and voice calls cost money per message. Help desk time costs money, and so does training. When you compare options, count all of these. A cheap method that causes constant lockouts may cost more in the end than a pricier method that people can use without help.

Concepts stick best when you watch them move. Here are three ordinary days at a company that uses enrollment policies well.

Walkthrough one: a policy change reaches existing staff

On Tuesday, the security team decides to make a second authenticator Optional but strongly encouraged for all staff. They edit the policy for the “Employees” group and change the email authenticator from Disabled to Optional. They also add a short banner message explaining why. On Wednesday morning, employees see a gentle prompt after sign-in inviting them to add a backup. Those who ignore it are not blocked. By the end of the month, sixty percent have added a backup, and lockout calls have dropped.

Walkthrough two: a lost phone on a business trip

Rohan is in another country when his phone is stolen. He opens his laptop and finds that his Okta account is asking for approval on the phone he no longer has. Luckily, during onboarding he also enrolled a laptop biometric as a backup. He uses it to sign in, removes the stolen phone from his account, and enrolls his new replacement phone when it arrives. The help desk is never involved, and the stolen phone can no longer approve anything for him.

If Rohan had enrolled only one phone, the story would be harder. He would have to contact the help desk from abroad, convince them of his identity through a careful process, wait for an administrator to reset his authenticators, and then set up everything again. That is exactly why encouraging a second authenticator is such a valuable part of enrollment policy.

Walkthrough three: a new contractor and the wrong policy

A contractor named Sana joins a project on Monday. Her account is created in the “Contractors” group, but the group rule that adds her to a “Project Alpha” group has a delay. For a few hours she is matched only by the Contractors policy, which allows phone voice calls. Her project manager notices that Project Alpha requires a stronger method. The identity team checks the group rule, finds the delay, and adds her manually. On her next sign-in, the stricter policy applies, and she enrolls the stronger method.

flowchart TD
  A1["Manager notices wrong settings"] --> A2["Check the person's groups"]
  A2 --> A3{"In the expected group?"}
  A3 -- No --> A4["Fix the group rule or add the person"]
  A3 -- Yes --> A5["Walk the policy list from the top"]
  A5 --> A6["Find the first matching policy"]
  A4 --> A7["Person signs in again"]
  A6 --> A7
  A7 --> A8["New enrollment prompt appears"]
    

What these stories teach

Keep this page handy. Every term used in this guide is explained here in a line or two.