/
/

How to Automatically Tag Azure AD Devices Based on Security State or Ownership

by Richelle Arevalo, IT Technical Writer
How to Automatically Tag Azure AD Devices Based on Security State or Ownership blog banner image

Microsoft Entra ID (formerly Azure AD) is now widely used for hybrid and cloud-native joined devices, making it more critical than ever to classify endpoints by ownership and security compliance. Automated tagging is central to this process, supporting Conditional Access, reporting, alerting, and lifecycle workflows, especially in multi-tenant MSP environments.

This guide walks you through methods to apply automated Azure AD tags to devices based on security state and ownership. It also covers how to enforce these tags and use them to apply access rules.

Click to Choose a Method💻

Best for Individual Users

💻💻💻

Best for Enterprises

Method 1: Use Azure AD dynamic groups for basic tagging
Method 2: Tag devices via Microsoft Graph API based on security state
Method 3: Use registry tags for ownership or security classification
Method 4: Use Group Policy to support consistent tagging on corporate devices
Method 5: Trigger Conditional Access or policy filters based on tagging

Methods to automatically tag Azure AD devices based on security state and ownership

Before getting into the methods, make sure you meet the following requirements to ensure a smooth process:

  • Microsoft Entra ID (formerly Azure AD) Premium P1 or P2 (for dynamic groups and Conditional Access)
  • Admin permissions to query and update Entra ID (formerly Azure AD) or Microsoft Graph API
  • PowerShell 7+ with the Microsoft Graph modules installed
  • Device compliance policies in Intune
  • Optional: NinjaOne for registry/policy tagging and reporting across tenants

Method 1: Use Azure AD (now called Microsoft Entra ID) Dynamic Groups for basic tagging

Use this foundational method to automatically add or remove devices based on real-time attributes such as ownership, operating system, or trust type. Dynamic membership ensures devices are always accurately included or excluded without manual work.

📌 Use Cases: Best if you need automatic, directory-level grouping of devices by built-in attributes like ownership, OS, or join type.

Step-by-step:

  1. Navigate to entra.microsoft.com and sign in with your admin account.
  2. In the left-hand menu, click Groups.
  3. Select All groups > New group.
  4. For Group type, click Security.
  5. Enter the Group name and Description.
  6. For Membership type, select Dynamic Device > click Add dynamic query.
  7. Enter device rules such as: (Read #1 in ⚠️ Things to look out for.)
    • device.deviceOwnership -eq "Company"
    • device.deviceOwnership -eq "Personal"
    • device.trustType -eq "AzureAD"
    • device.isCompliant -eq true

Example group rule for company-owned, compliant devices:

(device.deviceOwnership -eq "Company") and (device.isCompliant -eq true)

  1. Click Save.
  2. Use these dynamic groups to assign policies, monitor compliance, or segment reporting.

💡 Tip: For details, read Manage rules for dynamic membership groups in Microsoft Entra ID.

Method 2: Tag devices via Microsoft Graph API based on security state

Dynamic Groups can’t filter directly on compliance or risk. With the Microsoft Graph API, you can query devices by compliance/security state and write custom tags (extension attributes) back to the Entra ID (formerly Azure AD) device object. The tags can then be used for reporting, automation, or Conditional Access policies.

📌 Use Cases: Best if you want to automate tagging based on compliance or risk signals that aren’t available in Entra by default.

Step-by-step:

  1. Install the Graph module: (Read #2 in ⚠️ Things to look out for.)

Install-Module Microsoft.Graph -Scope CurrentUser

Install-Module Microsoft.Graph.DeviceManagement -Scope CurrentUser

  1. Connect to Graph:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.ReadWrite.All", "Device.ReadWrite.All"

  1. Query devices with non-compliant status:

$devices = Get-MgDeviceManagementManagedDevice | Where-Object { $_.ComplianceState -ne "compliant" }

  1. Apply an extension attribute tag:

foreach ($d in $devices) {

$entraDevice = Get-MgDevice -Filter "deviceId eq '$($d.AzureADDeviceId)'"

Update-MgDevice -DeviceId $entraDevice.Id -AdditionalProperties @{

extensionAttribute1 = "NonCompliant"

}

}

  1. Use these attributes for custom compliance reports or to build assignment rules.

Method 3: Use registry tags for ownership or security classification

When built-in attributes aren’t enough, you can add custom tags directly to the Windows registry. These lightweight tags can then be surfaced into Intune using Proactive Remediation or Custom Compliance.

📌 Use Cases: Best if you need custom, organization-specific labels stored locally on devices for compliance or reporting.

Step-by-step:

  1. On endpoints (especially hybrid-joined), use PowerShell to write registry tags:

New-Item -Path "HKLM:\SOFTWARE\Org\DeviceTags" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\DeviceTags" -Name "Ownership" -Value "Company"
Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\DeviceTags" -Name "Compliance" -Value "Healthy"

This creates a custom registry path with two tags:

    • Ownership = Company
    • Compliance = Healthy
  1. Verify via Command Prompt:

reg query HKLM\SOFTWARE\Org\DeviceTags

This is to confirm if the values are set correctly.

  1. Use RMM tools or Intune Proactive Remediation scripts to centrally collect and manage these values.

Method 4: Use Group Policy to support consistent tagging on corporate devices

In hybrid or AD-joined environments, Group Policy can enforce baseline registry tags or run scripts across all corporate devices. This ensures consistency in tagging, even before devices are enrolled in Intune.

📌 Use Cases: Best if you manage hybrid/AD-joined devices and want consistent corporate tags applied at scale.

Step-by-step:

  1. Press Win + R, type gpmc.msc, then click Enter to open the Group Policy Management Console.
  2. Navigate to the Organizational Unit (OU) containing your target devices. (Read #3 in ⚠️ Things to look out for.)
  3. Right-click the OU > Create a GPO in this domain.
  4. Right-click the new GPO > Edit.
  5. Navigate to:

Computer Configuration > Policies > Windows Settings > Scripts > Startup

  1. Click Add > Browse, then locate your PowerShell script.

Paste this command into a text editor and save it as a .ps1 file:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Org\DeviceTags" -Name "Ownership" -Value "Company"

  1. Once applied, all targeted devices will carry consistent tags.

This helps tag Windows 10/11 Pro devices not enrolled in Intune but joined to Entra or hybrid AD.

Method 5: Trigger Conditional Access or policy filters based on tagging

Once devices are grouped or tagged (Methods 1-4), Conditional Access and Intune filters use those tags to enforce access rules and apply the proper baselines. This is where tagging becomes actionable for real-world security.

📌 Use Cases: Best if you want to enforce access and policy decisions by consuming existing device tags.

Assign different compliance policies or security baselines (e.g., stricter controls for personal devices)

  • Use Intune assignment filters to apply stricter compliance policies and baselines to corporate devices (e.g., require BitLocker, Defender AV) while applying lighter rules to personal devices.

💡 Tip: For details, read Use filters when assigning your apps, policies, and profiles in Microsoft Intune.

Create Conditional Access (CA) policies tied to ownership or compliance

Use device filters in Conditional Access to enforce access rules based on ownership and compliance state.

Examples:

  • Require corporate devices to be compliant before accessing Microsoft 365 apps.
  • Allow personal devices, but only with MFA or limited browser access.

💡 Tip: For details, read Require device compliance with Conditional Access and Create a device-based Conditional Access policy.

Use Microsoft Defender for Endpoint to escalate risky or non-tagged devices for remediation

  • Integrate Defender risk signals into Intune compliance policies.
  • Devices tagged as High Risk or Noncompliant in Defender can be automatically blocked or forced to remediate via Conditional Access.

💡 Tip: For details, read Use Microsoft Defender for Endpoint to enforce device compliance with Microsoft Intune.

⚠️ Things to look out for

RisksPotential ConsequencesReversals
1. Using incorrect attribute values in dynamic group rulesGroup doesn’t populate; devices are excluded from targetingEdit the group rule with the correct syntax (e.g., device.deviceOwnership -eq "Company") and save
2. Missing or incorrect Graph API permission scopesScript fails silently or cannot update device objectsReconnect with the correct scope: Device.ReadWrite.All, DeviceManagementManagedDevices.Read.All
3. Linking a Group Policy Object (GPO) at the domain level instead of a specific OU.Tags apply to all domain devices, including unintended onesUnlink or reassign the GPO to the correct OU, then run gpupdate /force

Additional considerations

Here are important points to keep in mind when configuring tags:

Tagging sensitivity

Tags directly influence access and policy enforcement. Mistagged devices can bypass protections or be over-managed. Manual tagging is error-prone and vulnerable to manipulation by local admins. Use automated tagging via Intune filters, Graph API, or Defender rules to maintain integrity.

BYOD restrictions

Bring Your Own Device (BYOD) endpoints often can’t meet full enterprise security baselines. Tagging allows you to apply risk-based access controls without blocking productivity. Use ownership tags to restrict access for personal or untrusted devices.

Multi-tenant MSP environments

Managed Service Providers (MSPs) managing multiple tenants should standardize tagging logic across environments. Use consistent registry paths, device categories, or extension attributes. Align dynamic group rules to ensure policies and reports behave the same way across tenants.

Audit trails

Because tags are tied to access, changes must be traceable. Use Microsoft Entra audit logs, Intune device compliance reports, and Graph API execution logs to monitor who changes what, when, and why.

Troubleshooting

Here are the common issues you may encounter during configuration and how to resolve them:

Tags not visible

If a device or user doesn’t show the expected tag, it’s often due to missing Graph API permissions or because the device object hasn’t synced properly into Entra ID (formerly Azure AD).

  • Validate Graph API permission scopes:
    • Device.ReadWrite.All to write tags
    • Device.Read.All to read them
  • Confirm the user or device exists in Azure AD (now called Entra ID) and has synced or registered correctly.

Dynamic group not populating

If a newly created dynamic group remains empty, the issue is usually a rule syntax error or evaluation delay.

  • Double-check the rule syntax:
    • (device.deviceOwnership -eq "Company")
  • Know that dynamic groups can take up to 15 minutes to evaluate after creation or attribute changes. In many cases, simply waiting resolves the issue.

Registry keys missing

If the expected registry tags don’t appear on a device:

  • Confirm your PowerShell or GPO script is actually being deployed and executed.
  • Ensure it runs with system or administrator permissions.
  • If using Intune scripts, enable the option to run in 64-bit PowerShell to avoid values being redirected under WOW6432Node.

Intune filters not applying

If the compliance policy, baseline, or app isn’t applying as expected, even though filters are configured:

  • Verify that the filter rule syntax matches the actual device attributes.
  • Check that the filter mode is configured correctly (Include vs Exclude).
  • Make sure the compliance policy itself is valid and assigned. A filter won’t take effect if there’s no policy enforcement.

NinjaOne services

NinjaOne enhances Microsoft Entra ID (formerly Azure AD) tagging strategies by:

CapabilityWhat NinjaOne enables
Scripted taggingDeploying registry-tagging scripts based on device role, user, or compliance state
Registry reportingMonitoring and reporting on custom registry values such as Ownership, Department, or RiskLevel
Endpoint mappingTagging endpoints within NinjaOne itself to mirror Azure AD filters (e.g., “Non-Compliant,” “BYOD,” “Tier1”)
Tag-based alertsTriggering alerts or tasks when device tag values change or fall outside expected values
Policy automationIntegrating backup or patching policies based on tag-driven group membership

With NinjaOne, MSPs can extend Azure AD’s device tagging ecosystem to include registry-based logic, RMM visibility, and automation.

Automatically apply Azure AD tags for stronger security and compliance

Automatically tagging Microsoft Entra ID (formerly Azure AD) devices by ownership and security state enables smarter access control, better reporting, and more targeted policy enforcement.

This guide provided a comprehensive overview of how to use dynamic Azure AD groups and Graph API tagging, as well as registry- and GPO-based tagging on endpoints. It also covered methods for validating tags across systems using Command Prompt and PowerShell.

Finally, it explained how NinjaOne can extend and monitor device tagging across clients, giving MSPs and IT teams greater visibility and automation.

Related topics:

You might also like

Ready to simplify the hardest parts of IT?