Why should non-admin users be blocked from registering applications in Microsoft Entra ID?

Why app registrations create more than just a convenience setting

Allowing ordinary users to register applications turns a self-service feature into a durable access path. An application object can outlive the user who created it, carry delegated or application permissions, and become a foothold for later abuse. That is why the issue is not only who can create apps, but whether that creation path is controlled, reviewed, and attributable.

In practice, the risk is that an app registration can be used to establish a new identity-like object with its own credentials, permissions, and OAuth trust relationships. If a compromised user can create one freely, the attacker gains a way to persist even after the original account is reset, locked, or monitored.

Blocking non-admin registration also reduces the chance that shadow apps accumulate outside governance. When app creation is unrestricted, defenders often lose track of which apps are legitimate, who approved them, what permissions they requested, and whether they still need access.

How attackers abuse user-created applications

Application registrations are attractive because they can be used to impersonate a trusted integration, request access to data, and solicit consent from other users. A malicious or compromised user can register an app that looks routine, then use it for phishing, token theft, or permission abuse if the environment allows broad consent or weak review.

That abuse is especially dangerous when the app is used to harvest tokens or obtain sensitive Graph permissions. The attacker does not need to keep reusing the original account if the app itself becomes the vehicle for access, which makes detection harder and cleanup slower.

Admin restriction matters because it narrows the set of identities that can introduce new trust relationships into the tenant. When only approved administrators can register applications, the organisation can apply stronger review, naming, ownership, and permission standards before the app exists.

For the operational mechanics behind consent abuse and app-based trust abuse, see Entra ID Applications and Consent Guide, which covers enterprise apps, consent policies, and consent phishing response.

What good control looks like in Entra ID

The right control is not simply “disable everything”, it is to separate app creation from broad user self-service and make exception handling explicit. Approved admins should own registration rights, while application ownership, permission grants, and tenant-wide consent should be reviewed as part of normal governance rather than left to convenience.

That usually means checking three things: who can create registrations, who can grant consent, and who can assign or approve high-impact permissions. If those three are not aligned, a tenant can still end up with risky app objects even if the visible registration setting looks restricted.

It also helps to treat application registrations as part of the broader identity and privilege model. For a practitioner view of how app registrations, service principals, and least privilege fit together, Azure RBAC and Service Principals Guide is a useful companion, especially where app ownership and role assignment overlap.

Where app permissions or service principals already exist, review whether they still reflect a business need. Dormant apps, overbroad Graph scopes, and forgotten owners are common indicators that the tenant has accumulated access that no one is actively governing.

Risk and Threat Considerations

Unrestricted app registration creates a persistence mechanism that can survive ordinary account remediation. If an attacker compromises a standard user, they may be able to create a long-lived application identity, attach credentials, and use it to request access or exfiltrate data without repeatedly touching the original account.

Failure mechanism: the environment allows a low-privilege account to introduce a new trust object, then later treats that object as a legitimate integration even when it was created under compromise or without proper review.

Impact: the tenant can inherit hidden persistence, unauthorized token use, consent abuse, and harder incident response because the malicious app may remain active after the user account is contained.

Practitioner Guidance

What to verify: confirm whether user app registration is disabled, limited by role, or compensated by strong app consent controls and alerting. If any one of those controls is weak, treat app creation as a real attack path rather than a cosmetic setting.

What good looks like: application creation is limited to approved admins, every new app has a clear owner and business justification, and new credentials or high-risk permissions are visible quickly enough for review.

Common mistake: teams often focus on user consent prompts but forget that the app object itself is the durable asset. If the app can be created by anyone, consent controls alone will not close the persistence problem.

Practitioner takeaway: block non-admin app registration because you are controlling an identity and trust creation pathway, not just a portal setting; the real decision is whether users are allowed to introduce persistent access objects into the tenant.

Related resources from NHI Mgmt Group

• How do you stop non-admin users creating groups in Microsoft Entra ID and Microsoft 365?
• How should security teams extend Microsoft Entra ID to legacy on-premises applications without rewriting every app?
• What breaks when teams try to modernize legacy applications too quickly for Microsoft Entra ID?
• Why does using Microsoft Entra ID as a SAML identity provider improve authentication governance for SaaS applications?