Most Microsoft 365 security reviews focus on people: who has MFA, who holds admin roles, who signs in from where. Entra app registrations security gets far less attention, yet every app registration and service principal is an identity that can read mail, list files or change directory settings without a human ever typing a password. If you have never audited yours, this article shows you where to look and what to fix first.
What workload identities actually are
A workload identity is any non-human identity that authenticates to Microsoft Entra ID. In practice you will see three kinds in a small or mid-sized tenant:
App registrations (application objects) that your team or a vendor created for an integration, a script, a reporting tool or a line-of-business app.
Service principals, the local instance of an app in your tenant. Every enterprise application you consented to, including third-party SaaS tools, has one.
Managed identities for Azure resources, where Azure handles the credential for you.
The important difference from user accounts is that workload identities cannot perform MFA, often have no owner or lifecycle process, and need to store a credential somewhere. That combination is why attackers like them. A client secret pasted into a script on a file share, or committed to a code repository, is effectively a password that never expires and never gets challenged.
Why app registrations get forgotten
In the tenants I review, the pattern is almost always the same. Someone built an integration three years ago. The person who created it has left. The app still has a client secret valid for another year, holds Microsoft Graph application permissions like Mail.Read or Sites.Read.All across the whole tenant, and nobody can say whether it is still in use.
A few reasons this happens:
By default, regular users can register applications, so app objects appear without IT involvement.
User consent settings are often left permissive, letting staff grant third-party apps access to their mailbox and files.
App registrations do not show up in the usual user access reviews or offboarding checklists.
Application permissions (app-only access) are granted once by an admin and then never revisited.
A practical audit checklist
You can do a first pass in an afternoon from the Microsoft Entra admin center. Work through these in order.
List every app registration. Go to Entra ID > App registrations > All applications. Export the list and note the creation date and owners for each.
Find orphaned apps. Any app with no owner, or an owner who has left, goes on a review list. Microsoft’s own guidance is to keep owners to a small set of people and review them every few months.
Check credentials. Open Certificates & secrets on each app. Flag secrets with long lifetimes, expired credentials that were never cleaned up, and apps carrying several secrets at once.
Review API permissions. Look for application permissions on Microsoft Graph, especially anything ending in .ReadWrite.All, plus directory roles assigned to service principals. Ask whether a delegated or narrower permission would do the job.
Check redirect URIs. Remove unused URIs, avoid wildcards and plain http, and confirm you still own every domain listed. A lapsed domain on a redirect URI can lead to app compromise.
Review enterprise applications. Under Entra ID > Enterprise apps, sort by permissions granted and look for third-party apps that users consented to on their own.
Check sign-in activity. The service principal sign-ins tab in the sign-in logs shows which apps are actually authenticating. Apps with no sign-ins in months are candidates for removal.
Fixes that make the biggest difference
Restrict who can register apps and grant consent
Turn off the setting that lets all users register applications (Entra ID > Users > User settings), and delegate app creation to the Application Developer or Application Administrator role for the few people who need it. Then tighten user consent under Enterprise apps > Consent and permissions: either disable user consent or limit it to verified publishers with low-risk permissions. Enable the admin consent workflow so users can request an app instead of being stuck.
Replace secrets with better credentials
Client secrets are the weakest option. Microsoft recommends certificates or managed identities instead. If the workload runs in Azure and does not need to sign in users, a managed identity removes the stored credential entirely. For workloads outside Azure, such as GitHub Actions pipelines, workload identity federation lets the app authenticate without any secret. Where secrets must remain, keep lifetimes short and store them in Azure Key Vault, never in scripts.
Apply least privilege to permissions
Remove permissions an app no longer uses. Prefer delegated access over app-only access where the scenario allows it. For Exchange Online, application access policies or RBAC for Applications can limit an app with mail permissions to a specific set of mailboxes rather than the whole organization.
Use separate registrations per purpose
Do not reuse one app registration for several integrations. Separate registrations keep permissions and credentials isolated, so a compromise of one does not expose everything.
Monitoring and Conditional Access for workload identities
Auditing once is good. Watching continuously is better. Two capabilities matter here.
Audit log alerts. Adding a credential to an existing application outside your normal change process is a classic persistence technique. The Microsoft Entra audit logs record these events under the ApplicationManagement category (“Update application, Certificates and secrets management”). Send those logs to Microsoft Sentinel or a Log Analytics workspace and alert on them.
Conditional Access for workload identities. With Microsoft Entra Workload ID Premium licensing, you can create Conditional Access policies that target single-tenant service principals registered in your tenant. Policies can block a service principal from outside known IP ranges or when Microsoft Entra ID Protection rates it as high risk. Note the limits: Microsoft and third-party multitenant SaaS apps are not covered, managed identities are not covered, and the service principal must be assigned directly to the policy, not through a group.
The real fix is process, not a one-time cleanup. Three habits keep this under control:
A request process for new apps. Every new app registration needs a named business owner, a technical owner, a stated purpose and the minimum permissions it needs.
A quarterly review. Check owners, credential expiry, permissions and sign-in activity. Add app owners to your offboarding checklist so ownership transfers when someone leaves.
Entra recommendations. The Recommendations blade in the Microsoft Entra admin center flags apps with unused or expiring credentials. Review it monthly.
Do I need to license every app registration for Workload ID Premium?
No. Microsoft does not require you to assign Workload ID licenses to individual service principals. Licensing is sized to the workload identities that use premium features, such as Conditional Access and risk detection. Check the current Workload ID FAQ on Microsoft Learn before you buy.
Is it safe to delete an app registration I don’t recognize?
Not immediately. First check the service principal sign-in logs for recent activity and ask around. A safer path is to disable the service principal (or remove its credentials) and wait a few weeks. If nothing breaks, delete it. Deleted app registrations can be restored for 30 days.
What is the difference between an app registration and an enterprise application?
The app registration is the global definition of the app, usually in the tenant that built it. The enterprise application is the service principal, the local copy in your tenant that holds permissions and assignments. Third-party SaaS apps appear only as enterprise applications in your tenant, so review both lists.
Most Microsoft 365 security reviews focus on people: who has MFA, who holds admin roles, who signs in from where. Entra app registrations security gets far less attention, yet every app registration and service principal is an identity that can read mail, list files or change directory settings without a human ever typing a password. If you have never audited yours, this article shows you where to look and what to fix first.
What workload identities actually are
A workload identity is any non-human identity that authenticates to Microsoft Entra ID. In practice you will see three kinds in a small or mid-sized tenant:
The important difference from user accounts is that workload identities cannot perform MFA, often have no owner or lifecycle process, and need to store a credential somewhere. That combination is why attackers like them. A client secret pasted into a script on a file share, or committed to a code repository, is effectively a password that never expires and never gets challenged.
Why app registrations get forgotten
In the tenants I review, the pattern is almost always the same. Someone built an integration three years ago. The person who created it has left. The app still has a client secret valid for another year, holds Microsoft Graph application permissions like
Mail.ReadorSites.Read.Allacross the whole tenant, and nobody can say whether it is still in use.A few reasons this happens:
A practical audit checklist
You can do a first pass in an afternoon from the Microsoft Entra admin center. Work through these in order.
Entra ID > App registrations > All applications. Export the list and note the creation date and owners for each.Certificates & secretson each app. Flag secrets with long lifetimes, expired credentials that were never cleaned up, and apps carrying several secrets at once..ReadWrite.All, plus directory roles assigned to service principals. Ask whether a delegated or narrower permission would do the job.Entra ID > Enterprise apps, sort by permissions granted and look for third-party apps that users consented to on their own.Fixes that make the biggest difference
Restrict who can register apps and grant consent
Turn off the setting that lets all users register applications (
Entra ID > Users > User settings), and delegate app creation to the Application Developer or Application Administrator role for the few people who need it. Then tighten user consent underEnterprise apps > Consent and permissions: either disable user consent or limit it to verified publishers with low-risk permissions. Enable the admin consent workflow so users can request an app instead of being stuck.Replace secrets with better credentials
Client secrets are the weakest option. Microsoft recommends certificates or managed identities instead. If the workload runs in Azure and does not need to sign in users, a managed identity removes the stored credential entirely. For workloads outside Azure, such as GitHub Actions pipelines, workload identity federation lets the app authenticate without any secret. Where secrets must remain, keep lifetimes short and store them in Azure Key Vault, never in scripts.
Apply least privilege to permissions
Remove permissions an app no longer uses. Prefer delegated access over app-only access where the scenario allows it. For Exchange Online, application access policies or RBAC for Applications can limit an app with mail permissions to a specific set of mailboxes rather than the whole organization.
Use separate registrations per purpose
Do not reuse one app registration for several integrations. Separate registrations keep permissions and credentials isolated, so a compromise of one does not expose everything.
Monitoring and Conditional Access for workload identities
Auditing once is good. Watching continuously is better. Two capabilities matter here.
Audit log alerts. Adding a credential to an existing application outside your normal change process is a classic persistence technique. The Microsoft Entra audit logs record these events under the ApplicationManagement category (“Update application, Certificates and secrets management”). Send those logs to Microsoft Sentinel or a Log Analytics workspace and alert on them.
Conditional Access for workload identities. With Microsoft Entra Workload ID Premium licensing, you can create Conditional Access policies that target single-tenant service principals registered in your tenant. Policies can block a service principal from outside known IP ranges or when Microsoft Entra ID Protection rates it as high risk. Note the limits: Microsoft and third-party multitenant SaaS apps are not covered, managed identities are not covered, and the service principal must be assigned directly to the policy, not through a group.
Building app hygiene into your routine
The real fix is process, not a one-time cleanup. Three habits keep this under control:
Microsoft documents the full set of practices in its security best practices for application properties, which is worth bookmarking for your team. If you want an outside view of where your tenant stands, our Microsoft 365 security assessment includes an app registration and consent review, and our tenant checker gives a quick starting point.
Frequently asked questions
Do I need to license every app registration for Workload ID Premium?
No. Microsoft does not require you to assign Workload ID licenses to individual service principals. Licensing is sized to the workload identities that use premium features, such as Conditional Access and risk detection. Check the current Workload ID FAQ on Microsoft Learn before you buy.
Is it safe to delete an app registration I don’t recognize?
Not immediately. First check the service principal sign-in logs for recent activity and ask around. A safer path is to disable the service principal (or remove its credentials) and wait a few weeks. If nothing breaks, delete it. Deleted app registrations can be restored for 30 days.
What is the difference between an app registration and an enterprise application?
The app registration is the global definition of the app, usually in the tenant that built it. The enterprise application is the service principal, the local copy in your tenant that holds permissions and assignments. Third-party SaaS apps appear only as enterprise applications in your tenant, so review both lists.
Not sure what your app registrations can access today? Book a free Microsoft 365 security assessment and we will show you the workload identities that need attention, starting with the riskiest. For ongoing coverage, see our managed security services.