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

What was triedResultVerified
-ClientId -Tenant -ClientSecretparameter set not resolved18 Aug 2026
-ClientId -Tenant -CertificatePathconnected18 Aug 2026

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 retirement is a moving deadline. 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

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

Text
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 been retiring it: ACS is documented as deprecated, with tenants having it disabled for new applications. Entra ID application-only for SharePoint expects 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:

PowerShell
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.

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

References

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