Oktane18: Roadmap -- Using Device Context to Enable Seamless and Secure Access

John Meyer: My name is John Meyer. I'm with Okta. Welcome to the first afternoon session of the day. I'm going to go through a couple of housekeeping items and then introduce the session. This presentation may contain forward looking statements. Please refer to the accompanying slides for more information. Also, all of our sessions are being recorded, so please make sure all your phones are on mute. Then, we're also going to make sure that since it is being recorded, if you could stay in your seats during the session. Then, also, all of you should have received a survey on your way in. Please be sure to fill it out. Let us know how the session went so we can improve these sessions for next year. If you want to include your name and email, there's a chance to win a $100 Amazon gift card. With that, welcome to Roadmap Using Device Context to Enable Seamless and Secure Access. I'm going to kick it off to Ankit, and he'll introduce himself. Thank you.

Ankit Garg: Hi, everyone. Welcome to Oktane 2018. We are super excited to have you here and share with you what we have been working on over the past few months. My name is Ankit Garg. I'm part of the product management team at Okta, and with me, Sadashiva Rao from Cadence. He'll be coming on stage later on. We are here to talk about how you can use device context to enable seamless and secure access for users in your organization. Before we jump in … Excuse me. Sorry, I'm having some technical difficulty here. All right, before we jump in, here is a standard disclaimer around the content we'll be covering today. Now, as you think about seamless and secure access, there a few key challenges, which customers face today. The very first one is really passwords, the obvious one. Does anybody know how long does it take to crack an eight-character long password? Any guesses from the audience? One year, 30 days.

Audience: 30 minutes?

Ankit Garg: 30 minutes? I'll come back to that. The answer is, it depends. You can use a 25 GPU system or machine to crack a password in 5.5 hours. Now, we all know that with cloud computing, it's becoming easier and easier to set up these systems, and it is also getting cheaper, so it's pretty scary. You could use a 50 GPU machine to crack it even faster. Now, what did customers do to address problems with passwords? One of the key things they did was made passwords more complex for end users. You need to set up more complex passwords. They required things like you need to have at least one upper case character, one lower case character, a number or symbol in your password. That was to make the security of these passwords better, but it did create more end user friction. Now, end users had to remember like what kind of passwords they need to create. It is not consistent. Everybody kind of applies different policies, so they had to figure out how to do this. The question is, did it add security? The answer is, it did not. What we know about end users is when you enforce this kind of policies, they follow certain patterns. They will start their password with one upper case character, followed up with a series of lower case characters, and then end it with a combination of symbols and numbers. These numbers could be their date of birth, their apartment address and things like those. Now, you can use these patterns in your password cracking algorithms and crack passwords even faster, so it did not add security, but it created end user friction.

Further along, what customers did was now, they added a second factor. This is like a security best practice today. What you do is you input your user name password first, you provide a second factor, and then you get access to your account. Now, that did add security, but it created more end user friction. The other key challenge, which customers are facing today, is with the use of SaaS applications increasing, the traditional security model is no longer applicable. Previously, customers used to host their critical applications on-prem, and you could use your network as a boundary to protect those applications, but that's not true or scalable anymore. People are using applications such as Office 365, G Suite and whatnot, so you can't bring that traffic on-prem and then send it back out to the cloud. Summarize the challenges customers are facing. Passwords are not secure anymore. The user experience friction has actually increased, and customers are thinking deeply about what security architecture do we need to move towards in this parameter-less world there could be any device, which could be accessing these critical application from any sort of network environment?

Now, how is Okta thinking about solving this problem for customers? Okta is building a rich contextual access management framework, which allows you to use a variety of signals to decide how you want to treat an access decision. It starts with knowing about what app the user is accessing, what is the user group, which group the user is part of? In addition to that, we have been adding what network the user is on when accessing, along with what is the state of the device, and what location is the user from? Today, we also announced Risk Context, which is Okta's security team looks at a variety of signals, which we get when the attackers try to attack our networks, and we are incorporating that also into our contextual access management framework. Now, you can use all of these contextual information to make an intelligent access decision. It could be prompting the user for another factor. It could be allowing or denying access or completely tailoring the authentication experience the user goes through.

Now, let's talk about a couple of scenarios which would be awesome to enable, right, like this is a roadmap and vision session, so we're going to talk about things, which might not be possible, completely possible today, but Okta's hope is that we can accomplish this in the future. Let's take a company managed laptop. A user tries to sign into their Okta account. They input their username. Okta checks all these contextual signals along with the device information. Now, in this case, if the device is managed, wouldn't it be awesome if the user is automatically signed in without any further prompts? Now, that's an experience we want to enable in the future, which would be great for end users and would make them really productive. Let's take this a little bit further. Now, what if the user removes Carbon Black from their machine, which is a popular endpoint protection tool? What if Okta can detect that and change user's access to Outlook? For example, in this scenario, we can make the Outlook Access read-only, such that the user can only read their emails but not send or download any attachments from those emails to an endpoint, which might be compromised.

Last but not the least, we could also alert the user on the Okta dashboard that their endpoint protection or the endpoint security has changed, and the steps they need to take in order to remediate that problem. That's what we are striving to achieve here at Okta. If we break all of this scenario down, there are three key pieces to enabling a scenario like this. One is, understanding device context. Second one is, how do you use all this contextual information and enable frictionless sign-in experiences? Last but not the least, what are the set of integrations you need to do around user or device life cycle? What happens when a user is onboarded, offboarded? What happens when the device security posture changes? Let's start with device context, how we are thinking about devices, really classifying them into three broad categories. One is unknown device category, which is you might have used that device to sign into an application through Okta. We might fingerprint it, or you might explicitly registered that device. The next one is secure. What are some of the basic security properties we know about the device? For example, is it running the latest operating system? Is it tampered with? Does it have a passcode? Is it running the antivirus? The last one is, is the management policy by the tools, which you are using in your environment, enforced on that device?

Currently, our focus is really on building the managed set of use cases. Now, I'm going to talk a little bit about what key capabilities we have delivered in the recent past and what the roadmap is looking like over the next few months. Now, in order to apply these policies effectively, you need to be able to identify the device, what operating system the access is happening from, so we have delivered in our app sign-on policy, which is the snippet over here from our admin tool, the fact that you can select iOS, Android, or Windows, Mac, or for a request, which we cannot classify, those go into the other mobile or other desktop bucket. We have delivered that capability, which you can use today. Next, what we delivered was preventing unmanaged Windows machines to access applications, which are critical in your environment. Now, again, here you see a policy, which you can enable in your Okta environment to protect your Windows devices. Currently, this functionality only applies to domain-joined Windows machines, but it's management tool agnostic. You could be using in a CCM or GPO tool or even AirWatch or other tools in your environment for managing your domain-joined Windows machines.

We extended that capability to iOS, which is similar in the sense that it is MDM agnostic. You could be using any MDM in your environment, and you should be able to leverage this capability. Some other things, which we plan to deliver in the future is, like I talked about, our Windows capability currently, it only applies to domain-joined machines. We know that a lot of customers are adopting Windows 10, and along with that, they're also adopting a more modern management method, which is an MDM managed model. We plan to add support for that over the next six months. From a roadmap standpoint, like I said, we are focused on managed. What we have delivered is iOS and Windows. Over the next six months, we plan to add Mac support, and over a little bit longer period, which is 12 months, we plan to add support for Android managed used cases, as well as expand into the category of basic security checks on mobile devices on iOS and Android where we would check things like, is this device tampered with, does it have a passcode, and things like those. In the future, we would extend that capability to include Windows and Mac as well.

Now, let me show you some of these features, which we have been working on, what they look like. This is the most exciting part of the presentation where I'll be demo-ing our Mac devices capability, which we have been working on, and Android as well. Let me switch this over to my Mac machine here. Here, I have a Mac machine, which is currently in an unmanaged state. The user has not enrolled their machine. I try to sign in to my Okta account and try to access an application such as Outlook, which is protected by this capability of ensuring that the device is managed. You will notice when I try to access Outlook, Okta detects that the user's trying to access an application, which is protected and notices that the device is not managed, and provides users with a way to remediate that. In the learn mode, you could have any language you could provide to your end users. It could be the enrollment link for Mac or it could be instructions on how they can get that device to a managed state. Now, let's say I go through that process and now, I know that I need to make my device managed. I'd try to enroll my device now.

I'm demo-ing AirWatch over here. I'm going to go through the enrollment process here quickly and put my credentials over here. This might take a few minutes, but I'll talk through how this works really a little bit. Now, I install the profile, asking for my system password. Now, it's pushing on all the profiles, which you have configured in AirWatch for this machine. Along with all those profiles, what it is also doing is depositing proof on this machine whether it is managed or not. That is in form of a certificate, which we deposit on this machine. It'll come into the Keychain, which I'll show shortly. Let's quickly check the state of the device. You can see there the device information, the connectivity status and whatnot. It's all enrolled. Looks good. I'll sign out of my account to attempt again. I'm just going to close Safari for safety purposes. Let's look at the Keychain quickly. Right now, what is happening is that as AirWatch is pushing on all the profiles, what is also happening is that we are creating a Keychain on this device, an Okta Keychain, which will store the certificate of proof, which shows that the device is managed. It's still pushing now. It takes, sometimes 30 seconds to show up here.

Meanwhile, I'll open my Safari, try to log back into my Okta account. Do that. So now, you'll notice that Okta has created a Keychain over here, which will store the certificate like I was talking, so it's all good to go now. Let's see. Now, we access the Outlook application. What Okta is doing is checking for that credential, which is deposited on this device, which proves that the device is managed. Now, I have access to Outlook. In a few minutes, I was able to enroll my device, get access to Outlook, and now, Okta is able to check, in a very transparent way, that the device is managed. There are no prompts the user has to go through in order for us to verify that this device is managed. Isn't that awesome?

Ankit Garg: Thank you. So let me switch over to my Android device now. Let me see ... Switch it back. Start on, plug in, plug this back in. All right, so you already have Android which is already enrolled in AirWatch. And I'm trying to access Outlook. I'll input my username, sign in to Okta. Now, Okta detects that this application is sensitive and the device needs to be managed in order for the user to access this application. So what we have built is a flow, which is really user friendly. Where we guide the user through any steps which they might require in order to get access. A user might know that their device is already enrolled and secured and worked how it could have. Yes, my device is secure, and they will get access immediately.

Or let's say the user doesn't know whether the device is secured by AirWatch or not. Right here we show, ask user a series of questions in order to guide them. Is the AirWatch set up or not? Let's say I don't know and we will give them a way to enroll their device, which is through this enrollment language and admin can configure in the Okta console. But since my device is all secured and managed I know AirWatch is set up. Next, we would ask them if they have Okta Mobile installed or not. Okta Mobile is a required compliment of this feature, because Okta Mobile checks whether their device is managed or not.

In this case, I do have Okta Mobile installed through my AirWatch. I would say, "Yes I have Okta Mobile." And I have used Okta Mobile before, so I have signed into it and whatnot. Or let's say, "Yes, I want to connect." What it's doing, is it's communicating in the background through Okta Mobile and checking if the device is managed or not. And once we've verified that the device is managed, the user would be logged straight in to Outlook. It's taking a few seconds over here. All right, not sure what's going on here, but what would happen here is as soon as we verify that the device is managed, we would log the user straight in to the Outlook application. So while here, also our goal has been to build the best user experience and use the best technology on each platform. So that's how are thinking about device context and how we are treating each platform. I'm going to switch back to the presentation over here.

What next? As we think about utilizing this contextual signals, how can we enable frictionless sign-in experiences? I talked a bit about Okta's contextual access management framework, and how you could use a bunch of these signals to tailor the experiences the user is having in terms of what factors they need to use in order to sign in. That can be enabled by policy on Okta. The first capability which we are going to deliver over the next 12 months is, through Okta sign-on policy, which you see here as an example, you can tailor the factors the user needs to provide. So you can select word context, you want to enable those experiences for, and you can say, "Does the user need to provide a password?" Along with a password, what else do you want to enable? Is it Okta Verify Push or not? So for some values where you're comfortable, for example, if a user is in a network environment which is in your company, you can provide them with an experience of using Okta Verify Push as the only factor they need to provide in order to sign in. Further along, what we plan to bring to the Okta sign-on policy is device context. Now, we have built a lot of these capabilities in our managed use cases, in the app sign-on policy. But we are going bring that up to the Okta sign-on level. So you can enable even better sign in experiences by using device context. For example, if a device is managed, if you don't care about the network conditions, you could enable password-less factors for that user. So they could sign in using just Okta Verify Push, or another factor which they have enabled.

Another key capability which we are super excited to share is, you heard a little bit about how we are partnering with AirWatch. But the underlining technology which really enables that is an integration framework which allows you to incorporate your MDM tools with Okta. Here is an example when a user is accessing Outlook on a managed device. You can set up an IdP routing rule, which is based off context to send those authentication requests all the way to you MDM tool. And for supported MDM tools, that MDM tool can  check if their device is managed or not, verify user information, and send a SAML assertion back to Okta. And in that scenario the user would be seamlessly signed in. This works great on AirWatch or any other MDM tools which support this sort of integration. Similarly, on managed desktops and laptops, we want to enable a similar experience. How it's going to work is, you would enroll a strong credential on your managed device, which could be through the enrollment or after enrollment as well. The user would enter the user name, and they would be seamlessly signed in if they're on a managed device, and we have other contextual information which checks out. This is something we want to enable in the future.

Now, let's talk about user and device driven lifecycle for a little bit. There are some key use cases, which are really important to enable, to simplify the admins life. What if, from a user lifecycle perspective and their onboarding, we can push all application entitlements to the MDM? That way when a user enrolls their device in MDM, you could push all the native applications they require, day one, in order to be productive. Similarly, when they are leaving the company, what if we can sign the de-provision request to the MDM, such that all your critical company information is removed from that device? Similarly, on the device side we want to be able to check if there are any device security posture changes. And when those changes happen, how do you want to treat them? For example, would you want to change the application access permissions? I talked a bit about enabling a scenario where, if a device goes from, let's say managed to secure, how you could change that Outlook permission to read-only. And similarly you could affect Okta session as well.

So these are things which we are thinking about deeply, in terms of how we want to enable them in the future. And as we collect rich device information, we want to make it available to both admins and end users. The reason we want to make it available to end users is, for them to be able to see what kind of devices they are using and what is the security posture of them? Such that they can maintain better security hygiene. There needs to be a lot of education around security, because common users don't understand these things the same way. And this information could be really useful for admins as well, where they could use that information to determine what is the security posture of the organization? What kind of policies do they need to apply, and what not. After that, I would like all of you to think how you can use some of these capabilities to improve security and end user experience in your organization. Now Okta deeply cares about these things, and we would love to talk more and hear more from you, how you would want to use some of these capabilities to make your organizations more secure and enable end users. With that, I would like to invite Sadashiva Rao from Cadence to talk about how they are using device context in their organization.

Speaker 1: Good afternoon everyone. Can you hear me? Thank you Okta for giving me an opportunity to speak about our success story and implementing Okta device trust in this great even. My name is Sadashiva Rao, people who know me call me Sala. And I am a senior architect in Cadence, and I'm working there from past 15 years. Let me start with introducing a little bit about our company. We are industry leader in enabling electronic chip design, and we have offices in 21 countries around the globe. And we have around 7 thousand employees working for our great company. So we have around 60 applications, which are integrated with Okta, and I take care of all these integrations for Cadence. So why Okta device trust? When I met last year with my security team, they came up with a requirement, asking for me to implement Okta device trust, or device trust for some of our critical applications. So I started exploring how to do this, then Okta came and rescued me out of this. When I contacted them, they said that this feature is already enabled and ready to use. Some of the key benefits, I will not go in detail, Ankit has already explained. By the somebody is ... When we know that we are allowing the access of our applications through a secured company trusted device, we have a better access control and security in place. And we can protect our application and data in a better way, and effectively.

So this feature is very easy to implement. It is couple of configurations, you are all up and running. And it used more flexibility and more options. Like for example, you can enable this feature at each app level. Where in you can pick and choose what all critical applications you can enable and bring them under this policy, and less critical ones you can exempt. And also, it gives a flexibility to assign these rules at each user level, as well as group level. And you can exempt also at the user level and group level, based on your use cases. And one more from Fidelity is that, it gives, or the feature it gives is tells us, as to assign the user when they are accessing the application from the company network, or what I would say company network. So it is very easy to implement. I will go to the next, what is of a road map and where we are. In Cadence, we have around 70% of our users using Windows devices. That is where we started last year to implement this feature, to cover our major use cases. So we started with ID roll out, we tested it, once we found it is working, we rolled it out to all of our Windows user community in Jan 2018. So currently we are in the pilot rollout of IOS device manage, and we have enabled this feature for a couple of applications, and our testing is under way. And we are planning to rollout this feature by Q3. And to complete our other two devices, Mac and Android, we are planning to roll it out early next year, based on Okta, when that feature is available in Okta. So we have completed our rollout in Windows and we have not received any negative feedback, which is great. And if I am not wrong, we are one of the few first customers to successfully implement this rollout. So to conclude what we feel is ... Our security team is happy and there is no complaint from our customers, so it's kind of a win/win. With the help of Okta, we were able to manage this, and that's all I have now. This is a very success story for us, that we are successfully implemented. Now I would like to call Ankit back on stage to take this session forward. Thank you.

Ankit Garg: So, what we going to do next is, I'll ask Sala a few questions about how his rollout went and to get a better understanding of that, and then we'll open it up for audience Q & A. Thank a lot Sala for incorporating this feature, and I'm really happy that it went well for you. So what kind of policy are you really applying for your Windows users? What applications you are protecting? Some examples would be nice. And are you blocking access on unmanaged devices, how are you applying some of these policies in your environment?

Speaker 1: Actually, we have enabled this feature on almost all applications, and with some exemption at the group level based on the use cases. But overall we have applied this policy for all apps. We have few SAS application and non-permanent application, but overall we have applied for all the applications.

Ankit Garg: Awesome. And are you blocking devices which are not managed for users?

Speaker 1: Yeah, yeah we are.

Ankit Garg: Got it. Awesome. So you talked a little bit about the rollout. How did that go, any feedback from end users? Any glitches you ran into, any reported accidents in terms of access?

Speaker 1: Yeah, we didn't face any serious kind of obstacles or hurdles implementing this. But the only thing is, as you know, we had to deploy that Okta certificate to each end user mission. And we need the confirmation back to be installed successfully. That caused a little bit of a challenge, then we worked with Microsoft and they give us some wrapper scripts, which can identify and say, "Hey, this certificate is installed properly." So that caused one little bit of a hiccup we had, but it was not a major one. And one more thing is, this feature as you know doesn't support Firefox. Which is from Firefox side, it's by design, it doesn't tell out. So we need some help from Okta to kind of enable this feature in Firefox so that we can complete, we have a complete set of browser which we can work on.

Ankit Garg: Got it, awesome. That's really useful feedback. So we will look at how we can improve our tooling.

Ankit Garg: It's really useful feedback. So we will look at how we can improve our tooling to look at certificate install state and stuff like that. One area where we can improve this is like access logs where you know you can pull an access log of events and check whether the device was installed successfully or not and things like that. In terms of Firefox, the reason why it does not work today on Firefox is that Firefox has its own certificate or keychain which it uses on devices. It does not leverage the system keychain today. So our hope is that Firefox can actually improve that in the future. Where they are leveraging the system keychain and it would probably work really well on Firefox as well, once they enable log. What are some of the challenges you ran into with your Windows rollout? When you were going through this phase of testing it out and rolling it out to a broad audience, were there any challenges you ran into in terms of you know just doing the rollout? The sure size of Cadence is like, what eight thousand users?

Speaker 1: Yeah, we have around eight thousand users. There was not much a challenge as I said, the only thing was the confirmation of the certificate the - deployment of the certificate, other than that we have not got any negative feedback. But for end user, there is no change in the usage model of the application. It all happens in the background. All these checks so there is no performance degradation and nothing of that sort, so we are good there and even user, they don't know whether the device touched is enabled or not unless they go to another device and try to do something. So it was all good.

Ankit Garg: Awesome. That's great. And what are some of the other use cases you are looking forward to? We talked a bit about device context, how we are thinking about it. What are the some of the other things that might be useful for Cadence and what are the use cases around that?

Speaker 1: So especially in the IOS where we are doing the pilot currently, in our organization there are very few, you could say 30% of their devices are managed. And some people, they don't want to enroll their device. So we need some basic checks, which satisfies our permissions particularly, so that they are allowed to access this application without enrolling. Some key features such as checking the device, whether it is legal or whether it is a jailbreaker or some sort of minimum requirement on the security side, because there are a lot of people who will not be able to enroll or they don't want to enroll their device. Because they only want it their way.

Ankit Garg: Well, that's a common problem with BYOD programs and companies, where users are not comfortable enrolling their devices all the time in the DM. So how we are thinking about this at Okta, I talked a little bit about it as, so you have the flexibility of applying these policies to what applications, to what set of users, but along with that, like I was saying, we plan to expand into basic device security checks. So things like, is the operating system up to date, is the password on the device, is the device jailbroken or not? Like some of those device security checks. Feels like it's going to be useful in Cadence wherever.

Speaker 1: Yeah, definitely, that would be awesome.

Ankit Garg: Well, with that, I'll open it up for the audience. Thanks a lot, Tala, for answering some of my questions and discussing your rollout and how it's been for you with Windows, and we hope you can be at least successful with iOS and Android and Mac as well.

Speaker 1: Yeah. From my side, we thank Okta for all your support, your support is great.

Ankit Garg: Thank you.

Speaker 2: We do have a microphone as well, so if you have a question, raise your hand and I'll run it over to you.

Speaker 3: From the demo, it would appear that any end-user can enroll their device and then make it a managed device. How do you prevent users from making it a managed device and only using corporate devices?

Ankit Garg: Yeah, so that's a good question. Currently, the way we have built this functionality is that it offers a lot of flexibility. So you can provision how do you want to guide the user in scenario, where they're not managed. So, you can configure how you want to direct those users. What would be useful I think in the future is to make it even more granular like being able to set it for a set of users, like how do you want to guide them? Do you want to block them completely? Or is it based on device state, right? Like if I upload a bunch of devices into Okta, or re-integrate with your management tool or whatever you're managing the entry and say okay, these are my managed devices. I want to guide them to enrollment, but all others we want to block them, or we want to guide them to these instructions. So right now, we are focused really on one set of policy settings which apply in that scenario, but in the future, we can look at expanding that and making that even more granular. But you can actually configure the link you want to point the users to, even today.

Speaker 2: Next one's over here. Question?

Speaker 4: Much of what you've been talking about now is about the web apps for Outlook and some of those ones. What is the road map looking like for Okta to handle the rich client outlook dot exe on unmanaged machines? As it stands today, whether you have MFA or not, anybody can download that application, and as long as they have credentials, maybe they phished 'em, however, you can get in and it bypasses MFA, and you're straight in. Is there going to be a road map for that? Something you can do to work with Microsoft on that scenario?

Ankit Garg: Are you referring to the active sync clients, or are you referring to the modern art clients on Outlook?

Speaker 4: Well, both, actually. Because right now, I could just go to my home computer, download it, I could be sitting in Nigeria, and none of those checks from geo-fencing happen, cause it just goes straight into Microsoft. There's no check-back to Okta.

Ankit Garg: Yeah, so the other couple of things which you can do there today, like the functionality which I talked about and what I showed today on Mac, as well as what we have delivered on Windows, does work on modern ARC clients, like you can use it on Outlook for example. So you can use that functionality and Microsoft has been pushing all of their customers and users towards modern ARC clients. So this functionality works on those sort of clients. Now if you come back to active sync: what Microsoft does enable with Office 365 is the use of certificate-based authentication. So you could provision an Outlook client to talk active sync, and use a certificate for authentication. How you can use this functionality is that you can block access from active sync lines. So I've not shown how in the Office 365 apps sign-in policy, but over there you have granularity in saying: how do I want to treat legacy clients? How do I want to treat these modern or web-app clients? So, you can actually choose and say how you want to treat them. You can block them completely, such as they use certificates to authenticate, and you can also apply Okta device trust and device conducts policies, for modern, art, and web-app clients which would be both tech clients as well as the Web browser.

Speaker 5: Just going back to the demo, you were showing the registration on the user site, so the user said like, I don't have an MDM and then you guided the user to download the MDM client. What happens in the other scenario where the user selects they actually have an MDM?

Ankit Garg: Yeah, so how that guidance really works is if you select you already have MDM installed on your device, you can straight get to the phase where Okta would really be checking if the device is managed or not. So if you say yes, my device is secure, we would go straight to checking if the device is managed or not. If it checks out that the device is managed you would get access right away, but if not, we can put the user back in the guidance flow, where they can go back and verify: have they gone through all the steps in order to get access? Whether it be having your watch, or Okta mobile installed on their device, and being signed in to Okta mobile. Go for it.

Speaker 6: So currently, on the policy for sign, if the policy is violated, Okta can block the access. For the screen on the user's standpoint, we can customize it. Is there a customization in the short term that...?

Ankit Garg: Yeah, that's a good question. So currently, how this works is: the page where we land the user, the text on that is static, so it's not customizable, so that's a good point. We can enable that in the future, but the learn more language you are pointing the users to, that's customizable, like I said. So, you can configure the link you want to take users, when they hit the learn more button. So when they hit that you can point them to any article or information you would have put together for them, but in the future we'll look at enabling more customization on that page which they land on as well.

Speaker 2: One over here.

Speaker 7: All right, so in the beginning of your talk, you had highlighted something you're working on in the road map, where if a user were to uninstall Carbon Black from their PC, the device context would change and device trust would then change. So it's a real bummer to have to wait more than a year to do that. Do you know if any of your customers, or do you have any other workarounds, where even if it had to be a manual process I could add certs to a CRL and not trust a device that I knew fell out of trust, and then re-enable it once it became good again?

Ankit Garg: Yeah, that's a good question. So of course, these are a complex set of integrations and what we want to learn from customers are like, what are the tools which you want us to integrate with? So that's helpful feedback that Carbon Black is a popular one. How we are thinking about that is that how are we going to extend this framework, such that you can build your own logic, if you want to build that outside of Okta? What if we can enable a callout from our app sign-on policy where you can write custom logic, which could be checking against your Carbon Black tool, or whatever other things you might have in your org management and come back with an answer and re-incorporate that in the policy. So, our hope is that we want to open that up, such that you can write your own sort of risk engines or intelligence engines which you want to incorporate, and you can bring that into our app sign-on policy. And that doesn't mean that Okta is not going to build the integrations which are required to make customers successful, but we are looking at it both ways: that our customers who want to build their own intelligence engines and risk engines, we want to enable that scenario. But for customers who want to use Okta and integrations we are building, we want to identify the set of tools which will enable customers to be successful as well.

Speaker 2: One over here.

Speaker 8: Hi, I have two questions, hope that's okay.

Speaker 2: Sure.

Speaker 8: All right! So in the demo, you showed Okta mobile would check and see if the device is on their MDM management. Is it under my company's MDM, or under any MDM management?

Ankit Garg: It is your company's MDM, so basically-

Speaker 8: No, how does it know me know my AirWatch?

Ankit Garg: Yeah. So we can talk more about the details of the approach, but what that really essentially is checking is when you try to access, it talks to Okta mobile, and Okta mobile checks whether this identifier is managed on your company MDM. So we integrate both Okta and your company MDM in a way where we can check against your company MDM whether this device is managed or not.

Speaker 8: Okay. The other question: regarding device trust. And when we tried it, the caveat was the machine cannot be a shared work station. That scenario was not supported. Is that still the case?

Ankit Garg: I think you're referring to the Windows domain join scenario. That's still the case, but I would have to understand a little bit better what those scenarios are, so maybe we can chat right after this presentation, we can have a quick chat. Thank you.

Speaker 2: One here.

Speaker 9: Do you require Okta MDM as a product?

Ankit Garg: I'm sorry, can you ask that question again?

Speaker 9: Do you require Okta MDM as a product?

Ankit Garg: Not really. So all the functionality which I talked about around device conducts today would work with the MDMs you have in place. Of course, like as we are building our integrations and thinking about the approach we take on each platform, it could vary. For example, the iOS approach which we have already shared would work whatever MDM you have in your environment. And when we looked at Android, it requires certain integrations with the MDMs which are out these. So in first ways, we plan to add support for AirWatch and mobile for Android, and then expand to some other MDMs down the line. But what we are really focused on is that we want to provide you with the best experience, so we are focusing on what integrations and what technology approaches we need to take on those platforms. I hope that answers your question?

Speaker 2: I'll take one more question right here.

Speaker 10: So you guys talked more about AirWatch aspect of it. Are you guys right now doing anything with Intunes for Microsoft, and how does that support look like? And then the second question I have is around the support workflow. Like for example: if I'm trying to access an app which is highly secured, and for some reason I detect that it's a high-risk request which it came from, I would really want to go to service now, for somebody else to take care of it. Do you guys have any integration that's kind of planned on that?

Ankit Garg: Yeah, both good questions. First one, which is around like integrating with other MDMs such as Intune. So like I said, our approach is really MDM-agnostic on Blackphones where we can build an approach like that. And on Blackphones where in order to deliver a better experience, we need to build more tighter integrations with the writers. We are taking that approach, but overall directionally where we are headed is we want to enable approaches which are generic in nature, which you could use against MDM provider out there.

The second bit of your question about how can we enable support workflows, which you could build and use when you detect that this access is risky. So, we don't have any static integrations which a level is out of the box, but like I was saying, in the future what we want to do is open some of those decisions or access points or the policy, such that you can integrate with your own engines and come back with a decision. So I think that would enable those kind of scenarios in the future, but hopefully that addresses your question. I would love to chat with you as well and understand what service and what kind of workflow you would want to have and learn more about that, so we can see how we can enable that in the future. Thank you.

Speaker 2: All right, with that: thanks, everyone!