Use System Managed Identity for authentication against Microsoft Graph API

This guide shows how to use a system-assigned managed identity to call Microsoft Graph from Azure-hosted automation.

This is usually the preferred approach for Azure Automation, Azure Functions, and other Azure-native workloads because it removes the need to store secrets.

Why use managed identity

Benefits:

• no client secret to store or rotate
• identity lifecycle tied to the Azure resource
• simpler secret management
• better security posture for enterprise automation

Typical use cases

• Azure Automation runbooks
• Azure Functions
• scheduled reporting
• Intune or Entra inventory jobs
• background synchronization jobs

Prerequisites

• Azure resource that supports system-assigned managed identity
• permission to enable the managed identity
• permission to assign Microsoft Graph application permissions
• Microsoft Graph PowerShell modules if using PowerShell-based setup

Step 1: Enable the system-assigned managed identity

For Azure Automation:

1. Open the Automation Account
2. Go to Identity
3. Enable System assigned
4. Save the configuration

Azure creates a service principal in Microsoft Entra ID for this resource.

Step 2: Assign Microsoft Graph application permissions

Managed identities use application permissions, not delegated permissions.

Examples:

• User.Read.All
• Group.Read.All
• Device.Read.All
• AuditLog.Read.All

Grant only what the workload really needs.

Step 3: Authenticate inside the workload

With Microsoft Graph PowerShell

Connect-MgGraph -Identity
Get-MgContext

Example Graph call

Get-MgUser -Top 10

Operational recommendations

• document which Graph application permissions are assigned
• use least privilege
• split identities by workload if the access profile differs
• review permissions periodically

Summary

System-assigned managed identity is the preferred authentication model for Azure-hosted Microsoft Graph automation because it is more secure than secrets and easier to operate.