To understand factors, first see the problem they solve.

The weakness of a single secret

For many years, a password was the only thing standing between an attacker and a person’s account. But passwords are easy to reuse, guess, steal, or trick out of people with fake login pages. When a password is the only proof, losing it means losing everything that account can reach.

The idea of asking for more

Security teams realized that requiring more than one kind of proof makes attacks far harder. If an attacker steals your password, they still need your phone or your fingerprint. This idea is called multi-factor authentication, often shortened to MFA. The word factor simply means one kind of proof of identity.

Different kinds, not just more of the same

The key detail is that the proofs must be of different kinds. Asking for two passwords is not truly multi-factor, because an attacker who can steal one can probably steal the other. The strength comes from mixing different categories, which is exactly what factor types are about.

Two simple definitions that the whole guide builds on.

A factor

A factor is a method a person uses to prove who they are. A typed password is a factor. Approving a prompt on a phone is a factor. Touching a physical security key is a factor.

A factor type

A factor type is the kind or category of that method. For instance, “phone app prompt” is a factor type, “one-time code from an authenticator app” is another, and “security key” is another. When a person sets up a method for the first time, this is called enrolling a factor of a certain type.

A note on naming

Okta has used slightly different words over time and across product versions. In some places, you will see the word factor. In newer setups, you will often see the word authenticator used for the same general idea. The concepts are very similar, so if you meet either word in Okta’s screens or documentation, treat them as close relatives. Exact names and availability depend on your organization’s setup and plan, so always check the current documentation for your own environment.

Almost every factor type falls into one of three families.

Something you know

These are secrets stored in your memory, such as a password, a PIN, or the answer to a personal question. They are easy to use and need no special device, but they can be guessed, shared, or tricked out of people.

Something you have

These are physical or digital items in your possession, such as a phone, a hardware security key, or a smart card. An attacker must get hold of the item itself, which is much harder than learning a secret remotely.

Something you are

These are traits of your body, such as a fingerprint or a face scan. They are convenient and difficult to copy, and they are usually checked by the device in your hand rather than sent across the internet.

flowchart TD
  F[Factor Types] --> K[Something you know]
  F --> H[Something you have]
  F --> A[Something you are]
  K --> K1[Password, PIN, security question]
  H --> H1[Phone, security key, smart card]
  A --> A1[Fingerprint, face scan]
        

A friendly map of the common choices before we explore each one.

Okta supports a wide range of factor types, and the exact list can vary with product version and plan. The common ones are shown below in simple terms. We will look closely at each in the chapters that follow.

The most commonly used factor in many Okta organizations.

What it is

Okta Verify is a mobile app made by Okta. Once installed and enrolled, it can prove a person’s identity in several ways. The exact options depend on your configuration, but they typically include approving a prompt, entering a short code, and, in newer setups, a device-based sign-in method that can work without typing a password.

Push approval

With push approval, Okta sends a notification to the person’s phone saying someone is trying to sign in. The person taps approve or deny. It is quick and pleasant, which is why people like it. Some setups also ask the person to match a number shown on the sign-in screen, which helps prevent accidental or tricked approvals.

One-time codes

The app can also show a short code that changes every few seconds. The person types this code on the sign-in page. This works even when the phone has no internet connection, which is handy when traveling.

Device-based sign-in

In newer setups, the app can act as a trusted proof that the real device is present, using a cryptographic key stored securely on it and unlocked by a fingerprint or face check. This approach is designed to be strongly resistant to fake login pages.

A simple, widely understood factor that works offline.

How these codes work

Many people use general-purpose authenticator apps that show a short numeric code, refreshed every thirty seconds or so. When the person enrolls, Okta and the app share a secret, which is set up once by scanning a picture on the screen. After that, both sides can calculate the same code at the same moment, so the person simply types the number from the app.

Why people like them

These codes work without a phone signal, do not rely on text messages, and are widely supported. They are generally stronger than codes sent by text, because there is nothing traveling over the phone network that an attacker could intercept.

The remaining weakness

Although these codes are decent, they can still be tricked out of people. If a fake login page asks for the current code, and the person types it quickly, the attacker can use it right away. For this reason, codes are good but not the strongest choice for the most sensitive accounts.

Among the strongest factor types available today.

What they are

A security key is a small physical device, often shaped like a USB stick, that you plug in or tap against your device. Many laptops and phones also have built-in biometric features, such as a fingerprint reader or face scanner, that work in the same family of methods. These approaches follow an industry standard commonly called FIDO2 or WebAuthn.

Why they are so strong

With these methods, a secret key is created and stored inside the device or key, and it never leaves. When you sign in, the device proves it holds the key, but only to the real website, because the proof is tied to the genuine web address. A fake login page cannot reuse it. This makes these methods highly resistant to phishing, which is one of the most common attack styles.

The trade-offs

Physical keys can be lost, so people need a backup key or another approved method. Rolling them out also costs money and requires some guidance. Despite this, many organizations use them for administrators and other high-value users, where the extra protection is well worth it.

sequenceDiagram
  participant P as Person
  participant K as Security Key or Device
  participant O as Okta
  P->>O: Start sign-in
  O->>K: Ask the key to prove it is genuine
  K->>P: Ask for a touch or biometric check
  P->>K: Touch or confirm
  K->>O: Proof tied to the real web address
  O->>P: Sign-in accepted
        

Convenient factors that work for almost everyone, with known weaknesses.

How they work

With these factor types, Okta sends a short code to a phone number or an email address that the person has registered. The person types the code to prove they control that phone or inbox. Voice works the same way, except the code is read aloud in a phone call.

Why they are popular

They need no special app and almost everyone already has a phone number and an email address. This makes them easy to roll out to large groups, including customers and people with limited technical skills. They also serve well as recovery or backup options.

Why they are weaker

Text messages can be intercepted, and attackers can sometimes trick a phone company into moving a number to a different device. Email accounts can themselves be compromised. And like other codes, these can be tricked out of people through fake pages or phone calls. For these reasons, they are generally considered weaker than app-based, device-based, or key-based methods.

The rest of the toolbox, each with its own role.

Security questions

A security question asks something personal, such as the name of your first school. The idea is that only you know the answer. In practice, answers are often guessable from social media or public records, and people may reuse them everywhere. Because of this, security questions are considered weak and are usually discouraged, except perhaps as a low-risk fallback.

Hardware tokens

Hardware tokens are small physical devices that display a changing code or generate one when pressed. They work without a phone and are popular in places where phones are restricted. They are fairly strong but, like codes in general, can still be tricked out of people on fake pages.

Smart cards

A smart card is a physical card with a secure chip, often used in government, defense, and highly regulated businesses. The person inserts or taps it and enters a short PIN. These are strong, but they need card readers and a management process.

Third-party and custom factors

Many organizations already use another authentication product, such as a corporate token system. Okta can often connect to these so people can keep using what they know while Okta manages the overall sign-in. Some setups also allow custom connections to specialized services.

A single idea that explains most of the differences in strength.

What phishing is

Phishing is a trick where an attacker builds a fake login page that looks real and persuades people to type their details into it. The attacker then uses what was typed, immediately, on the real site. It is one of the most common ways accounts are taken over.

Factors that can be handed over, and factors that cannot

Some factors involve the person reading or typing something, such as a password or a code. These can be handed to a fake page without the person realizing. Other factors never expose a secret to the person at all. Instead, the device does the proving, and the proof is tied to the real website. A fake page cannot use that proof. Factors of this second kind are called phishing resistant.

flowchart LR
  A[Fake login page] --> B{Factor type used}
  B -->|Password or typed code| C[Attacker captures it and reuses it]
  B -->|Device-based or security key| D[Proof is tied to the real site]
  D --> E[Attacker gets nothing useful]
        

A factor is only useful once people have registered it.

The enrollment moment

Before a factor can be used, the person must enroll it. For a phone app, this might mean installing the app and scanning a picture. For a security key, it means registering the key. For a text code, it means confirming a phone number. Okta records which factors each person has set up.

Enrollment policies

Administrators can decide which factor types are required, which are optional, and which are not allowed at all. For example, a company may require a strong phone-based factor for everyone, allow a security key as an option, and disable security questions entirely. These choices are often applied to different groups of people differently, so stricter rules can protect powerful accounts.

Life of a factor

A factor moves through simple states. It begins as not set up, becomes pending while the person completes setup, and finally becomes active when ready to use. It may later be reset or removed, for example when someone loses a phone.

There is no single best factor, only the best fit for each situation.

Think about people and risk

Choosing factors means balancing three things: how strong the protection must be, how easy it is for people to use, and what devices and conditions they actually have. A factory floor with shared tablets has different needs from an engineering team on managed laptops, and both differ from a customer-facing mobile app.

A layered approach

Many organizations offer a ladder of choices. The strongest options are required for administrators and sensitive apps. A strong but friendly option, such as a phone app, is the default for most staff. Weaker methods, such as text or email codes, remain available only as backups and for recovery. This keeps protection high where it matters while avoiding needless friction elsewhere.

Offering variety is powerful, but it needs care.

Weakest link thinking

Attackers go for the easiest path. If a strong factor is required but a weak one is allowed as an alternative, the attacker will simply choose the weak one. That is why it matters not only which factors you offer, but which ones you leave available, especially for recovery.

Most trouble with factors comes from a few familiar habits.

Quick answers to questions beginners ask most often.

A factor is one method a person uses to prove who they are, such as a typed password, a phone prompt, a code, or a security key.

A factor type is the category of method, such as phone app, security key, text code, or email code. Each type has its own strengths and weaknesses.

They are very closely related. Newer Okta setups tend to use the word authenticator, while older ones use factor. Check which word your own environment uses.

Device-based and security-key methods are generally the strongest, because they resist fake login pages. Typed codes and secrets are weaker.

It is much better than a password alone, but weaker than app-based or key-based methods. Use it mainly as a backup, and avoid relying on it for administrators or very sensitive apps.

Because the answers are often guessable or findable online, making them a weak proof that attackers can exploit.

It means the factor cannot be handed over to a fake login page, because the proof is tied to the real website and never typed by the person.

You use a backup factor, if you enrolled one, or follow your organization’s reset process. After verification, you enroll a new device. This is why a second factor is strongly recommended.

Yes. Administrators can apply different enrollment and sign-in rules to different groups, so powerful accounts can be held to stricter standards.

At least two different kinds are the standard goal, such as a password plus a device-based proof. People should also have a backup factor enrolled for recovery.

We began at a vault that needed a key, a code, and a fingerprint, and ended with a full picture of Okta’s factor types. A factor is one method of proving identity, and a factor type is its category. Types fall into three families: something you know, something you have, and something you are. They range from familiar passwords and codes to strong device-based proofs and security keys that resist fake login pages. Choosing well means matching strength to risk, offering backups, protecting enrollment and recovery, and removing weak options that attackers could use as a shortcut. Understood this way, factor types become less a menu of technical terms and more a toolkit for building sign-in that is both safe and pleasant.