setup

30-second answer

setup checks this machine, tells you what is missing and how to obtain it, and writes the target down once so that nothing is retyped afterwards.

m365-governance setup

It reaches no tenant and it registers nothing.

The step that used to have no instructions

Every connection needs an Entra ID application registration. There is no default and no way around it: PnP.PowerShell has shipped no application of its own since 2.12.0. One registration serves every run.

setup prints the command that creates one, in your own tenant:

Register-PnPEntraIDAppForInteractiveLogin `
    -ApplicationName "M365 Governance" `
    -Tenant <your-tenant>.onmicrosoft.com

It prints the command; it does not run it. Creating a registration changes a directory, and this engine reads and acquires nothing. A read-only product that quietly wrote to a tenant during its own installation would have a write path after all.

Writing the target down

Give it the id and an address, and it writes m365-governance.toml:

m365-governance setup `
    --client-id <id> `
    --tenant-url https://<tenant>-admin.sharepoint.com

[target]
tenant_url = "https://contoso-admin.sharepoint.com"

[identity]
client_id = "…"

Every later command reads it, and says which file it read. A value arriving from a file nobody knew about would be the ambient configuration this exists instead of.

No secret belongs in that file. It is committed, copied into tickets and pasted into chats. A certificate password is named there by the environment variable that holds it, never by its value. A key that names a credential is refused rather than ignored, because ignoring it would leave the password in the file while the run carried on looking correct.

What it does not establish

That the registration exists, that anybody consented to it, or that it can read anything. setup prepares a machine. Whether the identity can reach the tenant is connect, and it is a separate question on purpose.