PnP PowerShell offers many ways to authenticate. Which one you choose comes down to a single question: is there a person at the keyboard or not. All methods below require your own -ClientId, unless you configured a default.
Interactive: the everyday method
A browser window opens and you sign in, including MFA. Suitable for work you run yourself.
Connect-PnPOnline -Url https://contoso.sharepoint.com -Interactive -ClientId <client id>Device login: no browser on that machine
You get a code to enter on another device. Useful on servers without a desktop, or over a remote session.
Connect-PnPOnline -Url https://contoso.sharepoint.com -DeviceLogin -ClientId <client id>Windows authentication (WAM)
Uses the built-in Windows sign-in prompt. Faster and more secure than the browser flow, and supports Windows Hello, FIDO keys and conditional access.
Connect-PnPOnline -Url https://contoso.sharepoint.com -OSLogin -ClientId <client id>App-only with a certificate
The right method for scheduled tasks. No user is involved, so MFA does not apply.
Connect-PnPOnline -Url https://contoso.sharepoint.com -ClientId <client id> -Tenant contoso.onmicrosoft.com -CertificatePath .\PnP.Automation.pfx -CertificatePassword (ConvertTo-SecureString -String "…" -AsPlainText -Force)If the certificate is in your certificate store, the thumbprint is enough:
Connect-PnPOnline -Url https://contoso.sharepoint.com -ClientId <client id> -Tenant contoso.onmicrosoft.com -Thumbprint <thumbprint>Managed identity
If your script runs in Azure (an Automation Account or Function, for example), use a managed identity. No certificate or secret to manage, and nothing that expires.
Connect-PnPOnline -Url https://contoso.sharepoint.com -ManagedIdentityWhich should you choose?
For manual work: interactive, or WAM on Windows. For automation in Azure: managed identity. For automation elsewhere: app-only with a certificate. Avoid client secrets where you can; certificates are safer, and a secret in a script is a leak waiting to happen.
Checking and closing the connection
Get-PnPConnection
Disconnect-PnPOnlineFrequent errors and how to fix them
These are the messages people type into search when the module will not start. The exact wording is here so this page can be found.
The term 'Connect-PnPOnline' is not recognized- The module is not loaded. Install on PowerShell 7 (not 5.1), close the window, then Import-Module PnP.PowerShell.
AADSTS700016 / Application not found- The Entra app is missing or the Application (client) ID is wrong. Register your own app (required since 2024).
AADSTS65001 / consent- Admin consent is missing. In Entra: the app → API permissions → Grant admin consent.
not compatible with Windows PowerShell 5.1- Current PnP.PowerShell runs on PowerShell 7 only. Use pwsh, not powershell.exe.
PnP Management Shell / multi-tenant app retired- Since 9 Sep 2024 you must register your own Entra app. Register-PnPEntraIDApp or create it in Entra.
Access denied / Attempted to perform an unauthorized operation- The app is missing Graph or SharePoint scopes, or Sites.Selected is not granted on this site.
Please specify a valid client id for an Entra ID App Registration- Since 9 September 2024, Connect-PnPOnline only connects with your own Entra ID app. Register it once with
Register-PnPEntraIDAppForInteractiveLoginand connect with-ClientId. You get the same message with an empty client ID or an app from another tenant. Step by step. Assembly with the same name already loaded- Multiple PnP.PowerShell versions. Uninstall-Module PnP.PowerShell -AllVersions, then one version, new window.
Questions about this, or need help setting it up? We are happy to think along.
Message on LinkedIn →