Conditional Access Policy Naming Conventions - Do you need them?

It's not unusual for a some environments to have complex policies that grow over a period of time, however the negative impact of these can introduce unexpected and unwanted difficulties when trying to identify what each policy does.

This drives the question, do you need an actual naming convention to help with that problem?

Let's take a step back and look at the wider picture.

Some businesses may have a team that manage conditional access policies, or perhaps they're an MSP that look after multiple customer tenants. In those situations, it's far too easy to get overwhelmed, introduce gaps and loose track of what's been implemented and where.

Yes everyone should document their implementations in an ideal world, but those of you reading this who've been in the industry a while have probably just laughed on the inside that in reality people rarely document updates made (yes I'm a cynic).

For example, if you've ever been involved with setting up a new Active Directory Domain or Azure Tenant, one of the first things you'll need to agree on is a standardised naming convention for objects, resources, accounts etc to ensure everyone works to a set design. Makes absolute sense of course!

Conditional Access Policies could absolutely benefit from the same approach.

But where you do you start?

Fortunately the community has done fantastic work in this arena already, and I take zero credit for the following recommendations. Thanks to Robbert Berghuis for sharing what we believe to be the source of the info at:

https://github.com/microsoft/ConditionalAccessforZeroTrustResources/tree/main

Naming Convention

<CA Number>-<Persona>-<Policy Type>-<App>-<Platform>-<Grant Control>-<OptionalDescription>

CA Number / Persona

CA Number	Persona
CA001 - CA099	Global
CA100 - CA199	Admins
CA200 - CA299	Internals
CA300 - CA399	Externals
CA400 - CA499	GuestUsers
CA500 - CA599	GuestAdmins
CA600 - CA699	M365ServiceAccounts
CA700 - CA799	AzureServiceAccounts
CA800 - CA899	CorpServiceAccounts
CA900 - CA999	WorkloadIdentities
CA1000 - CA1099	Developers

Policy Type

Defines the policy category

• BaseProtection (a default policy applied to all users or apps)

• AppProtection (individual policies used to allow or deny access to specific apps)

• DataProtection (can be used as an extra layer of security such as app protection)

• IdentityProtection (Used in addition to base protection policies for capabilities such as MFA-Phishing, Risky Sign-in's etc)

• AttackSurfaceReduction (Add additional policies to protect against certain locations, device types etc)

• Compliance (requires those logging in to view acceptable use / terms of use)

App

• All Resources (formally 'All Coud Apps')

• Selected Resources

Platform

• Any Device

• Android

• IOS

• Windows Phone

• MacOS

• Linux

Grant

• Allow or Block

• Require Multifactor Authentication

• Require Authentication Strength

• Require Device to be marked Compliant

• Require Microsoft Entra hybrid Joined Device

• Require App Protection Policy

• Require all of the selected controls

• Require one of the selected controls

Optional Description

Provide additional context or details about the policy's purpose.

Examples may include:

• Sign-inFrequency

• Block

• RequirePhishingResistantMFA

• ContinuousEvalulation

• PersistantBrowser

The following diagram provides a simple overview of the fore-mentioned policy structure and is available for download on my Github here.

Putting it all Together

So what does this look like in reality?

Well let's look at a Global policy first.....

CA001-Global-BaseProtection-AnyApp-AnyPlatform-MFA

This policy will enforce that ANYONE, accessing ANY APP from ANY PLATFORM will require Multifactor Authentication to sign-in.

CA101-Admin-IdentityProtection-AdminPortal-Windows-RequirePhishingResistantMFA

This policy will enforce that ALL ADMINS accessing the ADMIN PORTALS from WINDOWS DEVICES will require PHISHING RESISTANT MFA to sign-in.

Hope this all makes sense and gives you some ideas around whether implementing a naming convention would be beneficial to your business or clients.

My advice would be to document your existing environment, and try to get a good understanding of who's accessing your Tenant(s), from what device(s), what services they're accessing and from where.

Start off with foundational policy concepts such as the baseline requirements then build up from there.

I'll cover policy design in another blog, but let me know if this has been helpful or not.

Good luck!!