Start with the plain meaning of each word, then see where the custom part fits.

An authenticator is anything a person uses to prove their identity during sign-in. A password is one. A code sent by text message is another. A fingerprint check on a phone is a third. Okta lets administrators decide which authenticators are available, which ones users must set up, and which ones are required to open a given application.

A custom authenticator is an authenticator that you bring or build yourself, instead of using one of Okta’s standard choices. Two common ideas are worth knowing at a basic level. The first is a custom app authenticator, where your own mobile app can receive and answer sign-in approval requests through Okta. The second is a custom one-time-password authenticator, where tokens that make short-lived codes can be added to Okta even if they come from another source.

This guide keeps to a foundation-level view. It explains what these options are, why they exist, how they fit into Okta’s policies, and what to plan before using them. It does not walk through developer code, since the exact steps change with each release and are best taken from Okta’s current documentation.

Three questions this guide answers

Everyday phrases and what they really mean

Identity teams use short phrases that can confuse newcomers. When someone says “enroll an authenticator”, they mean a person sets it up for the first time so Okta knows about it. When they say “challenge”, they mean Okta is asking the person to prove themselves right now. When they say “verify”, they mean the person answered the challenge correctly. Knowing these three words makes most documentation much easier to read.

Standard authenticators solve most needs. Custom ones exist for the cases they do not reach.

For many years, the main way to sign in was a username and a password. The weakness of that approach is simple. Passwords can be guessed, copied, phished, or leaked. Once a password is known, an attacker can walk in as the user. Multi-factor authentication, often shortened to MFA, adds a second proof so that a stolen password alone is not enough.

Okta offers many ways to supply that second proof. For most organizations, a few of them are plenty. But real companies have history, rules, and special groups of people. Those differences create gaps that no standard list can fully cover.

Where the standard list falls short

Why this matters even for small teams

Some teams believe authenticator choices only matter to giant enterprises. In truth, the questions begin as soon as one group of people cannot use the default option. A small clinic whose staff share tablets, or a factory whose workers may not carry phones, faces the same puzzle on a smaller scale. Writing down the need early costs an afternoon. Untangling a rushed choice after it has spread to hundreds of people costs months.

The habit is cheap to start. List your groups of users, note what device each group can realistically use, and mark which apps are most sensitive. That one page already shows where a standard authenticator will do and where a custom one might be justified. It also prepares you for audits, mergers, and new regulations, all of which ask the same basic questions.

A short vocabulary list makes everything that follows easier to read.

Identity security has its own words. Most of them describe what kind of proof is used, and where in the process it is used. The table below puts the key terms next to a simple picture to remember them by.

Why two proofs beat one

An attacker may steal a password from a leaked list on the internet. It is much harder for the same attacker to also steal your phone, your hardware token, or your fingerprint. Because the second proof is a different kind of thing from the first, breaking one does not break the other. That is the whole logic behind multi-factor authentication.

Strong, stronger, strongest

Not every authenticator is equally strong. A code sent by text message is better than nothing, but it can be intercepted in some attacks. A push approval on a trusted phone is stronger. A security key that checks the real website address before responding is stronger still, because it resists phishing. When you choose or build a custom authenticator, you are also choosing a level of strength, so keep that in mind.

Common misunderstandings

You will meet two words for nearly the same thing. Knowing why avoids confusion.

Older Okta documentation and screens often use the word factor for a way of proving identity. Newer material, especially for Okta Identity Engine, uses the word authenticator. In everyday conversation, people swap them freely. The difference is partly one of design. Authenticators are managed as a clear list in one place, and policies point to that list.

What the newer model adds

Why this helps custom authenticators

Because policies work with the catalog instead of with individual tools, a custom authenticator does not need a separate set of rules. Once it appears in the list, administrators can place it in an enrollment policy and an authentication policy exactly as they would a standard one. This keeps the design tidy and lets the same security thinking apply to both.

To know when to go custom, first see what already comes in the box.

Okta provides a range of authenticators that cover many situations. The exact list depends on your edition and version, but the families are stable. Knowing them helps you judge whether a custom option is truly needed, or whether a standard one will do.

Asking the right question first

Before you build or import anything custom, ask whether a standard authenticator can meet the same need. Often it can. A company that thought it needed a custom approval app discovered that Okta Verify, with a few policy tweaks, did the job. Going custom adds work to build, test, secure, and support, so it should be the answer only when the standard ones truly fall short.

A few words you will hear in meetings

Colleagues may say “possession proof” when they mean something you hold, such as a phone or token. They may say “assurance level” when they mean how sure the system is that a person is real. They may say “step-up” when a person who is already signed in is asked for a stronger proof before a sensitive action. And they may say “break glass” when they mean an emergency account that bypasses normal rules, kept locked away for disasters.

None of these words is hard. Each simply names a piece of the picture you have already seen. When a new term appears, ask which of the four buckets it belongs to: enrollment, verification, policy, or recovery. Placing the word in a bucket usually reveals what it means and who is responsible for it.

Here is the full picture of how a person, their authenticator, and Okta work together at sign-in.

The design has four main parts. The first is the person and the device or token they hold. The second is the authenticator itself, whether it is a standard one or a custom one. The third is Okta, which holds the policies and makes the decision. The fourth is the application the person wants to open. Okta stands in the middle, asking for proof and judging the answer.

flowchart LR
  subgraph User["User Side"]
    P["Person"]
    D["Phone or token"]
    CA["Custom authenticator"]
  end
  subgraph OktaZone["Okta"]
    EP["Enrollment policy"]
    AP["Authentication policy"]
    CAT["Authenticator catalog"]
    LOG["System Log"]
  end
  APP["Protected application"]
  P --> D
  D --> CA
  CA -->|"Enroll and respond to challenges"| CAT
  EP --> CAT
  AP --> CAT
  P -->|"Sign in request"| AP
  AP -->|"Access granted"| APP
  CAT --> LOG

The components, one by one

Why the middle matters

Everything passes through Okta’s policies. That means custom authenticators do not bypass your security rules. They join them. A sign-in that uses a custom authenticator is judged by the same authentication policy, recorded in the same log, and managed in the same console as a sign-in that uses a standard one.

At a basic level, two ideas cover most custom authenticator talk. Each solves a different problem.

Okta describes custom authenticators in a few forms, and the names can change with releases. Two ideas appear again and again. One lets you place sign-in approval inside your own mobile app. The other lets you bring in tokens that produce one-time codes. Both plug into the same catalog and the same policies.

Custom app authenticator, in simple words

Imagine your company already has a mobile app that customers or staff use all day. With a custom app authenticator, that app can also act as the place where a sign-in approval arrives. A person gets a notification, opens the familiar app, and taps to approve. They do not need to install and learn a separate authenticator app.

Custom one-time-code authenticator, in simple words

A one-time code is a short number that is valid for a very short time, often about thirty seconds, and then useless. A token generates these codes. With a custom code authenticator, the codes made by your own tokens are accepted by Okta. The person reads the code from the token and types it in when asked.

Before an authenticator can help at sign-in, Okta must learn that it exists and trust it. That first meeting is called enrollment.

Enrollment is the setup step. During enrollment, the person and the authenticator are linked to the person’s Okta account. A secret or a key is created, one side keeps it, and Okta stores what it needs to check answers later. After enrollment, the authenticator is ready to be used whenever Okta asks for proof.

sequenceDiagram
  autonumber
  participant U as User
  participant O as Okta
  participant A as Authenticator or app
  U->>O: Sign in with password
  O->>U: Policy says set up an authenticator
  U->>A: Open the app or token and start setup
  A->>O: Register and share what Okta needs
  O-->>A: Confirm registration
  O->>U: Ask for one test proof
  U->>A: Approve or read a code
  A->>O: Send the answer
  O-->>U: Enrollment complete

Why Okta asks for a test proof

After registration, Okta usually asks for one real proof to confirm that everything works. This protects the person from a nasty surprise later. Without it, someone could finish setup, believe they were protected, and discover only on a busy morning that the authenticator never worked.

What can go wrong at enrollment

At every sign-in, Okta asks a question and checks the answer. Here is the path in plain steps.

When a person tries to open an application, Okta first checks the authentication policy for that app. The policy says which proofs are needed in this situation. Okta then challenges the person using one of the authenticators they enrolled. If the answer is right, the person gets in. If it is wrong or missing, Okta refuses or asks for another proof.

flowchart TD
  S["Person opens an application"] --> P{"Authentication policy checked"}
  P --> C["Okta issues a challenge using an enrolled authenticator"]
  C --> R{"Is the response correct?"}
  R -->|"Yes"| G["Access granted and session started"]
  R -->|"No"| F["Retry, use another authenticator, or be denied"]
  F --> L["Event written to System Log"]
  G --> L

Step by step

Time matters for codes

Many one-time codes depend on the clock. The token and Okta both calculate a code from the current time, so they must agree within a short window. If a token’s clock drifts, its codes stop matching. Hardware tokens that drift are one of the most common reasons for a “wrong code” complaint when the person typed everything correctly.

Here is how your own mobile app can become a place where sign-in approvals happen.

The idea is that a company already owns a mobile app. With the help of Okta’s developer tools for mobile devices, that app is taught to speak Okta’s language for sign-in approvals. After that, a person can enroll the app as an authenticator. When Okta wants proof, it sends a notification to the app, and the person approves inside it.

The moving parts

What happens inside

During enrollment, the app creates a pair of keys, which are two linked secrets. One stays safely on the phone and is never shared. The other, the public one, is given to Okta. Later, when the person approves a request, the app uses the secret key to sign the answer. Okta checks the signature with the public key. If it matches, Okta knows the answer came from the enrolled device.

Adding a check on the phone

Many setups let the app ask the person to unlock with a fingerprint, a face check, or a device passcode before the approval is sent. This adds another kind of proof, something you are or something you know, on top of the thing you hold. It protects against a stolen phone left unlocked on a desk.

This option brings tokens that produce short codes into Okta, including tokens you already own.

A token is a small device or a program that makes a new code every so often. Behind the scenes, each token holds a secret value called a seed. The token mixes the seed with the current time, or with a counter, and produces a short number. Okta holds a copy of the same seed, does the same math, and checks whether the numbers match.

How tokens get into Okta

Why seeds must be guarded

The seed is the heart of the token. Anyone who learns it can make the same codes forever, without holding the device. That is why the file of seeds is highly sensitive. Store it in a protected place, share it with as few people as possible, and delete copies once the upload is done and confirmed.

An authenticator in the catalog does nothing until a policy says who may or must use it.

An authenticator enrollment policy answers a simple question for each group of people: which authenticators may they set up, which must they set up, and which are not allowed at all? Policies are made of rules, and rules are matched to groups. A person gets the rule of the first policy that fits them.

Three common settings

A worked example

Keep the policy readable

Policies grow messy when every small group gets its own special rule. Aim for a handful of clear groups, each tied to a real need, with a short description of why. A new administrator should be able to read the list and understand the intent without calling anyone.

Enrollment decides what people can use. Authentication policy decides what each door actually demands.

An authentication policy is attached to an application, or a group of applications. Its rules say how strongly a person must prove themselves to get in. The same person may face a light check for a low-risk tool and a firm check for payroll. Custom authenticators take their place in these rules just as standard ones do.

What a rule can look at

The idea of assurance

Assurance is a word for how sure Okta is that the person is real. A password alone gives low assurance. A password plus a phone approval gives more. A password plus a phone approval that also needed a fingerprint gives more still. Policies let you set the minimum level for each application, so that sensitive apps always get the strongest proof.

Where custom authenticators fit

Each custom authenticator is placed in the policy as a possible proof. For example, a rule may say that sign-in to the warehouse system requires a password plus a possession proof, and the allowed possession proofs are the custom token and the custom app. The rule does not care how the proof was built, only that it meets the required kind and strength.

The security world is slowly moving away from passwords. It helps to know where custom authenticators stand in that move.

Passwordless sign-in means a person proves who they are without typing a password at all. Instead, they use something they hold, such as a phone or a security key, along with something they are, such as a fingerprint. The idea is simple. If there is no password, there is no password to steal, guess, or phish.

A related idea is phishing resistance. Phishing is a trick where an attacker builds a fake website that looks real and persuades people to type their secrets into it. A phishing-resistant authenticator is built so that the trick fails. For example, a security key checks the real website address before it answers, so a fake site gets nothing useful.

Strength compared in plain words

What this means for custom choices

A custom one-time-code authenticator is useful, but codes can be typed into a fake site, so treat them as moderate strength. A custom app authenticator can be stronger when it signs approvals with a key that stays on the device and asks the person to unlock the phone. Even so, it should be judged carefully. When the stakes are very high, such as administrator access, prefer authenticators that are known to resist phishing, and use custom ones for the groups where they truly fit.

A proof is only part of the story. Where it comes from, and on what device, also matters.

Imagine two sign-ins with the same correct phone approval. One comes from a company laptop in the head office. The other comes from an unknown computer in a faraway country at three in the morning. A good system does not treat them the same. Context is the name for these extra clues, and policies can use them to ask for more or less proof.

Common context clues

How context works with custom authenticators

Context is judged by the authentication policy, not by the authenticator. That means a custom authenticator benefits from the same checks as a standard one. A policy can say, for instance, that a sign-in from an unmanaged device must use a stronger possession proof, or that a sign-in from an unusual place must repeat the challenge. The authenticator provides the proof, and the policy provides the judgment.

Devices that your custom app lives on

If you build a custom app authenticator, the phone itself becomes part of your security story. A phone with an old operating system, a broken lock screen, or a tampered setup is a weaker home for a secret key. Decide which phones you will support, and whether you will refuse approvals from devices that look unsafe. Keeping the supported list short makes testing and support much easier.

A custom authenticator becomes part of your defense. A weak one becomes part of your attack surface.

Standard authenticators from Okta are built and tested by a large team. When you add a custom one, you take on part of that responsibility yourself. The good news is that the main risks are well understood, and a few steady habits cover most of them.

The main risks

Habits that protect you

The best authenticator on paper fails if people dislike it. Planning the human side is half the project.

People accept security when it is quick and clear, and resist it when it is slow or confusing. A custom authenticator must therefore be judged by how it feels in daily use. A secure design that makes people wait ten seconds at every sign-in will tempt them to find workarounds.

What good experience looks like

A sensible rollout plan

Every authenticator will eventually be lost, broken, or forgotten. A good plan makes that a small event, not a crisis.

People lose phones, drop tokens in water, and reset devices without warning. When that happens, they are locked out until a safe path lets them back in. The challenge is that the recovery path is itself a way in. If it is too easy, attackers will use it. If it is too hard, people will flood the help desk.

Common recovery paths

Rules for a safe help desk

You cannot manage what you cannot see. A few steady signals tell you whether your authenticators are healthy.

Monitoring means watching a system’s health so that you hear about trouble before your users do. Logging means keeping a written diary of what happened. For authenticators, the diary records enrollments, challenges, successes, failures, and resets. Okta’s System Log is the main place to read it.

Where to look

Metrics worth tracking

Alerts that earn their keep

Set alerts for events that deserve a human look: many failed challenges for one account, new enrollments on administrator accounts, resets outside business hours, and sudden jumps in push requests that nobody started. Keep the list short, so that each alert still feels important.

Instead of memorizing errors, learn a method: check the simple things first, and narrow down.

Most authenticator problems sit in one of four places: the person’s device, the network between the device and Okta, Okta’s own settings, or the policy. Ask what changed recently, since most surprises follow a change such as an app update, a new policy, or a phone upgrade.

Walkthrough 1: Push approvals do not arrive

Walkthrough 2: A token code is rejected

Walkthrough 3: A user cannot enroll

Walkthrough 4: Everyone fails at once

When many people fail at the same time, suspect something shared. Look for a recent app release, a policy change, a notification service outage, or a certificate that expired. Roll back the latest change if you can, and check the status page of your notification providers. A sudden group failure is rarely about the people.

No design is perfect. Here is an honest scorecard for custom authenticators.

Key trade-offs in plain words

A short method helps you decide whether a custom authenticator is the right move.

The decision is not about what is most advanced. It is about what meets the need with the least risk and effort. Walk through a few questions in order, and the answer often becomes clear.

A five-question method

A good plan turns a clever idea into something people can safely rely on.

Custom authenticators touch several teams at once. The identity team owns Okta. Developers own the mobile app. Security reviews the risks. The help desk answers the calls. Without a plan that names each team, the project stalls in the gaps between them.

Who does what

A project timeline in simple stages

Think about the whole life, not only the launch

Budget conversations often cover only the build. The true cost includes years of updates, support calls, token replacement, security reviews, and training. A simple honest estimate of the yearly running cost helps leaders compare a custom path with a standard one, and prevents unpleasant surprises in the second year.

A pattern is a proven way of solving a repeating problem. An anti-pattern is a popular mistake.

Patterns that work

Anti-patterns to avoid

A short field guide of habits that save time and avoid late-night incidents.

Best practices, in order of when you meet them

Mistakes that appear again and again

An authenticator that fails at sign-in locks people out of their work. Careful testing is not optional.

Testing means trying the system on purpose, in safe conditions, to find problems before real users do. For authenticators, the most important tests follow the whole life of a person’s use: setup, daily sign-in, mistakes, and recovery. A test plan that covers only the happy path will miss the problems that cause the most pain.

The tests worth running

Test environments

Where possible, test in a separate Okta environment that mirrors production but holds only test accounts. This lets you change policies freely without risking real sign-ins. Keep a small set of named test users for each group, so that results are repeatable from one round of testing to the next.

Test again after every change

When auditors visit, they ask how you prove who is signing in. Your authenticators are part of the answer.

Compliance means following rules set by law, customers, or the company itself. Frameworks for security, finance, and privacy often ask for strong authentication on sensitive systems, and for evidence that the controls work. Governance is the set of habits and records that make this evidence easy to produce.

Evidence auditors often ask for

Governance habits that help

Privacy in plain words

Authenticators can involve personal information. A custom app may hold device details, and a token record links a serial number to a person. Collect only what you need, protect it, and delete it when it is no longer required. Fewer stored details mean less to explain if a regulator asks.

Here are four common situations where custom authenticators earn their place. The companies are fictional teaching examples.

Public facts that give context

Multi-factor authentication has been recommended by many security agencies for years, because stolen passwords remain one of the most common causes of breaches. Okta, founded in 2009, built its business on connecting people to applications securely, and its authenticator catalog is one of its central features. The detailed setups of specific customers are not public, so the stories above remain fictional.

Quick answers to the questions that come up most often.

The whole guide in one place.

A custom authenticator lets an organization add its own way of proving identity to Okta, whether that is a trusted mobile app or a set of tokens it already owns. It joins the same catalog, policies, and logs as standard authenticators, which keeps security rules consistent. It is a useful tool for specific groups, and a costly one when used without a clear need.

A mental model to carry with you

When any authenticator question lands on your desk, sort it into one of four buckets. The first bucket is enrollment: how does a person and their device or token become trusted? The second bucket is verification: what happens at the moment of each sign-in? The third bucket is policy: who may use what, and which proof does each app demand? The fourth bucket is recovery: what happens when something is lost or broken?

Most confusing situations turn out to be a mix-up between buckets. A person who cannot set up their phone has an enrollment problem. A rejected code is a verification problem, often a clock or a typing issue. A user who sees the wrong prompt has a policy problem. A locked-out traveler has a recovery problem. Naming the bucket first tells you which logs to open and which team to call.

This model also helps when you explain the design to others. Managers care about policy because it is about risk. Support teams care about recovery because it is about volume. Developers care about enrollment and verification because they are about the app. A good identity architect speaks to all of them and keeps the plan written down.

A final word on the people behind the proof

Behind every sign-in is a real person trying to start their day, reach the tools they need, and get on with their work. Security that ignores this reality gets bypassed, resented, or quietly switched off. Security that respects it, by being quick, clear, and forgiving of honest mistakes, earns trust and keeps working for years.

For custom authenticators, this means three promises. First, make the common path fast, so that people barely notice the extra proof. Second, make the rare path safe, so that a lost phone or broken token never becomes an open door. Third, make the whole design easy to explain, so that a new colleague can read it in an afternoon and understand why each choice was made.

If you keep those promises, the technology becomes almost invisible, which is exactly how good security should feel. People sign in, do their work, and go home. The authenticator does its quiet job at the door, whether it is a standard one from Okta’s catalog or a custom one built for the special needs of your company.