Oktane20: Securing Financial Services Workforce with Zero Trust

Sai Maddali: Awesome. How's it going everyone? Welcome to Oktane20 Live, the first one ever. We're super excited to talk about Zero Trust and passwordless today. My name is Sai Maddali, and I'm a product manager here at Okta working on our devices ecosystems, so device identity, passwordless on Mac and Windows. I'm super excited to talk to you guys about this today. Before we dive into all the good stuff, a quick forward looking statement. As you know, Okta is a public company, so any forward looking statements in here are subject to change and feel free to read this at your own time. What we're going to talk about today, three main things. The first one is we're going to talk a little bit about what we see [inaudible 00:00:47] Okta from [inaudible 00:00:49] Zero Trust and passwordless and things like that.

Sai Maddali: We're going to get into the importance of understanding and trusting devices, and enabling and building a secure workforce for the world today. Then I'm going to pass it off onto Chris and team where they're going to talk a little bit about how they tackle this problem at Capital Group. It's a pretty fascinating story. So the first one that I'm very interested in talking about is what the world is like today. Talk to a lot of customers, a lot of companies over the last three years here at Okta, and there's a few patterns that have started to emerge and I think some are more true today than ever. The first one is multiple resource types, right? If you look at how your enterprises and how most of their enterprises are there out there today, one thing that becomes extremely apparent is not only your cloud footprint is growing from an app and resource perspective, but you also probably have a lot of legacy on-prem applications to deal with.

Sai Maddali: So you are in this hybrid world where your cloud footprint is growing faster and faster, but you also have to worry about how to figure out and deal with that legacy on-prem footprint that you have. The second piece is multiple networks, and I don't just mean your internet, your enterprise internet, but you also have a growing cloud footprint too. You probably have some mixture of AWS, GCP and Azure where you're running different workloads for different use cases, and it's only going to become more true as you grow over the next couple of years. The third one, I think it's more true today than ever especially within the last couple of weeks because of COVID, is a distributed workforce. That is you have your employees and contractors and partners that are accessing your resources from not just their home but also multiple other locations. The fourth one, I think it's also getting more and more true every day because of breaches, is that there are compromised credentials that are sprinkled and sprayed everywhere.

Sai Maddali: The fifth one, this is one of my favorite things to think about because I do work on devices, is that there's thousands and thousands of devices and millions of signals, right? Because you have your end users connecting to your resources from multiple different locations, but also from multiple different devices, and all of these devices have various signals, like what operating systems are they running? Are they jailbroken? What unmanaged signals do I need to think about? Does it have a TPM? Stuff like that, and making sense of these signals and understanding how to deal with this device management from a security angle is going to become really hard and really important. Related to that, BYOD is becoming way more prevalent, right? Because it's not just my personal laptop or my work laptop that's managed, but I'm also accessing a lot from mobile phones, from iPads, from a whole swath of personal devices that I have. You also probably have a lot of security tools, right?

Sai Maddali: I think this was very interesting because you probably have a couple of tools for your endpoint security management, that's something for your mobile, like MDM management. You probably also have multiple tools for managing devices, different types of devices. So you probably have ... You're continuing to use something like SCCM for Windows, maybe something like Jamf for Mac and maybe into VMware for any of our mobile workloads. So it's a mixture of devices all achieving similar goals, right? I think something that's also very real in this world, and I briefly touched upon this a little, are passwords. Passwords are everywhere, and that's just the reality of the world that we live in today. No one really likes passwords. I definitely don't like passwords, and I'm sure not a lot of you also like passwords. The only people that really like passwords really are hackers, right? Passwords are interesting because it puts a lot of trust on the end user, it puts a lot of trust in ensuring that they are careful about which passwords to pick, what the password requirements to choose.

Sai Maddali: Yes, you can impose some restrictions on them, but ultimately it's on them to figure out what password they're using, and that's a really hard proposition for us to have, right? Because chances are I will be reusing my passwords, chances are I'll be using something that's not very secure, and so it is really important, especially in this evolving workforce, to extend that trust beyond the user. Because compromised credentials are a reality and it's important for us to understand how to be proactive about making sure that'll never be a problem. Or how do you reduce the risk from that problem? Right? That's the core message of this presentation, is that enabling Device Trust is a very crucial step in getting to that world of passwordless and laying the right foundation for your zero-trust architecture. What that really means is how do you extend that trust that you put in an end user today and take it beyond them, take it to the device that they're accessing it from, which is almost always how resource access happens?

Sai Maddali: But this is a very interesting and a new paradigm too because one thing that becomes very apparent when you start thinking about this problem is it's this age old challenge that you have of how do you balance user experience with security? Okta did a survey last year called the Digital Enterprise Report, you can find it on our blog, where we interviewed a lot of enterprise companies and understanding how are you approaching Zero Trust, how are you approaching digital transformation and what are your biggest concerns? What are your biggest challenges? Something that's not very surprising from a remote work, how do you enable Zero Trust and passwordless for an evolving workforce? Number one is security, right? That's definitely not a big surprise, but what's more curious and what's more interesting is efficiency is quite literally right after that. They're equally a big concern for a lot of enterprises, right?

Sai Maddali: I think that's very fascinating because it does bring to light this angel challenge that all of us have is how do you balance user experience with security because you can't impose too many security restrictions at the cost of losing efficiency, especially in this evolving remote workforce that it's inevitably going to happen. Because on one side, you have your end users and your end users are very much about, "Hey, I want access to everything that I need as soon as possible, and I want to go through as few steps as possible because I don't want to add any friction to the work that I'm trying to get done." Right? That's a fair concern. Similarly, if you're an admin, you do want to enable an experience like that, right? So your question is, how do I enable an experience like that, but do it at a lower risk and low effort manner? Because you don't want to spend multiple cycles solving for a need that's not going to have a high ROI, right?

Sai Maddali: Similarly, a lot of the CxOs and VPs are thinking, "Okay, I do want to enable the secure, efficient, collaborative workforce for my company, but also want to do it in a secure and compliant and regulatory manner." Right? Very different needs but similar goals that all of them have. It's definitely not easy to achieve something like that, right? And it's definitely not an overnight journey. So the first one to really think about is understand the lay of the land, especially now with how things are changing, and it's understanding what are the users' needs when they do need to work remote, and you probably are doing a lot of this today but it's really understanding and laying out the journey that the user would need to take in opening their laptop all the way to accessing and doing recovery to enrollment, right? Because it's a very interconnected journey where you can't really have any edges or gaps. The second piece is start authenticating everyone and everything. If you don't have multi-factor today, that's step zero. That's the first thing you need to get on.

Sai Maddali: The second thing you want to think about now is, how do you also extend that into the devices world? I highly recommend joining and watching the device and security roadmap sessions where we talk a little bit about that. The third piece is, in parallel or you can do it after, is really setting a roadmap for how you can achieve passwordless and also a strong MFA enterprise. What I mean by that is really thinking through the different assurance levels that each of the factors that you have in your enterprise are. How does SMS compare to things like WebAuthN? How does that relate to email OTP versus a password? And really setting these buckets of high assurance to low assurance factors so you can really think through what it means for your passwordless journey, and also I highly recommend going to the security and device roadmap because we'll talk a little bit about the frameworks and how you can think through it the long term.

Sai Maddali: Then eventually, you'll be able to get to a place where you have a single place to really understand that device and user health risks and how they're interconnected, so you can actually drive intelligent workflows and intelligent remediations for that journey that you're trying to create. So the big takeaways are enabling Zero Trust ... Sorry, enabling Device Trust is a crucial step in achieving passwordless and zero-trust architecture, and that's really the core message of this entire presentation. Really when you go back, please experiment and understand how you can think through and play with and rollout these phishing-resistant and device-bound factors like WebAuthN, or Fido or FastPass. FastPass is a new optic experience we're releasing, and that's something you should go check out in the device's roadmap. Once you've understand this, really lay out your roadmap and plan for how you can achieve that in a fast manner over the next couple of months and years.

Sai Maddali: These are a couple of sessions that I highly recommend. The first two are the device identity and security roadmap. The third one is Okta plus Microsoft. The interesting thing there is we'll talk about a lot about also on-boarding and how you can do things to take advantage of things like AutoPilot and Okta to really drive that day one experience for devices. I also highly recommend the future of continuous authentication by Okta's Chief Product Architect, Karl McGuinness, where he's going to talk about how we're thinking about continuous auth and what that means for your enterprise over the next couple of years. Now that said, I talked about a lot, but I want to keep it real and I want to pass it on to Chris who's going to talk a little bit about how they've achieved this at Capital Group in a very innovative and creative way. So Chris, I'm going to pass it on to you.

Chris Miller: Thanks Sai, and thanks everyone for joining us today. My name is Chris Miller. I work at Capital Group. For a little background, Capital Group is home to the American Funds, which was founded in 1931. It's one of the largest investment management firms serving over 55 million investors worldwide. So like many organizations, we started our cloud journey with a few SAS providers, which quickly drove our need for an identity federation solution. But today, where we're at, is we actually leverage a large number of SAS providers, and we take advantage of a number of the different cloud platform services like Amazon, Microsoft and Google. As a financial services organization, security is really at the forefront of how we make our technology decisions. As we look to Zero Trust, and there's been a lot in the news and the analysts have talked a lot about Zero Trust. It can mean a lot to a lot of different people, but for us it's really become a core part of our forward-looking security strategy.

Chris Miller: As Sai mentioned, we really believe that applying more rigor to how we validate both the identity of a user as well as the trust level of the device that they're using is really going to be positioned as the best to provide really the highest level of security for our investors and our associates. Passwords alone are dying as Sai talked about, and we really think that the ability to move away from just using passwords, and as I'd mentioned, really focus on better identity validation as well as the trust level of the device is really where the future is on how we continue to protect identities and our company and our investors and our associates. So I'd like to go ahead now and hand over the presentation to Brian Svidergol who's going to walk through how we've been partnering with Okta on our Zero Trust journey.

Brian Svidergol: Hey, thanks Chris. I first want to break down our Okta environment, give you guys a background of what we have here and how long we've had it. We first deployed Okta in 2015, so we've had it for about five years and the initial deployment was fairly limited, just a couple of apps. Today we have three production tenants, two are customer facing and then our corporate tenant, and today we're going to focus on the corporate tenant. We have 21 non-production tenants, so this is your typical dev [inaudible 00:14:13] QA environment. Then we have some dedicated developer tenants, and then we have a few sandbox tenants like for a specific team that wants to experiment. We have added over 200 apps to our Okta corporate environment, and in 2019 we added 81 new applications. This is an app breakdown. We have a lot of SAML-based apps, and when we first started with Okta, I'd say 95% of the apps that we were adding were SAML-based.

Brian Svidergol: But we do see a big uptake in OIDC-based apps and we think that's going to be a big growth area for us. Then here's our app distribution. Right now we're sitting at about 83%, 84% of our apps are in the cloud. For Okta, most of those are SAS-based, but we do have some on-premise apps and we're looking to expand that as needed. Okay, so let's look at our initial configuration. So the first thing to know is that we had a need to minimize data exfiltration and adhere to our existing security policies. So when we implemented Okta, we needed to still meet those requirements for all the Okta-based applications. So we started with IP-based restrictions and group-based app assignments. What that meant is, if you're on the Capital Group network, then you can get to our Okta apps. If you aren't, then you can't, unless you VPN in first. Well, what we figured out is there's substantial overhead in managing IP-based restrictions, because as a big enterprise organization, we're routinely adding new offices, we're adding new wireless networks, we have sub-net changes, we're doing IP rearchitectures, we're adding vendors or vendor networks.

Brian Svidergol: Those restrictions became a bit of an operational overhead for us. Then second, we started with a single MFA, and this was a legacy MFA, the kind that you might carry in your pocket or maybe you have a virtual MFA app on your corporate issued laptop. Let's talk a little bit about the user challenges. So first things that we discovered, users wanted to use more personal devices, and that initial configuration with the IP-based restrictions, well, you couldn't put a personal device on the Capital Group network and so a lot of people couldn't get to any apps from their personal devices. Then for all of the cloud-based apps, the initial configuration dictated that you had to VPN in to Capital's network and then go out to the cloud-based apps from there. That was a performance degradation. The experience was a little bit slow. A lot of times people wanted to just take their laptop home, boot it up and connect to a couple of things. But once you added in the VPN, it really degraded the user experience. We had a couple of other initial configuration challenges I want to bring up.

Brian Svidergol: One is we ended up adding a guest network for employee personal devices. So up until a couple of years ago, everybody that had a personal device, they had to provide their own connectivity for it. So we didn't really have to account for it with Okta. But then we added a guest network and suddenly that network was part of our IP-based restrictions and we had to go in and change all of our applications because we didn't want any personal devices getting to apps at that moment. I think what we discovered was ... One more thing I want to add actually. So we had on-premises proxy services. So for all web traffic, everybody goes out through our on-premises proxy, and those were working fine, but we decided to move proxy to the cloud through a cloud-based proxy service. What that meant is we no longer controlled the IP addresses for the proxy. So from an Okta perspective, we couldn't really limit the IP addresses, just the Capital Group anymore.

Brian Svidergol: We would have to include the cloud-based proxy and the provider shares those IP addresses with all of their customers. So we really needed a new way to handle app security and we decided to look at Okta Device Trust. Okta Device Trust to the rescue, so a couple of things. We had a few questions first when we looked at Device Trust. First, how do we maximize app security? We still need to minimize data exfiltration. We want to simplify the user experience because with our initial configuration people had to think about who owned the device, where the device was and which network they were connected to, and then we want to make the apps more available. So what we started discovering is more people are working remotely on the road, for example, more people are working at home, and people's expectations, in 2015 compared to today in 2020, they've changed a lot. They expect at least basic app connectivity from personal devices and from every location, maybe it's HR type stuff or it's approving CRQs or something like that.

Brian Svidergol: So Okta Device Trust, we decided to check it out, and initially what we did is we looked at iOS only. So iOS at the time was our most prevailing mobile platform out there and it was in high demand and we already had the devices under management. So what we did is we configured Device Trust for iOS and we configured just a couple of key applications, two in particular that people were clamoring for. One was ServiceNow and the other was Jabber. Then we started looking at other platforms. We had pretty good success with iOS. Users were happy, but how do we expand it? What do we look at next? So we started looking at the Android side, and we got in on the Android beta and then we started looking at Windows and Mac. We started small pilots for all three of those. Got a few users in IT, got them up on a couple of apps and sort of, we'll call it, kick tires. As part of that, we were noticing an improvement in the user experience. Things were simpler, people were reporting that they didn't really have to understand as much as they did in the past.

Brian Svidergol: They were working in a similar way, whether they were at the office, at home, whether they're on their device or a different device, laptop versus phone, for example. Then on the admin side, what we found is with rolling out Device Trust, we want them to include our help desk a bit more. One of the offloads, some of the, we'll call it, level one support on-boarding, and so we started rolling out help desk limited admin rights to do some of the basic stuff to help with this roll out, and that was a good experience. But we also want to do expand that with self service. Eventually after the pilots ran out, we experienced really good success, so we decided to go all in across all four platforms. So first we did all of our Windows in points, and today, right now we're sitting at over 15,000 Windows devices. Then we looked at Mac. We have a smaller footprint of Macs, but we're currently on 88% of our Mac devices as well.

Brian Svidergol: At this point, we've really reached a time where we're looking at expanding from our initial set of apps and we've been doing that one at a time, typically a couple a week, two or three a week based on usage. So high usage apps or apps that people find a lot of benefit from when they're coming from different devices in different networks. We took a lot of in user input for that and we've really hit our core apps first. We still have a bit to go. We do have over 200 apps, and then this really brings us closer to Zero Trust as Chris mentioned. At CG, Zero Trust, it means we never trust, we always verify, and our initial configuration was we inherently trusted every device that you connected to our network. So we're no longer in that position. Now we trust devices based on Okta's Device Trust and we can authenticate devices and users. That's our Device Trust overview. I do want to turn it over to Kelcey now to talk about our automation and our self-service efforts.

Kelcey Lorenzo: Thanks Brian. Hi everyone. My name is Kelcey Lorenzo, and I'm going to talk a little bit about our self-service and automation efforts at Capital Group with Okta. When we talk about self-service, what our team is focusing on currently is an automated self-service platform for application on-boarding and application administration, in addition to a self-service method for user login profile management, particularly with multifactor authentication for our associates. When we're taking a look at the different areas that we could potentially expand and develop self-service portals or different automation frameworks in the space, we targeted a few different challenge areas that we wanted to tackle. So like Brian mentioned earlier, we have multiple different tenants for Okta in our environment and over 200 applications. Since everything is being done manually currently without an automation framework or a method for managing our applications, there's just a big lack of consistency across of our environments.

Kelcey Lorenzo: This is due to the fact that everything has to be done manually, whether it's applying a sign on policy to an application or promoting an application across our different tenants environments. This just leads to a big operational overhead for our support and operations teams. So if you take a look at the chart on the right hand of the screen, you can see this is just a general breakdown on the different types of tickets that our Okta queue gets on the average month. You can see the biggest section of the pie chart is for troubleshooting. So this is generally just log in failures, application assignment failures, one-off errors that we need to work with individuals or teams on. But then the next biggest sections are application on-boarding and configuration. The tasks that fall under these two categories are really just talking to teams, getting their application configurations and manually inputting those configurations into our environment, in addition to making slight changes to maybe redirect your eye or an authorization server as teams are developing.

Kelcey Lorenzo: In theory, those two sections for application on-boarding and configuration could be completely removed from our queue if we had a self-service way for teams to handle the on-boarding and configuration of their applications, and then our team as Okta admins and our operations team could focus more on doing user or customer to customer interactions and helping people out with more details instead of being bogged down by these additional tickets that need to be processed. The last area that we wanted to focus on developing on self-service is for new users and on-boarding devices. So while Okta does have this capability for self-service out of the box with their application dashboard, not many of our users interact with this dashboard on a daily basis. Some may know how to reset or re-enroll their factors through the dashboard, but other users never see the dashboard at all, and this is due to the fact that we implemented Okta as more of a background authentication engine in our organization, and so to some users it's virtually invisible and they don't notice it at all and that was definitely with intention.

Kelcey Lorenzo: But now that we're looking for more self-service opportunities to develop better company, we're looking for a way to provide that cleaner user experience or user experience that just aligns more with the way that our associates work. This brings me to one of our examples of an application that we developed in-house at Capital Group, a self-service portal that we call the CG Okta portal that primarily focuses on self-service for multifactor authentication management. So there is a few different key targets that we wanted to hit with this portal, and the first one was definitely alleviating help desk calls. So prior to this portal being available in our environment, if an associate, say for instance, got a new cell phone and wanted to re-enroll their new phone in Okta Verify, they would have to call the help desk and get connected with the help desk and then go through the process through a third party with a help desk agent instead of being able to just do it themselves.

Kelcey Lorenzo: These calls could typically range from either maybe 15 minutes or maybe up to 45 minutes depending on how busy our help desk agents are. This leads to the second point that we try to ... or the second target we try to satisfy with this portal, just to save our associates more time. So all of our associates are doing amazing work at Capital Group and their time is very precious to all of us. An associate may be able to just reset this on their own in five minutes, the same amount of time it would take to even get connected to a help desk agent. Providing this portal for associates would just, again, save them more time, they can manage their factors when they want to and wherever they want to, and then they can ensure that they can access all of their applications while they're either on the network or if it's available through Device Trust.

Kelcey Lorenzo: Then again with all of our self-service and automation efforts, we're just trying to provide more accessible options to our users to ensure that we provide them with ways that work best with how they're used to working in our environment. Now, I'm going to go through a high level architecture of the CG Okta portal and then we're going to go through a demo to see the portal in action. Starting at the top left of the diagram with the end user, our end user will access the portal through a web browser and our web portal is built in AngularJS, so there'll be single signed on through Okta into the portal. During the single sign on, we'll use the Okta Angular SDK to pull in their login profile. This logging profile will provide us with some general information on the user, in addition to their factors and the enrollment status of each of the factors we make available to them. So say for example, the user wants to enroll in SMS text message as another factor.

Kelcey Lorenzo: [inaudible 00:30:23] initiate that change through the front end and it's going to be sent to a backend intermediary server built in Node.js, and then before anything is changed or even sent to Okta, we're going to follow that Zero Trust methodology that Brian mentioned earlier at Capital Group, how we never trust and always verify, and challenge them with the second identity verification challenge, just to ensure that they are who they say they are and there isn't some attacker or another person trying to enroll their device on a different user's profile. So this can be done either through any previously or current enrolled factor that the user has in Okta or we also have an in-house identity validation EPI at Capital Group. So once they complete that challenge and we confirm, okay, the user is who they say they are, the change to update their enrollment status for SMS will be sent to Okta. The user will satisfy any confirmations in order to enroll their number, and then once everything is registered on their login profile, the information will be relayed back to the Node.js server and to the front end and updated in real time.

Kelcey Lorenzo: So the user can immediately see that their status in Okta VR or in SMS text message was immediately confirmed, and then they can go about their day and now use SMS text message as their MFA factor. Now we're going to take a look at a demo. After the user is single signed on in, they're going to be presented with this dashboard. At the top you can see that we pulled in the user's name. For this example, we're going to use my user and you can see the different factors I have available to me to enroll in, and the enrollment status of each. So for this example, I'm already enrolled in Okta Verify and I'm going to enroll an SMS text message as a second factor. So when you click enroll, this is the second identity validation challenge, and I'm going to use Okta Verify to confirm I am who I say I am. A push notification is going to be sent to my enroll device, and once I confirm that, yes, it's me making this change, I'm going to be presented with this form to input my mobile number that I want to use for SMS text.

Kelcey Lorenzo: When you input the number, a verification code is going to be sent to your phone from Okta, and once I put in the verification code and I verify that it's correct, there's going to be a message displayed to the user, so me, saying that I successfully enrolled in SMS text message for MFA. We also provide a little instruction blurb on how to use it on your next login. So when you close that window, you can see that my status for SMS text message updated automatically, so I can visually see and confirm that yes, I am enrolled in SMS text message and the next time that I go to use an application that requires a MFA, I have both options of Okta Verify and SMS now. That was just one of the examples of different projects that we're working on here at Capital Group in the space of automation and self-service with Okta. So now looking forward, what's next?

Kelcey Lorenzo: The main focus area is that self-service application on-boarding. Since our teams are definitely exploring the OIDC space and the [inaudible 00:34:05] space as Brian mentioned earlier, these application configurations are a little bit more nuanced than, for example, a SAML application to the on-boarding into Okta. So with this self-service application on-boarding platform, we can allow and enable our application teams and developers to on-board an application when they want to and then also make changes to that configuration in Okta as they're developing in order to get their applications deployed and tested with the least amount of friction as possible. To go along with that, another area that we're looking into and designing and researching is an automated application administrative platform. This will definitely offload a lot of that operational overhead that I mentioned earlier and save a lot of our operations and admins teams a lot of time.

Kelcey Lorenzo: For example, if we wanted to apply a sign on policy across our entire organization, right now one of our operations engineers would need to go onto the Okta admin council, click into the application and apply that policy by hand for every single application, the hundreds of applications we have across the various tenants in our environment. That's just opening up an opportunity for some mistakes to be made, misconfigurations to be put in place. Whereas if we had an automated platform or an automated method to handle these sort of tasks, we'd be able to create a configuration file in one place, have multiple people check it to make sure that it's correct and then push it out automatically to our entire environment. This will save also a lot of time with debugging, troubleshooting, some head-scratching that our applications teams go through whenever they encounter an error that they've never seen before.

Kelcey Lorenzo: At the end of the day, with these two methods in addition to the CG Okta portal and other automation self-service methods that we're working on at Capital Group, the end goal is to enable our application teams to be able to move faster, get their applications set up with the least amount of friction. Especially where they're moving toward a more agile methodology with DevSecOps, we don't want to be what ... our team doesn't want to be the force that's holding them back. Then also with this, our team can then take more of a backseat or a step back and just provide more expertise troubleshooting and guidance for these application teams as we all work together to secure our environment at Capital Group. So now, I'm going to pass it back to Chris for some key takeaways.

Chris Miller: Thanks Kelcey. If we want to look at our key takeaways here, I would suggest three things here. From a ... Get my slides to change. All right, there we go. The key takeaways that we have here are ... Okay, so here we go, is really as we started the conversation around Zero Trust is that strong identity plus Device Trust is a better security as well as a better user experience. Hopefully between the conversations that Brian and Kelcey have shared, that's becoming obvious. The idea that a single password being lost or compromised could cause a problem in our environment is going down due to Zero Trust. So if you're not thinking about this, it's something you would definitely should be thinking about because it's just better security and a better way to protect your company as we look at mobile and cloud activities. The second takeaway is that Device Trust works, and it's easy to get started. As Brian mentioned, we didn't do a all-in right away thing. It was really easy for us to get started with this.

Chris Miller: Pilots and prototypes are easy to do with Okta, and I think you see the value right away, both in terms of how easy is it to set up and how much the users actually enjoy working this way. The last takeaway that I would highlight for everyone here is that smooth adoption requires thoughtful user engagement. So as Brian walked through all the technical pieces on what we've done, I think hopefully you've heard from Kelcey that there's a lot of things you can do with Okta in terms of how you provide that user experience, because the last thing you want is to have folks that are frustrated [inaudible 00:39:01] usage is a lot more behind the scenes for Okta, so providing a really clean, simple user experience for them to adopt this and to really be able to get the benefits is important. On the back side of things, the DevSecOps, I'm assuming many of you are somewhere in your journey of DevSecOps as a company. You're really putting all of this in the hands of the developers to move fast and to be able to do what they want to do, but have security just built into the process of how they do it is really important.

Chris Miller: So if you think about an option, you want to think about your user bases, your developers, your associates, think about what's most meaningful for them and how they work and make sure you're keeping that in mind as you go through your adoption. So Device Trust, Zero Trust, strong identity is better, it's easy to get started and think about user experience. So those would be the three things that I would leave you with for today, and that concludes our presentation around Zero Trust at Capital. If there's any questions as we go into the live sessions, we'll be happy to chat about that. Hopefully this has been interesting for you and has inspired you to go do something in the zero-trust space. If you've been thinking about it or considering it or haven't yet decided, hopefully this helps you at least get a perspective of how financial services company like ourselves are adopting these technologies successfully.