PnP PowerShell app-only, certificate or client secret?

30-second answer

On PnP.PowerShell 3.3.0, an Entra ID application-only connection uses a certificate. -ClientSecret exists on the cmdlet, but it belongs to the SharePoint ACS parameter set, which is the retired model, and combining it with -Tenant fails before authentication is attempted at all.

What this proves

The first row is a parameter binding failure, not a credential one: PowerShell decided the combination does not name any supported way of connecting, so nothing was sent anywhere. Asking the module which parameter set carries -ClientSecret answers it directly, and the answer is SharePoint ACS (Legacy) App Only.

What it does not prove

It does not prove a secret was rejected. Nothing reached Entra ID or SharePoint, so nothing there formed an opinion about the secret. A reader who takes the message as a rejected credential goes looking at the secret, and the secret was never the problem.

It also does not generalise across versions. PnP.PowerShell changes its parameter sets between releases, and ACS stopped working in SharePoint Online for every tenant on 2 April 2026. What is established here is the behaviour of 3.3.0, on 18 August 2026. A different version may well accept a secret in an Entra flow, and this article does not predict that either way.

PowerShell

# Works
Connect-PnPOnline -Url $url -ClientId $appId -Tenant $tenantId `
  -CertificatePath ./app.pfx

# Fails, and not with an authentication error
Connect-PnPOnline -Url $url -ClientId $appId -Tenant $tenantId `
  -ClientSecret $secret

# Which parameter set owns -ClientSecret
(Get-Command Connect-PnPOnline).ParameterSets |
  Where-Object { $_.Parameters.Name -contains 'ClientSecret' } |
  Select-Object Name

Example output

Parameter set cannot be resolved using the specified named parameters.
One or more parameters issued cannot be used together or an insufficient
number of parameters were provided.

Name
----
SharePoint ACS (Legacy) App Only

Explanation

Azure ACS application-only for SharePoint is the older model, and Microsoft has retired it: ACS stopped working in SharePoint Online for new tenants on 1 November 2024 and for existing tenants on 2 April 2026, with no option to extend. Microsoft's guidance for Entra ID application-only access to SharePoint REST and CSOM requires a certificate, and PnP's parameter sets reflect that split. The name of the surviving parameter set is the clearest documentation of the module's position.

Self-signed is enough for the application to authenticate; the certificate proves possession, and it is not a trust anchor for anybody else. Any standard tool produces one. What the app registration needs is the public certificate; what the script needs is the .pfx:

openssl req -x509 -newkey rsa:2048 -keyout app.key -out app.crt `
  -days 365 -nodes -subj "/CN=my-automation"
openssl pkcs12 -export -out app.pfx -inkey app.key -in app.crt -passout pass:

Upload app.crt to the app registration, keep app.pfx where the script runs, and treat the .pfx as the secret it is.

Production considerations

• Certificates expire. A one-year certificate is a one-year outage with a date on it: put the renewal somewhere that will be read.
• The .pfx is a credential. It belongs where secrets belong, not beside the script in source control.
• Connecting successfully still says nothing about permissions. See Connected, and still refused.

Related governance rules

None. This is how a script proves who it is.

References

• Granting access via Entra ID Application Permissions (Microsoft, checked 6 November 2026)
• Azure ACS retirement in Microsoft 365 (Microsoft, checked 6 November 2026)
• Connect-PnPOnline (PnP PowerShell)

Found something wrong? Suggest a correction. The article source is not public; the engine it cites is.