Wins & Challenges: Implementation of Conditional Access policies Persona-Based IAM design in a large enterprise

Hello, hello. It works. Great.

Good day, colleagues. Thank you very much for your time and thank you for joining. My name is Pavel. I work as a cloud solution architect in Novo Nordisk based in Denmark, and today I will talk about conditional access policies, specifically about persona-based design and what kind of wins and challenges you can experience there. Primarily challenges, I have a long list, but let's go into that. So we'll start with some introduction to set this in, what is it about.

Next, we'll talk about some general considerations which we usually agree on when we start implementation of CA design. Next, we'll touch briefly persona-based design and proceed with the wins and challenges. So session assumptions here, this session is kind of advanced in the sense that I will not explain what is a conditional access policy, how to configure that, what options we have, and so on. So I expect that you know what is it about. You know what a conditional access policy is. It is focused primarily on CA.

I'm not touching some other cool things like strong authentication and agentic AI and all these things. It's primarily about CA. And the last but not least assumption that I assume that EntroID is your identity provider, otherwise it doesn't make a lot of sense. So what we are doing here, we are building zero-trust architecture and we use a conditional access policy engine which contributes to that, and the engine is very flexible and it has a lot of different options and you can do it in many ways.

But as an outcome, the implementation is very different and it depends on customer needs and there is no golden standard how you should structure your CA policy, how you should design that. And if I have a great design in my organization, I can just copy and paste it in your organization and it will work. So as an example here, that's from Microsoft Docs, how you can set the naming standards for your policies, and here you can see that you can use, I don't know, application with some requirements for principle, with some conditions and some enforcements.

I'm not saying it's a good example, but it's definitely an example and it shows the complexity. So there are many ways how you can do that. But usually when we sit around the table and think about, okay, what should we do? What kind of general considerations we all agree on? That would be something like that. So probably we agree that we want to build zero trust. It means that it should be scalable, it should include all resources, it should include all accounts.

We want to minimize the number of CA policies on the one hand, but on the other hand, we don't want to build one size fits all and have a hundred exceptions from that. So it should be kind of balanced in that sense. We want to follow some naming standards. We want to use report-only mode to do evaluation and we want to roll out in rings and probably we want to use configuration as a code. And we can discuss how do we want to use block versus grant versus session controls.

Probably we would like to prioritize grant controls with some enforcements and use block controls on some global catch-all policies. And the last part of this here, we want to treat CA assets as items that access to those must be highly restricted. And I intentionally use assets word here, so that's not only CA policies. These are all objects in your infrastructure that may affect conditional access policy. It could be groups, it could be attributes related to accounts, it could be, you know, authentication strength, protected actions, whatever you use.

So you should evaluate and have a list of permissions that could touch those so how we can somehow bypass CA policy without touching CA policy itself. So all this should be included in that. As soon as we agree on those, we can actually move forward and think about the structure. And one of the approaches is we call it persona-based design. It was developed by Klaus Jesperson, who is a former Microsoft consultant from Denmark. And there are many ways how we can structure that you see on the slide. You can do it based on the org structure. You can do it based on some resource criticality.

But we use it as persona-based design and it's very successful design that was developed a time ago and it is used by many customers across the world. And obviously it's based on personas. And by saying persona, we mean identity types that share common attributes, common responsibilities, experiences, objectives, and access. And this is the screenshot from Klaus GitHub, so which kind of persona you can use. And it doesn't mean that you should follow that one, but you got the idea, right? So we should take the accounts and somehow classify them, split them in different groups.

And next we can apply different requirements that probably would be not the same for admins and let's say for guests. So it would be different set of policies. As soon as we agree on general considerations, we agree on persona design.

Actually, we immediately have some wins here. We have clear design, good naming standards. It is based on attributes. So we either can use dynamic security groups or we can use IGA solution that can manage these attributes. It is truly zero trust. It includes all by default. It's covered. And it's scalable in a sense that we include all future accounts and all future scenarios there as well. It is quite balanced in a sense that it's not very high level and it's not very low level. And it naturally assumes rollout in rings.

So each persona itself is a ring, and you can do rings inside of your persona when you do rolling out. I will stop here. If you want to go further with that, there will be a link to Klaus GitHub. You can go and explore yourself. There are some PowerPoint materials, Excel templates and other stuff. So this is something that actually we want to implement. And it sounds like a great idea and it's documented. Let's just go and do that. But that's where life happens. So when we start with the implementation, we will experience some challenges. And that's my challenge with this slide.

I have really a lot of content here. I will not explain all these things. I was thinking, what should I pick and choose?

Top five, top 10, top three. And I will try to cover these five today that I can see the kind of basics and important. And the last two are some kind of tricky workaround that you can use in your organization. But let's start. So the one challenge is we mentioned that we want to build this personas based on the groups. And probably you want to do it based on dynamic security groups. It sounds like a great idea. And it's easy and it's dynamic. You don't need to maintain that. But as soon as the persona becomes a dynamic group, then membership in this group becomes crucial.

And technically, it means that now you need to be in charge for good hygiene of dynamic groups in your organization. Because if you do not have a good hygiene, and here you can see some recommendations how we can achieve that, then you could be throttled. And if you are throttled, the account will not become a member of the dynamic group. And if an account is not a member of the dynamic group, it means that the policy will not be applied. So that's one thing. Another thing, we mentioned the dynamic groups based on attributes. Which attributes do we mean here?

Because if we use standard attributes like extension attributes, now we expose in our scope, we need to include all the roles in EnterID and all the service principles that have permissions to write those attributes. Because those potentially may affect CA policy. One idea that we explored, it would be nice to use custom security attributes. These are looked, you know, much better in the sense that they are fenced, and there is no access to those by default. And these are not supported for dynamic groups, as you probably know. And they are partially, it's done intentionally.

They're not supported because we don't want to expose those visibility of custom security attributes inside of dynamic security groups. So what you could do in place, you can use kind of dynamic groups that will be managed by your IGA solution. So IGA will add, remove accounts from groups. And IGA will be in charge for assigning this custom security attributes. So that's a good way how you can mitigate the challenge explained here. And you can actually get benefit from custom security attributes. And you can mix this. So you can use groups, and you can use attributes in CA policies.

And this is a very basic thing. So as soon as we agree on persona-based design, this is something that you need to decide next. So it will be a logical next step here.

Next one, service accounts in cloud. So these cannot work interactively. So a lot of CA policies, let's say, related to multi-factor authentication could not be applied. They cannot, you know, click the button on the phone. So you can use some mitigation factors, such as location, device compliance, or certificate-based authentication in some cases. And a separate case is the RPA, Robotic Process Automation, or bots accounts that are expected to work interactively, clicking some buttons, and they don't support MFA out of the box.

So some third-party libraries can help here, such as Bonsai Castle and some others. And there was a good session yesterday about passwordless. So I'm not a big fan of these third-party libraries. But it was mentioned yesterday, and I agree with that, that any form of authentication is better than static password. So if you use password and this MFA, that's better. But generally, it's an evil. So don't use those. And generally, you should say no to anyone who is asking service account in cloud and provide them better cloud options, such as managed identity, service principles.

But again, potentially, you have some legacy applications that cannot use that. So you could be in that situation that you must approve of it. But if you approve that, you could say, as a strategy on company level, it comes with a cost. So if you want to use it, you can do that. But pick and choose, I don't know, at least one, or maybe based on criticality, at least two additional restrictions that will be placed against your service account.

Next one, device compliance. That's a big one.

Actually, it comes from zero trust for devices. We cannot trust a device if device is not compliant, if we are not in control, if we are not sure that all the policies are there, device is not jailbroken, and the health state is green, and so on. So it sounds very simple.

OK, let's just do one safe policy, scope to all applications, to all accounts, and enforce device compliance. And that's where challenge comes, because probably you will experience some, I call it, poorly written applications. What we had seen in the last time, it was primarily iOS applications, and it's iOS native applications. So they use kind of a legacy web component that is not recommended by Apple, but developers use that. And it's like a headless browser behind the scene, and that headless browser doesn't provide the signal from the device.

So the connection is treated like it comes from an unmanaged device. So the solution here, work with the vendors, ask them to fix that. And while it is happening, usually the workaround is to use browser version of this application, like Safari or Edge. So it's nothing to do with application. It's more the way how it was implemented in that native form. And that's one thing. Another thing, some scenarios are not supported. For example, share type path. So it supports just limited set of applications, but it cannot be used for all applications that you potentially need.

And that's nothing to do with application. That's the problem with this scenario. Microsoft doesn't support it, and Apple doesn't support it. So what should we do here? One potential workaround, if you have MDM solution, you can classify accounts that are used on those devices in a separate group.

And next, configure enrollment of specific certificate. Even you can go deep and specify the specific template for those accounts.

And next, configure CA policy that only certificate-based authentication on that template will be allowed for these accounts, and all the rest is blocked. So and that's kind of a way how we can bring the device signal through CBA to EntroID. So that works, actually. That works. Until vendors will mitigate this or until you implement another solution, how we can bring the device signal from those. But I think this is the biggest one that we've been working last year or something. We finished that in 2025, and it took a while to build all that.

Next one, allow application policy and exclusion options. So sometimes you have a scenario when you want to allow only specific list of applications for specific persona type. The good example here, guest identities. We have guests invited in our organization, and we want to say, OK, generally, we allow this, I don't know, this number of apps. All the rest is blocked by default.

Next, we grant access to specific guests on application level, but the idea here is that someone, if someone will misconfigure something, the access will not be exposed on the limited set of applications available. So it sounds very simple. Let's just create CA policy, you know, scope it to all persona accounts, and exclude applications that are allowed, block all the rest. And now you come to the problem that some applications cannot be excluded by design, including some first-party Microsoft applications. The exception just doesn't work. It's not supported. What should we do here?

The idea is that, OK, we potentially could exclude accounts, but it means that they will access everything. So one trick that they can use, actually, interesting fact that Defender for Cloud Apps supports these scenarios, even when Android is not supporting that. So what you could do, you could create a policy on Android's side that will exclude the applications that you can exclude, and redirect all the other authentication traffic to MDA side, and create a mirror access policy on MDA side that will allow applications that cannot be excluded here, and block the rest.

So as an outcome, we have the full list of applications that you want to allow. It's just split it into pieces, and one piece lives on Android, another piece lives on the MDA side. So that could be the solution here. And if you are not in that situation that you need to exclude such a problem application, then congratulations. You don't need to do that. You can just mitigate it on EnterID level. But if you are in that scenario, then you can do this one. But if you do this one, then you have a bonus challenge.

And the bonus challenge is related to MDA groups versus EnterIC groups, because you tend to create a mirror policy on MDA side that will be scoped to the same group that you used on EnterID side. But group membership is a sync operation from EnterID to MDA, and it may take some time. And the problem here that account may be already in the group on EnterID, but this membership is not synced on MDA yet. And the only solution here, you need to adjust your business process.

So these accounts, they should come in the group in advance, and they should have enough time to be synced on MDA So that's the idea. So we have a safe policy that is scoped to some group A, and we create a mirror policy that is scoped to the same group. And you have a business process that ensures that as soon as account comes in this group, it will not access the application immediately, but we'll have this delay. So we'll have enough time to sync this configuration. But that's not the case in some situations. In some situations, you need to onboard account urgently.

So it means that it will not be in that group yet, and that could be a problem. So how we can fix this? You can create a catch-all policy here and scope it to all users and exclude group A, B, C, D, all groups that do not fulfill this scenario. And in this case, if this sync has not happened yet, then the connection will be in scope of that catch-all policy. And here you can provide some kind of custom message to the user, like your access has been provisioned, something like that. You need to wait and come later.

So it's not the best solution, but we expect that it will not be the standard process how it happens. But in some situations, or if it happens, someone was lost and not synced yet, then at least you are not leaving the user alone in the rain, standing without access. Yeah. So let me sum it up here. As you could see, CA design, even such a great design, which was developed by Klaus Jespersen, persona-based design, won't fly on its own. You need to do your basics. And these basics are related to groups, related to service accounts, related to service principles.

I didn't touch service principles here, but it could be a separate session how we can build CA policies for workload identities. This adoption is a continuous process. You have the design, you have the roadmap, what you are building, the model you are moving into, and you can adjust it. Start from one persona this time, completely onboard the persona into the design, proceed with the next one. And the last but not least here, if you want to take one thing from the session, I would say please don't be quiet about challenges.

A lot of work is in progress from Microsoft's side, and a lot is not in progress. But actually, make some noise if you have problems and provide this feedback to the vendor. And we can say that for the last two years, we experienced this feedback loop works, actually. So when we complain, and at some point it comes as a solution. Some links here that you can use, and the first one is a link to Klaus' GitHub for a detailed description of persona-based design, and some other links that I used when I prepared the presentation here. That's it from my side. Thank you very much.