Two names that sound like alphabet soup, and one simple idea hiding underneath.

FIDO2 is a set of open standards that lets people sign in to websites and apps without relying on shared secrets such as passwords. It was created by the FIDO Alliance, an industry group that includes technology companies, banks, and security vendors. The name FIDO stands for Fast Identity Online. FIDO2 has two main parts that work together.

The first part is WebAuthn, short for Web Authentication. This is the rulebook that browsers and websites follow, published by the World Wide Web Consortium, usually shortened to W3C. WebAuthn defines how a website asks for a proof of identity and how the browser carries that request. The second part is CTAP, the Client to Authenticator Protocol. It defines how the browser talks to the small device or built-in component that actually creates the proof, such as a security key plugged into a USB port, or the fingerprint sensor inside a laptop.

In everyday speech, people use “WebAuthn” and “FIDO2” almost as synonyms, and Okta itself labels its feature “FIDO2 (WebAuthn).” You may also hear the word passkey. A passkey is the friendly consumer name for a FIDO credential that can sign you in without a password, and which in many products can be synced across your devices.

And where does Okta fit?

Okta is an identity platform. It sits between your people and your applications, checking who they are before letting them in. In this picture, Okta plays the role of the website that asks for proof, which the standards call the relying party. Okta lets administrators add FIDO2 (WebAuthn) as an authenticator, which means users can register a security key, a built-in biometric authenticator, or a passkey, and then use it to prove their identity when they sign in. Administrators can go further and require this kind of proof for sensitive applications.

To appreciate the new tool, look closely at the old one and where it breaks.

Passwords have a design flaw that no amount of cleverness can fully fix. They are shared secrets. Both you and the website know the secret, and every time you sign in, you send it across the internet. That means the secret lives in at least three places: your memory, the website’s storage, and the network path between them. Attackers can go after any of those three.

Four common ways passwords fail

Phishing. An attacker builds a fake sign-in page and tricks you into typing your details into it. This is the story at the top of this guide. It works because humans judge pages by how they look, and attackers can copy looks perfectly.

Credential stuffing. People reuse passwords. When one website leaks its database, attackers try the leaked pairs on many other sites. Even strong passwords fail if they are reused.

Server breaches. If a website stores passwords poorly, a break-in exposes all of them at once. Even well-stored hashes can be cracked when the passwords are weak.

Interception. Malware on your computer, or a malicious browser extension, can record keystrokes as you type.

Second factors helped, but not enough

Multi-factor authentication added a second proof beyond the password, such as a text message code or an app code. This was a major improvement and blocks many attacks. But most second factors share the same weakness as passwords: they are something a human reads and types into a page. If the page is fake, the human types it into the fake page, and the attacker relays it to the real page in real time. This is called a real-time phishing proxy or adversary-in-the-middle attack. Security teams use the term phishing-resistant for methods that cannot be relayed in this way.

This matters for Okta administrators because an identity provider is the front door to everything else. A stolen Okta session can open email, source code, finance tools, and customer data in a single stroke. Hardening that front door with phishing-resistant proof is one of the highest-value security upgrades an organization can make.

The path from clumsy one-off gadgets to a standard built into every phone and laptop.

Why Okta cares

Okta’s customers include organizations of every size, from startups to large enterprises and government agencies. As phishing campaigns against identity systems grew more common and more skilled, security guidance from governments and industry groups increasingly named phishing-resistant authentication as the target state. Okta responded by supporting FIDO2 (WebAuthn) as an authenticator, and by adding policy controls that let administrators require phishing-resistant methods for chosen applications and groups. Over time the product has also extended its support toward passkey-style experiences. The exact feature set depends on which Okta engine and release your organization uses, so always confirm details in current documentation.

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

The two ceremonies

The standards use the word ceremony for the short, formal exchange between the user, the browser, the authenticator, and the website. There are exactly two. The registration ceremony happens once per authenticator, when you enroll it. The authentication ceremony happens each time you sign in. Both follow the same pattern: the website sends a challenge, the authenticator answers after the user approves, and the website checks the answer.

Roaming versus platform

A roaming authenticator is a separate device that you carry from computer to computer, such as a USB or NFC security key. A platform authenticator is built into the device you are already using, such as the fingerprint reader in a laptop. Roaming authenticators are portable and independent. Platform authenticators are convenient because nothing extra needs to be carried.

Everything about FIDO2 rests on one clever trick. Once you understand it, the rest feels natural.

Public key cryptography, sometimes called asymmetric cryptography, uses a pair of keys that are linked by mathematics. The pair has a special property. Something signed with the private key can be checked using the matching public key, but the public key cannot be used to forge a signature, and cannot be turned back into the private key. You can hand your public key to the whole world and lose nothing.

The challenge and response dance

Suppose Okta wants to confirm you are really you. During enrollment, your authenticator created a key pair and gave Okta the public key. Now, at sign-in, Okta generates a random challenge, which is just a long unpredictable number, and sends it to your browser. Your authenticator signs that number with the private key. Okta uses the stored public key to check the signature. If it matches, only the holder of the private key could have produced it. At no point did the private key travel anywhere.

Why this beats a password

With a password, the website must store something that can be used to verify you, and you must send the actual secret every time. With public key cryptography, the website stores only a public key, which is worthless to a thief. If Okta’s database were stolen, the attacker would hold public keys that cannot sign anything. And because each challenge is new, a recorded sign-in cannot be replayed.

One key pair per site

A key detail is that the authenticator creates a separate key pair for every website. Your credential for Okta is not the same as your credential for any other service. This prevents one site from tracking you across others and means that a leak at one service has no effect on another. It is the cryptographic version of using a different lock for every door.

Not all FIDO2 authenticators look alike. Each type has strengths, and choosing the right mix is a core design decision.

Device-bound versus synced

One of the most important distinctions today is whether a credential is device-bound or synced. A device-bound credential lives in one authenticator and cannot be copied out. If you lose that device, you lose the credential and must enroll another. A synced passkey is stored in a cloud-backed vault tied to an account, so it appears on your new phone when you sign in to the same account. Synced credentials trade a little theoretical strength for a big gain in convenience and recoverability.

PIN, touch, and biometrics

Authenticators can require different local gestures. A simple touch proves a person is present. A PIN or biometric proves that the right person is present, because someone who steals a security key still needs the PIN. For sign-in that replaces passwords entirely, user verification matters, because there is no password left to act as the second check.

A map of every actor involved when someone signs in with a security key or passkey.

The diagram below shows the cast. A person uses a browser or an app. The browser talks to Okta over HTTPS and to the authenticator over a local link. Okta consults its policies, stores credential records, writes logs, and finally lets the user into the application.

flowchart LR
  USER["User"] --> BROWSER["Browser or Native App"]
  BROWSER |"CTAP2 over USB, NFC, Bluetooth or built-in"| AUTH["Authenticator: Security Key or Passkey Provider"]
  BROWSER |"HTTPS"| OKTA["Okta Sign-In Service - the Relying Party"]
  OKTA --> POLICY["Enrollment and Authentication Policies"]
  OKTA --> UD["Universal Directory with credential ID and public key"]
  OKTA --> APP["Protected Application"]
  OKTA --> LOG["System Log"]
    

Walking through the boxes

User. The human who approves the sign-in with a touch, PIN, or biometric.

Browser or native app. The go-between. It carries Okta’s request to the authenticator, and, crucially, it adds the true web address of the site. A page cannot lie about its own address to the browser. This is what makes phishing resistance possible.

Authenticator. The guardian of the private key. It performs the signing and enforces the local gestures such as touch or PIN.

Okta sign-in service. The relying party. It creates challenges, verifies signatures, and decides what to do next based on policy.

Policies. Enrollment policies decide who may or must enroll which authenticators. Authentication policies decide what proof each application requires.

Universal Directory. Where Okta keeps the user’s profile and the record of each enrolled authenticator, including the credential identifier and the public key. Notice that no secret is stored here.

System Log. The diary of events such as enrollments, successful verifications, and failures.

Protected application. The destination. Okta passes the user to it only after the policy is satisfied.

How an authenticator is enrolled, step by step, and what each party contributes.

Registration is a one-time introduction between Okta and an authenticator. Afterward, Okta knows the authenticator’s public key and can recognize its signatures. A user typically starts this from their account settings, or Okta prompts them during sign-in when policy requires enrollment.

sequenceDiagram
  participant U as User
  participant B as Browser
  participant A as Authenticator
  participant O as Okta
  U->>O: Choose to set up a security key or passkey
  O-->>B: Registration options with a random challenge
  B->>A: Ask to create a new credential for this site
  A->>U: Request touch, PIN or biometric
  U-->>A: Approve
  A-->>B: New public key and credential ID with proof of creation
  B->>O: Send the registration response
  O->>O: Verify the challenge and origin then store the public key
  O-->>U: Authenticator enrolled
    

Step by step

What Okta stores

Okta stores the credential identifier, the public key, and some metadata. It does not receive and cannot reconstruct the private key. If an Okta database were exposed, the attacker would only gain material that is useless for signing in.

Attestation: who made this device?

During registration the authenticator may also send an attestation, a signed statement saying what kind of device it is. High-security organizations use this to allow only approved hardware models. Many organizations skip strict attestation because it adds friction and privacy concerns. Okta provides settings that influence how authenticators are accepted, and some versions allow limiting accepted models by their identifiers. Check the options available in your org.

What happens each time you tap your key to sign in.

After enrollment, every sign-in is a quick challenge and response. The entire exchange usually takes only a second or two of human time, with most of that spent touching a key or scanning a finger.

sequenceDiagram
  participant U as User
  participant B as Browser
  participant A as Authenticator
  participant O as Okta
  U->>O: Sign in to an application
  O-->>B: Authentication request with a fresh challenge
  B->>A: Ask for a signature for this site
  A->>U: Request touch, PIN or biometric
  U-->>A: Approve
  A-->>B: Signed response
  B->>O: Send the signed response
  O->>O: Check signature, challenge, origin and counter
  O-->>U: Access granted
    

What gets checked

When Okta receives the response, it checks several things in order. It confirms that the challenge matches the one it just issued, which stops replays. It confirms the origin, which stops phishing relays. It confirms the credential belongs to this user. It verifies the signature using the stored public key. It confirms that user presence was proven, and user verification too if policy demands it. Finally it may look at a signature counter, a number that the authenticator increases on every use. If the counter ever goes backward or repeats unexpectedly, that can hint that a credential was cloned, although synced passkeys often do not use counters in the same way.

Username-first and usernameless flows

In a typical flow, the user first tells Okta who they are, perhaps by entering a username. Okta then knows which credentials to ask for. In a usernameless flow, the user does not type anything. The authenticator itself finds a discoverable credential for the site and offers it, as in a passkey prompt. Okta then learns who the user is from the credential. This is what makes truly passwordless and typing-free sign-in possible.

The heart of the matter: how origin binding turns a convincing fake into a dead end.

Every FIDO2 credential is created for a specific relying party identifier, which is essentially the domain name of the site. The authenticator remembers that link. When a sign-in request arrives, the browser tells the authenticator which origin the request came from. The authenticator will only use a credential if the origin matches the one tied to that credential.

sequenceDiagram
  participant U as User
  participant F as Fake Lookalike Site
  participant BA as Browser and Authenticator
  participant R as Real Okta
  U->>F: Visit a lookalike sign-in page
  F->>BA: Request a signature for the fake domain
  BA-->>F: No credential exists for this domain
  F-->>U: Nothing for the attacker to relay
  U->>R: Visit the real sign-in page
  R->>BA: Request a signature for the real domain
  BA-->>R: Signed response
    

Why the user cannot be tricked

With a typed code, the human is the only judge of whether a page is real, and humans are fooled constantly. With WebAuthn, the judge is the browser and the authenticator, which compare domain names exactly. A single wrong letter in the address means no credential is found. The authenticator does not feel urgency, does not read the page’s logo, and cannot be sweet-talked.

Why relays fail too

Even an attacker who sits in the middle and forwards messages cannot succeed. The signature produced for the fake domain includes the fake domain. When the attacker forwards it to the real Okta, Okta sees the wrong origin inside the signed data and rejects it. And since each challenge is unique, the attacker cannot save a signature and use it later.

What it does not stop

It is honest to say what phishing resistance does not cover. It does not stop malware that has already taken over the user’s device and session. It does not stop a person from being tricked into approving a legitimate prompt on the real site for an attacker’s purpose, although the design makes this far harder. It does not protect against a stolen, already authenticated session token. And it does not secure the account recovery process if recovery is weak. Those require other layers, discussed in the security chapter.

A credential has a life: it is born, used thousands of times, sometimes lost, and eventually retired.

What data lives where

The last row is worth underlining. Okta never receives your fingerprint or your face. The biometric check happens inside the device, which then simply tells the authenticator, “the right person is here.” Okta only ever sees a signature.

Multiple credentials per user

A user can have several FIDO2 authenticators enrolled at the same time, such as a laptop biometric, a primary key, and a spare key kept in a drawer. Each is a separate credential with its own key pair. This is not a loophole but a recovery feature. Good deployments encourage at least two enrolled authenticators from the start.

What an administrator actually sets up, in plain language and in the order that works best.

Configuration has three layers. First, you turn on the FIDO2 (WebAuthn) authenticator and choose its settings. Second, you decide who may or must enroll, using enrollment policies. Third, you decide where it is required, using authentication policies for applications. Doing these in order avoids locking people out.

The key settings to understand

The authenticator on its own protects nothing. Policies decide where it counts.

Okta separates two policy ideas that beginners often blur together. Authenticator enrollment policies answer, “Who may register which authenticators, and who must?” Authentication policies answer, “When someone opens this application, what proof must they present?” You need both to get a real security improvement.

Enrollment policies

These are usually attached to groups. You might say that everyone in the engineering group must enroll a FIDO2 authenticator, that the finance group may enroll one but is not required to, and that contractors cannot enroll one yet. Because policies are evaluated in a defined order, you can create a strict rule for the pilot group at the top and a general rule for everyone else below it.

Authentication policies

These are attached to applications. Each rule can say who it applies to, under what conditions such as network location or device state, and what proof is needed. A typical strong rule for a sensitive application would require that the user possess a phishing-resistant authenticator and verify themselves locally with a PIN or biometric. A typical lighter rule for a low-risk application might accept a password plus any approved second factor.

Sensible rollout order

The safe order is: configure the authenticator, set a permissive enrollment policy for a pilot group, let people enroll, confirm that they have at least two authenticators, and only then tighten the authentication policy on the applications. Reversing that order is the classic recipe for locking people out of their own accounts, because you would be demanding a proof that they have not yet been able to create.

The same standards that harden multi-factor sign-in can also remove the password completely.

Most organizations begin by using FIDO2 as a strong second step after a password. This already blocks phishing relays for the second step, but the password remains a weak spot. The next stage is to let the authenticator do both jobs at once: it proves possession of the key and, through a PIN or biometric, proves the right person is present. That single gesture satisfies two factors, something you have and something you are or know, and the password disappears.

Three stages of maturity

Choosing authenticators by audience

flowchart TD
  A["Who is the user group?"] --> B{"Privileged or high risk?"}
  B -->|"Yes"| C["Require hardware security keys with a phishing resistant policy"]
  B -->|"No"| D{"Company managed devices?"}
  D -->|"Yes"| E["Allow platform authenticators such as Windows Hello or Touch ID plus a backup key"]
  D -->|"No"| F["Allow passkeys and security keys with a strong recovery process"]
  C --> G["Enroll at least two authenticators per person"]
  E --> G
  F --> G
    

How Okta’s other features relate

Okta offers other phishing-resistant options beyond FIDO2, notably Okta FastPass, which uses the Okta Verify app and device-bound keys. These are related ideas built on the same principle: a private key bound to the device and to the genuine origin. Many organizations use FIDO2 security keys for administrators and shared or unmanaged-device situations, and FastPass or built-in biometrics for managed daily use. Which combination suits you depends on your devices, your risk, and your Okta release.

The technology is the easy half. The people and process half decides whether the project succeeds.

Phase 1: Prepare

Inventory your applications and rank them by sensitivity. Inventory your user devices and browsers, since WebAuthn needs a modern browser and a secure HTTPS connection. Decide your domain setup, because credentials are tied to the sign-in domain. Confirm which Okta engine your organization runs and which FIDO2 features it offers. Choose which authenticators you will support and buy hardware keys if needed, usually two per privileged person.

Phase 2: Pilot

Pick a small, friendly group, often the IT and security teams themselves. Let them enroll, try different browsers and devices, and report every awkward moment. Fix documentation and settings based on what they find. A pilot that surfaces ten small issues saves you from a thousand support tickets later.

Phase 3: Waves

Expand to departments in waves, beginning with the highest-risk groups such as administrators, developers, and finance. For each wave, give clear instructions, short videos or screenshots, and a date after which the policy will tighten. Hold short office hours so people can enroll with help.

Phase 4: Enforce

Once most users in a group have at least two authenticators enrolled, turn on enforcement for the applications that matter. Keep a gentle fallback for a short grace period, then remove it. Review exceptions regularly, and let each exception expire.

Phase 5: Sustain

Add enrollment to new hire onboarding. Review reports of users with only one authenticator. Replace aging hardware keys. Revisit settings when Okta releases new capabilities.

A strong lock is only as good as the process for people who lose their key.

Attackers are practical. If the front door is steel, they look for a side window. In passwordless and phishing-resistant systems, the side window is almost always account recovery: the process by which a person who has lost every authenticator regains access. If recovery is easy to talk your way through, the strongest key in the world does not matter.

Layers of recovery

What good identity verification looks like

For assisted recovery, avoid questions whose answers are easy to find, such as a date of birth. Prefer a live video call with a manager who knows the person, a check against HR records, or approval from a second authorized person. For administrators and other high-risk roles, require an in-person or highly verified process. Log every step so there is an audit trail.

FIDO2 closes the biggest door. These are the other doors and windows to check.

It would be dishonest to call any technology unbreakable. FIDO2 sharply reduces risk, but attackers adapt. The goal is to understand what remains and cover it with other layers.

Threat 1: Enrollment hijack

If an attacker can sign in with a weak method and enroll their own authenticator, they gain a durable foothold. Protect enrollment itself. Require a strong proof before adding a new authenticator, notify the user whenever one is added, and monitor for unexpected enrollments.

Threat 2: Weak recovery

As discussed, attackers who cannot beat the key will target the process that replaces it. Treat recovery as a security control with its own design review.

Threat 3: Fallback to weaker methods

If your policy still allows a text message or app code as an alternative, an attacker will simply pick that option. Phishing resistance only exists where weaker options are not accepted. This is the most common gap in real deployments: strong keys everywhere, but weak fallbacks still enabled.

Threat 4: Session theft

After a successful sign-in, the user holds a session token. Malware or a malicious browser extension can steal that token and use it elsewhere. FIDO2 protects the moment of sign-in, not the life of the session. Use shorter sessions for sensitive apps, device-aware policies, and endpoint security to reduce this risk.

Threat 5: Compromised endpoint

If malware controls the computer, it can wait for the user to approve a legitimate prompt, then abuse the resulting session. Hardware with user verification limits what malware can do silently, but endpoint protection remains essential.

Threat 6: Social engineering of approvals

An attacker may ask a user by phone to “approve the prompt that just appeared” on a real sign-in. Because a touch is a silent gesture, training should teach people never to approve an unexpected request, and policies that require a PIN or biometric add a further moment to pause.

Threat 7: Admin account abuse

Administrators can reset authenticators. Restrict who holds that permission, require strong authentication for them, and log every reset. A few well-protected administrators are safer than many casual ones.

Supply chain and device trust

Buy hardware keys from reputable vendors and distribute them carefully. In high-security settings, use attestation settings to accept only models you have vetted, and record the identity of the person who receives each key.

Strong sign-in only helps if you notice when something unusual happens around it.

Okta records activity in the System Log, including events about authenticator enrollment, sign-in attempts, and policy evaluation. Learn what these events look like on a normal day so that unusual ones stand out. Exact event names vary by release, so search the log for authenticator and sign-in activity and become familiar with the results in your own org.

Events worth watching closely

Metrics for the program

Other helpful numbers include the volume of help desk tickets about authenticators, the time to resolve a lost-key case, the number of sign-ins still using weak methods, and the number of active exceptions. Plot them monthly. A falling count of weak-method sign-ins is the clearest sign that the project is working.

Getting alerts to people

Send log events to your security monitoring platform, and set alerts for the high-value events above. Okta also offers ways to react to events with automation, such as Event Hooks or Workflows, which can open tickets or notify managers. Make sure alerts go to a monitored team channel, not one person’s inbox.

Reliable shapes that many successful rollouts share.

How the patterns combine

Each pattern covers a different weakness. Starting with high-value users gets quick wins. Two authenticators prevent lockouts. Tiered policies balance security and convenience. Removing weak fallbacks keeps attackers from downgrading. The break-glass account is the parachute. Enrollment at onboarding keeps the system healthy as people join. Together they form a program rather than a one-time project.

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

An honest ledger of what you gain and what you pay.

Trade-offs to think through

Security versus convenience. Hardware keys with PINs offer the strongest assurance but ask more of users. Built-in biometrics and passkeys feel almost effortless. Many organizations use the strongest option for high-risk roles and a convenient one for everyone else.

Device-bound versus synced. Device-bound credentials are harder to move and therefore harder to steal, but harder to recover. Synced passkeys are easy to recover but inherit the risk profile of the sync account. Choose per audience.

Strict attestation versus openness. Allowing only approved models improves control, but adds administrative work and may exclude devices people already own. Open acceptance is simpler but offers less assurance about the hardware.

Speed versus safety in recovery. Instant resets make users happy and attackers happier. Slower, verified resets protect accounts but cost time. Match the strictness to the sensitivity of the account.

Big-bang versus phased rollout. A single switch date is easy to explain but brittle. Phased waves take longer, yet catch problems when they are still small.

A checklist to read before launch and during every review.

Best practices

• Start with the highest-risk users such as administrators, developers with production access, and finance staff.
• Require two authenticators per person so a single loss never means a lockout.
• Enroll before you enforce. Check coverage, then tighten application policies.
• Remove weak fallbacks on sensitive applications, so attackers cannot downgrade the sign-in.
• Protect enrollment and recovery with strong identity checks, notifications, and logs.
• Settle your sign-in domain early, because credentials are tied to it.
• Test across browsers, operating systems, and remote desktop setups before wide release.
• Keep a tested break-glass administrator path secured with hardware keys.
• Monitor new enrollments, resets, policy changes, and weak-method sign-ins.
• Train the help desk, and give them a script that does not bend to urgency.
• Reduce session risk with shorter lifetimes and device-aware rules for sensitive applications.
• Document ownership and review the setup whenever Okta releases relevant capabilities.

Common mistakes

What happens when phishing-resistant sign-in meets the real world. Public reports are summarized in general terms. Always check the original sources for exact details.

Okta supports many ways to prove identity. Seeing them side by side explains where FIDO2 fits and why.

Okta offers a menu of authenticators, and a good design uses several of them for different people and situations. The main question to ask of each is simple: if a criminal builds a fake sign-in page and tricks the user into using this method, can the criminal reuse what the user provided? If yes, the method is vulnerable to phishing. If no, it is phishing-resistant.

Why codes and prompts fall short

A typed code is a secret that is valid for a short time. During that time, anyone holding it can use it. A real-time phishing proxy gets the code from the user and forwards it within seconds, well inside the validity window. A push prompt is different but has its own weakness: a determined attacker can trigger many prompts until a tired user taps approve, or can phone the user with a convincing story. Number matching and context details improve push, but the approval is still a human decision on a message, not a cryptographic check of the website.

What makes FIDO2 different

With FIDO2, the human is not asked to judge anything. The decision about whether the website is genuine is made by the browser and the authenticator, which compare domain names exactly. The human only confirms presence. This transfer of judgment from a tired person to a precise machine is the real innovation.

The standards are universal, but real computers are messy. Knowing the compatibility landscape avoids unpleasant surprises.

WebAuthn is a web standard, so it lives inside the browser. Every current mainstream browser on desktop and mobile supports it, and the major operating systems provide built-in authenticators. But support has layers, and a smooth experience depends on the combination of browser, operating system, and authenticator.

What must be true for WebAuthn to work

Tricky environments

Remote and virtual desktops. When a person works inside a remote session, the key is plugged into their local computer, not the remote one. Whether the remote tool passes the key through varies. Test your own tools. In some designs, the sign-in happens on the local side before the remote session starts, which avoids the problem.

Shared and kiosk machines. Personal biometrics do not make sense on a computer many people use. Hardware keys with a PIN are the usual answer.

Embedded browsers and older apps. Some desktop apps open sign-in inside a small embedded browser that may not support WebAuthn well. Prefer apps that use the system browser for sign-in.

Private browsing and strict privacy settings. Some privacy tools block or limit credential features. A user who reports odd behavior might be using such a setting.

Mobile experiences. Phones can use built-in biometrics, nearby-device authentication, or NFC and USB keys. The experience varies by operating system version, so test the phones your people actually use.

Most trouble falls into a handful of 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.

WebAuthn and FIDO2 change the nature of proof. Instead of handing over a secret that a fake page can copy, the user’s device signs a fresh challenge for one specific website, using a private key that never leaves the device. Okta supports this as an authenticator, and with the right policies it can require it where it matters most. The cryptography is solid and the standards are open. What decides success is everything around it: sensible policies, two authenticators per person, strong recovery, careful rollout, and steady monitoring.