Entra application hygiene: investigate the workload identity, not the display name
An Entra application called test, old, or do-not-use is not evidence that it is safe to remove. The same is true in reverse: a reassuring display name does not make an application safe. Start with what the workload identity can do, how it authenticates, and who can explain its purpose.
The object model matters
An app registration is the application definition in its home tenant. A service principal is the local identity that receives permissions and signs in inside a tenant. Managed identities are also service principals, but do not have an app registration to clean up. Microsoft documents these distinctions clearly in its application and service principal model. Treating these three objects as one inventory produces false positives.
Build an evidence record
For every candidate, capture the application ID, service-principal ID, owner count, credential type and expiry, delegated and application permissions, directory roles, consent history, and workload sign-in activity. Service-principal sign-ins have their own log stream, separate from user sign-ins, and are a useful signal rather than proof of safety. See Microsoft’s sign-in guidance.
Then classify the record:
| Decision | Minimum evidence |
|---|---|
| Keep | Named owner, understood purpose, valid authentication path |
| Investigate | No owner, broad permissions, expiring credential, or unclear activity |
| Contain | Credible risk, exposed credential, unexpected consent, or privileged access |
| Retire | Owner approval, dependency check, rollback plan, and a recorded change |
What I check before touching anything
I look for high-impact application permissions, directory-role assignment, certificates or secrets that are already expired or close to expiry, and a service principal with no accountable owner. A dormant identity with Application.ReadWrite.All deserves more attention than a frequently used identity with a narrow delegated permission.
Deletion is the last action, not the first. Disabling sign-in or removing a credential can be a better reversible control while the owner validates impact. Microsoft also recommends managed identities for supported Azure workloads because they remove the need for the application team to manage credentials.
A repeatable operating loop
Export the inventory. Triage it. Ask an owner to confirm the purpose. Make one reversible change through an approved change record. Validate the workload and sign-in logs. Only then complete retirement and preserve the decision record.
The public application hygiene inventory is deliberately read-only. It creates a starting evidence set. It does not make a cleanup decision for you.