Loading summary
A
Hello, everyone, this is Tom Muren. I'm here with another Risky Business News sponsor interview. Today I have with me Brett Winterford, who is the VP of Threat Intelligence at Okta. G', day, Brett. How are you?
B
I'm well, thanks, Tom. Thanks for having me on.
A
Yeah, it's great to have you. We haven't spoken for a while, but you sent me a blog post from Okta which talks about, I guess it's a part of a phishing campaign where the threat actor actually explicitly says, do not sign in with Octa FastPass. It's causing problems with login processes and obviously that's a fiction. Now, I've heard you talk about Okta FastPass before and I've never really had a good idea of what it actually is. So can you first of all tell me, what is it? How does it work? Why would red actors even care? What difference does it make from their perspective? That seems like a good place to start.
B
Awesome. FastPass is the passwordless sign in method that's built into the Okta Verify app. So the Okta Verify application is the client that sits on your mobile device or your desktop that you authenticate with if you're an Okta customer? In most cases. Yeah. And the design goals for FastPass when we created it was okay. We want to create passwordless authentication. We want it to be the most usable and deployable and secure way of signing in. So usability, it's passwordless. It can be zero click or one gesture and you're signed in. So something much easier than passwords and OTPs.
A
So presumably when you enroll and set it up in the first place, there's some process that's robust to say this is tied to a particular device and person.
B
That's right.
A
And then once you've done that, it's okay because it's device based. Bob's your uncle. We've got a lot of trust in that agent or whatever it is.
B
Exactly, yeah. So basically it's relying on the power of public key cryptography to do that. So at the time that a user enrolls with the service, cryptographic key pair is created, the private key stays on the device, public key goes to the Okta service, so that when you sign in, you are able to prove possession of that secret key without having to reveal the key. So basically you sign a challenge that proves to the Okta service that, yes, this is the user and device coupling that we expect for that sign in, which then can enable that user experience. That's really easy. And it can be Run in phishing resistant mode. It can be run in either. So if you enforce phishing resistance in policy in the Okta identity engine, then FastPass checks that the origin of a challenge matches the domain that was configured at the time of enrollment. So if it isn't the same origin as the time of enrollment, then the sign in fails and Okta will then warn the user and also create a system log event in the back end for Okta administrators or security teams to act on, knowing that the user was trying to sign in through attacker infrastructure.
C
Right, right.
A
So it's kind of a bit like certificate pinning, but not as strong. Right. So it's just at enrollment and I guess if your infrastructure changes, you would force them to re. Enroll into a new domain or whatever. Is that the. It's sort of a compromise.
B
Correct. But you know, you're not going to have a lot of infrastructure changes in a, in a cloud or cloud kind of environment because it's the Okta service is the infrastructure. So.
A
Yep, yep. Now why would someone not run it in phishing resistant mode?
B
Because there are certain examples, edge cases, I guess, where phishing resistance, whether using a photo key or a fast pass is going to cause a problem that can happen, for example, when you are first or onboarding with some mobile device management tools, that kind of thing, usually there's a thick client application involved, there is some kind of enrollment activity enrolled. And what you can do in Okta is you create authentication policies for all the resources that you want to restrict to phishing resistant authentication. And then you might have some examples where you don't require phishing resistance because it simply won't work.
A
So you've got that as an option because you need to have it as an option, but it's not for the 1% of 2%.
C
Yeah, right. Okay.
A
And so we've got the sort of basics of what FastPass is. What's the implication for the threat actors? Why are they telling people? I mean, obviously they can't phish it.
B
But yeah, that's the thing. So what we see is that as more and more of our customers use phishing resistant authentication and enforce it in policy, whether it's using FastPass or Fido. But FastPass is the one that's had the most dramatic growth. There are a few ways to be able to successfully bypass, I guess, the authentication process. One of the ways they might try to do it is to convince the user to cancel out and downgrade to an MFA factor that offers less resistance to phishing. So push or OTP sms, something like that. So if the user is enrolled in multiple authenticators and the policy allows them to sign in using any one of those authenticators for a given resource, then the attacker's objective is to try to have them downgrade. So we've seen some examples of that in the past. For example, we saw some campaigns a couple of years ago where the adversary in their phishing lure said, please remove your physical security key from your device for the next seven hours. I mean, that was a pretty obvious one.
A
And they just construct some sort of rationale for that.
B
Exactly.
A
And some percentage of people will buy it for whatever reason and do that. Is that the way it works?
B
That's the way it works. We also saw something really interesting recently. It was covered on the show, actually, where some threat researchers had assumed during some phishing activity. We saw in March that attackers had managed to bypass cross device authentication in Fido because the attackers had thrown up a page. It was a kind of a live human operated phishing kit, in this case, where the attackers are choosing what the next page they present to a user in the phishing kit, depending on what signal they're getting. And this one threw up a QR code for cross device authentication. I think there was an assumption from the external threat researchers that they'd found a way to bypass it, when in fact, I mean, you think about it rationally if that user should be signing in using passkeys. But there are other factors available. What would you do as a user if you've tried to use the passkey that's on your mobile device to authenticate and it didn't work right. Maybe you try again, but then maybe you'd actually just cancel out, select a factor that is something that they're able to bypass. And that's what happened. Yeah, and that's what happened here with the FastPass example. So in this case, the attackers had configured a rogue Slack tenant and then they had taken the profile information of the CEO of that company, so the photo and the title and the name of that individual, and created that as the administrator of that tenant, started inviting targeted users to this Slack tenant. And then they found a way of smuggling in phishing links to an evil Gen X powered phishing kit. So anniversary in the middle phishing kit into the notifications that are sent to the email inboxes of users that were invited to that particular Slack tenant. And what they wanted to make sure of is that none of the Targeted users used FastPass because if they did not, not only would it fail and they wouldn't succeed in their objectives, but it would also create a detection event that would not just result in burning their infrastructure for that customer, because it creates a system log event for those customers. But every, you know, every day our team is warning dozens of organizations that there is phishing infrastructure that has been set up that appears to be targeting, or at least there's been domain set up that appears to be targeting their users. And we have a range of detections, but one of the global detections is that those system log events created when a FastPass enrolled user tries to authenticate via a proxy. And so for every one of those detections, there might be 15 other user interactions in Okta system log. And we can use that intelligence to feed the broader product and help other customers, particularly highly targeted customers who use a product called Identity Okta Identity Threat Protection, to also be protected from that phishing structure.
A
What happens there if they try FastPass, that is a pretty strong signal that there's a phishing attempt and it points to the adversary infrastructure.
B
Because that's right.
A
It must do. Right?
B
Yeah.
A
And that just tips you off that this is going on. And then you can look for that domain or whatever.
B
We can analyze the domain and the structure behind it, figure out the intent, and then that can be fed into our broader set of products so that that particular ip, if anyone else tries to interact with that ip, there can be automated responses to that activity.
C
Right. Okay. Okay.
A
And so that means that if they're going to scale a campaign, they've got to have many, many different IPs, because I guess getting many, many different domains is probably not that hard, but getting many, many different IPs is maybe a bit harder, perhaps.
B
I mean, either way, we're imposing costs.
C
Right.
B
And that's, that's the point. So they want the user to downgrade to a lesser factor. And I think MFA downgrade is a subject that maybe everyone should be looking at at the moment, because across the board it seems to be as, as the world embraces methods of signing in with higher assurance, this is where attackers are going to have to go. They're either going to have to attack the enrollment or the recovery processes. We've seen that obviously with, you know, the scatter swines, gutted spider attacks on help desks, et cetera. Or they're going to try and force a downgrade.
C
Right.
A
That was going to be my next question. I guess that does seem to be the logical conclusion is why have a phishing susceptible backup method? What's the point of Installing a phishing resistant one if it's just relatively easy to push users back to the phishing susceptible one.
B
Yeah, and the key lesson, I guess, for our customers is enforce phishing resistance in policy. And you don't have to worry about it. You just have to make sure that your users are enrolled in multiple phishing resistant authenticators. So I've got FastPass set up on my laptop and my mobile. I've got a. I happen to have a physical security key as well enrolled. So I never need to call a help desk. Even if I ever did have a problem in the future with FastPass or I lost my device and I had to configure a new device, I would have sufficient sufficiently strong authenticators in reserve, waiting ready to go. But then you also have to design your help desk processes to account for that. So what are the scenarios in which a user might be calling up the help desk and needing to verify their identity? In our case, we're able to push authentication challenges to a user before leaving to open a help desk ticket. If a user can't satisfy that and they're a certain kind of privileged user, for example, you might have to have policies that say there is no remote recovery for that authenticator. The investment that people need to make in the first instance is to ensure that they have sufficient number of strong authenticators that they are decommissioning older forms of authentication that they don't need any longer and enforcing phishing resistance in sign on policies for anything that matters.
C
Right, Right.
A
So I guess the. There's sort of costs on both sides, right? So there's the cost of rolling out phishing resistance, there's the cost of getting compromised because you've got.
B
One thing I should say is you said there is the cost of rolling out phishing resistant authenticators. Well, for an organization like mine that insists on every user having a physical security key for their first enrollment. In other words, to unlock the device for device access, you require a physical security key, which then can become a recovery key from that moment on. Now, not every organization is going to roll out a physical security key to thousands and thousands of users. That's why FastPass is becoming more and more popular, because it's just a software client to push out. It's far more economical and deployable as a means of allowing a tightly managed, high assurance form of authentication without actually having to invest. So the cost of change is the only cost. It's the change comms. It's convincing users to change from the method they're using today to a more secure method.
A
So you say that the FastPass enables you to actually detect phishing attacks. What are the sort of trends that you're seeing there?
B
So we've sent 1,000 notifications over the last three months to organizations where I've said, it appears that there is phishing infrastructure being configured to target your users. And that is a 200% higher than this time a year ago, at a time when the total volume of fishing activity, if you look globally across the industry, the Anti Fishing Working Group puts some numbers together every quarter and they're saying that the total number of fishing campaigns has plateaued, albeit at a very high level. But there isn't any dramatic growth in phishing at the moment. So we put it down to a couple of factors. One, the range of detections that our team has in place is expanding all the time, but two, that there has been a fairly dramatic growth in the use of FastPass in our customer base. It tends to double or triple every year. And so the more that our customers are enrolling their users in Okta, FastPass and applying phishing resistance in policy, the more signal that gets created, the more detections that then can protect other Okta customers.
C
Right, right.
A
So you're getting better and better visibility into just the outrageously high number of plateaued phishing. So, good news, I guess?
B
Yeah, I think so. I think so. Well, when. When we get to, you know, 80 and 90% of our users using FastPass, then we'll be in a very, very good place.
A
Brett Winterford, VP of Threat intel at Okta, thanks very much.
B
No worries. Thanks.
Episode: Sponsored: Why threat actors hate Okta FastPass
Date: August 25, 2025
Host: Tom Muren (A)
Guest: Brett Winterford, VP of Threat Intelligence at Okta (B)
This episode of Risky Bulletin explores why attackers fear Okta FastPass, focusing on the mechanisms behind Okta's passwordless authentication, how it raises the bar for phishing resistance, and the impact it's having on threat actors’ tactics. Host Tom Muren interviews Brett Winterford of Okta, shedding light on FastPass’s technical details, real-world incidents, and broader implications for organizational security strategy.
The conversation is pragmatic, technical, and down-to-earth, with a focus on practical security implications and organizational reality rather than hype. Brett Winterford provides concrete examples and actionable insights, while Tom Muren keeps the discussion accessible and grounded.
Okta FastPass provides strong, scalable phishing resistance in a user-friendly form. Its widespread adoption is not only thwarting attacker tactics—forcing adversaries to invest more to circumvent controls—but also bolstering detection rates for the entire Okta customer community. The key to maximizing this benefit is robust policy enforcement and user enrollment, balanced with thoughtful help desk processes and change management. As organizations further embrace phishing-resistant authentication, attackers are forced to adapt—and the cost of attack continues to rise.