Nicolas Blank, Merill Fernando, and I spent our last webinar on why app sprawl happens: Onboarding an app takes four minutes and needs no approval, while offboarding has no owner, no trigger, and no process.
If you watched it, you already know the diagnosis. This post is the treatment. Think of it as the companion guide, less “here’s the problem,” and more “here’s exactly what to build.”
TL:DR
Every application in your tenant needs three things: a birth certificate, a review date, and a death certificate. Here’s how to give it all three.
You cannot govern an app better after the fact than you defined it at creation. Whatever’s missing on day one stays missing for the life of the app, unless someone deliberately goes back and fixes it. And we all know that nobody does. So this is where to start, not where to get to eventually.
Build an intake form that forces an answer to six questions before an app registration gets created:
Two things to get right when you implement this. First, keep the business owner and technical owner as two separate named people wherever you can. The business owner answers “should this still exist?” and owns the justification and the decommission trigger. The technical owner answers “is this configured correctly?” and owns credentials, rotation, and permission scope. Collapse them into one name, or leave one blank, and you don’t have accountability, you have a hope. And only Nic and I deal in hope in this regard. You should not.
Second, don’t just populate the Owners field and call it done. A populated field isn’t an owned app. Nothing about Entra enforces that the field is filled in, confirms the person still wants the role, or clears it when they leave the company. Build your own process to validate it. That’s on you, not the platform.
⭐ QUICK ANSWER: Entra ID application lifecycle management means giving every app a named owner and a review date the day it’s created, then a real decommission step when it’s retired. The five stages are request, provision, operate, recertify, and decommission. Entra tracks what exists; it never decides whether it should stay.
Once an app exists, it decays in exactly four ways, silently, like a thief in the night, with nothing that trips an alarm on any single day. Here’s what to build against each one.
Credentials. Secrets and certificates get issued once and forgotten. There’s no native rotation in Entra, so build your own trigger: use an app management policy to cap secret lifetimes tenant-wide and set a monitoring rule that flags anything older than 12 months or expiring inside 30 days. Resist the urge to extend an expiring secret to avoid an outage. That just delays the same fragility to a worse moment.
Permissions. Scope only grows unless something forces it back down. Two habits fix this:
Access. Assignments freeze at go-live and never get revisited. Set up recurring access reviews, not just for your users, for your applications and service principals too. If your licensing includes Entra ID Governance, this is largely a configuration exercise, not a build. If it doesn’t, put a recurring calendar reminder in place until you can get it automate. A manual review beats no review.
Ownership. The person named as owner changes teams, changes roles, or leaves, and the record never notices. Tie a check here to your HR leaver process directly if you can when a person offboards, their owned apps should surface as an exception queue, not silently keep running with a ghost owner attached.
Before you build any of the above, get this distinction right, because it changes what “complete” means for your inventory.
Every app is really two objects. The app registration is the definition. It lives in the tenant that created it and declares what permissions the app may ever request. The service principal is the local identity. It’s what signs in, holds the specific consent that was granted in your tenant, and carries the live credentials.
Here’s the part that catches people out. Third-party SaaS tools have no app registration in your tenant at all. Only a service principal. If your audit process only looks at app registrations, you are structurally blind to most of your third-party footprint, which is often where the highest-risk, least-visible access actually sits. Audit both objects, not just the one that’s easier to find.
You don’t need new tooling to make real progress. Entra already ships with controls most tenants have never switched on:
A practical note: several of these sit behind Entra ID Governance or Workload Identities Premium, not the base SKU. Check your own licensing before you plan a rollout around any of them – there’s no point building a process around a control you haven’t bought yet.
And be clear-eyed about where the platform simply stops, so you don’t spend time waiting for Entra to do something it was never going to do.
What Entra doesn’t give you:
Entra will tell you exactly what exists in your tenant. It will never tell you whether it should still be there. That judgment call is yours to build a process around.
This is the actual target state, and it’s a loop, not a one-time project:
Almost every organization I talk to has built stages one and two reasonably well. That’s the exciting, visible part of the process. Stages four and five are what separate real governance from paperwork, and they’re the two everyone skips, because they’re unglamorous and nobody’s job depends on doing them.
This is the step that gets half-done more than any other, so treat it as its own checklist, not an afterthought at the end of an offboarding ticket:
My practical advice: Disable first and wait before you delete, like pulling the network cable out of the server and perform the “scream test”, like Nic calls it. Block sign-in, then give it thirty days. If nothing breaks, no failed job, no support ticket, no confused Teams message, you have your confirmation, and you can finish the job with confidence instead of hoping.
You don’t need a budget approval or a platform migration to begin. Six moves, starting today:
If you take nothing else from this guide:
If you haven’t watched the webinar this guide accompanies, it’s worth an hour – Nicolas, Merill, and I go deeper on why each of these gaps exists in the first place. But if you only have ten minutes today, the six moves above are where I’d actually start.
Run a free assessment with AppGov Score and see exactly which apps in your tenant are missing an owner, a review date, or a way out.
It’s the set of controls that follow an app from creation to retirement: a named owner and a review date at onboarding, monitoring and access reviews while it runs, and a real decommission step when it’s no longer needed. Entra ID tracks what exists in your tenant; it doesn’t manage any of this for you.
The app registration is the global definition of the app and lives in the tenant that created it. The service principal is the local identity that actually signs in, holds the granted consent, and carries the live credentials. Third-party SaaS apps often have only a service principal in your tenant, with no app registration at all.
Set a review date at the moment an app is created, not later. From there, tie ownership checks to your HR leaver process so an owner’s departure automatically flags their apps, and run a recurring access review on top of that, at least annually if you don’t have Entra ID Governance to automate it.
An unowned app has no one to confirm it’s still needed, no one accountable for its permissions, and no one who notices when its credentials expire. Populating the Owners field isn’t the same as having an owner; if nothing validates that the person still wants the role, the field is just a name, not a control.
Block sign-in on the service principal first and give it roughly 30 days to confirm nothing breaks. Then revoke every granted permission, delete its secrets and certificates, remove its role assignments and group memberships, and delete the service principal and app registration. Record that it happened so it doesn’t get quietly recreated later.
Entra ID has no native business-owner attestation, no lifecycle state on the application object, no built-in decommission workflow, and no long-term credential monitoring. It will show you what exists in your tenant; deciding whether it should still be there is a process you have to build yourself.