[AUTHOR: open on a specific moment you hit this. A task where you installed the wrong module, or watched someone run both with two sign-in prompts stacked up for a job that touched a single SharePoint list. One or two concrete sentences.]
Every comparison of these two modules lists the same feature differences and stops exactly where the useful part starts. Which one do you install, today, for the thing in front of you.
For SharePoint work, the honest answer is not the one the comparisons set up.
The short version
SharePoint work, meaning sites, lists, libraries, permissions and content: PnP PowerShell.
Everything else in the tenant, meaning users, groups, licences, Teams, Intune, conditional access: Microsoft Graph PowerShell.
They are built completely differently
Microsoft Graph PowerShell is autogenerated from the Graph API. Every endpoint Microsoft exposes becomes a cmdlet, automatically, which is why the full umbrella runs to over forty sub-modules. It reaches the entire tenant, and the cmdlet names carry the fingerprints of the machine that generated them rather than a person who sat down to name them.
PnP PowerShell is community-built, focused on SharePoint, and its names read like English. On my machine it exposes 775 commands, every one shaped Verb-PnPNoun:
Get-PnPList
Get-PnPListItem
Set-PnPListItem
Add-PnPFile
Get-PnPSiteCollectionAdminYou can guess most of them without looking. Writing a script at speed, one you have not written before, that guessability does more real work than any feature table will ever capture.
The support difference nobody says out loud
Microsoft Graph PowerShell is a Microsoft product. Something breaks, you have a support path and a ticket to raise.
PnP PowerShell is community-maintained. Microsoft backs the PnP initiative, but the module itself carries no official support and no ticket queue. It is excellent and it is everywhere, and none of that helps you at 2am when a production job has stopped and your organisation’s rule is that automation runs on vendor-supported tooling. Somewhere with that rule, the support line decides everything before the feature comparison even starts.
The September 2024 change is the tell. Microsoft deleted the shared app registration PnP had always used, and overnight every PnP script needed its own app registration to sign in. That is a community timeline landing on production systems, and I wrote the whole episode up in Connect-PnPOnline: Specified Method Is Not Supported.
Where each one is genuinely better
PnP wins on SharePoint depth, and it is not close. Graph can read a list and write an item. The moment the job is a permission audit, a bulk field change, a site template, or version cleanup, PnP has a command for it and Graph has you hand-assembling raw API calls. Everything in my PnP PowerShell posts would be considerably more work in Graph.
Graph wins on everything that is not SharePoint. Users, groups, licence assignment, Teams, mailboxes, devices, sign-in logs, conditional access. PnP has crept into a little of this, it even ships Get-PnPEntraIDApp and sign-in report commands, but Graph is the native home and always will be, because that is the API it is generated from.
Both do authentication properly
Neither module makes you trade away an auth method to get it. Connect-PnPOnline covers the full range:
-Interactive yes
-DeviceLogin yes
-ClientId yes
-ClientSecret yes
-CertificatePath yes
-Thumbprint yes
-ManagedIdentity yes
-AccessToken yesInteractive when you are at the keyboard, certificate or managed identity for the unattended jobs. Connect-MgGraph covers the same ground on the Graph side.
The part that changes the question
PnP can call Graph directly. It ships with two commands for exactly that:
Invoke-PnPGraphMethod
Get-PnPGraphAccessTokenFrom inside a PnP session that is already connected, you can hit any Graph endpoint that has no PnP command of its own:
Invoke-PnPGraphMethod -Url "v1.0/users?`$top=5" -Method GetMost comparisons never mention this, and it quietly dissolves the whole versus. A job that is mostly SharePoint with a little Graph in it does not need two modules, two connections and two auth contexts held in your head at once. You connect with PnP, do the SharePoint work with PnP commands, and drop to Invoke-PnPGraphMethod for the one user lookup you actually need.
So, in practice
- Mostly SharePoint: install PnP, and reach into Graph with Invoke-PnPGraphMethod when you need to.
- Mostly users, groups, Teams, devices: install Graph. It is the native tool and it is supported.
- Production automation under a vendor-support rule: that rule decides it. Graph.
- Both all day: install both. They coexist without complaint, and each is best at its own half.
Treating this as a religious choice is the thing that irritates me about how it gets argued online. They are tools with different shapes. I reach for PnP first because I live in SharePoint, and Graph stays installed for the days I do not 🙂
