Options on Connecting SharePoint online modules in PowerShell

Worth a direct correction before anything else: username/password authentication to SharePoint Online — the pattern most older connection examples are built around — stopped working entirely as of May 1, 2026, when Microsoft fully retired legacy (IDCRL) authentication with no re-enable option. A second, separate method — app-only authentication via a client secret — also stopped working, since it depended on Azure ACS, retired the same year. Both connection patterns below are genuinely current as of this writing, not just “recommended” alternatives to methods that still technically function.

In this post: Why the old examples don’t work anymore · Connect-SPOService, the current way · Connect-PnPOnline, the current way · Certificate-based app-only, for unattended scripts · Managed identity, for scripts already running in Azure · Which one should you actually use? · Related reading

Why the old examples don’t work anymore

Two genuinely separate retirements, worth telling apart since they affect different connection patterns:

Legacy authentication (IDCRL) — the pattern of building a `SharePointOnlineCredentials` or `PSCredential` object from a plaintext username and password and passing it directly to `Connect-SPOService` or `Connect-PnPOnline`. Blocked by default tenant-wide from mid-February 2026, with a temporary admin override available only until April 30, 2026, and fully retired with no re-enable option as of May 1, 2026.
Azure ACS-based app-only authentication — the pattern of registering an app in the old SharePoint app catalog and connecting with `-ClientId`/`-ClientSecret` against ACS rather than Microsoft Entra ID. Retired April 2, 2026, the same date the classic SharePoint Add-in model it was originally built for was retired.

A script built around either pattern doesn’t degrade gracefully — it fails to authenticate at all, with no partial functionality. Both examples below use methods that don’t depend on either retired mechanism.

Connect-SPOService, the current way

Simplest current option — omit credentials entirely and let it prompt interactively, which also correctly handles MFA rather than fighting it:

Connect-SPOService -Url "https://yourtenant-admin.sharepoint.com"

For a script that needs to specify modern auth explicitly rather than rely on the default prompt behavior, `-ModernAuth` requires `-AuthenticationUrl` alongside it — the two are paired, not independent switches:

Connect-SPOService -Url "https://yourtenant-admin.sharepoint.com" `
    -ModernAuth $true -AuthenticationUrl "https://login.microsoftonline.com/organizations"

Connect-PnPOnline, the current way

The equivalent interactive pattern for PnP PowerShell:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -Interactive

For a headless environment with no browser available to complete an interactive sign-in — a container or a remote session — `-DeviceLogin` displays a code to enter on a second device instead:

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -DeviceLogin

Worth flagging directly, since it still shows up in guides that haven’t been updated: `-ClientId`/`-ClientSecret` app-only authentication depended on Azure ACS and stopped working when ACS was retired. It isn’t a matter of preference anymore — it’s a genuinely non-functional connection method now, not just a deprecated one still worth avoiding.

Username/password authentication and ClientSecret-based app-only auth aren’t just discouraged now — both are fully retired and non-functional as of 2026, not degraded-but-working legacy options.

Certificate-based app-only, for unattended scripts

For anything that runs unattended — a scheduled task with nobody there to click through an interactive prompt — certificate-based authentication against a Microsoft Entra app registration is the current, supported path, for both cmdlets:

# Connect-SPOService
Connect-SPOService -Url "https://yourtenant-admin.sharepoint.com" `
    -ClientId $clientId -TenantId $tenantId -CertificateThumbprint $certThumbprint

# Connect-PnPOnline
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" `
    -ClientId $clientId -Tenant $tenantId -CertificatePath "C:\Certs\app.pfx" -CertificatePassword $certPassword

This uses Microsoft Entra ID for the actual auth handshake, not ACS — a genuinely different, currently-supported mechanism despite superficially looking like the retired ClientSecret pattern above. The app registration and certificate need to be set up once in Entra ID, with the certificate’s public key uploaded to the app registration — worth doing ahead of time rather than mid-script, since it’s a one-time setup step, not something to script around each run. Worth planning for the certificate’s own expiration too: unlike a client secret that can be regenerated in seconds, replacing an expired certificate means generating a new one, uploading the new public key to the app registration, and updating every script referencing the old thumbprint — a real maintenance task worth calendaring, not something to discover when a scheduled script suddenly starts failing.

Managed identity, for scripts already running in Azure

Worth knowing as a genuinely simpler option than certificates for one specific case: a script already running inside Azure — an Automation runbook, an Azure Function, a VM with a managed identity assigned — can authenticate with no secret or certificate to manage at all:

Connect-SPOService -Url "https://yourtenant-admin.sharepoint.com" -ManagedIdentity
Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/yoursite" -ManagedIdentity

No certificate expiration to track, no secret rotation, and nothing stored in the script or a key vault reference for it to leak — the identity is tied to the Azure resource itself. The tradeoff is that it only works for workloads actually running inside Azure with an identity assigned; it’s not a general-purpose replacement for certificate auth on a script running from someone’s laptop or an on-premises server.

Which one should you actually use?

Running a script yourself, interactively, at a keyboard with a browser available — `-Interactive` (PnP) or the credential-less prompt (SPOService).
Running a script on a headless machine or over a remote session with no browser — `-DeviceLogin`.
A scheduled, unattended script with nobody present to authenticate — certificate-based app-only, set up once in Entra ID ahead of time.
An unattended script already running inside Azure (Automation, Functions, a VM) — managed identity, since there’s nothing to rotate or store.
An old script using a username/password or ClientSecret pattern — it’s not a style choice to update eventually; it’s already broken and needs replacing now.

Streamlining SharePoint Add-In Installation with PowerShell — the related Azure ACS retirement in more depth, and what replaced the add-in model it originally served.

Both retirements land in the same year, and both break connection scripts the same way — silently, with an authentication failure rather than a warning, not a slow degradation that gives advance notice. Worth auditing any scheduled or unattended SharePoint script specifically for these two patterns rather than assuming a script that worked fine last year still does today.