Conditional Access Essentials: Naming conventions, personas, emergency access & design process
- welka2111
- 2 days ago
- 9 min read
Updated: 37 minutes ago
Introduction
This blog post presents a comprehensive framework for implementing a persona-based Conditional Access architecture, based on the Conditional Access Zero Trust model. It offers guidance on structuring and naming Conditional Access policies, along with a solid starting point for policy creation. Without a standardised framework and naming convention like the one outlined here, policies tend to accumulate over time in an unorganised, ad-hoc manner by different administrators. This often leads to overlapping policies and confusion, especially if the original policy creators are unavailable to explain their intent. Adopting a structured, persona-based framework makes policies easier to understand, manage, and troubleshoot, while ensuring full coverage of scenarios and minimising conflicts. This baseline approach follows the persona-based methodology developed by Claus Jespersen, formerly of Microsoft (now retired), whose framework continues to serve as a reliable foundation for designing clear, consistent, and effective Conditional Access policies.
With proper personas and naming conventions, your policies can stay neat and tidy even as your company grows.
Table of contents
Conditional Access for Zero Trust
When it comes to designing Conditional Access policies, there are two common approaches: 1 - Zero Trust, and 2 - Targeted.
The Zero Trust Conditional Access architecture aligns most closely with the core principles of Zero Trust. By selecting the All cloud apps option in a Conditional Access policy, you ensure that every endpoint is protected by the specified grant controls, such as known user and known or compliant device. Crucially, this protection doesn’t just apply to apps and endpoints that explicitly support Conditional Access; it applies to any endpoint the user interacts with.
The alternative, Targeted architecture, takes a narrower view by applying Conditional Access only to specific apps you choose. While this may seem more controlled, it introduces potential blind spots.
The “Zero Trust” in Conditional Access for Zero Trust stems from the mindset that we should not start with targeted policies by default. Instead, the goal is to apply Conditional Access to all cloud apps, and then make exclusions where necessary.
There are good reasons for this:
Some applications can’t be directly selected in Conditional Access, but are still covered under All cloud apps
It significantly reduces the chance of leaving gaps in protection.
This broader, default-protective approach makes it much harder for threats to exploit overlooked services or endpoints, and ensures you’re starting from a position of maximum coverage.
Persona-based approach
There are several ways to organise Conditional Access policies, one of which is by the sensitivity of the resource being accessed. However, in practice, this method can be challenging to apply effectively while still ensuring proper access for different types of users.
For instance, consider a policy that requires both a known user and a known device to access a sensitive resource shared by guests and employees. If a guest tries to access this resource from a managed device, the policy may block their access. To accommodate both groups, the policy would need to be modified, often resulting in a less secure configuration.
Another method is to base policies on a user's position within the organisation. This can quickly lead to a proliferation of policies, making them difficult to manage.
A more effective strategy is to group users into personas - clusters of individuals who share similar access needs - and create policies tailored to those common requirements. Personas represent identity types that share enterprise attributes, roles, responsibilities, and access patterns.
Recognising how different personas interact with enterprise assets and resources is key to building a robust Zero Trust approach.
I would recommend having several Conditional Access personas, which you can adjust for granularity or simplicity:
Global - for all user personas (can be with some exceptions, such as emergency access and service accounts)
Admins (the powerful ones)
Internals (your everyday employees)
Externals (contractors or temporary helpers)
Guests (partners or visitors)
Service Accounts (special user accounts for apps or automation)
Emergency Access (your emergency/ break glass accounts)
Emergency access (break glass) accounts
Setting up Conditional Access can be risky. If you assign the wrong settings or controls to an active policy, you could cause all sorts of problem. In the worst case, you might even lock out users, including the very admins who’d need to fix it. To protect against these risks, Microsoft recommends setting up emergency access accounts - also called “break glass” accounts.
Once you have your break glass accounts in place, you can put them in a group and for example call it "CA-EmergencyAccess", where "CA" stands for Conditional Access, followed by the name of your persona. This group should therefore be excluded from all Conditional Access policies, except for specific policies created just for it. Doing this gives you a big advantage where if you mess up a Conditional Access policy and lock yourself out of the tenant, you can use the emergency access account to get back in.
I’ve also written before about emergency access (break glass accounts) here: [link1], [link2], [link3], .
Working with sub-personas
Sometimes, you want to get a bit more specific - like the admin or internal group but with a few exceptions. That’s where sub-personas come in.
For example:
CA-Admins-Exclusion-DeviceState means admins who get a special pass to bypass certain restrictions.
CA-Internals-Travelling - your standard employees who travel outside of the approved locations, whether for business or pleasure.
It’s all about flexibility while keeping control.
Role assignable groups
Some groups are super sensitive - think admins or emergency access. For these, you want extra locks on the door.
Role assignable groups are like VIP passes that only certain trusted folks can hand out. Plus, they protect members from being messed with by less-privileged admins.
My recommendation? Use role assignable groups for at least anything admin-level or emergency-related. It’s like putting your crown jewels in a safe.
Quick peek at typical personas and their policies
Here’s a quick snapshot of what you might do with some personas:
Global (does not require an Entra ID group as a dedicated policy can be scoped to All users with specific personas excluded). Global policies can be applied to all user personas except emergency access and/ or service accounts. Think of scenarios where you may want to enforce MFA for everyone or block legacy authentication without any exceptions (other than service accounts)
Admins: Block non-compliant devices, enforce passkeys, block sketchy locations, and make them reauthenticate often - these folks have power, so keep them on a short leash.
Internals: Let them in on managed devices, require occasional reauthentication, and block dodgy locations - but perhaps give a little leeway for business travel.
Externals: Mostly web-only access, require app protections on mobiles, and block non-approved locations.
Guests: Limited app access, no client apps, and regular reauthentication.
Service Accounts: Locked down to approved IPs.
Emergency Access: Special rules locking down to approved IPs, enforce phish-resistant MFA, and exclude from other policies - because when things go sideways, these accounts save the day.
Key design questions before you start
Before diving in, you want to ask some important questions - like a detective prepping for a case:
What licences do you have? (Because some features need the fancy tickets.)
Which authentication methods are you cool with? (Authenticator app, SMS, phone calls, FIDO2 keys)
Are all your users set up for MFA yet?
Do you let folks use Windows Hello for Business?
What about legacy setups - still hanging around?
Got any existing Conditional Access policies or “break glass” accounts? (spoiler alert: you should!)
How do you handle third parties - contractors, partners, or guests?
What devices and platforms do people use?
Are BYOD devices allowed, and if so, what apps can they use?
Do you want users to accept terms of use?
How often should people reauthenticate?
Any locations or IP ranges to approve or block?
Asking these questions early saves you from pulling your hair out later.
Design decision process - Conditional Access architecture
When designing your Conditional Access policies, a great place to start is by running a discovery workshop using a simple template like the one below. This helps you map out the level of access each persona requires in a clear and structured way.
The process involves making key decisions and validating important details about your users, such as whether they work remotely full-time, are always in the office, or follow a hybrid working model. You’ll also want to understand which applications they use regularly, the types of devices they access from, whether corporate-managed or Bring Your Own Device (BYOD),and their specific remote access needs.
It’s equally important to capture their current access requirements to ensure policies align with real-world use cases. Once you’ve gone through this discovery and decision-making process for one persona, repeat the same approach for each of your other personas. This consistent method will help you build a well-rounded, effective Conditional Access strategy that truly reflects how your organisation works.
Naming conventions
Now that you have a clear understanding of what you want to achieve with your Conditional Access policies, it’s time to agree on your naming conventions.
Why are naming conventions important?
Imagine trying to find your favourite jumper in a dark, messy closet where everything’s jumbled together. That’s what managing Conditional Access policies without naming conventions is like. You’ll waste ages hunting for the right policy, you’ll make mistakes, and scaling up? Forget it.
Having a clear naming convention is key to helping you and your team quickly understand what a policy is about. This makes managing and troubleshooting policies much smoother. Your naming convention should align with the overall framework you’re using to organise your policies.
Breaking down the naming format
The suggested format for naming policies combines personas, policy types, and apps, and follows this pattern:
<PolicyNumber>-<Persona>-<TargetResource>-<Platform>-<GrantControl>-<SessionControl>
Sounds complicated? Nah, think of it like a postcode for your policies. For example:
001-Global-AllApps-EnforceModernMFA
103-Admins-AllApps-NonCompliant-Block
202-Internals-AllApps-UnapprovedLocations-Block
208-Internals-AllApps-UnapprovedPlatform-Block
Each bit tells you something important: like who the policy is for (persona), what it’s protecting (target resource), and what the policy does (grant/block).
Setting up personas and policies
Alright, let’s build a couple of personas and some baseline policies. I’ll show you how to create a group for your administrators and your emergency/break glass accounts, make both groups role-assignable, and then set up some Conditional Access policies from scratch.
First, we’ll create a group for our administrators. If you need a refresher on best practices for admin accounts, have a look at this post: https://www.welkasworld.com/post/data-strategy-breakdown-series-basic-security-hygiene-1?force_isolation=true.
Sign in to the Microsoft Entra admin centre as a Privileged Role Administrator (or higher).
Go to Entra ID > Groups > All groups.
Click New group.
Fill in the details:
Group type: Security
Group name: CA-Admins
Description: Add something meaningful so it’s clear what this group is for
Microsoft Entra roles can be assigned to the group: Yes (important - you can’t change this later)
Membership type: Assigned
Choose a group owner
Add your admin accounts as members
You can assign the admin roles you need during this step or leave it unassigned for now - I’m going with Global Administrator and Privileged Role Administrator (for demonstration purposes)
Click Create when you’re ready.
Next, we’ll do the same for your emergency access persona. If you don’t already have any break glass accounts, set them up first.
Creating a break glass account is simple:
Go to Entra ID > Users > New user > Create new user
Fill out the details - for example, a username like bg1@yourdomain.com. The second account might be bg2@yourdomain.com, or you could use a different naming convention like breakglass1@, emergencyaccess@, or even a code name.
Use a long, secure password.
Assign the account the Global Administrator role permanently - not as an eligible role.
Create the account, then repeat for the second one (Microsoft recommends having two).
If you want the full step-by-step straight from Microsoft, check out this guide: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access
Once you’ve got both break glass accounts ready, create a dedicated Microsoft Entra group for them and make it role-assignable (I only selected Global Admin in this instance).
The official guidance for role-assignable groups is here: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/groups-concept
Alright, now let’s set up a Conditional Access policy to get started. Our policy will block legacy authentication for everyone (just make sure none of your service accounts rely on legacy auth prior to enforcing this policy), helping keep your environment secure by stopping older, less secure sign-in methods. Let’s dive in and build it from scratch!
Policy 1: 001-Global-AllApps-LegacyAuth-Block
Head over to Entra > Conditional Access > Policies > New policy.
Give your policy a name - I’m calling mine “001-Global-AllApps-LegacyAuth-Block.”
Under Users, set Include to All users and don’t add any exclusions.
For Target resources, choose All resources (this used to be called “All cloud apps”) and leave exclusions empty.
Next, under Conditions, click to edit Client apps. Switch Configure to Yes, then tick only the last two options: Exchange ActiveSync clients and Other clients. Click Done.
In the Grant section, choose Block access, then click Select at the bottom.
Now, before saving your policy, it’s a good idea to set it to report-only mode first. This way, you can check if anything or anyone still needs legacy authentication without accidentally locking people out.
When you try to enforce the policy, you’ll see a warning:“Don’t lock yourself out! We recommend applying a policy to a small set of users first to verify it behaves as expected. We also recommend excluding at least one administrator from this policy. This ensures that you still have access and can update the policy if needed.”
So, proceed carefully - and don’t say I didn’t warn you!
Conclusion
And that’s a wrap on this post! Naming conventions and personas might not sound exciting, but they’re the real secret to making Conditional Access run smoothly and scale without headaches.
With the step-by-step guide on setting up personas and Conditional Access policies from scratch, you’re well on your way to building a solid, secure foundation. Keep your naming consistent, group your users wisely, and plan ahead. Your future self, and your security team, will definitely thank you for it.