Rethinking application access in Microsoft Entra ID

If you have worked with application access in Microsoft Entra ID for some time, you have likely seen environments where groups play a central role in granting access to applications.

A common access model looks like this:

User → Group → Application

How application access is typically managed

In most Microsoft Entra ID environments, access to applications is managed through group assignments.
Administrators assign one or more groups to an enterprise application, and users receive access when they are added to those groups.

The access model looks like this:

User
↓
Group
↓
Enterprise Application

This approach offers several advantages.

Applications only need to be configured once with the relevant groups. Administrators can then manage access through group membership without modifying the application configuration.
Groups also work well with automation. Dynamic groups, HR-driven provisioning, and role-based access models all integrate naturally with group membership.
For many organizations, this became the standard way of managing application access.

When groups start to drift away from applications

Over time, however, groups often begin to serve multiple purposes.

A group originally created to grant access to one application may later be reused for other systems or resources. This happens naturally during integrations or when administrators want to avoid creating additional groups.

For example, a group like:

Finance_Users

might eventually grant access to:

• a finance SaaS application
• a reporting platform
• a SharePoint site
• a Power BI workspace

At first glance, this reuse seems efficient. Fewer groups need to be created, and administrators can manage multiple resources through a single membership list.
But this approach also introduces a new challenge.
When reviewing access, it becomes difficult to determine which application the access actually relates to.
Removing a user from the group may unintentionally remove access to several systems at once.
Over time, administrators may realize they are no longer managing access to applications directly. Instead, they are managing group memberships whose purpose has expanded far beyond their original intent.

The hidden complexity of nested groups

Another challenge that often appears in Entra ID environments is the use of nested groups.
Instead of assigning users directly to a group that grants application access, administrators may add one group as a member of another.

The access chain can then look like this:

User → Group A → Group B → Application

Nested groups are often introduced to simplify administration or reuse existing group structures. However, they can also make it harder to understand how access is actually granted.
When investigating why a user has access to an application, administrators may need to trace membership across multiple groups. This additional layer of indirection can make troubleshooting and access reviews more difficult.

The impact on access reviews

This becomes particularly visible during access reviews.
Imagine reviewing access to a specific SaaS application. Ideally, the reviewer should be able to answer a simple question:

“Should this user still have access to this application?”

However, when access is granted through reused groups, the question becomes more complicated.
Removing the user from the group might also remove their access to other systems that depend on the same group.
As a result, access reviews become harder to perform confidently. Reviewers may hesitate to remove users because the impact of the change is unclear.
This is one of the reasons organizations begin to look for more direct ways to manage application access.

The challenge of auditing access decisions

Group-based access management can also make it difficult to understand how access was originally granted.
When a user appears to have access through a group, administrators often need to answer several questions:

Who added the user to the group?
When was the access granted?
Why was the access granted?

While audit logs may record the technical event of a group membership change, they rarely capture the business context behind the decision.
Without governance workflows, the reason for access is often lost over time. This can make it harder for administrators and auditors to determine whether access is still appropriate.
Governance features such as access requests, approvals, and access reviews help capture this context and make access decisions easier to understand later.

Why this becomes visible during governance projects

Governance projects expose something that’s easy to miss in day‑to‑day operations: when groups have been reused for multiple systems, it’s no longer clear what access they actually represent. Access reviews, request workflows, and entitlement management all rely on understanding why a user has access to an application. Reused or multi‑purpose groups break that clarity.

Instead of reviewing access to an application, reviewers end up reviewing membership in a group whose purpose has expanded over time. That uncertainty makes reviewers hesitant to remove users and makes administrators work harder to explain how access was granted in the first place.

This is often the moment organizations realize they need a more direct model for application access, one where governance workflows manage who gets into an application, and groups focus on what users can do once they’re inside.

SCIM provisioning adds another layer

Many modern SaaS applications integrate with Entra ID using SCIM provisioning. SCIM allows user accounts to be created and removed automatically based on identity platform events.

In a traditional group-based setup, provisioning often follows this path:

User → Group → Application → SCIM provisioning

When a user becomes a member of the group, the provisioning service creates the user in the target application.
This works well, but it can also add complexity when troubleshooting.

A common scenario is when an administrator expects a user to appear in an application, but the account is not created.

To diagnose the issue, several things must be checked:

• Is the user a member of the correct group?
• Is the group assigned to the application?
• Is the group included in the provisioning scope?
• Are there provisioning errors in the SCIM logs?

Each layer introduces another place where something may go wrong.
Reducing the number of layers involved in access decisions can make operations significantly easier.

Governance introduces a new option

With the introduction of Microsoft Entra ID Governance, organizations gained new tools for managing access more directly.
One of the most important features is Access Packages.
Access packages allow organizations to define how access should be requested, approved, and reviewed.

For example, an access package can require:

• a manager approval
• automatic expiration after a defined period
• periodic access reviews

Instead of administrators manually assigning users to groups, users can request access through a controlled workflow.
Access packages can grant access in several ways, including:

• group membership
• SharePoint or Teams resources
• direct application assignments

This last option introduces an interesting shift in how application access can be managed.

Direct application assignments under governance

With the introduction of Microsoft Entra ID Governance, identity platforms gained stronger governance capabilities. When governance processes control how access is granted, assigning users directly to an application becomes more manageable.

The provisioning flow becomes simpler:

User → Application → SCIM provisioning

Instead of tracing access through multiple groups, administrators can see directly whether a user is assigned to the application.
This also simplifies troubleshooting and makes it easier to understand why a user exists in a system.
In addition, it reduces the need to create groups that exist only to grant access to a single application.

Groups still play an important role

This does not mean groups disappear from the architecture.
Many applications rely on groups to define roles or permissions inside the application itself.

For example, groups may represent roles such as:

• Administrator
• Project Manager
• Finance Approver
• Read-only user

In these cases, groups control what a user can do inside the system, rather than whether the user can access the system at all.
This creates a useful separation.

A practical access model

In many modern environments, application access is managed through two layers.

Application access

Governance workflows determine whether the user should be provisioned into the application.

Access Package → Application assignment

Application authorization

Groups define the permissions the user receives inside the application.

Group → Role inside application

This model allows organizations to manage access more clearly while still supporting complex role structures inside applications.

Final thoughts

Group-based access management has been a cornerstone of identity architecture for many years. It introduced structure, enabled automation, and made large environments easier to manage.
However, as environments grow and governance requirements increase, relying exclusively on groups to control application access can introduce new challenges.
Modern governance capabilities in Entra ID allow organizations to manage application access decisions more directly, while still using groups where they make the most sense.
For many environments, the goal is not to eliminate groups entirely, but to ensure that they are used for the right purpose.
Groups can represent roles and permissions inside applications, while governance workflows determine who should have access to the application in the first place.