Security Deep-Dive: Adaptive Authentication for Enhanced Security

Snegha Ramnarayanan​: Great. Well, good afternoon everyone. Thank you so much for being here. My name is Snegha, and I'm on the Sales Engineering team, specializing in the security products. So first up, why are we here today? I know some of you attended the roadmap, so I really hope that gave you an intro into what's coming up, what's new. But I know a question always comes up, "What can I do today?" So, what I want to give you today, is a toolkit of what you can do today.

When you get back and you're able to set things up in your environment and say, "Hey, that feature that she mentioned, it actually solves this problem for me." Once we get through that, we're joined by our Product Manager for Adaptive Authentication, Neha Anand, who'll give us a sneak peek into what else is coming out with Adaptive Authentication.

So how did we get here? So we all first think about single sign-on authentication, Okta login, and all of that. Then we said, "Do right credentials actually mean the right user?" Somebody having username, password, actually imply that this is actually who you say you are. That's where we introduced multi-factor authentication. And I know all of you have gone through the project of MFA everywhere, or we need to add multi-factor authentication here, because we had a phishing attack, different things like that.

So that's where Okta comes in and Okta's really been pushing the barriers on how we can do multi-factor authentication. And I hope you've had the chance to see all the different ways and factors that we offer, to integrate with both third-party providers, as well as natively offer multi-factor authentication for your different applications and integrations. So is that it? Is that all we do when we say we do MFA everywhere, and that's where we stop. So we clearly realized that's not enough because we no longer live in limited boundaries. We don't have just physical context. We can no longer say, "Just on or off network." We have to think about more. We have to think about dynamic context, context that changes. What do you need to know about a user before you can act or decide on if it's yes, no, step up MFA, or maybe some other reaction.

That's where adaptive MFA comes in. It's all about contextual access, along with the decisions that you want to customize for your organization to lead to. I know that something that you've all been hearing a lot today, which is, we have to match security and usability. And we hope with some of the features that you're going to see today, you've seen how we've taken some steps towards that. And then get to see some roadmap as well.

So first step, I know the word "network zones," is already very familiar. You all have blacklists, whitelists, and things like that. So how is this adaptive and what has Okta done to help you there? This is broken down into three pieces. So first step, Location Blacklisting. I'm sure you've all had different data metrics that you've run to see where are your threats coming from, where are these logins that weren't the right logins coming from? Location Blacklisting gives you the ability to granularly say, "Hey, this location, this region, should just not be able to access Okta." And you can make those decisions based on many different things, based on the data you already see.

Next step is IP Reputation. So, I know we have you create these blacklists based on what you know, and what you want to decide, but Okta has engines on the backend, that can give you very useful information about an IP address. So in our system log, when you have IP Reputation, you get to see all the different information about this IP, within Okta. You can look at that and then react and say, "This doesn't look like the kind of IP that I want access from." So I'm now going to block it. I'm going to add it to my blacklist.

Last, but not the least for network, is Tor Detection or Proxy Status. What this means is, we are able to combine policies with being able to check if you're coming from a Tor node, if you're on a proxy, or not on a proxy. You can combine this with the other Okta policies to really define how access comes in, on or off network.

So next, we're going to talk about Behavior Detection. So behavior detection is just like it sounds. I know a lot of us have security breaches. We talk about different things, and the first thing we ask ourselves is, "Is there something that I should have noticed before, that could have helped prevent what just happened?" That's exactly what behavior detection is about, it's asking you, "Is there something off about this user's authentication? Is there something different about the way this user's logging in this time?"

So we're doing this in a few different ways. So first is, we have new device, new IP, new location, and they're just as they sound. You get the ability to configure within Okta, how many authentications you want to compare that data with. And then, create a policy to say, "If they're coming from a location that I really haven't seen before, I really think they should MFA further." Or maybe, you want to create a different policy based on the user, and what their typical behavior is. So we do that for a new device, new IP, and new location.

And then, and this is one of my favorite features, because I can call it superman, Velocity Behavior. It's basically to cover impossible travel. And what that means is, you've been logging in from Vegas just now, two minutes later, you're coming in from San Francisco, that's clearly not possible. So impossible travel gives you the ability to detect travel that's not possible. And the ground speed is configured by you, so it's completely ... It's not a black box, it's something tailored to your needs, to actually act and ask yourself, are these behaviors common? Should I be taking different security measures? And what you'll notice is, some of these things directly address some security threats that you may be seeing in different parts of your applications.

So the third bucket here, I know this word comes up a lot, devices right, because like I was saying before, no longer is access static. So that ends up meaning I can't just ask you for your username or password or just one ID and say, "You're good to go." I have to now wonder, how you're accessing something. And a big thing, and I know most of you must have thought about this is endpoints. And endpoints could be anything, could be the type of clients that are coming in from, it could be the kind of devices that you're coming from, laptop, at home, your mobile devices.

So how can Okta look at these things, and include them in our security story? So first is Client Filters. What is Client Filters? Something as simple as saying, "Okta has the ability to see what type of device you're accessing Okta from." And you should be able to decide what your access policy is, based on that. A common story I hear from customers is, "Hey, I know what my laptops are doing because I control them in a certain way. But mobile devices are a little different. I want to treat them a little differently." So using Client Filters, the first thing that you can do is create a different policy for desktop versus mobile. Or even more granularly, iOS, Android, Windows, Mac, all separately.

Next step is new Device Behavior. I know we just talked about new device, and how we can use that for our policies, so there's one other feature that we have with that. We now offer the ability to do new device emails, which means any time you're coming in from a device that we haven't seen before, we will send you an email, so that you, as a user, are aware of how your credentials, how your account is being used and so that you can take actions based on that as well.

Now, the third piece is Device Management. And I know a lot of you may be using some EMM tools, you may be using JPOs, policies, domains, and you may be managing your devices in many different ways. And of course, access should also be based on those security policies that you may have. Of course, as you may have seen with a lot of our announcements, we're trying our best to give you not just integrations, native capability to be able to detect this management before you access Okta.

So how we do this is currently, we offer this on iOS and Windows. And the way we do that is asking, "Is this device enrolled in a MBM solution?" Or, for laptops, "Do you have an Okta issued-certificate? Is this a device that I trust?" And what this gets you closer to is being able to say, "Not only is this the right user, but it's also the right device that's accessing my Okta secured applications."

Those are the three highlights of all the features that by the way, you currently have, and can use. And what I wanted to do is show you a quick demo on how can you configure this within the Okta portal. As well as a quick Velocity Behavior demo as well. So let's go into that.

So first step, we're going to go to your portal that you're all familiar with. And you may not have some of the features that I'm going to show you today, but they definitely are something you can add on. As you'll see, the many different things that I talked about, are now under security. So first step, let's look at behavior detection. This is as simple as you creating a policy for you to decide what you define as impossible travel, for example. Or, you can have new IP, and you get to decide what this X-number of authentication means to you, because each company's unique, each security story is unique.

Once you configure these, you'll notice that there's nothing different about the way you configured these policies. You go in here and all you need to do is you have a section now that says "And Behavior Is," and you can combine, not just Velocity, but many different behaviors together, for you to decide what's an anomaly, and what's weird, what's different. And this can be combined with your different MFA polices that you already have, and also be done on a group basis.

So next we have device trust. I know some of you may have seen this in previous sessions. So just to come back to that device, trust is again, under our security policies, very easily configurable. You just create your policies here, and of course, we drive back to our applications and what that means on an app level. So if we look here, I know Office 365 is a very commonly used application, and many different things in this sign-on page, get you closer to being able to create your security rules. So everything from the protocols, to the device types, combined with device trust and MFA. And of course, all the behavioral policies at the Okta level will get you closer to addressing your security needs.

Now, what we're going to do is actually try to log in. So I'm going to log out of this account. I'm going to use another account. So right now, we're in Las Vegas, and I'm going to show you also how this data shows up within Okta. So if I log in here, you'll notice that I didn't have to MFA. This is where I've been logging in from for the past two days, so it is a secure login. And now, I'm using a server here, just for demo purposes, but we're going to login to a server, and I'm going to show you the location for that as well. But we're going to try to attempt the same thing. We're going to log in to the same tenant as the same user and what you'll notice is that I should be prompted for MFA. So just like you saw there, it detected that this is not the policy that I usually use, there's something different about my account. So now I'm only going to be logged in using Okta Verify with touch ID. Without doing that, that anomaly is detected and you're able to address that use case.

Now, you wonder where this goes in, right? So if we go back here, and the reason I mention this is, a lot of us talk about security and data going really closely together. And Behavior Detection is something that really gets you closer to not just making your Okta access decisions, but really using those to be able to create your policies outside of Okta as well. So let's take a look at that.

So this is the user, and, I actually may have to switch screens there. But I hope the demo showed you what you're able to do with behavior today, and luckily, everything that we presented, is something that you can use today in your Okta environment. So now that we've seen what we have today, that's clearly just the first step that Okta has taken to get closer to adaptive MFA. So now, I'm going to introduce Neha Anand, our Product Manager, to give us a sneak peek into what's coming next.

Neha Anand: Okay. Thank you Snegha. So that was a lot of good information. And the best thing about everything she shared with you, is that it's all available in the product today, either in production or in EA, soon to GA. And so if you are not already taking advantage of these, I would recommend that you explore these options and try to use it in your account to secure your users.

With that, let's start with the next section of this session. Hi, I'm Neha, I'm the Product Manager for Adaptive Authentication. This is my intro number three. This is my first time, this is my first time actually, so I'm very excited to be here and to talk to you about division that we have for Adaptive Authentication, and the top initiatives that we have for 2018.

So I've been in the security industry for a little bit now. And one thing that I have seen very often, and heard from several security professionals, is that there is a trade-off between security and user experience. So if you want high security for your organization, which I'm sure everyone in this room does, then there is a certain impact to your user experience that you have to bear with. So we, the adaptive authentication team at Okta are aiming ... so this is our vision to bring a balance between the two, and at the same time make sure that the right user continues to have access to the right resources.

Now there are two questions then: how do we plan to do it, and what does it mean? What would the user experience be like? What does it mean when we say that the right user would continue to have access to the right resources?

So let's look at the first question: how do we plan to do it?  Okay. In very simple terms, we are collecting a bunch of relevant information that we will be using to create the profile of your right user, and continuously evaluate that profile to look for changes, good or bad, and then respond to those changes accordingly.

Now, the evaluation process could be either rule-based, which is ... some of which is already present in the product today that Sneha talked about earlier. Or, it could be risk-based which will be using a machine learning model. As far as the response is concerned, you have the option to either not prompt the user for anything, if it's the say ... your user is the right user, so you may not take any action and let the user continue to use whatever, you know, the service that they are using. Or you can prompt the user from a bunch of factors, or you can deny access to the user because it happens to be a bad user.

To build a profile of the user, we have identified six different contexts. The first one here is user context, which is mainly the user behavior, where we can look at how often does the ... so what's the normal working hours for the user? What are the locations that the user normally logs in from? What was the authentication method used by the user? Say, number of devices, or what type of devices does the user use?

The second context is device context, so is the device known, secure, or it's a jailbroken  device?

Then we have the location, an IP, some of which Sneha touched upon earlier.

And then we have ... the fifth one here is the application context. Does the application have sensitive data? What type of privileges does the user have? Does the user have access to those applications or not? Is the user an admin, a super admin, or just a regular user for that application?

And the last one is Okta Threat Insight, which is basically where we look at data across all of our customers and come up with threat insights that can be used by everyone in their policies, to identify risk.

So this here is not an exhaustive list. This is a sample of all the different attributes across these contexts that we will be evaluating, and use it to build a profile of the user. The ones in green are the ones that are available today, and you can use it through the rule-based policies. And the rest are things that we are planning on supporting in future.

Now once we have all these attributes, or the values for these attributes for a user from each event collected, based on the changes, we can respond accordingly. So you can match your authentication or your response to the risk observed from any changes to these context.

So for example, this here is a safe user. This user is logging in within the known working hours, using a known device which was probably issued by your own company, from your company headquarters, and is on the company network, is trying to access an application, Office 365 in this case, and this IP is not a suspected IP based on Okta Threat Insight.

Now this is a very low risk, low to no risk user. And for this user, we may just prompt the user to present a password and login. Now say some of these contexts change now. So, this user is still logging in within the working hours using the device, using a company-issued device, but now the user is logging in from a location that is not known to us from an IP or a network- from an IP that was not known to us, and is trying to log in to. Now this IP still happens to be not suspected by our Okta Threat Insight. So some of the contexts have changed, so this is a moderate risk. So we may prompt the user to present a stronger level of authentication, which could be Okta Verify with Push.

And the third example that I have, this is a scenario where we are seeing high login velocity from the user. It's a device that we have not seen before, a location and a network that we have not seen before, and this user is attempting to log into AWS. And it happens that this IP is a suspected IP and is a risky IP, based on what Okta Threat Insight tells us. So it's a high risk scenario, and in this case we would want to prompt the user for must stronger level of authentication. It could be Okta Verify plus AWS.

Now this is just an example. You can use your own choice of factors that you want to present based on your risk definition. And in this example as you can see, all of these six contexts are on red alert. But in a real scenario, it's possible that even changes to one single context can end up in a high risk situation.

So now that we know what our plan is, like what do we want to do around our vision. Let's see user experience would look like.

This user here is your safe user. Sixty to seventy percent of your enterprise users would fall into this category. This user logs in from office or from home using a company-issued device, or their own personal phone, maybe iPhone or Android. So what would be the experience for this user like? So when the user goes into office, goes to office, they log in and they are prompted to log in using Okta Verify. Once they do that successfully, they continue to access the applications as needed throughout the course of the day, and they're not prompted to authenticate themselves again. Now once they are done, they go back home and at home ... when they are at home, because we have already identified that this is a location that the user frequently logs in from, and a network that the user frequently logs in from, the user won't be prompted to authenticate themselves again and they can continue to use the service without any interruptions.

Next is a user who is your ... one second. Next is a user who travels a lot, so this could be your sales person or your SE who travels a lot. So the experience in the office stays the same as the previous user, but once they move to say ... they are in the airport, so based on the IP information and the location information that we get, we can identify that this is a public IP and based on that, some of the policies would kick in.

So for example, in this case, because a new IP and a new location has been detected, we would prompt the user to authenticate themselves using Okta Verify with Push, and maybe some other factor along with it. And in this example, what I have taken is that we ... the policy that kicks in also changes the session length, and so if the user tries to access any application beyond that session length, they will be prompted to authenticate themselves again. And the last example is of a user who is a malicious user, and they have just got access to the credentials and they are trying to log into an app; AWSS3. And in this case, it's a new device, it's a new location, it's a new IP. So we prompt the user to say present password and Okta Verify with Push. They have the password, but they don't have the second factor, the Okta Verify, which they are unable to present, and has therefore they're not able to log in and their access is denied.

So as you can see, there are a lot of different pieces that need to be put together to complete this picture, some of which is available in the product today, and some of which is what we are working on. With keeping that in mind, let me walk you through the top three initiatives for 2018.

The first one is Okta ThreatInsight. This is one of the six contexts that I talked about and you've already heard a lot about it in the keynote and the security roadmap sessions. The second one is factor sequencing. It's a key piece, it's a key concept for our contextual response. And the third one is risk scoring, which will be the basis for our risk-based policy.

Okta ThreatInsights. A friend of mine used to say that you don't always need to experience everything by yourself to know what the implications would be. Sometimes you can learn from the experience of others and make the right decisions, and particularly the bad experiences. And this in my opinion is the underlying principal for this feature. Okta has this wonderful vantage point from where we can see billions of events across all of our customers and come up with insights and patterns that can benefit other customers as well, particularly the threat patterns.

So for example, there is a customer A and an employee of that customer A clicks on a link, and a malicious bot gets installed on their device. Now this bot can then fan out a phishing attack to other employees on the network. Now Okta can look at all the events before and after a threat attack and come up with a pattern design and use it for other customers as well. So say there is a customer B where we observe a similar sequence of events, we can proactively preempt that attack from happening.

Now this is the broader concept around Okta ThreatInsight, and in phase one what we are focusing on is to apply this concept at the IP level. So we will look at all the IPs and the events that are coming from those IPs, analyze those events to see if those are malicious in nature, and then tag those IPs as risky IPs. And this information will be available to all the customers. They can use this information in their policies and make a decision of how they want to respond if an event, or a login event originates from one of the risky IPs.

Next is factor sequencing. Now this is an important concept for us in terms of the contextual response. This is also a first step, this is also our first step towards helping you move away from passwords; so basically eliminate passwords.

I don't think anyone here likes password, particularly the complex ones. Some of you are probably using LastPass or a similar product to manage the passwords across all your accounts, but many of us here are still relying on our memories to remember the passwords. I mean I personally use the same password across many of my accounts, and I don't think we need to iterate more on how painful using passwords is from the user experience point of view, and how insecure a password can be. So coming back to point, this feature here gives you the flexibility to use a factor of your choice and be able to prompt for stronger authentication factors, depending on what is a risky scenario for you.

The other thing I want to highlight with this feature is that there would be ... what we are trying to do here is a shift in the concept of authentication method. So today, in the current setup, you think of authentication as primary authentication and secondary authentication. Primary authentication is always password, and secondary authentication is some other factor that you present in combination with the password. But with this, we give you the option to define your own authentication method, irrespective ... so we move away from primary and secondary. It's just authentication method, and this authentication method could be either a single factor, or it could be a combination of factors. Now if you are using a single factor, then our recommendation would be to use a stronger authentication method; say for example Okta Verify with Push. If it's a combination of factors, say one or more factors combined together, then you may or may not use passwords as one of your options. It could be say, SMS plus Okta Verify. So that is the flexibility that you get with this feature.

And the last topic on my list is risk scoring. Risk scoring as I said would be the basis for our risk-based policy. This feature, as the name suggests, is meant to compute the risk score for a user based on the most recent login event, and compared with the historical profile that we have created for the user. The risk score will be computed continuously and ... one second. Yeah. And as you can see, that the centerpiece for this model is a machine learning, this whole feature is a machine learning model, and the ... so all these events are fed into this model. It computes the risk, we will evaluate the risk score, and then decide upon the action that needs to be taken.

So in this case, this user is a low risk user, and so we may just prompt the user to present a password. You may even choose to not prompt the user to authenticate themselves, because it happens to be the right user. And the other thing to note here in this model is in addition to continuously evaluating the risk score of the user, we will also be continuously updating the profile of the user based on any new information that we get around the user. So that would be the feedback that goes into our training dataset, as well as updating our records for the user.

Neha: As well as updating our records for the user. This other user that you have has a moderate risk. We prime the user for Okta verify. This one is a risky user. We primed them for Okta verify and some biometric method of authentication similarly for the other users, you know. The model or the policy engine would take into consideration all the events, the attributes across all the contacts that we get, spin up a risk score, and then take the action accordingly.

This is the concept, and I can think of at least two questions that you guys have in your mind. The first one would be what is this model like? What is going on in this model? And the answer to that question is what we are working on and we aim to answer it in 2018. As we get more information we can share it with you on a need basis.

And the second question is would you as a customer get the option to change around some of these controls to define what the risk scoring process will be like. And the answer to that is yes. I don't know if you can notice. Come on. What? Yes. Sorry. So, again. Anyway, what I was trying to show is that those bars over there is to give you an idea that, yes, we do want to expose some of these controls, these knobs to use, that you can turn around and define it based on your definition of risk.

And for that I have an open request to all of you. If you have a use case or a requirement for this capability we would really appreciate if you can share that with us, your business need for us, and your use case, so that we can factor it in our design process, and deliver you a product that meets your requirement.

This risk scoring, go to the next slide, yes. So this risk-based model, to start with we will apply it to our Okta sign-in policy, and we will extend it in future to the app sign-on policies, to factor enrollments, and of course continuous authentication.

Now that brings me to the end of this discussion. Hey. Once again.

Snegha: No worries. Great.

Neha: Wait.

Snegha: I got it.

Neha: Okay.

Snegha: Great. Thank you so much for being here today, and we hope you got some tools and tips as to what you can do and how you can solve your needs, not just today, but also as to where Okta is going with these features.

With that we do want to open the floor for any questions or feedback, anything that you have for us.

Speaker 1: Hi. Oh, that's loud.

Snegha: Hey.

Speaker 1: Sorry. Are you going to be able to expose some of those behavior-based items for the users? I mean if the admins are going to apply these policies we need to be able to see in advance what the behaviors are going to be, what behaviors the users has been experiencing in the past. How do we make the intelligent decisions for the right policies?

Neha: Yeah. So is your question that we expose these to the end user or to the admin so that they can look at-

Speaker 1: The admins.

Neha: Yeah.

Speaker 1: The goal here is the admins have to be able to make the right decisions for these policies to predict what the end-user experience will be.

Neha: Right. Yeah. So that is one of the things that we are considering, to have some of this information that the admin can look at it. So you do have the CIS log events where you can look at the list of events. But to also to have some more, say, kind of a reporting or a dashboard where you can look at those, the hottest events or get an understanding of how the usage is across your account and what your users are doing. So that is something that we are considering. It's in the plan, yes.

Speaker 2: So, sorry. So you've deployed already but we can't make an intelligent decision for that deployment because you guys don't have the ability to see it yet. Is that right?

Neha: No. So you can see it in the CIS logs that is there. So if you can show it to him in the-

Snegha: Yeah, I'll show it. Yeah.

Neha: This is not your lap-

Yeah. So we'll just quickly show it to you. So, yes. So that way you can look at it in the CIS log events where we do have all these events with a lot of these details around the IP network or what type of event got triggered. We have all that information.

Snegha: Yup. So actually what I was trying to get to with the previous, towards the end of my demo was, so we have many layers to get to to expose it even further. But where we are today is our CIS log data is going to show you not just what's happening today but also if you do add a behavior detection policy, as mentioned, and then go into the CIS log. So you noticed that I did one of those demos for you, so that will show up right over here. So you'll be able to notice what changed by seeing where they usually come from, what changed, what policy did they hit, and why was there a difference.

So let's say we're going to make this more and more seamless over time. Today it's a little bit more manual because we just introduced these policies, but the data is all visible in CIS log and also you can export this into other tools that you may already have. Yeah.

Any other questions?

Speaker 3: Yes. Today with what you have in place today, or in the future, do you have any options around disabling clients that don't use modern authentication? Like the older versions of Outlook, ActiveSync, etc.?

Snegha: Yeah, absolutely. So is that question typically focused on Office 365 for you or outside?

Speaker 3: Yeah.

Snegha: Office 365?

Speaker 3: Yeah. Exchange Online. Yeah.

Snegha: Yeah, absolutely. Actually that's the screen I was on so I might as, go back. So what we do is we have the ability to break down different protocols. So one is Exchange ActiveSync separately, and then we see modern authentication separately, as well as web traffic separately. So if you are trying just allow modern op what I would recommend is creating a blanket deny rule in your sign-on policies right over here. So right over this our default sign-on policies always says allow. So right above that I would create a default deny all policy, and above that I would layer that with what you want to allow, which in your case would be just allow modern op for specific clients. And that way you can ensure that your users are using modern op.

Any other questions for us today? Yes.

Speaker 4: I think we have time for just one more.

Speaker 5: So as it affects the rule-based policies and the-

Neha: The risk-base.

Speaker 5: The risk-based policies, is that an either/or situation? Do you have to pick one versus the other?

Neha Anand: No.

Speaker 5: Or is it a combination of the two?

Neha: It would be the, yeah, it could be either/or or both.

Speaker 5: And then are they layered on top of each other such that you have context of what our rules would be?

Neha: So they would both be kind of referring to the same data pool that we will collect. So, yeah.

Snegha: Yeah. You'd be able to layer them or them.

Neha: Yes.

Snegha: It's up to you as to how you define that.

Speaker 5: Thanks.

Snegha: Yeah. Good. Over there.

Speaker 6: Is there any thinking going on about coming up with some other factor for somebody? Where we get situations where, okay, I don't have a phone, I can't have one, I don't want a phone. Security question's not safe enough, we can't deploy, you know, the keys and stuff.

Neha: Yubikey.

Speaker 6: Is there any thinking about, okay, another way?

Neha: So-

Speaker 4: Do you want to repeat the question?

Neha: Yes. So, the question is there any thinking around any other way of authenticating in scenarios where the regular authentication methods won't work. That's correct. Right? That's the question.

Speaker 6: Right.

Neha: Yes. So, first of all, would this be a method that you want to define or you are expecting us to come up with some other method that can-

Speaker 6: Something else.

Snegha: No. You're looking for a factor that-

Neha: Some other factor?

Snegha: When you don't have a phone and you can't deploy subkeys or security question?

Speaker 6: Right.

Snegha: Yeah.

Speaker 6: And it's just like some breakthrough, blue sky, factor.

Snegha: Of course. A DIY factor.

Neha: Yes.

Snegha: So today it's not on like our immediate roadmap but this is a common use case that we hear from customers as to we have different type of workers and I can't ask someone to use their phone, or they can't use a security question because that's not considered secure.

So we're hoping some of the things that we talked about with adaptive authentication what that'll do is, at least when we get closer to this, even before we revolutionize factors, one day hopefully, will be that with all the contextual access that you can add on before you do op and MFA, that even if you use security question or, let's say, you know, even before yubikey if you can just use security question, the ability to be able to combine that with the many different layers that Neha showed with our roadmap, that your security posture itself will be much stronger than it is today by just asking somewhere for credentials and security question.

So that's where we're headed first and then hopefully as we, you know, get more feedback we'll be able to offer more options as well.

Neha: And I just wanted to add one more thing. If you attended Alex's session, the security roadmap session, he mentioned about custom factors. So if you have an idea in your mind that this is the combination of factor that I want to present to my user in certain scenarios, and that's not available on the regular list of factors, then you can use this feature of custom factor and come up with that so.

Speaker 6: Thank you.

Neha: Sure.

Snegha: Great. So we have three more minutes. Any other questions? Yeah.

Speaker 7: Sorry. This is a two-part question.

Snegha: Okay.

Speaker 7: Two-part question. Can you describe a little bit about how you anonymize the data before it goes into the threat detection model? And second part of that is do Okta tenants have the option of opting out of having their activity included in the model?

Neha: So your first question about anonymizing. So we do have, we are considering that some of the fields that we collect, some of the attributes that we collect, that we hash those out. You know, suspect the PII information so that it's, we don't have the PII information sitting in plain text or, you know. We will hash them out. So that's the plan.

And the second question that you had was do you have the option to opt out of this. Yes, of course. I mean this is all enabled by a feature flag or, you know, if you have this is available with adaptive MFA SQ. So if you don't want to use this option then-

Speaker 7: I was, so-

Snegha: Were you wondering about being part of the data?

Speaker 7: Yeah.

Neha: Oh, okay.

Speaker 7: If we don't have our data included in the model is that possible?

Neha: I don't get it. What do you mean by you don't want the data to be included the model? You don't want us to store the data but you would want to use the risk-based model?

Speaker 7: Separate from the question of using the risk-based model, right. In the keynote they were talking about the network effect of combining all Okta customers data together.

Neha: Yeah.

Speaker 7: If, you know, I have, I'm dealing with the Mission Impossible team and I don't want their IP address as part of that model.

Neha: Okay.

Speaker 7: Is that possible to just say we don't want to contribute?

Neha: I'll have to take that offline. I'm not sure if we have a switch site now that would say that no, you can skip these. So I'll have to take that offline.

Snegha: Great. Any other last questions? We have one more minute.

Speaker 8: Howdy. So right now you have mobile device trusts for Android and iOS. Is macOS and Windows on the roadmap for this?

Snegha: Yeah. So quick recap on device trust is we have iOS and Windows out today in production. Android and Mac are coming out later this year. To give you the sequence Mac is coming out we have estimated Q3 and Android is estimated for Q4. So, you know, if you're interested we should be starting a beta program soon. Just reach out to your account team and we should get you in.

Speaker 8: Sounds great.

Snegha: Yeah.

Neha: Okay.

Snegha: Well, thank you so much for all the questions and being here. Have a great Oktane.

Neha: Thank you.