Cloud Security Stack
Architecture notes

Architecture

App registrations and service principals: the identities nobody reviews

They have no multi-factor authentication, no device state, frequently no owner, and permissions granted by someone who left three years ago.

11 min read · Reviewed 22 August 2026 · Architecture notes from tenant reviews.

Why these are the quiet problem

Every identity governance conversation is about people. Access reviews target users, Privileged Identity Management manages user role assignments, and Conditional Access evaluates user sign-ins. Service principals sit outside all of it.

They authenticate with a secret or a certificate, they are not subject to Conditional Access in the same way, and their permissions were frequently granted once, during a project, by an administrator who has since moved on. Nobody has looked since.

What to actually check

01

Which applications hold write permissions to mail or files

Mail.ReadWrite, Files.ReadWrite.All, Directory.ReadWrite.All applied at application level. These are tenant-wide and they do not care whose mailbox it is.

02

Which have secrets expiring, and which have secrets that never expire

The first is an outage waiting to happen. The second is a credential with no lifecycle, which is worse.

03

Which have no owner

An application with no owner is one nobody can vouch for. That list is always longer than expected and it is the right place to start removing things.

04

Which have not authenticated in ninety days

Sign-in logs cover service principals. An application that has not been used in three months is a candidate for disabling, and disabling is reversible.

The consent question worth asking

Who in your tenant can grant consent to a third-party application, and does that include ordinary users? If user consent is unrestricted, anybody can authorise an external application to read their mail, and increasingly that is how phishing campaigns establish persistence rather than by stealing a password.

Moving to something better

Managed identities remove the credential entirely for anything running in Azure, and that is the single best structural improvement available. Where a managed identity is not possible, certificates outlive secrets and rotate more predictably.

The governance layer that helps most is simply an owner on every application and a quarterly review of the list. Unglamorous, and it catches almost everything.

The verdict

Our pick

Inventory, owner, expiry, then managed identities where possible

The inventory is free, assigning owners costs an afternoon, and managed identities remove whole categories of credential problem permanently.

Who should skip

Do not start by tightening consent policy alone. Restricting user consent without an application inventory produces a queue of approval requests nobody has context to decide.

Disclosure. Some links on this site are affiliate links. Scoring weights are published before any programme is joined, and commission is never a ranking input. Full policy, and the method behind this guide.