Every application that authenticates against your tenant starts as an app registration, and in most tenants the registration blade is an archaeological site: hundreds of apps, owners long departed, secrets expired or worse still valid, and consent grants nobody remembers approving. Today is the governance treatment.

The Object Model in Three Sentences

An application object is the global definition, living in the home tenant. A service principal is that application’s local footprint in each tenant where it operates, and it is the thing that holds role assignments, receives consent, and appears in sign in logs. Multi tenant SaaS means one application object in the vendor’s tenant and a service principal in yours, which is why governing service principals, not just your own registrations, is the actual security job.

Permissions: Delegated, Application, and the Consent Chokepoint

Delegated permissions act as the signed in user, bounded by what the user can do; application permissions act as the app itself with no user present, and an application permission like Mail.Read on Graph means all mailboxes, which is why they are the crown jewel target of OAuth phishing campaigns. The control that matters most in the whole identity stack: disable unrestricted user consent. Users may consent only to verified publisher apps requesting low risk permissions (or to nothing), everything else routes through the admin consent workflow with named reviewers, an SLA, and the request visible in audit logs. That single policy converts illicit consent grant attacks from a user click into a reviewed request. On the reviewing side, judge requests by permission, not by app: Sites.Read.All for the whole tenant when the app needs one site should bounce back with instructions to use Sites.Selected, and Graph’s resource specific consent patterns increasingly make the narrow grant possible, so insist on it.

Credential Hygiene and the Cleanup

Client secrets are the weakest credential in the platform: strings that leak, expire at the worst moment, and get pasted into pipelines. The ladder out, in order of preference established across this series: managed identities where the workload runs in Azure, workload identity federation where it runs elsewhere (GitHub, other clouds, Kubernetes), certificates from Key Vault where a confidential client credential is unavoidable, and secrets only for the stragglers, with short lifetimes and an expiry alerting runbook, because the Saturday outage from an expired secret is the most preventable incident in cloud computing. Application policies can enforce this tenant wide, blocking new secrets on new registrations or capping their lifetime, and I recommend it once the estate is ready.

The cleanup is a queryable problem: registrations with no owners get owners or get disabled; service principals with no sign ins in 90 days (the sign in logs and the Graph reports tell you) get reviewed for deletion; credentials nearing expiry page their owners, not the identity team; and redirect URIs pointing at dead domains, a real account takeover vector when the domain is re registerable, get pruned. Fold the whole review into a quarterly access review cycle alongside the PIM reviews from two days ago, assign each app an owning team in a required tag or naming convention, and registrations stop being archaeology and start being inventory. Tomorrow: the customer facing side of identity with External ID.

Cheers
Osama