Mission Critical Conditional Access at Scale

So a little bit of stuff. So this is a big big company. We have that many people. Interestingly so I was when I was recollecting the stats to update this slide because this is a slide that we put in lots of different things, that has increased by 18,000 people since February which surprised me because I've actually seen a whole lot of people leaving and oh, that's that's interesting. And there's there's a bunch of stats up here. There's a bunch of things about passwordless and phishing resistance. This stuff that I like to talk about a whole lot. I don't know if any of you saw Nishant just talking about passkeys, it's a big big deal for us. That is basically just an implementation detail within this particular thing where we're just talking about conditional access but there are a whole bunch of things that we will get to there. Other big big things up here, so we've got lots and lots of devices. An interesting thing is that there are fewer managed devices in our environment than there are employees. This comes up later as an interesting problem that we will talk about when we get into some of the details of what we're trying to do and we have a lot of apps in our tenant. These we also don't allow like just end user registration free for all where we actually have tooling that supports this, these are people who are all going through a process and and putting stuff into it. But it's a big big environment. There's lots and lots of stuff. I have like a pretty substantially large team. My guess is that unless you're like at Walmart or something, your org is not this big. I'm hoping that a bunch of the things that I talk about actually will still make sense and be useful to you in your potentially smaller organizations. But but yeah, this is this is the world that I live in on a day to day basis. Alright. So let's start with the story. It was a few years ago, I will not say exactly when. We have a situation where a developer is having a problem, his app isn't working and so he talks to somebody and gets them to look at the logs and there's this CA policy and it's causing his thing to not work. And so he has another buddy that he worked with recently who helped him get some app permissions set up in the tenant and calls him up and is like, hey, you know, my app isn't working and I'd like to is there something we can do about this and like, you know, maybe you have some you could do something and this guy's like, oh, well, yeah, I see I I I see it's like it's getting blocked on this policy. So this guy, his job is actually to do, like, application registration permission consent stuff, happens to have global admin because, you know, sometimes you need global admin, and he decides to help his buddy out and he turns off the policy that it was causing the problem. So this policy, as it turned out, was a policy that we had at Accenture. It was basically like all users, all cloud apps MFA. It was our MFA posture for the entire company and he turned it off and so anyway, there was this was discovered relatively quickly and corrected relatively quickly and then at the time, did not have the job I have now. Back then, I was like I had this really cool role where I was like this architecture strategy guy, so I wasn't actually responsible for anything, I just made pronouncements. I now I'm actually still have that job but I also have to run the whole ship as well too. But this was bad and so one of my colleagues from information security organization basically contacted me, she's direct report to the CISO and she says, Joe, that's TF, what happened there? And that began our journey of trying to be a little bit more serious about how we manage this thing because as it turns out conditional access has this ability and this increasing ability within people's organizations to essentially define your entire security policy and if you mess this up, terrible terrible things can happen and I will talk about some other terrible things that have happened anyway even since we got more serious. But what we're really going to do here is we're going to go through a little bit of stuff and we've actually already covered more or less points one and two. I'm going to talk a little bit about rules governance and process stuff, possibly a little bit boring but actually incredibly important, then I'm gonna get into some specifics. I am hopeful that there are some of the companion talks later in in HIP will actually hit things in more detail. This is not a super detailed CA policy construction talk that we're going to get into, but we will hit some specific implementation details. This talk is very AI light. If you're missing Melissa's AI Doom talk right now, I really appreciate you coming to mind. I would love to see her AI Doom but we're not really going to be AI Doom here. We'll talk a little bit about AI later but this is almost almost completely AI free today. Okay, so let's keep going. So I want to talk about essentially some high level like rules and process related stuff. A thing I want to start off with here is that in the the thing that I think matters a lot is having really actually good competent people. I am very, very fortunate within my organization to have a couple of people who are really, really good at conditional access, really care about what they're doing, and are also really concerned about following the rules and the processes that we put together in order to try and make sure that we don't do things incorrectly and then also continuously improving around how we're actually doing that to make things better. In terms of taking all this stuff seriously, think this is a thing I don't really have a slide for but I think it's really important for people to think about. It's entirely possible that a bunch of the people in this room are those people, so good for you and then hopefully some of the things I talk about will actually help improve your life as you go about trying to take some things back to your organization but this is for sure people first. Alright. So getting into that, I wanna talk go through and talk a bit about how we structure things in terms of how we go about doing stuff. I'm gonna start off with guiding principles and standards, and then we'll get into some of the other bits. So first of all, we have these two basic sets of things which are the rules that we live by in Accenture. I don't want you to actually even try to read any of that, none of that is important. The reason I have these slides with these screenshots is mostly just to prove that these things exist and you can read them. We have published these things. Okay. So the first thing is these things we call guiding principles and we put this together years ago. This document has a very, very low rate of change, so we wrote it once. I don't think we've really changed it much since then, but we published this on a website that we have internally that is like the first thing that you're supposed to read if you want to request a conditional access policy. Read this first and this is essentially the rules for how we operate the platform. One of the and so I actually thought about actually going through the entire thing and explaining it because there's a bunch of pretty interesting and useful nuggets, but I think I'm not gonna do that, just going to highlight that it exists. One of the things that we do cover in there is that a goal that we have is to try and minimize the number of CA policies, you know, potentially probably because, you know, there's only so many you can have and if you let it get out of out of hand then you can have problems. A thing that happens to us in being a large consulting company is that we get a lot of requests from individual client teams like, our client wants us to restrict this blahdy blah to this blahdy blah for this set of people and that's a thing if I ever say yes to that once, I have to say yes to that to everybody and I don't have enough policies for that because I usually, those policies are all mutually exclusive, they can't be structured together into a thing that would just take up one slot in the policy architecture. The answer to that is no. We're not doing that. You cannot have that and that's a thing that we publish in our guidelines. The point of this is really that we have this thing that talks about how we're going to go about running our our ship so that if you ask us and you violate our guidelines, we're gonna tell you no, but we're also gonna be able to tell you why we said no. And then also if you ask us to do things but it doesn't align to our guidelines, we will then try to reroute it through the guidelines to make that available. If anyone's really curious about this, I could potentially share this I don't think there's anything particularly sensitive it's not in the deck or anything like that but ask me afterwards I think that would probably be okay. This wait, oh my god, don't hold down the button. So this bit, the standards so we are very very rules oriented, we have a bunch of standards, these are essentially authored by our information security organization. A bunch of people in my team participate on working on them as well too, but they're basically the rules of how security works at Accenture. These actually have a pretty high rate of change. They they do like them on a quarterly rev cycle, and they essentially define the security posture for the entire organization across a whole bunch of different pivots. The standards that are relevant to conditional access are actually spread out across a of different things, but this basically defines our posture, ends up being incredibly important for a bunch of the other things in terms of what we do because to a great extent, our goal with conditional access is to implement Accenture's standards in terms of, like, how we're presenting a security posture and the things where it's relevant, things like authentication, stuff like that. That is our primary goal is to align the policies that we've implemented with these standards and then handle all the changes and whatnot. Keeping moving there we go. Oh, no. Alright. So governance, this is largely about keeping track of who owns what and how things are managed within the organization. There's primarily like three tool sets involved with this. So we have this system that we run internally which is our application ownership system. Basically, every application as it's known within Accenture is registered in this this registry and it determines like this ownership model for it. It's incredibly important and powerful and it's something that we use throughout our entire IT model for keeping track of stuff. If you've ever had that problem like I don't know whose app this is and I don't know who's responsible for it, this is a problem we try very, very hard not to ever have and since it's a custom ServiceNow application that we built, it's part of our platform, that ties into these things up here. Every CA policy must have an owner and every app registration must have an owner. That's how we know how those things are owned. Jacob, you have a question? So it's more much more complicated than that. So the the owner is the the registration, and then there are people who are associated with it who are in different roles, and there's actually a and then it actually rolls up into a hierarchy. So, like, it, like, goes all all the way up to an org level with, like, a really senior person within the organization, and these things are actually required to be updated every 90 days. So if people come and go from these various roles and slots, the application lives on, the people can change around it and stuff. And then we actually yeah. So it's it's not a person, it's a it's a thing. And, yeah, we use this a lot for everything. So also managing all the users. Exclusions are like a GRC function, we use Archer internally for this and exclusions are super super important. Sarah talked about that this morning, it really resonated with me. A bunch of the mistakes that I will talk about as I move along are all related to exceptions. But it is very, important that all of the exceptions are managed in our GRC tool, it's a rule that we try and live with every day and hopefully you guys also have something similar within your organization for doing that. And then once we're a ServiceNow shop, all the changes or tickets that all kind of stuff. So that's that's governance in a nutshell for what we're trying to do. Okay. Process. So we were pretty process heavy. This is the kind of thing that would make a lot of smaller IT shops possibly possibly swoon and might convince a lot of IT administrators who wish to be much more agile in their behavior to like, I would never ever want to work there. But we have developed a process that we're relatively comfortable with for how we're actually doing our change control around conditional access. It basically comes into a thing that works like this. So, you make a request which is done in ServiceNow then you have to go and present your change in a change control board that happens on a weekly basis. It's Tuesday morning at 07:30 a. M. Central Time. It's like you are not invited but anyone at Accenture can attend and this is a time zone that works for like everyone and no one at the same time in a big global organization. It's mostly really, really painful for the people in in in Asia, but, you know, we all get by. My guy in California who's in charge of Privileged Access Workstations really hates this meeting too. But anyway, you gotta present it. We run through. We make sure that, like, everything you're doing aligns with our stuff. We will reject it if it does not. If it is approved, then it will move into this thing where we will deploy it later on that week and then the change rolls that way. There is a way if there are emergencies that these things can be skirted and avoided, but we still also are trying to do all this stuff and make sure that it happens. The takeaway here is not that you have to do what we do, but you ought to do something and have some structure around how you're putting your your stuff together to make sure that you don't end up making changes like the person who from the beginning of the story who made a change that he should not have done which was not even his job. Another piece of this, we actually follow our own rules. So if we are running a big campaign where we're doing a big major transformation like phishing resistance or managed device compliance or something like that, if we as our own team are doing stuff, we actually present our own stuff to our own team and, like, have other stakeholders approve it and make sure that they're actually comfortable with what we're doing. So there's no like us backdoring our own stuff. Okay? And this part, so we're not a regulated industry so we do not have a lot of audit pressure coming from that but we still get audited a lot or at least I feel like we do. Mostly, we're audited like financials related stuff and we got a lot of client specific audits because we have a lot of client contracts and they ask us are you doing this and you're doing that and so we also audit ourselves. We have our own like internal audit function that goes around just randomly auditing stuff in the company. And so it's really important for us and possibly for you if you are also audited that you have the right stuff in place so that you're ready to be audited. Like, one of the most important things is like what are you going to be audited for? Like what are the actual rules that the auditors are going to go and look at to see if you actually did things right? Are things tracking to your GRC system? And do you have a framework to actually for an auditor to be able to make a rational decision as to whether or not you're doing things well or not. Okay, so next embarrassing story guess who just recently failed an audit related to conditional access? This guy. And so what happened was we had some people excluded from a CA policy related to privileged access workstations that I will talk about later. They were in the process of onboarding, so their system had actually just been like included within tier zero. There a decision had been made. They were in the process of onboarding and they were taking a little bit longer than they probably should have and we happened to just get audited right in the middle of this thing and they didn't have like a specific EGRC exception in place and the auditors caught us. This is very easy to fix and the basic problem here was that we were not following our own rules because we were in this kind of weird transitory state and so not perfect, but at the same time, you know, at least the auditors at least knew where to look and had had a reasonable thing and all, you know, we didn't really have much to say other than, yeah, we should have been better, we probably shouldn't have actually implemented this the way that we did. But I'm gonna move on from there and switch over to implementation details now. So deep and cleansing breath and now we will get slightly more technical. Okay. So, first of all, this is real screenshot from my production tenant. There's an interesting question. So the guiding principle, we want to have as few policies as possible. So it's not clear from this if you think I'm winning or losing, I'm definitely under the policy max for CA but it's a lot. My recommendation to all of you would be to try to have fewer than I have, but it's a big complicated IT organization. There's a bunch of things that we have to do that have very, complicated targeting that requires us to break things up into multiple different policies in order to accomplish specific outcomes and so our goal is to have as few as possible but at the same time we still have an awful lot. So, yeah, key takeaway for for all of you guys is that we are we're we're trying very hard to keep this as minimized as as we can throughout what we're doing, but sometimes it does take a lot. A thing that I would say is that you you want to try and keep the surface area like down and not let things get away from you and have lots of little onesie twosie things all over the place. Make sure that you can kind of keep track of them and know what they all are. A bunch so I didn't really talk about this in the process section, but a thing I will mention very quickly is that part of our process is that we do we do staging to production from a tenant perspective, and we also do report only to real implementation as part of our thing. So it goes like report only staging, implemented staging, report only production, staging production, so you have to go through all four steps. We use report only a lot as a check to make sure if things are not going to work the way we expect them to. So the fact that I have 11 policies and report only looks to me like what I would expect to be kind of normal for how my team is managing this. This does not always work. There are a bunch of things that you cannot necessarily always catch with report only. Another thing that we're also planning to implement soon is for things that are potentially impactful and hard to measure, more ring deployment as part of like the enable in production but expand out. We we do a bunch of things like that for for campaign based stuff, but for other kinds of changes, ring deployment is another thing that we're considering adding into our mix soon to help us try and make sure that we're not accidentally flattening the Accenture environment with a with a single click. So anyway, that's that's what we're looking at for policies. You will definitely not be able to to read this so and it is not important that you do but the point of this is that I think you should have a naming convention for your your CA policies. I don't really care what it is. I will explain what ours is very quickly, but having a consistent naming convention for them is incredibly powerful. We did not used to have a naming convention for our CA policies, they were kind of all over the place and it was very hard to just be able to look at them and tell what they are. Within our model, we have this number here that's actually a governance ID tying back to that tracking system, and that actually helps us know who owns this policy, who does it belong to. A lot of times they belong to our own team, but that's okay. That's actually good. There's also a little bit of thing that does sort of indicate like what that number is because nobody actually really has all the numbers memorized, there's a lot of them. And then these things are supposed to actually state what they actually do in a human readable way in a consistent model so that you can actually read them. So this is what we're doing, I would recommend you do something, you don't have to do what we do, but do something and it took us actually a lot of effort to go back and clean up the mess that we had before we got it into this state and now we do not let it get out of control anymore. Another fun fact, Microsoft default policies are off. We do not use them. I'm not saying that you should not use the Microsoft default policies, they may be great for you, They do not generally work for us at our scale and so generally they will float to the top and appear in my screenshot, but they are not something that we're using. But I'm not making a specific value judgment other than at the scale that we're operating, they're not for us. Okay? Okay. So now I'm gonna get into a little bit more specifics around how we're targeting users and applications. So starting with member users. So there's within the tenant, have this many these are not all member users, by the way, so this stat's a little misleading. This also includes guests and other stuff, but gives you a sense of, like, the the the total counts of people and there's a whole bunch of different ID types. We put a lot of effort into our identity life cycle governance model in order to actually be able to track all this stuff. So every single identity in our tenant and also in Active Directory is tagged with a specific thing. So, like, I actually know that there's 47,000 AD service accounts in in on prem, most of which are also synced to the cloud. Probably should have mentioned before in case you hadn't already guessed, we are a big hybrid identity shop. So there's AD, there's Entra, it's synced. We're still syncing in the up direction and not the down direction because we haven't done that yet and still admiring the problem of eventually getting off of AD, but we are not close to that. We're also an e five shop in case anyone's curious about licensing and stuff. There's some things I will talk about later as we get into some specific functionality that are e five. If any of you out there are also e five customers and are being upsold by Microsoft on e seven and want to talk to me about your negotiation strategy on that, I would love to have a conversation with you. And, yeah, anyone wants to guess what my my Microsoft bill is that that we can talk about that over beers too. So anyway, targeting users. We have a specific rule here. We only use cloud only groups for targeting. We could use on prem groups that are synced up from on prem but we have a rule. Out of curiosity, this a standard or a guiding principle? No, it's a guiding principle. Yeah. So security does not care about this, we do one of the things that so I have a rule that systems that are like cloud consumed should use cloud only resources and so I forced my team to like live this every day by not actually allowing people to use hybrid sync groups for this purpose because they're consumed in the cloud, but this is this is a role that I made up to help us share the, like, moving to Entra only thing and live the dream every day. But yeah, guiding principle it's just something that I make us do. So there's a bunch of things that we do here but a big piece of it is that we so we are using cloud only groups always, that's a rule. There's a mix of dynamic groups that we're using, these things over here. So I'd mentioned that we're we do a bunch of identity lifecycle stuff in order to try and tag all the accounts and stuff like that And so I actually have like an all employees group that's dynamic and that will roll that up and all contractors. So this changing all the time as our identity life cycle stuff flows through the tenant and we use those a lot for a lot of our targeting. There's this whole big thing that we do with passwords, so a giant piece of our Accenture work from our security posture perspective which I will get into in a sec is passwordless and phishing resistant. Phishing resistant is kind of a cloud only concept. Passwordless is actually both a legacy and a phishing and a cloud concept for us in that for when I say passwordless, those people in Active Directory who are passwordless are actually marked as smart card login, so they're like fully and completely passwordless from an on prem perspective. So in order to get that into the cloud, we have some automation where we actually sync that signal, that smart card login flag up into the cloud so that I can also build dynamic groups around that because I actually need that in order to drive a bunch of my policy, but that's a big thing. We also do a lot of campaign based targeting. So when we're doing a big deployment of something like expanding phishing resistance or expanding managed device compliance, there's a lot of basically what you would call, like, ad hoc membership groups that people are member putting people into and out of in order to manage campaigns and and, you know, essentially controlling groups of people to do stuff. Alright? And then like I've mentioned before, our goal is to always document and manage all the exclusions in the GRC tool those have to be justified with something. There are in some cases they're also specifically mentioned in a security standard, but generally speaking if there's a policy that says something is required and then somebody's excluded from the policy we have to know why that is and who's in it and why and how that's governed. Okay? Keeping going, so guests guests are really different this is actually a thing that we've had to put a whole bunch of effort into because they have a tendency to bleed over into your CAA policies and my take, at least for the way we operate, is that we have to treat people who are guests very differently from people who are our member users. And so the primary use case within Accenture for for b to b guests is client collaboration. So, like, imagine that we have clients and we want them to invite them in to collaborate on team sites. We also do, like, a lot of outsourcing where we might build an application and then we have people from the client and people from Accenture all logging into this app together, so we might be using b2b guest to handle that. So we actually have like over 3,000 integrated organizations and it looks like 31,000 B2B guest accounts these are actually like pretty well governed with access packages and stuff like that so we don't have stale guests lying around. And so we treat them really, really, really differently. So because I don't control their devices, I'm not their IT guy and I don't get to make a whole bunch of rules around what they're doing, they may not be an e5 shop, they might not even know that their people have identity risk on their accounts which will flow over into my tenant when they try to log in. If they're not actively managing that, I don't want to just block them because then that that person is stuck. Right? Like that that IT org has no idea what to do with that because they don't even know that that feature exists and so my choice is to either let them in or block them and our goal is client collaboration, so we're gonna let them in. So we have lower requirements. We require MFA. We generally always accept MFA from the guest org so we're using XTAP for that. The only time we don't do that is if a client asks us not to. Like there are we have clients who use other MFA systems and they really hate it when their people get asked to register for Azure MFA when they come to our in their tenant because they don't do Azure MFA. So they're like, if you're gonna do that to us, it has to be in your tenant and so okay. But that's the exception, not the rule. Generally speaking, we always want to accept people's device signals and MFA from their tenant. And then if they have risk, all we're gonna do is MFA them no matter how bad it is, which is the same thing that they needed to get in. So it's probably maybe a re auth, but it's like a pretty low barrier whereas, like, the boom is lowered on the member users. They're like having to do much much crazier stuff, but I also control their devices mostly. Okay. So that's a little bit around how we do guess. It's important in how you design your CA policies that you always think about guests differently if you have them in your tenant because the rules the same rules may not apply and you just kind of need to partition this stuff out. Okay. Targeting applications, so our there's basically a few things that we do. We will occasionally target all cloud apps. All cloud apps is a good thing to try and do if you can. It is an interestingly difficult control to use all the time because it is hard to exclude things from all cloud apps because there are parts of the Microsoft experience that are not actually excludable, so you have to be real careful with all cloud apps targeting but we do try to use it where we where we can. We do a bunch of crazy stuff with this. This is probably one of the most interesting technical things that we do within our system and I will talk about that in a second and then occasionally we will target single apps with things. I'm gonna jump over and talk about CSA based filters. So one of the things that we need to be able to do is have lots of apps within a CA policy. I mentioned that I've got 59,000 and I think the limit on the number of apps you can put in a CA policy if you just put them by hands like two fifty, so that's not going to get it done. If I have like 22,000 apps that match a managed device compliance policy and I want those all to be in one thing, I'm not going to accomplish that outcome with any number of CA policies, it's just not going to happen. So we do some some pretty fancy stuff in order to make this happen. So there's a piece of functionality within Entra called custom security attributes. I find them to be mostly useless except for this and but here they actually are are pretty shiny and useful. And so what we actually do is we have an automation that goes against that IT governance system that I talked about before. It looks at all the apps in our tenant. It looks them up in the governance system and then it decorates them with a bunch of of CSAs that describe different stuff about them like their data classification, which is a thing that comes from the governance system. And so if I have an application that has what we call restricted data in it, we apply a bunch of CA policies to that by default and talk a little bit about that when we get into the next section here, but this system is a thing that we use for doing all of our CSA based targeting and it's incredibly powerful. This was not easy to build and we actually needed a source of data to get this off of to make it useful, but I actually think it's one of the most interesting and most powerful parts of the platform, a thing for you to consider for your organizations as well too if you want to have more automation in terms of how you want to be able to apply stuff to applications, CSA based targeting is incredibly useful and powerful, and we've gotten a lot of really, really great results with it. Like, it's completely transformed how we manage the platform internally. Okay. So getting towards the end here, I'm gonna run through a couple of of actual specific things that we want to do. So we have a number of like broad goals that we try to accomplish with CA and I'm gonna hit a bunch of them. I'm gonna actually start with this one because it's the only one I don't have a follow-up slide on. So just talk about this there's not really that much to it but I will tell another embarrassing story. We recently had attempted to implement a session policy to require fresh auth for people like just token expiration and a thing that we came to discover after having deployed this was that it works really poorly in organizations that are using a primary refresh token based authentication alpha managed devices. It just does not jive with that at all and people were having like just terrible experiences like bleeding over into their mobile devices as a result of this just disaster. So we had to go back and rearchitect this. Unfortunate our our and part of what failed here was even though we had this pretty structured way of testing this it was really hard to test and so it didn't really actually line up very well with like our report only to prod thing and it didn't really show up in staging in a way that was meaningful because we just didn't have enough of usage scenarios. So that ring deployment thing that I talked about previously is the thing that we're hoping to do in the future to not do that. But if you're thinking about doing session policies which you probably should, be careful with how that particular thing interacts and consider the levers that you pull here really carefully. Okay. Let's get into some other stuff. So I have in previous hip conferences spent the entire time talking about passwordless and phishing resistance. For the purposes of this talk, it's just a slide, it's just an authentication strengths policy. This is things that we do and so there's a couple of things that I would want you to take away from this. The main thing is that we build up our authentication strengths in layers. So we start with this baseline like MFA for everyone for all things and then we kind of narrow the scope as it goes down driving this through different mechanisms. My goal is really to have a 100% phishing resistance across the entire org. I've actually done a ton of work over the last year getting like moving from passwordless to full phishing resistance. We doing a lot of phone sign in. I had seven if you look at this previous slide, if you remember, there was like 737,000 people that had phone sign in registered on their mobile devices, passwordless but not phishing resistant. And so we had to get pass keys to all of those people and then also force them to stop using that through a pass key required policy or a phishing resistant required policy. So we have gotten to the point where we've hidden hit all the hard things and now we're we're really struggling with different parts of the business where this is actually hard to make work mostly because we don't control the devices where people are logging in and it's become hard, but we're getting there. So, like, the main thing I would want you to take away from this is that auth strengths are an incredibly important part of the stack, things that you probably should be working on and thinking about. And my my recommendation from my key architect on this is that we build this up in layers. We think that's a good way to do it and maybe something that you guys can actually take away from this in terms of how you consider structuring your stuff. Let's keep going I'm starting to run out of time. Managed device enforcement this is possibly the most difficult thing we've ever done getting back to that CSA based thing so our InfoSec guys came to us and said well, we want to require managing compliant device for kind of everything but we also like have all these people at Accenture who don't actually use Accenture devices to do work and so that and we also have a number of things where we don't necessarily want to require this like there may be certain applications that just aren't that sensitive and we want to make available to people's personal devices and stuff like that. They came up with this really elaborate thing that's all based on all these different rules and all these different exception categories and they said could you please roll this out and do this in a way that doesn't break the business? And so we spent a long time figuring this out, This whole thing that I talked about previously with CSA based tagging has gotten us to this point. The stat that I had at the beginning was showing like about 41,000 of our apps have some kind of policy requiring manager compliant device. Has changed tremendously like it was like like two years ago there's 20,000 so it's actually gotten a lot a lot larger and one of the things that's really cool about this model is that we don't really change this anymore. We may remove people from exclusion lists, but the actual the whole app model just works. If somebody adds a new app to the tenant and it meets a certain specification, it just gets this automatically. Nobody changed anything in any policy, just kind of all moves around magically with all the CSAs and all the automation and stuff. Alright? Keep going. We have privileged access workstations, believe it or not I have a thousand tier zero admins in Accenture. I don't know if that's good or bad, but it's a lot. We've got but I have 16,000 administrators at Accenture, so it's only it's less than 10%. And CA is incredibly important in this stack. One of our rules is that all all privileged access, all tier zero privileged access is supposed to be done with privileged access workstation. That's actually a CA policy that's primarily enforcing that. I talk a little bit about how we actually implemented our model here. These are just special enter join machines that are in the tenant that are managed in a a real specific way. It could have a great debate on how you should have pause and how you should design them and if we've done it the right way, but the main thing is that a big piece of what we do within this model is actually implementing privileged access workstations. A lot of this is also done at the account level, so I know what all my tier zero admin accounts are separate from all the other admin accounts and then so we apply these controls this way. The audit that I failed recently was related to implementation of this control. Sign in risk this one has also been really hard for us. A big part of the problem that we had for a long time was that we there was no there was no self-service remediation mechanism for passwordless users. There finally is now. Thank you Microsoft for shipping that. That was incredibly helpful back in the in the springtime when that finally came out. Forcing people who don't have passwords to change their password was like and so the main thing that I would say talking to my architect, the thing that he wanted you guys to know is that a large scale deployment of Entra Identity Protection which is p2 e5 feature, you really really want to focus on self-service remediation. If you are blocking people or sending people to your help desk, it's going to be incredibly difficult scale. So giving them controls that they can implement a lot of what we do is make people do a phishing resistant authentication to clear their risk incredibly helpful. The thing that is super super hard in this is accounts with shared ownership. We know what our accounts with shared ownership are because we have a pretty good governance model, but figuring out an automation to do something with those is super hard. But I don't have enough time to talk about that. So the last thing, my last minute that I'm going to take, we messed this up really badly. This is probably one of the most important policies in your tenant is your register security info. So the posture on this so, like, the worst thing that that can happen in my mind is that a threat actor registers a credential in your tenant that would be really, really, really bad. It would be especially bad if a threat actor registered a really valuable credential like a PASCII or a FIDO token because there's a really good chance that you use that as a control for a bunch of your stuff and now they have the ability to bypass a bunch of your other controls. So take this policy really, really, really seriously. We made a terrible mistake with exclusions recently that caused us to rethink our entire rule set around this. It's a standards problem. The standards, they they made sense at the time and then when we went back and looked at something bad that happened, we all decided, oh, that was a really terrible decision. We shouldn't have done it that way and now we're actually backing this back out. So part of part of the overall thing is that standards aren't forever and make sure that you go back and question them from time to time to make sure that they're useful. I am out of time, that was mostly what I wanted to talk about. I had a couple of other things but none of it's really that important. I don't know if I have any time for questions or not, but thank you very much. Hopefully, you got something useful out of my