Multi-factor authentication stopped a large share of attacks. Attackers adapted, and so must defenders.

How Attackers Beat the Second Step

All four attacks share a root: a human decides in the moment whether to trust a page or a prompt. Phishing-resistant methods remove that decision from the human and give it to the device and the web address.

The term is used loosely. A clear definition prevents false comfort.

What It Means

A method is phishing-resistant when a fake page cannot make it work against the real service, even if the person is completely fooled. Two properties give this: the proof is bound to the true web address (so it fails elsewhere), and the secret never leaves the device (so there is nothing to type or copy).

What It Does Not Mean

• It does not mean unhackable. Device theft, malware on the device, and weak recovery paths remain.
• It does not mean every method labelled “strong”. App codes, push approvals and text codes are stronger than a password alone but are not phishing-resistant.
• It does not replace other controls. Device health, network and session rules still matter.
• It does not help if fallbacks stay open. If a weak method remains available, attackers will ask for that one.
• It does not fix recovery. A strong front door with a weak back door protects nothing.

A short dictionary makes the rest of the guide easier.

The core idea is simple: the device answers only the address it was introduced to.

sequenceDiagram
    participant P as Person
    participant D as Device or key
    participant B as Browser
    participant S as Real service
    P->>D: Registers once at the real address
    D->>S: Public key stored for that address
    Note over P,S: Later, at sign-in
    S->>B: Challenge for the real address
    B->>D: Challenge plus the address shown in the browser
    D->>D: Checks address matches the registration
    D->>B: Signed answer, only if the address matches
    B->>S: Signed answer
    S->>S: Verifies signature with the public key
    

1. At registration, the device creates a key pair for the real address and gives the service the public half.
2. At sign-in, the service sends a fresh random challenge.
3. The browser tells the device which address it is really on. The person cannot override that.
4. The device signs the challenge only if that address matches a registered one.
5. The service checks the signature with the stored public key.

On a fake page, step four fails. The device sees a different address and has nothing to sign. There is no code for the person to read out and no prompt to approve by mistake.

Okta offers many authenticators. Only some resist phishing. Knowing which is which is the first design skill.

Which of these your org can use, and how they are configured, depends on your Okta product and edition. Confirm the current list and the exact names in the official documentation.

The FIDO2 family comes in several shapes. Each suits different people and risks.

• Decide per population. Administrators may need hardware keys. Ordinary staff may be best served by device-bound passkeys or FastPass.
• Think about syncing. Syncing helps with lost devices and also moves trust to another vendor’s account. Security teams should decide this on purpose.
• Plan for two methods per person. One lost key must not mean a locked-out employee.
• Check support. Browsers, operating systems and older applications differ.

Okta’s own device-based method is built to make strong sign-in feel nearly invisible.

FastPass works through the Okta Verify app on a person’s device. The app holds a key for the device and checks both the device and the web address before it answers. It can sign someone in without a typed password, and Okta can use signals about the device, such as whether it is managed or has a screen lock, when deciding whether to trust it. Details vary by operating system, edition and Okta release, so confirm what applies to you.

Some organizations already run certificate-based sign-in, especially in government, defence and heavily regulated industries.

• What it is. A person holds a card or token with a certificate issued by a certificate authority. Sign-in proves possession of the matching private key, and the key never leaves the card.
• Why it resists phishing. The proof is bound to the connection, and there is no code to relay.
• Where it fits. Existing card programmes, regulated sectors and places where physical badges already exist.
• What it costs. Issuing and revoking certificates, card readers, support for lost cards and compatibility with web and mobile.
• How Okta fits. Okta can work with certificate-based sign-in, often through an identity provider or its own support, and the supported setups differ by edition. Confirm the options.

If you already have a card programme, it may be the quickest path to phishing resistance for some populations. If you do not, a passkey or FastPass programme is usually cheaper to start.

A picture of the parts shows where each decision is made and where weak paths can remain.

flowchart LR
    P["Person with device or key"] --> APP["Application or Okta dashboard"]
    APP --> OK["Okta sign-in service"]
    OK --> AP["Authentication policy for the application"]
    AP --> ENR["Authenticator enrollment policy"]
    AP --> DEV["Device and network signals"]
    AP --> RISK["Risk checks"]
    OK --> REC["Recovery and help desk process"]
    OK --> LOG["System Log"]
    LOG --> SIEM["Monitoring platform"]
    

• Authenticators are the methods people hold.
• Enrollment policies decide which methods a group may register, and which are required.
• Authentication policies decide what each application demands at sign-in.
• Device and risk signals adjust the demand, for example by asking for more proof on an unknown device.
• Recovery decides how a person returns after losing everything.
• Logs show who used what, and where weak methods still appear.

Following one sign-in from first click to last redirect removes most of the mystery.

sequenceDiagram
    participant U as Person
    participant A as Application
    participant OK as Okta
    participant POL as Authentication policy
    participant DEV as Device or key
    U->>A: Opens the application
    A->>OK: Redirects to sign in
    OK->>POL: Which proof does this app require?
    POL-->>OK: Phishing-resistant method on a healthy device
    OK->>U: Asks for the allowed method
    U->>DEV: Touches key or unlocks device
    DEV->>OK: Signed answer bound to the real address
    OK->>OK: Verifies signature and device signals
    OK-->>A: Sign-in succeeds
    

1. The person opens an application, which sends them to Okta.
2. Okta finds the authentication policy for that application and the person’s context.
3. The policy names the methods that satisfy it. If only phishing-resistant methods are allowed, nothing weaker is offered.
4. The person uses their key or device.
5. Okta verifies the signed answer and any device signals, then completes sign-in.

The crucial point: the policy decides what is offered. A weak method that is still on the list is a weak method an attacker can request.

Two kinds of rules do two different jobs. Mixing them up causes most early confusion.

• Enrollment says what people can have. Authentication says what they must show.
• You need both. A person who has a passkey but whose application still accepts text codes can be attacked through the text code.
• Order matters. Policies are evaluated in a defined order. Check the order carefully when you add a new strict rule.

Names and layout of these policies differ across Okta engines and releases. Confirm in current documentation, especially if you moved from the older engine.

Different groups of people have different devices, risks and needs. One method for all is rarely the best.

Strong design starts with naming the attackers and what each can do. Not every attacker needs the same defense.

Phishing-resistant methods are powerful against the first two, which cause the most real-world breaches. They are only one part of the answer to the others. Say this clearly to leaders so they do not expect miracles.

Push prompts are friendly and often used, and they sit in a middle zone: better than text codes, weaker than origin-bound methods.

How Fatigue Attacks Work

An attacker who already has a stolen password triggers sign-in again and again. The person’s phone buzzes at night, at lunch, in a meeting. Eventually someone taps “Approve” to make it stop, or by mistake. The method itself worked exactly as designed.

Reducing the Risk

• Number matching. The sign-in screen shows a number, and the person must pick or type it in the app. This stops blind approvals, and it can still be relayed by a fake page that shows the real number.
• Context in the prompt. Show the application and place of the request so a strange one stands out.
• Limit repeats. Rate-limit prompts and lock after several refusals.
• Teach people to report. An unexpected prompt should be a reason to call security, and never a reason to tap yes.
• Move away over time. Treat push as a stepping stone while passkeys or FastPass are rolled out.

The single most common failure in phishing-resistant programmes is leaving the old methods switched on.

Imagine every employee has a passkey. If the sign-in page still offers “Use a text code instead,” an attacker’s fake page simply asks for that. The person, who has never seen a problem with text codes, happily follows. Phishing resistance is only as strong as the weakest method that is still allowed.

Policy is where good intentions become rules the system will actually enforce.

Elements of a Rule

• Who. The group or population the rule covers.
• Where. Network zones, countries or locations.
• Device. Managed, registered or unknown, and the health of the device.
• Risk. The level of suspicion Okta assigns to the attempt.
• Required proof. Which methods satisfy the rule, and how many.
• Re-authentication. How often the person must prove themselves again.
• Action when not met. Deny or step up.

The last row matters most. A catch-all rule that allows weaker sign-in “for everyone else” becomes the attacker’s favorite path. Make the default deny, and open exceptions on purpose.

Not every application needs the strongest rule on day one. Sort them by what would be lost if an account were taken.

• Start with the critical tier, since the harm from loss is highest and the user numbers are smallest.
• Use the same tiers as your risk register, so everyone agrees on what “critical” means.
• Review the tiers yearly. Applications move up as they hold more data.
• Remember single sign-on: a weak sign-in to Okta gives a path to every application behind it.

A strong key on a compromised laptop is a locked door in a burning house. Device health belongs in the design.

• Managed or registered. Is this device known to the company?
• Screen lock and encryption. Does the device protect itself when lost?
• Up-to-date operating system. Old systems carry known holes.
• Security software present. Is the protection tool running?
• Not jailbroken or tampered. A modified device cannot be trusted to guard keys.

Okta can collect device signals through its own tools and through integrations with device management and security products, and policies can use them. Which signals are available, on which platforms and in which editions, should be confirmed in current documentation.

Practical Advice

• Treat device checks as an additional layer, not a substitute for strong authenticators.
• Make the failure friendly. Tell the person what is wrong and how to fix it.
• Plan a route for devices that cannot meet the standard, such as hardware keys on a clean machine.
• Watch for signal gaps. A device that does not report is not necessarily healthy.

The moment someone registers a new method is the most dangerous moment of its life. Whoever registers first owns the account.

The Bootstrap Problem

To register a strong method, a person must first prove who they are by some other means. If that first proof is weak, the strong method inherits the weakness. An attacker with a stolen password could register their own passkey and lock out the real person.

Safer Enrollment Paths

• Require a strong method, or a verified in-person check, to add the next method.
• Notify the person and their manager when a new method is registered.
• Log every enrollment and review unusual ones, such as new keys right after a password reset.

People lose phones and break keys. Recovery must be possible, and it must not be easier than normal sign-in.

Principles

• Always have a second method. Two registered strong methods per person remove most recovery needs.
• Recovery equals sign-in strength. A recovery path that needs only an email link is a weak sign-in in disguise.
• Add friction on purpose. A short delay and a notice to the person and manager give a chance to stop abuse.
• Prefer people over scripts for high-risk accounts. A trained human checking identity beats an automatic form.
• Limit scope after recovery. A recovered account may begin with limited access until it is re-verified.

flowchart TD
    A["Person reports lost key"] --> B{"Do they have another registered strong method?"}
    B -->|"Yes"| C["Sign in with it, then add a replacement"]
    B -->|"No"| D["Identity check by trained support using HR records"]
    D --> E{"Check passed and manager confirmed?"}
    E -->|"Yes"| F["Issue time-limited enrollment link to verified channel"]
    E -->|"No"| G["Refuse and report to security"]
    F --> H["Person registers new method; notices sent to person and manager"]
    

When the front door gets stronger, attackers call support. The help desk is now part of your authentication system.

• Script the identity check. Use questions that cannot be answered from public information or a leaked database. Verify against HR data or a manager callback, and never against details the caller supplies.
• Call back on known numbers. Use the number in HR records, never the one the caller gives.
• Limit what support can do. They should not be able to remove a method and add a new one in one step, and certainly not for administrators.
• Require a second person for sensitive resets. A manager, a security analyst or both.
• Allow staff to say no. Pressure from a “senior executive in a hurry” is a classic trick. Leaders must back staff who refuse.
• Train with real examples. Practise recognising urgency, flattery, threats and familiarity.
• Log and review. Every reset reviewed by someone else, with sampling for patterns.

Whoever can change the sign-in rules can undo them. Administrators are the first population to protect.

• Hardware keys, two each. Preferably with a PIN so a stolen key is useless.
• Separate admin accounts. Use a dedicated account for administration, not the everyday one that reads email.
• Strict policy for the admin console. Phishing-resistant only, managed device, short sessions, no fallbacks.
• Limit who can change policies. Fewer people, with named roles, and review of every change.
• Break-glass accounts. A small number of emergency accounts with very strong, separately stored credentials, tested and alarmed so any use is noticed.
• Watch the watchers. Alert when authentication policies, enrollment settings or admin roles change.
• Protect API tokens. Administrative tokens act with powerful rights, so store them safely, give them narrow scope and rotate them.

Some applications cannot do modern sign-in. They often become the way around your policy.

Okta offers ways to bring more of these under policy, and what is possible depends on the application and your edition. Where nothing works, isolate the application, limit who can reach it and plan its replacement. Keep a list of exceptions with an owner and a deadline.

Strong human sign-in does nothing for scripts, integrations and background services. Attackers know this and look for them.

• List them. Find every service account, integration token and automation key. Most organizations discover more than they expected.
• Give each an owner. A named person or team answers for it, and reviews it each year.
• Use narrow rights. Each account may do only the job it exists for.
• Prefer short-lived, workload-bound credentials over long passwords or tokens that never expire.
• Keep secrets in a vault, never in scripts, chat messages or shared documents.
• Rotate on a schedule and immediately after a person with access leaves.
• Watch usage. Alert when a service account signs in from a new place or at a strange time.
• Never use a human account for automation. Human policies then break, or get weakened to suit the script.

Okta offers ways to authenticate applications and services with scoped, short-lived credentials, and the options differ by feature and edition. Confirm what applies to your environment.

Real workplaces are not tidy rows of managed laptops. Some staff work from phones, personal computers or a counter shared by a whole shift.

• Ask what people will actually carry and use, not what looks neat on paper.
• Give pilots to the hardest groups early, since they find the problems.
• Do not force a personal phone on people without a fair alternative, and ask your legal team about local rules.

Turning on strict rules for everyone on one Monday is the fastest way to a help desk meltdown. Roll out in steps, riskiest and smallest groups first.

Set dates, but let results move them. A phase finishes when its numbers are healthy: high enrollment, low support load and no unexplained failures, and not merely when the calendar says so.

A pilot is not a formality. It exists to discover the problems you did not predict.

• Choose varied pilot users. Include remote staff, people with older devices, frontline workers and people who travel.
• Measure what matters. Enrollment success, time to enroll, sign-in failures, support contacts and satisfaction.
• Ask open questions. “What confused you?” finds more than “Was it easy?”
• Watch real behavior. Sit beside a few people as they enroll. Silent struggles show up.
• Fix before widening. Rewrite confusing screens, stock spare keys, adjust policies.
• Share what changed. People tolerate bumps when they see their feedback used.

People accept changes they understand. They resist changes that appear as surprise commands.

Messages That Work

• Why. Tell the Meera story. A plain example is stronger than a list of statistics.
• What changes for me. One sentence per audience: staff, managers, administrators, support.
• What to do and by when. Short steps with pictures, in the languages of your workforce.
• Where to get help. Walk-in sessions, a hotline and a self-help page.
• What not to do. Never approve a prompt you did not start. Never share a code. Report odd requests.

Formats

• A two-minute video of the enrollment.
• A one-page guide per device type.
• Reminders from managers, not only from IT.
• A phishing exercise that shows, safely, how the new method stops a fake page.

On the day rules tighten, the support desk meets the problems first. A prepared team turns anger into thanks.

• Prepare scripts and short guides, and update them weekly in the first month.
• Add extra staff or a surge desk for the days around each phase.
• Give support a clear route to security for suspicious calls.
• Collect call reasons and feed the top five back to the project every week.

A security method that some people cannot use is not secure. It becomes an exception, and exceptions become holes.

• Offer more than one kind of unlock. Fingerprint, face, PIN and key touch suit different people.
• Consider physical limits. Small keys can be hard to handle for some. Larger or different form factors exist.
• Consider vision and hearing. Enrollment screens should work with screen readers and not depend on sound or color alone.
• Consider language and literacy. Simple words, translations and pictures help.
• Consider access to technology. Not everyone owns a smartphone. Provide keys.
• Handle privacy about biometrics. Biometric data on a phone usually stays on the phone. Explain that, and offer a PIN alternative.
• Document accommodations. Approved alternatives should be written, limited and reviewed, not improvised.

Legal duties about accessibility and biometric information vary by country, so ask your legal and HR teams what applies to you.

Keys and devices live real lives. They are forgotten, lost, broken and left behind when people leave.

• Keep an inventory of issued hardware, with owner and date, and reconcile it quarterly.
• Tag spare keys, store them securely and count them.
• Make revoking a lost key a two-minute task, and measure it.

You cannot hand a hardware key to every customer. But you can still move them toward stronger sign-in without losing them.

• For customers, a forced change often costs more than a fraud loss. Measure both before deciding.
• For federated partners, record in the contract which assurance level the partner must meet.
• For contractors, never allow weaker sign-in just because they are temporary. Temporary access to critical systems is still critical.

Customer identity may use separate Okta products with different features, so confirm which options apply to you.

Strong sign-in protects the moment of entry. Attackers who cannot beat it may try to steal what happens afterwards.

After a person signs in, the browser holds a session cookie or tokens that prove it. If malware or a malicious browser extension steals that proof, the attacker can use it without ever signing in. This is called session theft or token theft, and phishing-resistant methods do not stop it directly.

Reducing the Risk

• Short sessions for sensitive tools. Re-authentication limits how long a stolen session lasts.
• Tie sessions to devices. Where supported, bind sessions to a device or network so that a copy elsewhere fails.
• Protect devices. Keep systems patched, restrict browser extensions and run security software.
• Monitor odd sessions. Same session from two distant places, or a sudden change of device details, should raise an alert.
• Re-check before dangerous actions. Step-up for payments, exports and administrator tasks.
• Make sign-out and session revocation fast. Support and security must be able to end all sessions for a person quickly.

Which session-binding and revocation features exist depends on your Okta edition and the applications involved, so confirm in current documentation.

Risk signals can ask for more proof when something looks odd. They must raise the bar, never lower it below the floor.

• The floor stays. Low risk must never mean “weak method accepted.” Low risk may mean fewer prompts, not weaker proof.
• Tune carefully. Too many step-ups irritate people. Too few miss attacks.
• Explain denials. A clear message with a help route stops angry calls.
• Log the reasons. Later you can see which rule fired and why.

A strict policy that locks out the finance team on quarter-end day is a self-inflicted outage. Test before you enforce.

Okta provides tools to review which rule applied to a sign-in and to preview policy results. Their names and capabilities vary by release, so confirm what you have.

Authentication policy is among the most powerful settings you own. A careless edit can open a hole or lock out thousands.

• Treat policy like code. Keep a written record of every change: what, why, who approved, when.
• Require a second reviewer for changes to critical and high tiers.
• Prefer additions to edits. A new, narrow rule is easier to reason about than a change to a broad one.
• Test in a safe org when possible, then apply the same change to production.
• Announce changes. Support should hear before users do.
• Alert on unreviewed changes. A policy edit outside the change process may be an attack.
• Review all policies yearly. Remove old exceptions and unused rules.

Every key, passkey and device registration is born, used, aged, replaced and retired. Governing that lifecycle prevents silent decay.

flowchart LR
    A["Issue or register"] --> B["Verify the person"]
    B --> C["Active use"]
    C --> D{"Lost, stolen, or replaced?"}
    D -->|"Yes"| E["Revoke and replace"]
    D -->|"No"| F{"Person left or role changed?"}
    F -->|"Yes"| G["Withdraw and retrieve"]
    F -->|"No"| C
    E --> C
    G --> H["Retire and record"]
    

• Register only after a strong identity check.
• Review registered methods per person at least yearly. Remove unused or unknown ones.
• Watch for ghost registrations. Methods added by attackers hide among legitimate ones.
• Retire cleanly when people leave or devices are replaced.
• Record each step for audit.

Browsers, operating systems and Okta itself change every few months. A setup that works today can quietly break next quarter.

Give one person the monthly duty of reading these sources and writing three lines for the team: what changed, whether it affects us and what we will do. Small, regular attention beats a yearly scramble.

Strong authentication touches security, identity engineering, IT operations, HR, support, legal and leaders. When everyone owns it, nobody does.

• Name one accountable programme owner and a deputy.
• Hold a monthly meeting during rollout and a quarterly one afterwards.
• Keep an exceptions register with owner, reason, approver and expiry.
• Report to leaders on a single page of metrics.

You cannot manage what you cannot see. A few measures show how far the programme has come and where weak paths remain.

Okta’s System Log records authentication, enrollment, policy and recovery events, and you can stream it to your monitoring platform. Event names and streaming options change, so confirm them in current documentation. Build a dashboard that the owner looks at weekly, and set the tracked numbers into leaders’ reports.

Even with strong methods, you must notice when someone is trying to get around them.

Alerts Worth Having

• A new authenticator registered shortly after a password reset or recovery.
• Several failed or refused prompts for one person in a short time.
• Any use of a break-glass account.
• Change to an authentication policy, enrollment policy or administrator role.
• A weak method used to reach a protected application.
• A support reset for an administrator or executive.

When an Account Looks Taken

Thinking about failures in advance turns panic into procedure. Strict rules raise the cost of every failure, so plan for them.

flowchart TD
    A["Many people cannot sign in"] --> B{"Did a policy change recently?"}
    B -->|"Yes"| C["Roll back or relax the change under the emergency procedure"]
    B -->|"No"| D{"Is Okta reporting a service problem?"}
    D -->|"Yes"| E["Follow status updates and communication plan"]
    D -->|"No"| F{"Is one device type or browser affected?"}
    F -->|"Yes"| G["Check recent updates and compatibility"]
    F -->|"No"| H{"Is a signal or integration failing?"}
    H -->|"Yes"| I["Check device management and risk integrations"]
    H -->|"No"| J["Escalate with logs and examples"]
    

Strict policy needs an escape hatch for the day the normal path breaks. The hatch must be strong, quiet and loudly alarmed when used.

• Few accounts. Two or three, held by named senior staff.
• Strong and separate credentials. Long secrets and hardware keys, stored in separate sealed places.
• Excluded from risky dependencies. They should not rely on the same device checks or services that might have failed.
• Alarmed. Any sign-in sends an alert to security and leaders at once.
• Tested. Try them every quarter and record that they still work.
• Reviewed after use. Every use gets a written review and a password and key rotation.

Break-glass accounts are deliberately an exception to phishing-resistant rules in some designs. Record that exception, protect the accounts physically and keep their use rare and visible.

Auditors do not only ask whether you require strong methods. They ask how you know, and how you would prove it.

Collect this evidence as a habit, not in a panic. Save one export per control each quarter, with the date and the name of the person who checked it.

Strong sign-in often uses fingerprints, faces and device information. People are right to ask what is collected and who sees it.

• Explain where biometrics live. In most modern designs the fingerprint or face is checked on the person’s own device and is not sent to the company. Say so, and verify it for your chosen methods.
• Offer a PIN alternative. No one should be forced to give a body feature.
• Collect the minimum device information. Operating system version and encryption status are usually enough.
• Separate work from personal. On personal phones, avoid seeing personal apps or content.
• Limit who can see logs. Authentication logs reveal movements and habits.
• Set retention. Keep logs as long as audit and security need them and no longer.
• Be open. A short, plain notice builds trust and reduces objections.

Leaders ask what it costs and what they get. Honest numbers win trust.

Benefits to Count

• Fewer successful account takeovers, and fewer incidents, investigations and forced resets.
• Fewer password reset calls once passwords fade out.
• Faster sign-in for staff, which saves seconds many times a day.
• Better position with insurers, regulators and customers who ask about strong sign-in.

Phishing-resistant sign-in is a large security gain with real costs. Seeing both helps you plan.

Teams keep rediscovering the same good and bad habits. Naming them helps you follow the first and avoid the second.

Some beliefs sound sensible and lead to poor decisions.

A single page to run through before launch and every quarter after.

• Applications are sorted into tiers, and the top tiers require phishing-resistant methods only.
• Every person has two phishing-resistant methods registered.
• Weak methods are removed from enrollment and policy for protected groups.
• The final rule denies, and exceptions have an owner, reason and expiry.
• Enrollment of new methods requires a strong check, and notifications are sent.
• Recovery is as strong as sign-in, with delays, notices and trained people.
• Help desk staff follow a script, call back known numbers and cannot reset administrators alone.
• Administrators use hardware keys, separate accounts and the strictest policy.
• Break-glass accounts exist, are alarmed and are tested quarterly.
• Legacy protocols and local passwords are blocked or isolated.
• Device health is part of policy for sensitive access.
• Sessions are short for sensitive tools and can be revoked quickly.
• Policy changes are reviewed, recorded, tested and alerted.
• Dashboards and alerts are in place and watched.
• Accessibility alternatives and privacy notices are published.
• Key inventory and registrations are reconciled quarterly.
• Evidence for audit is saved every quarter.

Let us solve the problem from the start of this guide, step by step.

flowchart LR
    ADM["Administrators"] -->|"Two hardware keys"| CRIT["Critical tier: admin console, cloud admin"]
    STAFF["Staff on managed laptops"] -->|"FastPass or device passkey"| HIGH["High tier: email, claims, finance"]
    FIELD["Field staff on personal phones"] -->|"Phone passkey"| HIGH
    COUNTER["Shared counters"] -->|"Key per person"| HIGH
    CON["Contractors"] -->|"Hardware key with sponsor"| MED["Medium tier: collaboration and tickets"]
    CRIT --> OK["Okta policies: default deny"]
    HIGH --> OK
    MED --> OK
    

Six months later, when a new fake notice reaches the claims team, the page asks for a code and the person has none to give. The fake page cannot make the passkey answer. Meera, who once lost a mailbox to this trick, forwards the notice to security instead.

Numbers make the stakes visible. All figures here are illustrative and meant to show the thinking, not to predict your results.

Scenario 1: The Cost of Weak Fallbacks

Suppose 9,000 staff each receive one convincing phishing message per month, and 3 in 100 would fall for a fake page that relays codes. That is 270 compromised sign-in attempts every month. If phishing-resistant methods are required and weak fallbacks are removed, the fake page cannot complete the sign-in. If a text fallback stays available, attackers simply request it, and most of the 270 return.

Scenario 2: Support Calls Over Time

Before the programme, password resets run at roughly 1,800 calls a month. During enrollment months, calls rise to 2,400 as people need help registering. After passwords fade for most users, resets fall to 600 a month. The project pays back its extra month of calls within a short time, and each avoided call also avoids an attacker’s chance to talk their way in.

Scenario 3: The Lost Key

With 40 administrators, each holding two keys, 80 keys exist. If one key in 40 is lost in a year, two keys are lost. With a PIN and a quick revoke process, each loss is closed in minutes and costs a replacement. Without a second key, the same loss becomes a lockout and an emergency recovery.

You do not need to solve everything at once. A path of small, safe steps works better than one big promise.

The First 90 Days

When someone says “I cannot sign in,” a steady routine finds the cause faster than guessing.

The Routine

• Ask for the exact time, application, device, browser and what the person saw.
• Find the matching events in the System Log.
• Identify which policy rule applied and what it required.
• Compare with what the person has registered.
• Fix the case, then the cause, then look for others with the same pattern.

When you plan a new group or a new person, ask the same short questions in the same order.

flowchart TD
    A["New person or group"] --> B{"Administrator or privileged role?"}
    B -->|"Yes"| C["Two hardware keys with PIN, strict policy"]
    B -->|"No"| D{"Uses a managed company laptop?"}
    D -->|"Yes"| E["FastPass or device-bound passkey, plus a second method"]
    D -->|"No"| F{"Uses a personal phone willingly?"}
    F -->|"Yes"| G["Phone passkey with device checks, plus a hardware key as backup"]
    F -->|"No"| H{"Shared computer or no device?"}
    H -->|"Yes"| I["Hardware key per person with short sessions"]
    H -->|"No"| J["Review the case with security"]
    

• If a person cannot use any phishing-resistant method, record an exception with an owner, a reason and an expiry date.
• If a method cannot be recovered safely, do not choose it.
• If a group is large and diverse, split it and give each part its own method.
• If in doubt, pick the more phishing-resistant option and add training.

Most rollouts stumble on small details that nobody wrote down.

Success looks quiet: small routines, few surprises and no heroic rescues.

Notice what is missing: no mailbox takeover, no midnight reset marathon and nobody asking how an attacker got in. That calm is the real product of careful work.

Teams repeat the same early mistakes. Knowing them in advance is a cheap kind of experience.

A strong rule that people work around protects nothing. Leaders and staff must see why, and must find the new way easier.

• Start with a story. A real or realistic phishing case lands better than a slide of statistics.
• Win leaders first. When executives enroll first and say so, others follow.
• Make the new way faster. Show the one-touch sign-in beside the old typing of codes.
• Offer help in person. Walk-in sessions beat long documents.
• Name champions. Respected people in each department answer questions and report problems.
• Listen and adjust. Publish the changes you made because of feedback.
• Celebrate milestones. Report enrollment percentages, blocked attacks and reduced calls.

Engineers move on. A programme that only one person understands is a risk with a name and a leaving date.

Once a year, ask someone new to follow the recovery runbook in a test copy. Wherever they stumble, the document needs work.

Quick plain-language meanings for the words used in this guide.

Short answers to questions that come up in almost every project.

Phishing-resistant authentication gives sign-in a property that codes and approvals cannot: the proof works only on the real address. The rest of the work is making sure no weaker path remains.