Naming conventions are not bureaucracy. In an environment without the hierarchy that Group Policy provided, names are the only structural documentation you have.
The architecture article explained why naming discipline matters – Intune has no OU structure, no inheritance, no visible policy order. A policy’s name is often the only thing that tells you what it does, what it targets, and why it exists. This article gives you the actual convention I use and the reasoning behind each segment.
The pattern
Every policy name follows this structure:
[Platform] - [Framework] - [Type] - [Category] - [Scope] - [Name] - [Version]
In practice, for a Windows Settings Catalog policy managing BitLocker from the OIB baseline, that looks like:
Win - OIB - SC - Encryption - D - BitLocker - v3.7
Each segment carries specific meaning. None of them are optional.
Segment by segment
Platform tells you what the policy targets. Win for Windows, Mac for macOS, iOS for iOS, And for Android. Cross-platform policies targeting users rather than devices get All. This goes first because it’s the most fundamental filter – when you’re looking at a list of sixty policies, platform is the first thing you need to know.
Framework tells you where the policy came from. OIB for OpenIntuneBaseline policies. MSFT if you’re using Microsoft’s built-in baselines. VCIO or your own initials for policies you’ve written from scratch. This matters because it tells you where to look when you need to understand or update a policy – whether it’s governed by an external baseline you’re tracking, or something you own entirely.
Type tells you the Intune policy type. SC for Settings Catalog, ES for Endpoint Security, TP for Template-based profiles, CR for Compliance policies, RM for Remediations. This lets you filter quickly in the portal and tells you what kind of conflict behavior to expect.
Category tells you the functional area. Encryption, Defender AV, ASR, LAPS, Firewall, Edge, OneDrive, Office, WUfB. This is the segment that tells you what the policy actually does. Keep categories consistent across policies – if you call it Encryption in one policy, don’t call it BitLocker in another.
Scope tells you whether the policy targets devices or users. D for device, U for user. This is the segment most people skip, and it’s the one that causes the most confusion when you’re troubleshooting why something isn’t applying. A user-targeted policy won’t apply to a device group. Knowing the scope from the name saves you the step of opening the policy to check.
Name is the plain-language description of what the policy does. Keep it short and specific. BitLocker, Defender Antivirus, ASR Rules, Local Admin Password. This is not the place for marketing language or aspirational descriptions. Describe what the policy configures, not what you hope it achieves.
Version tracks the baseline version if you’re following an external baseline, or your own version increment if you’re managing the policy yourself. v3.7 for OIB policies tracks the OIB release. For custom policies, start at v1.0 and increment when you make meaningful changes. This tells you immediately whether a policy is current or running an older version that may need updating.
A policy name should answer seven questions without you having to open it. Platform, origin, type, function, scope, purpose, version.
Applying it to groups
Groups follow a simpler pattern because they don’t have the same type complexity:
[Product] - [Object Type] - [Platform] - [Function]
Examples:
Intune - Devices - Windows - PilotIntune - Devices - Windows - ProductionIntune - Devices - macOS - ProductionIntune - Users - All LicensedIntune - Users - Pilot
The product prefix keeps Intune groups together in the directory. The object type – Devices or Users – tells you immediately what kind of group it is and therefore what kind of policy it can receive. Platform narrows it further. Function – Pilot, Production, Exclusion – tells you its role in the assignment model.
Applying it to Conditional Access policies
Conditional Access naming follows my VCIO CA Framework convention (inspired by Joey Verlinden’s approach), which uses a numeric prefix to establish policy order and a structured, VCIO-tagged suffix to describe the policy’s purpose:
CA[number]-VCIO-[Persona]-[Control]
Examples:
CA000-VCIO-Global-BlockLegacyAuthCA100-VCIO-Privileged-PhishingResistantMFACA200-VCIO-Users-Windows-CompliantDeviceCA400-VCIO-Guests-MFA
The numeric prefix does double duty – it establishes a logical grouping by persona (000s foundation, 100s privileged and Tier 0, 200s managed users, 300s BYOD, 400s externals, 500s non-interactive, 600s agents, 700s the P2 risk overlay) and it sorts the policy list in a consistent order in the portal. When you have thirty CA policies, that sort order is the difference between a readable list and a wall of text.
Enforcement
A naming convention only works if it’s followed consistently. Document it, put it somewhere accessible, and apply it to every policy from day one. Retrofitting names onto an existing environment is painful – not technically difficult, but operationally disruptive because policy names appear in reports, alerts, and documentation. Changing them mid-flight means updating everything that references them.
If you’re taking over an environment that has no naming convention, don’t try to fix it all at once. Rename policies as you touch them for other reasons. New policies always get the correct name. Over time the environment converges without a disruptive bulk rename operation.
Intune Deployment Guide · Phase 2: Identity and Tenant Foundation
‹ Previous: [2.3] Designing for Scale: Naming, Structure, and Assignments
Next: [2.4] Conditional Access Prerequisites: What Must Be True First ›
