Connecting to Microsoft Graph with PowerShell – Choosing the Right Method

If you’re still using AzureAD or MSOnline modules, you’ve probably already seen the deprecation warnings. The future of managing Microsoft 365 and Entra ID is all about Microsoft Graph, and if you’re a PowerShell person, the Microsoft Graph PowerShell SDK is where you want to be.

In this post, we’ll walk through different ways to connect to Microsoft Graph using PowerShell, along with the pros, cons, and example scenarios for each method.

We’ll cover:

• Interactive sign-in for admins and ad-hoc tasks
• Device code authentication for headless or limited environments
• App-only authentication using certificate (recommended for automation)
• App-only authentication using client secret (OK for labs, not ideal for production)
• Managed identity (for Azure Automation, Functions, etc.)

Prerequisites – Microsoft Graph PowerShell SDK

First, make sure you have the Microsoft Graph PowerShell SDK installed:

You can verify the module:

From now on, we’ll use Connect-MgGraph as the main entry point.

Interactive sign-in (delegated permissions)

This is the most common way to start: you sign in as yourself, get a token with delegated permissions, and run commands in your own security context. Perfect for:

• Day-to-day admin tasks
• Testing scripts
• One-off operations

Example

You’ll see a browser window asking you to sign in and consent to the requested scopes (if not already granted).

When to use:

• You’re running the script from your own workstation
• You don’t need unattended / scheduled execution
• You’re exploring APIs or building a new script

Things to remember:

• Scopes define what your token can do – don’t just use .Default everywhere.
• For production automation, delegated access is usually not the best choice.

Device code authentication (delegated, no browser on the machine)

If you’re running PowerShell on a server without a browser (or with strict restrictions), you can use device code authentication. This still uses delegated permissions, but the sign-in happens on a different device.

Example

You’ll get something like:

To sign in, use a web browser to open https://microsoft.com/devicelogin and enter the code ABCD-EFGH…

After completing the login on another device, the PowerShell session will receive a token and you can continue.

When to use:

• Servers without GUI / browser (jump boxes, management servers)
• You still want to authenticate as a user, but not on the same machine

App-only authentication with certificate (recommended for automation)

For scheduled tasks, runbooks, Azure Functions or any unattended automation, you should use app-only authentication. That means:

• A registered app in Entra ID
• Appropriate application permissions granted (and admin consented)
• A certificate used to authenticate the app

This is more secure and doesn’t rely on a real user account.

Step 1 – App registration (high level)

In Entra ID:

1. Register an App (App registrations → New registration).
2. Upload a certificate (Certificates & secrets → Certificates).
3. Add Microsoft Graph Application permissions (e.g. User.Read.All, Directory.Read.All, Mail.Read).
4. Click Grant admin consent.

Step 2 – Connect in PowerShell

You can then verify:

The Account field will show the app ID rather than a user.

When to use:

• Azure Automation runbooks
• Scheduled scripts (Task Scheduler, Azure Functions, etc.)
• Anything that must run with no user interaction

Why certificate > client secret:

• Certificates are more secure than client secrets
• Secrets are just long passwords; they can leak, be checked into code, etc.
• Certificates can be stored in Key Vault and rotated cleanly

App-only authentication with client secret (good for labs)

You can also authenticate your app using a client secret. This is easier to set up, but less secure than certificate-based auth. Good for:

• Lab environments
• Quick demos
• Prototyping

Example

When to use:

• Non-production environments
• Proof-of-concept scripts

When not to use:

• Production automation, especially with broad permissions
• Anywhere secret storage and rotation are not properly handled

Managed identity (for Azure-hosted automation)

If you’re running your code in Azure (e.g. Azure Automation, Azure Functions, Azure Container Apps), you should strongly consider using a managed identity. This lets the platform handle credentials for you.

High-level steps:

1. Enable a system-assigned or user-assigned managed identity on your resource.
2. Assign the necessary Graph permissions via roles (or app role assignments).
3. Use the managed identity to obtain a token, which the Graph SDK can use.

In many cases, the Graph PowerShell SDK can automatically use the managed identity when available and properly configured. For advanced setups you might combine Connect-MgGraph with -Identity or use Get-AzAccessToken + Connect-MgGraph -AccessToken, depending on your environment and module versions.

This topic deserves its own deep dive, so I’ll cover a full managed identity + Graph PowerShell flow in a separate post.

When to use:

• Azure Automation
• Azure Functions
• Scripts running as part of Azure infrastructure

Why it’s great:

• No secrets, no certificates to rotate manually
• Identity is tied to the resource
• Permissions are centrally managed in Entra ID

Picking the right method

Here’s a quick summary to help you choose:

• Interactive / Device Code (delegated)
• App-only with certificate
• App-only with client secret
• Managed identity

Summary

Microsoft Graph is the future of automation and management in Microsoft 365, and learning how to connect to it properly from PowerShell is a key skill for any M365 admin.

Whether you’re running quick, ad-hoc scripts from your workstation or building fully automated workflows in Azure, choosing the right authentication method will make your life easier, your scripts more reliable, and your security team a lot happier.

In my upcoming posts, I’ll dive deeper into certificate-based app-only authentication and managed identity scenarios, including real-world examples and ready-to-use code snippets.

Happy scripting!