Edit

Share via

Phase 1: Implement the framework to manage at scale

  • Article

This section of the Microsoft Entra Permissions Management operations reference guide describes the checks and actions you should consider taking to effectively delegate permissions and manage at scale.

Define a delegated administration model

Recommended owner: Information Security Architecture

Define Microsoft Entra Permissions Management administrators

To begin operationalizing Microsoft Entra Permissions Management, establish two to five Permissions Management Administrators who delegate permissions in the product, configure key settings, and create and manage your organization’s configuration.

Important

Microsoft Entra Permissions Management relies on users with valid email addresses. We recommend that your Permissions Management Administrators have mailbox enabled accounts.

Assign designated administrators the Permissions Management Administrator role in Microsoft Entra ID to perform needed tasks. We recommend you use Privileged Identity Management (PIM) to provide your admins with just-in-time (JIT) access to the role, rather than permanently assigning it.

Define and maintain folder structure

In Permissions Management, a folder is a group of authorization systems. We recommend you create folders based on your organizational delegation strategy. For example, if your organization delegates based on teams, create folders for:

  • Production Finance
  • Production Infrastructure
  • Pre-Production Research and Development

An effective folder structure makes it easier to delegate permissions at scale, and provides your authorization system owners with a positive product experience.

To help streamline your environment, see create folders to organize your authorization systems.

Create Microsoft Entra security groups to delegate permissions

Microsoft Entra Permissions Management has a group-based access system that uses Microsoft Entra security groups to grant permissions to different authorization systems. To delegate permissions, your IAM team creates Microsoft Entra security groups that map to authorization system owners, and Permissions Management responsibilities you define. Ensure users with shared ownership and responsibilities in the product are in the same security group.

We recommend you use PIM for Groups. This provides JIT access to Permissions Management to users and aligns with Zero Trust JIT and just-enough-access principles.

To create Microsoft Entra security groups, see manage groups and group membership.

Assign permissions in Microsoft Entra Permissions Management

After Microsoft Entra security groups are created, a Permissions Management Administrator grants security groups needed permissions.

At a minimum, ensure security groups are granted Viewer permissions for the authorization systems they are responsible for. Use Controller permissions for security groups with members that perform remediation actions. Learn more about Microsoft Entra Permissions Management roles and permission levels.

For more on managing users and groups in Permissions Management:

Determine authorization system lifecycle management

Recommended owners: Information Security Architecture and Cloud Infrastructure

As new authorization systems are created, and current authorization systems evolve, create and maintain a well-defined process for changes in Microsoft Entra Permissions Management. The following table outlines tasks and recommended owners.

Task Recommended owner
Define the discovery process for new authorization systems created in your environment Information Security Architecture
Define triage and onboarding processes for new authorization systems to Permissions Management Information Security Architecture
Define administration processes for new authorization systems: delegate permissions and update folder structure Information Security Architecture
Develop a cross-charge structure. Determine a cost-management process. Owner varies by organization

Define a Permissions Creep Index strategy

Recommended owner: Information Security Architecture

We recommend you define goals and use cases for how Permissions Creep Index (PCI) drives Information Security Architecture activity and reporting. This team can define, and help others meet, target PCI thresholds for your organization.

Establish target PCI thresholds

PCI thresholds guide operational behavior and serve as policies to determine when action is required in your environment. Establish PCI thresholds for:

  • Authorization systems
  • Human identity users
    • Enterprise Directory (ED)
    • SAML
    • Local
    • Guest
  • Non-human identities

Note

Because non-human identity activity varies less than a human identity, apply stricter right-sizing to non-human identities: set a lower PCI threshold.

PCI thresholds vary based on the goals and use cases of your organization. We recommend you align with the built-in Permissions Management risk thresholds. See the following PCI ranges, by risk:

  • Low: 0 to 33
  • Medium: 34 to 67
  • High: 68 to 100

Using the previous list, review the following PCI threshold policy examples:

Category PCI threshold Policy
Authorization systems 67: Classify the authorization system as high risk If an authorization system has a PCI score higher than 67, review and right-size high PCI identities in the authorization system
Human identities: ED, SAML, and local 67: Classify the human identity as high risk If a human identity has a PCI score higher than 67, right-size the identity’s permissions
Human identity: Guest user 33: Classify the guest user as high or medium risk If a guest user has a PCI score higher than 33, right-size the identity’s permissions
Non-human identities 33: Classify the non-human identity as high or medium risk If a non-human identity has a PCI score higher than 33, right-size the identity’s permissions

Next steps