Restricting Who Can Register Applications and Consent to Them

A user finds a useful cloud tool, selects Sign in with Microsoft, accepts the permissions request and carries on working.

The application may now have access to their Microsoft 365 profile, files, calendar or mailbox. In some cases, it may retain access even when the user is no longer actively using it.

The app might be legitimate. It might also be poorly secured, excessively privileged or designed specifically to steal Microsoft 365 data.

Microsoft Entra ID gives organisations separate controls over two related actions:

• Who can register applications in the tenant
• Which permissions users can grant to applications

Restricting both can reduce shadow IT, malicious OAuth consent and uncontrolled application access. The challenge is doing it without blocking every useful integration or forcing employees to work around IT.

Application Registration and Application Consent Are Different

These settings are often confused, but they control different activities.

Application registration

An application registration creates an identity for software in Microsoft Entra ID.

Developers may register an application when building:

• An internal web application
• An automation script
• A Microsoft Graph integration
• A mobile application
• A background service
• A custom Microsoft Teams or Power Platform solution

The registration defines information such as redirect addresses, supported accounts, credentials and requested API permissions.

By default, ordinary users may be able to create application registrations unless the tenant setting is restricted. Microsoft lets administrators disable general user application registration and then return that ability to selected people through suitable roles. 

Application consent

Consent is the authorisation that allows an application to access protected data or perform actions.

A user may encounter a consent screen when signing in to a third-party service using their Microsoft 365 account. The application presents the permissions it wants, and the user or an administrator decides whether to approve them. 

Disabling app registration does not automatically prevent users from consenting to existing third-party applications.

Likewise, restricting user consent does not necessarily prevent authorised developers from registering internal applications.

Both settings need deliberate configuration.

Why Unrestricted Application Registration Is a Risk

Allowing every employee to create app registrations can result in:

• Abandoned test applications
• Applications with no business owner
• Long-lived client secrets
• Poorly secured redirect addresses
• Unnecessary Microsoft Graph permissions
• Applications remaining after their creator leaves
• Confusing enterprise-application inventories

An app registration does not automatically receive access to company data merely because it exists. However, it creates another identity and configuration object that must be secured, owned and reviewed.

This is particularly important when employees experiment with Microsoft Graph, PowerShell scripts, AI tools or automation platforms without understanding credential management.

A forgotten application secret can become the cloud equivalent of a shared password that nobody remembers creating.

Why Unrestricted Consent Is More Immediately Dangerous

Consent can grant an application access to real Microsoft 365 information.

Depending on the permissions requested, an application might be able to:

• Read a user’s profile
• Read or modify files
• Access calendars
• Read email
• Send email
• Maintain access while the user is offline
• Read directory information
• Manage groups or other resources

Some permissions can be approved by users if tenant policy allows it. More sensitive permissions require administrator consent.

A malicious application may use a convincing sign-in page and permission description to persuade users to grant access. This is commonly known as an illicit consent or OAuth consent attack.

Changing the user’s password may not remove an application’s granted permissions. The consent itself must be identified and revoked.

Step 1: Restrict General Application Registration

In the Microsoft Entra admin centre, review the tenant setting controlling whether ordinary users can register applications.

The setting is found within the user settings for Microsoft Entra ID. Setting Users can register applications to No prevents ordinary users from creating new registrations. 

For many small and medium-sized businesses, No is the safer default.

Most employees do not need to create software identities in the tenant. Those who do are usually members of a known development, automation or IT group.

Before changing the setting:

1. Identify employees currently developing or maintaining integrations.
2. Review existing application owners.
3. Document active internal applications.
4. Create an approval route for new registrations.
5. Assign registration permissions only to selected people.

The setting should reduce uncontrolled creation—not prevent legitimate development.

Step 2: Delegate Registration Rights to Approved People

Once general application registration is disabled, grant the capability back only to employees who genuinely need it.

Microsoft Entra includes roles such as:

• Application Developer
• Application Administrator
• Cloud Application Administrator

These roles are not interchangeable.

Application Developer

This is generally the more suitable starting point for people who need to create application registrations for development work without receiving broad tenant-wide application administration.

Application Administrator

This is a privileged role that can create and manage application registrations and enterprise applications and can grant consent for many application permissions.

Cloud Application Administrator

This role has similar cloud-application management capabilities, although there are differences involving areas such as Application Proxy.

Microsoft also supports custom roles for more specific application-registration and management needs. 

Apply least privilege. A developer who needs to register an app does not automatically need permission to manage every enterprise application in the tenant.

Where Microsoft Entra Privileged Identity Management is available, consider making privileged application-management roles eligible rather than permanently active.

Step 3: Review User Consent Settings

Application consent settings are located under:

Microsoft Entra ID → Enterprise applications → Consent and permissions → User consent settings

Microsoft provides options ranging from allowing broad user consent to preventing users from consenting and requiring administrative review. 

A practical approach for many organisations is to allow user consent only when:

• The application comes from a verified publisher
• The permissions are classified as low impact
• The request meets an approved app-consent policy

Requests outside those conditions should require administrator approval.

This provides a better balance than either extreme:

• Allowing users to approve almost everything
• Blocking every app integration regardless of risk

Verified publisher status is useful, but it is not an absolute guarantee that an application is appropriate for your organisation. You must still assess the requested permissions, data use and business purpose.

Step 4: Configure an Admin Consent Workflow

When users cannot grant the requested permissions themselves, they need a safe way to ask for approval.

Without a workflow, they may receive a generic Need admin approval message and then contact whichever administrator they know—or abandon the process and use a personal account instead.

Microsoft’s admin consent workflow creates a review queue for application requests. Users can submit a business justification, and designated reviewers can approve, deny or block the request. 

The workflow can be configured under:

Enterprise applications → Consent and permissions → Admin consent settings

Choose reviewers who understand both technology and business risk. Depending on the organisation, this might include:

• An IT administrator
• A security lead
• A data-protection representative
• An application owner
• A managed service provider

Avoid routing all requests to one person. Delayed approvals encourage employees to find workarounds.

What Reviewers Should Check

Admin consent should not be a rubber-stamp process.

For each request, confirm the following.

Is there a genuine business purpose?

Ask what task the user is trying to complete and whether an approved service already exists.

Is the publisher trustworthy?

Review:

• Publisher verification
• Supplier identity
• Security reputation
• Privacy terms
• Data-processing terms
• Support arrangements

What permissions are requested?

Permissions should be proportionate to the application’s purpose.

A meeting-scheduling tool should not need unrestricted access to every file the user can open.

Are the permissions delegated or application-based?

Delegated permissions normally operate in the context of a signed-in user.

Application permissions can allow background access without an interactive user and may affect a much broader set of data. Those requests deserve particularly careful scrutiny.

Is consent being granted to one user or the whole tenant?

Tenant-wide admin consent can authorise an application for many or all users. It should be granted only when that scope is intentional and justified. Microsoft provides a dedicated process for granting tenant-wide administrator consent. 

Who will own the application?

Every approved application should have:

• A named business owner
• A technical owner
• An approved user population
• A review date
• A removal process

Step 5: Review Existing Enterprise Applications

Restricting future registrations and consent does not clean up applications that already exist.

In the Microsoft Entra admin centre, open:

Enterprise applications → All applications

Review:

• Recently added applications
• Applications with no owner
• Applications with broad Microsoft Graph permissions
• Apps that have not been used recently
• Apps created by former employees
• Unknown publishers
• Apps with tenant-wide consent
• Applications with credentials nearing or exceeding their intended lifetime

Microsoft provides tools and guidance for reviewing and revoking permissions granted to enterprise applications. 

Do not delete an unfamiliar application immediately. First determine whether it supports a production system, single sign-on integration or automated workflow.

Classify each application as:

• Approved
• Restricted
• Under review
• Scheduled for removal
• Blocked as malicious

Step 6: Review Consent and Application Audit Events

Microsoft Entra audit logs can help identify changes involving:

• New application registrations
• New service principals
• Permission grants
• Admin consent
• Application ownership
• Credential additions
• Application deletions

These events are valuable when investigating suspicious OAuth activity or determining who approved an application.

Microsoft’s admin consent workflow also produces audit records that can help show request and review activity. 

Set alerts or recurring reviews for high-risk events such as:

• Tenant-wide admin consent
• New applications requesting mail or file access
• Credentials added to sensitive applications
• Consent granted shortly after a suspicious sign-in
• App registrations created by unexpected users

Avoid Blocking Useful Work

The objective is controlled adoption, not a complete ban on third-party applications.

Employees turn to new tools because they need to:

• Convert documents
• Automate repetitive work
• Schedule meetings
• Analyse information
• Connect customer systems
• Build internal applications

Provide an approval process that is quick enough to use.

A simple low-risk request may need only:

• Business justification
• Publisher verification
• Permission review
• Named owner

A high-risk application may require:

• Security assessment
• Data-protection review
• Contract review
• Limited pilot
• Senior approval
• Formal offboarding plan

The approval effort should match the risk.

Common Mistakes

Disabling app registration but ignoring consent

Users may still authorise existing third-party applications.

Disabling consent without an approval workflow

Employees receive dead-end errors and look for unapproved alternatives.

Giving developers Application Administrator

They receive far more authority than required simply to register their own apps.

Approving based only on publisher verification

A legitimate publisher can still request excessive access.

Granting tenant-wide consent casually

One user’s request becomes access available across the organisation.

Never reviewing existing applications

Old integrations and permissions remain indefinitely.

Removing applications without checking dependencies

Automations, sign-on services and business workflows may suddenly fail.

Application Governance Checklist

• Set Users can register applications to No unless broad registration is genuinely required.
• Assign Application Developer or another suitable role only to approved people.
• Review privileged application-management roles.
• Restrict user consent through an appropriate app-consent policy.
• Prefer verified publishers and low-impact permissions for user consent.
• Enable the admin consent workflow.
• Assign at least two trained reviewers.
• Document business and technical ownership.
• Review existing enterprise applications.
• Remove obsolete permissions and applications.
• Monitor consent and application audit events.
• Repeat the review regularly.

Final Thoughts

Microsoft 365 application access should not depend on whichever user clicks Accept first.

Restricting application registration reduces uncontrolled software identities. Restricting consent limits which external services can access Microsoft 365 data. An admin consent workflow gives employees a legitimate path to request the tools they need.

The strongest approach combines all three:

Limit who can create applications, control which permissions users may grant and provide a fast, accountable approval process.

Then review the applications that already exist. Confirm their owners, permissions, usage and business purpose.

A smaller, well-governed application estate is easier to secure, audit and support—and much harder for an attacker to hide inside.

Need Help Securing Microsoft 365 Applications and Consent?

Hamilton Group can help your business control app registrations, OAuth permissions and third-party access in Microsoft Entra ID.

Our experts can help you:

• Restrict user application registration
• Assign least-privileged application roles
• Configure user-consent policies
• Enable the admin consent workflow
• Review enterprise applications
• Audit Microsoft Graph permissions
• Investigate suspicious OAuth grants
• Remove obsolete applications safely
• Build an application-approval process
• Establish recurring application access reviews

Visit hgmssp.com, call Hamilton Group on 0330 043 0069, or book a meeting with one of our experts to control which applications can access your Microsoft 365 environment.