Organizations today are under increasing pressure to automate routine tasks across Microsoft 365 while maintaining stringent security controls. Traditional approaches that rely on hard‑coded credentials or individual service accounts introduce risk, complicate credential rotation, and hinder auditability. Managed identities, a feature long celebrated in Azure environments, now extend their benefits to Microsoft 365 automation, offering a way to authenticate runbooks and scripts without exposing secrets. This shift aligns with the broader industry move toward zero‑trust principles, where identity becomes the primary perimeter. By leveraging a single, centrally managed identity, teams can reduce operational overhead and improve compliance posture.
One of the first hurdles encountered when trying to use managed identities for Microsoft 365 workloads is the inability to assign Graph application permissions through the Entra admin center portal. The graphical interface does not expose the necessary app role assignments for Microsoft Graph, forcing administrators to turn to PowerShell. This limitation is not a bug but a design choice that encourages scriptable, repeatable processes. Embracing this approach early on helps organizations build automation pipelines that are version‑controlled and easily auditable, rather than relying on ad‑hoc clicks in the portal.
To grant the required permissions, administrators must first retrieve the service principal associated with the user‑assigned managed identity and the service principal for Microsoft Graph itself. Using the Azure AD PowerShell module or the newer Microsoft Graph PowerShell SDK, they then call New‑MgServicePrincipalAppRoleAssignment for each permission scope needed, such as User.Read.All or Group.ReadWrite.All. This cmdlet creates an explicit link between the identity and the desired Graph API permissions, effectively granting the managed identity the ability to call those APIs on behalf of the tenant.
When the automation scenario extends beyond Graph to workloads like Exchange Online, Teams, or Intune, additional steps are necessary. Each of these services may require a specific Entra administrative role to be assigned directly to the managed identity’s service principal. For example, to run Exchange Online cmdlets, the identity must be granted the Exchange Administrator role. This dual‑layer permission model—app roles for Graph and directory roles for other services—ensures that the principle of least privilege is respected while still providing the breadth of access needed for complex automation.
Once permissions are in place, the managed identity must be explicitly linked to each Azure Automation account (or other automation host) that will use it. This linkage is performed via the Identity blade of the automation account, where administrators add the user‑assigned managed identity as a permitted identity. After this association, any runbook within that account can reference the identity by its client ID, enabling seamless authentication without storing credentials in connection assets or variables.
Inside a runbook, authentication to Microsoft Graph is initiated with the Connect‑MgGraph cmdlet, using the -Identity switch and supplying the managed identity’s client ID via the -ClientId parameter. The client ID can be retrieved securely from an automation variable, a key vault, or an environment variable, ensuring that the value never appears in plain text within the script code. This pattern mirrors how managed identities are used in Azure Functions or Azure App Services, providing a consistent developer experience across platforms.
The same authentication paradigm applies when connecting to Azure resources through the Az module. Connect‑AzAccount also accepts the -Identity and -ClientId parameters, allowing a single runbook to pivot between Microsoft Graph calls and Azure Resource Manager operations without re‑authenticating or managing multiple secret stores. This uniformity simplifies runbook design and reduces the cognitive load on automation engineers who would otherwise need to juggle different authentication methods for cloud and productivity services.
Most of the Microsoft 365 PowerShell modules—including those for Exchange Online, SharePoint Online (with caveats), Teams, and Intune—have been updated to recognize managed‑identity tokens when presented via the -Identity switch. This means that, after the initial setup, the same runbook can call Get‑Mailbox, New‑TeamsChannel, or Set‑IntunePolicy without any additional credential handling. The modules internally exchange the managed identity token for a service‑specific token, abstracting away the complexity of token acquisition and renewal.
SharePoint Online remains a notable exception to this broad compatibility. As of the latest release, the SharePoint Online Management Shell does not natively accept managed‑identity authentication in the same way as other modules. Administrators intending to automate SharePoint tasks should first test the connection in an isolated runbook, possibly using an app‑only Azure AD app with certificate credentials as a fallback, while evaluating whether the upcoming preview features for managed identity support meet their needs. This cautious approach prevents unexpected failures in production automation.
The extra effort required to configure permissions and link identities is more than offset by the operational advantages gained. A single user‑assigned managed identity can be reused across dozens of automation accounts, runbooks, and even Azure Logic Apps, dramatically reducing the number of service accounts that must be monitored, rotated, and de‑provisioned. Centralizing identity management also simplifies compliance reporting, as auditors can trace all automation actions back to a single, well‑defined principal rather than a scattered collection of credentials.
To put this guidance into practice, start by inventorying the Microsoft 365 workloads your automation currently touches and mapping each to the required Graph permissions or directory roles. Next, create a user‑assigned managed identity in Azure AD, noting its object ID and client ID. Assign the necessary app roles via New‑MgServicePrincipalAppRoleAssignment and any directory roles through the Entra admin center or PowerShell. Link the identity to each target automation account, store the client ID in a secure automation variable, and update your runbooks to use Connect‑MgGraph -Identity -ClientId