A member of staff finds a useful online application.

They click:

Sign in with Microsoft

The application then asks for permission to:

• view their profile
• read files
• access email
• maintain access to data

The employee clicks:

Accept

It feels like an ordinary sign-in.

From a security perspective, however, something much more important may just have happened:

a third-party application has been authorised to access company data.

This is why controlling applications in Microsoft Entra ID should be part of every organisation's Microsoft 365 security baseline.

But there are two controls that are frequently confused:

Who can register applications?

and:

Who can consent to applications?

They are not the same thing.

What Is an Application Registration?

An application registration creates an application object in Microsoft Entra ID.

Developers use application registrations when building software that needs to authenticate against Microsoft identity services or access APIs such as Microsoft Graph.

For example, an internal application might need to:

• authenticate employees
• read authorised SharePoint data
• access Microsoft Graph
• send mail
• integrate with another Microsoft service

Registering the application establishes its identity and trust relationship with Microsoft's identity platform.

By default, Microsoft says ordinary users in a Microsoft Entra directory can register applications and manage the applications they create.

For many SMEs, that is more freedom than employees actually require.

What Is Application Consent?

Consent is different.

Consent is the process through which permission is granted for an application to access a protected resource.

For example, an application might request permission to:

read your profile

or:

access files you can access.

These are normally delegated permissions, where the application operates on behalf of the signed-in user.

Some permissions can be approved by the user.

Others are sufficiently powerful that Microsoft requires an administrator to approve them.

Microsoft Entra also allows administrators to control which applications and permission categories users are permitted to consent to.

Registration and Consent Are Separate Security Decisions

This distinction is crucial.

Setting:

Users can register applications = No

does not mean:

users cannot consent to third-party applications.

Likewise, disabling user consent does not necessarily prevent developers from creating application registrations if registration remains enabled.

Think of them as two gates:

Gate 1 — Application registration

Who can create applications in our tenant?

Gate 2 — Application consent

Which applications can employees authorise to access company information?

A sensible Microsoft 365 security review should examine both.

Why Does This Matter?

OAuth consent has become an important attack and data-exposure route because an attacker does not necessarily need to steal a user's password repeatedly if the victim can instead be persuaded to authorise a malicious application.

Imagine an employee sees:

Document Viewer Pro would like permission to:

Read your profile
Read your files
Maintain access to data you have given it access to

The employee thinks:

“It needs that to open my document.”

and clicks:

Accept.

The application may now possess authorised access through OAuth.

Changing the employee's password does not necessarily address an inappropriate application consent grant.

The application itself and the permissions granted to it need investigating.

Should You Disable Application Registration?

For many ordinary businesses:

yes, I would strongly consider it.

Most employees do not need to develop Microsoft Entra applications.

Microsoft provides a specific tenant setting for this.

In the Microsoft Entra admin centre, go to:

Entra ID > Users > User settings

Find:

Users can register applications

and set it to:

No

Microsoft confirms that doing this prevents ordinary users from creating application registrations.

But don't stop there.

What About Developers Who Genuinely Need It?

Do not leave application registration enabled for thousands of employees because three developers need it.

Microsoft provides the Application Developer role.

When:

Users can register applications = No

selected users can be assigned this role so they retain the ability to create application registrations.

That gives you a much better model:

Default user

→ cannot register applications.

Approved developer

→ can register applications.

Application administrator

→ broader application-management capability.

This follows the principle of least privilege.

Application Developer Is Not the Same as Application Administrator

Be careful with the roles you assign.

If somebody simply needs to develop and register an application, they should not automatically receive broad administrative rights across every application in the tenant.

Microsoft supports several approaches, including:

• Application Developer
• application ownership
• Application Administrator
• Cloud Application Administrator
• custom roles

Microsoft specifically recommends using application ownership or appropriately scoped roles where possible rather than granting unnecessarily broad administrative access.

Now Deal With User Consent

Next go to:

Entra ID > Enterprise apps > Consent and permissions > User consent settings

This controls what ordinary employees can authorise.

Microsoft currently provides several broad approaches.

Do not allow user consent

Users cannot grant new application permissions themselves.

An administrator must handle the approval.

This gives strong central control.

However, it can create administrative overhead.

Allow consent under controlled conditions

Microsoft supports allowing users to consent only when conditions are satisfied—for example, applications from verified publishers and permissions classified as low impact.

For many organisations, this is the better balance.

Broad user consent

Users can consent to applications for permissions that do not require administrator consent.

I would generally avoid an unnecessarily permissive configuration for a business tenant.

Microsoft's current recommendation is to restrict user consent so users can consent only to applications from verified publishers, and only for selected permissions.

What Is a Verified Publisher?

Microsoft's verified-publisher programme provides additional assurance about the identity behind an application.

That does not mean:

verified = completely safe.

It means the publisher has gone through Microsoft's publisher-verification process.

That is a useful signal when deciding whether employees should be allowed to consent without administrator intervention.

But administrators should still consider:

• what the application does
• which permissions it requests
• whether the business needs it
• what information it will access

Publisher verification is one layer of trust.

It is not a substitute for reviewing permissions.

Permission Risk Matters Too

Compare these two requests.

Application A

Wants:

basic profile information

Application B

Wants extensive access to:

• mail
• files
• contacts
• organisational information

Those should not receive the same level of scrutiny.

Microsoft Entra consent policies allow organisations to restrict consent according to criteria including application and permission characteristics.

The sensible objective is:

low-risk, trusted requests can follow an efficient route

while:

higher-risk access requires administrative review.

Enable the Admin Consent Workflow

If employees cannot approve an application themselves, you still need a sensible way for them to request legitimate applications.

Otherwise you create:

“Computer says no.”

and employees find another workaround.

Microsoft Entra provides an admin consent workflow.

When enabled, a user who encounters an application requiring approval can submit a request.

Designated reviewers can then investigate it.

Microsoft's current workflow provides an Approval required experience and can notify designated reviewers when requests are submitted.

That is much better than telling employees:

“Email IT a screenshot if something doesn't work.”

What Should the Reviewer Check?

Do not treat application approval as:

Recognise company name → click Approve.

Check:

Publisher

Who created the application?

Is the publisher verified?

Business purpose

Why does the employee need it?

Permissions

Exactly what information does it want?

Scope

Does it need access only for one user or across the organisation?

Existing alternatives

Do you already pay for another approved product that performs the same job?

Data sensitivity

Could the application access:

• customer information
• financial information
• confidential documents
• employee data

Persistence

Does it request ongoing access?

The correct question is not:

“Is this app popular?”

It is:

“Does the business benefit justify the access being requested?”

Be Very Careful With Tenant-Wide Admin Consent

Administrators can grant consent on behalf of the organisation.

That is powerful.

If tenant-wide admin consent is granted, permissions can apply much more broadly than an individual employee's approval.

Microsoft therefore recommends evaluating tenant-wide consent requests carefully and reviewing the publisher, permissions and business justification before approval.

Do not turn:

“One employee needs this tool.”

into:

“This application now has authorised access across our tenant.”

without understanding the scope.

Restrict Who Can Use an Approved Application Too

Consent and application access are also separate.

Even after an administrator approves an application, you may not want every employee using it.

Microsoft Entra can require:

user assignment

for supported enterprise applications.

You can then assign access to:

• specific users
• selected groups

rather than effectively making the application available to everybody.

Microsoft confirms that requiring user assignment can restrict application access even when tenant-wide admin consent has already been granted.

This gives you another useful control:

Application approved

does not have to mean:

Application available to everyone.

Review Existing Enterprise Applications

Changing the settings today does not magically remove applications employees previously authorised.

You also need to inspect what is already present.

Go to:

Entra ID > Enterprise applications

Review:

• unfamiliar applications
• owners
• permissions
• consent
• sign-in activity
• who uses them
• whether they are still required

This is particularly important in organisations that have used Microsoft 365 for years without formal application governance.

You may discover:

• abandoned SaaS products
• trial applications
• old integrations
• applications belonging to former projects
• tools nobody remembers approving

That is effectively identity-layer shadow IT.

Don't Delete Unknown Applications Immediately

An application you do not recognise is not automatically malicious.

It may support:

• payroll
• CRM
• backup
• document signing
• HR
• security
• another business-critical system

Before removing access, establish:

who uses it

what it does

which permissions it has

what will break if it disappears.

Then revoke or remove it when you have evidence that it is:

• malicious
• excessive
• abandoned
• no longer required

Good security reduces risk without creating unnecessary outages.

Audit Consent and Application Changes

Application governance should not be a once-a-year exercise.

Microsoft Entra records application-related activity that administrators can investigate through its audit capabilities, and Microsoft specifically notes that application additions and consent activity can be audited.

Security teams should consider monitoring for:

• new application registrations
• new service principals
• consent grants
• changes to application credentials
• changes to owners
• administrative consent
• unusual application activity

A new application receiving powerful permissions deserves attention.

Application Secrets and Certificates Matter Too

Once an application registration exists, somebody may add:

• client secrets
• certificates
• federated credentials

These effectively become credentials for the application.

They need proper management.

Avoid:

• unnecessarily long-lived secrets
• credentials stored in source code
• credentials shared through email
• forgotten application secrets
• applications without accountable owners

Where possible, use stronger credential mechanisms and establish clear ownership and expiry processes.

Application governance is not finished when the app is registered.

A Sensible SME Baseline

For many Microsoft 365 SMEs, I would consider a baseline along these lines:

Application registration

Ordinary users: disabled

Approved developers: Application Developer role where genuinely required

User consent

Restricted to appropriately trusted applications and selected low-impact permissions, or completely disabled where the organisation's risk profile justifies it.

Admin consent workflow

Enabled so legitimate requests have a controlled route.

Administrative consent

Restricted to appropriate administrators.

Enterprise applications

Reviewed periodically.

Application access

Require user/group assignment where appropriate.

Monitoring

Review application and consent activity.

That is substantially safer than:

“Employees can connect whatever they like, and we'll investigate if something goes wrong.”

Don't Forget Existing Consent

This is worth repeating.

Changing:

User consent = restricted

controls future consent behaviour.

It does not necessarily undo access already granted to existing applications.

Microsoft provides mechanisms for reviewing and revoking previously granted permissions.

Therefore, a proper project should include:

configure future controls + review existing applications + revoke unnecessary permissions.

How This Helps With Shadow IT

Shadow IT is not limited to somebody installing Dropbox on a laptop.

Modern shadow IT can happen entirely through the browser:

1. Employee discovers SaaS product.
2. Clicks Sign in with Microsoft.
3. Grants OAuth permissions.
4. Company information begins flowing into another platform.

Nothing was installed.

No administrator deployed software.

Traditional application-control tools may never see the event.

That is why Microsoft Entra application consent has become such an important part of SaaS governance.

The Practical Configuration Checklist

For a typical Microsoft 365 tenant:

1. Open Entra ID > Users > User settings.
2. Review Users can register applications.
3. Consider setting it to No.
4. Give approved developers the Application Developer role where required.
5. Open Enterprise apps > Consent and permissions.
6. Review User consent settings.
7. Prefer restricted consent for trusted/verified applications and selected low-impact permissions, or disable user consent where appropriate.
8. Configure the admin consent workflow.
9. Define who reviews requests.
10. Review existing Enterprise Applications.
11. Investigate existing consent grants.
12. Require user assignment for applications where appropriate.
13. Remove unnecessary applications and permissions carefully.
14. Monitor new registrations and consent activity.
15. Review the configuration periodically.

The core principle is:

Employees should not have more application-authorisation power than their job requires.

How Hamilton Group Can Help

Microsoft 365 security is about much more than passwords and MFA.

Hamilton Group can help businesses review and secure Microsoft Entra ID, including:

• application registrations
• Enterprise Applications
• OAuth consent
• admin consent
• Microsoft Graph permissions
• privileged roles
• Conditional Access
• MFA
• Microsoft Secure Score
• Microsoft 365 security
• shadow IT
• tenant security reviews

We can identify applications that already have access to your Microsoft 365 environment, review the permissions they hold and help implement a controlled approval process for future applications.

Visit hgmssp.com or call 0330 043 0069 to discuss Microsoft 365 and cyber-security support.

SEO Meta Description

SEO Keywords

Drupal-ready blog summary

I would replace the current article with this version. The most important change is avoiding an overly simplistic “disable all user consent” recommendation. Microsoft’s current guidance recommends restricting consent to verified publishers and selected permissions for many organisations, while complete blocking remains available when the organisation's risk profile calls for it. Just as importantly, disabling application registration does not solve the OAuth-consent problem—they need to be governed separately.