Okta FastPass: a leaked password should not be enough to get in

A question I was asked recently: is an Okta FastPass rollout worth the effort? Yes. I would put it ahead of almost anything else on an identity roadmap, and this is the longer answer.

I have watched the right password arrive from the wrong place more than once. When FastPass was in front of it, that was the whole story: a failed sign-in in the log, and nothing else.

Rolling out Okta is not the finish line

Single sign-on puts every application behind one sign-in. That is the point of it, and it is also the risk. The same sign-in that saves your staff forty passwords now opens forty applications for whoever gets through it.

So the strength of that one sign-in is the whole game. If it is a password and a push notification, you have built a very convenient front door with an ordinary lock. The other half of this is in What SSO actually buys you.

What a leaked password buys an attacker today

Passwords leak. They get reused on a site that gets breached, typed into a convincing page, or lifted off a laptop by malware. Assume any given password is already out. The useful question is what it gets someone.

With a one-time code or a push notification as the second step, the answer is often everything. Modern phishing kits do not just copy your password. They sit between you and the real sign-in page and pass along whatever you type or approve, as you do it. You enter the code, they use it. You tap approve, because you did just try to sign in, and they walk away with the session.

This is not theoretical. In 2022 Microsoft described one campaign of this kind that had targeted more than 10,000 organisations since the year before, stealing session cookies after the victim had already completed MFA.

What FastPass changes

FastPass takes away the thing every one of those attacks relies on: something the user can be tricked into handing over.

When a device is enrolled in Okta Verify, it gets its own private key. At sign-in, Okta sends a one-time challenge, Okta Verify signs it with that key, and Okta checks the signature. There is no code to type, so there is no code to steal. Okta Verify also checks that the request is coming from the real Okta sign-in page and not a lookalike, so a fake page has nothing to pass along.

The password can still leak. It just stops being enough.

The layers, in plain terms

FastPass is not one setting. It is a few, and each one answers a different question.

Is this the real sign-in page?

Phishing resistance. The fake page gets nothing. In the sign-in policy, this is the possession factor set to phishing resistant.

Is the key stuck to this device?

Hardware protection. The key can be required to live in the device's secure hardware, the TPM on a Windows laptop or the Secure Enclave on a Mac, so it cannot be copied off and used somewhere else.

Is a person actually there?

User verification. A fingerprint, Face ID or the device PIN, so an unlocked laptop left on a café table is not the same thing as the person who owns it.

Is the device in decent shape?

Device assurance. Okta Verify reports things like the OS version, disk encryption and whether a screen lock is set, and your policy can turn away a device that falls short. This works on devices you do not manage, too.

Is it one of ours?

Managed devices. Optional, and the only layer that needs your MDM: a certificate pushed to company laptops lets the policy say "only our devices" for the applications that matter most.

Put together, a leaked password on its own gets an attacker a failed sign-in in your logs. That is what peace of mind looks like in an identity system. Not that nothing bad ever happens, but that the most common bad thing stops working.

What it does not fix

FastPass makes the sign-in hard to fake. Attackers know that, so they go around it. Plan for these before you call the project done.

• The help desk. In 2023 Okta warned that attackers were calling IT service desks and talking staff into resetting MFA on super admin accounts. FastPass cannot help if someone hands the attacker a fresh enrollment. Verify callers properly, and most of all for admins.
• Enrollment. The moment a new device is enrolled is the weak point. If a password and a push are enough to enroll a device, an attacker can enroll theirs. Require a phishing-resistant factor, or a verified help desk step, before a new device is added.
• Fallbacks. If the same policy also accepts push or SMS, the attacker will pick push or SMS. Require phishing resistance in the policy itself, not as one option among several.
• Stolen sessions. If malware lifts a session cookie from a signed-in browser, the sign-in has already happened. Shorter sessions for admins and sensitive apps, and binding admin sessions to the network they started on, limit how far a stolen one goes.
• Browser extensions. Researchers have shown that a malicious extension with broad permissions can undermine the check on the sign-in page. Control which extensions your browsers allow.

How I would roll it out

1. Admins first. Require FastPass for the Okta Admin Console before anything else. It is the smallest group with the most to lose, and I explain why in Your Okta tenant, day one.
2. A pilot group, usually IT, on a test app. Check the sign-ins show up as FastPass in the logs before you go further.
3. Applications in batches, a few days apart, starting with the ones that hold the most.
4. Close the gaps: phishing resistance required in the policy, enrollment protected, the help desk process written down.
5. Then device assurance, and managed devices where they matter.

Two practical notes. Chrome now asks users for permission when the Okta page talks to Okta Verify on their machine, so push the Chrome policy that pre-approves your Okta domain before rollout day, or your first morning is a queue of tickets. And do not roll out Windows Hello for Business at the same time. Okta's own guide says to keep them apart, and I agree.