Tag: Microsoft Entra ID

Implement and configure Microsoft Entra Private Access (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure storage, databases, and networking (25–30%)
   --> Implement security for Azure network services
      --> Implement and configure Microsoft Entra Private Access


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Microsoft Entra Private Access is a cloud-delivered, identity-centric Zero Trust Network Access solution that allows users to access private applications and network resources without requiring a traditional VPN. It uses the Global Secure Access client on user devices and private network connectors deployed inside the organization’s network.

Instead of granting a user broad network-level access after connecting to a VPN, Microsoft Entra Private Access allows administrators to define which private resources users can access and apply Microsoft Entra ID-based controls such as user and group assignments, Conditional Access, multifactor authentication, and device compliance requirements.

Microsoft Entra Private Access is particularly useful for:

  • Remote access to on-premises applications.
  • Access to private applications hosted in Azure or other cloud environments.
  • Replacing or reducing reliance on traditional remote-access VPNs.
  • Applying different access policies to different applications.
  • Implementing least-privilege access to internal resources.
  • Supporting hybrid and distributed workforces.

1. Understanding the Microsoft Entra Private Access Architecture

Microsoft Entra Private Access includes several major components.

Microsoft Entra ID

Microsoft Entra ID provides the identity and access control layer. It determines:

  • Which users and groups can access private resources.
  • Whether Conditional Access requirements are satisfied.
  • Whether multifactor authentication is required.
  • Whether the device must be compliant or managed.
  • Which private applications are available to the user.

Microsoft Entra Private Access does not simply trust a user because the user is connected to a corporate network. Access is evaluated using identity and policy.

Global Secure Access Client

The Global Secure Access client is installed on supported end-user devices. It identifies traffic destined for configured private resources and forwards that traffic to the Global Secure Access service.

The client is responsible for acquiring the appropriate traffic and establishing the secure connection to the service. At the time of the current implementation guidance, Windows is the primary client platform used in the Private Access configuration tutorials.

Global Secure Access Service

The Global Secure Access service receives traffic from the client and brokers access to the configured private resources. The service applies the applicable traffic-forwarding and access policies before sending traffic toward the private network.

Private Network Connector

A Private Network Connector is a lightweight agent installed on a Windows Server inside the organization’s network. It creates outbound connections to the Microsoft service and provides access to private resources that the connector server can reach.

The connector does not require inbound firewall ports to be opened for users on the internet. The connector initiates outbound communication to the service, which reduces the need to expose internal resources directly to the public internet.

Private Resources

Private resources can include:

  • Internal websites.
  • Remote Desktop Protocol servers.
  • SSH servers.
  • File shares.
  • Internal application servers.
  • Private IP addresses.
  • Fully qualified domain names.
  • Private applications hosted in on-premises or cloud networks.

The connector server must be able to resolve and reach the private resource through the organization’s internal network.


2. Microsoft Entra Private Access Versus a Traditional VPN

A traditional VPN generally provides network-level connectivity. Once connected, a user may receive access to a broad address range or subnet.

Microsoft Entra Private Access is designed to provide more granular, application-aware access.

Traditional VPNMicrosoft Entra Private Access
Often grants broad network accessGrants access to configured resources
Usually depends on VPN credentials or certificatesUses Microsoft Entra identity and policy
Frequently requires inbound VPN infrastructureUses outbound private network connectors
Access is commonly based on network locationAccess is based on identity, device, and policy
Can expose many internal routes after connectionCan restrict access to specific applications
Often requires separate VPN client infrastructureUses the Global Secure Access client

Microsoft Entra Private Access is not automatically a complete replacement for every VPN scenario. It is best suited to private application and resource access where identity-based, least-privilege access is preferred.


3. Quick Access and Per-App Access

Microsoft Entra Private Access provides two primary ways to define private resources:

  1. Quick Access.
  2. Global Secure Access applications, also called per-app access.

Quick Access

Quick Access is used to define a broad collection of private resources that should be routed through Microsoft Entra Private Access.

Administrators can configure:

  • Fully qualified domain names.
  • Individual IP addresses.
  • IP ranges.
  • Private subnets.

Quick Access is useful when an organization is beginning a VPN replacement project or needs to provide access to a broad set of internal resources.

However, Quick Access can provide wider access than is desirable in a mature Zero Trust environment. Microsoft recommends using Quick Access as a transition stage and moving toward more granular per-application access where practical.

Per-App Access

Per-app access uses a dedicated Microsoft Entra enterprise application to represent a specific private application or group of related application segments.

For example, an organization could create separate private applications for:

  • Human resources.
  • Finance.
  • Internal customer support.
  • Development environments.
  • Production administration.
  • Corporate file services.

Each application can have its own:

  • User and group assignments.
  • Connector group.
  • Application segments.
  • Conditional Access policies.
  • Access lifecycle.

Per-app access supports least privilege because a user can be granted access to one private application without automatically receiving access to other resources on the network.

Quick Access and Per-App Access Comparison

FeatureQuick AccessPer-App Access
ScopeBroad group of private resourcesSpecific application or application segment
Primary useVPN transition and broad private accessGranular Zero Trust access
Policy separationMore limitedStronger policy separation
Typical configurationFQDNs, IP addresses, and rangesEnterprise application segments
Least-privilege alignmentModerateStrong
Recommended long-term approachUse selectivelyPrefer where practical

4. Traffic Forwarding Profiles

Traffic forwarding profiles determine which traffic is captured and sent through Global Secure Access.

The Private Access traffic forwarding profile identifies traffic destined for configured private resources. Traffic is forwarded only when it matches the configured private access destinations.

The traffic-forwarding process evaluates traffic against the applicable profiles. Traffic that does not match the configured profiles is not automatically forwarded through Global Secure Access.

For Microsoft Entra Private Access, the administrator must configure both:

  1. The private resources that should be accessed.
  2. The Private Access traffic forwarding profile.

Enabling the Private Access profile alone does not grant access to every private resource. The destinations must also be configured through Quick Access or a Global Secure Access application, and the appropriate users or groups must be assigned.


5. Prerequisites

Before implementing Microsoft Entra Private Access, verify the following requirements.

Licensing

The Private Access profile requires:

  • Microsoft Entra ID P1 or P2.
  • Microsoft Entra Private Access or Microsoft Entra Suite.

The exact licensing requirements should be verified before deployment because licensing and feature availability can change.

Administrative Roles

Depending on the operation, administrators may require roles such as:

  • Global Secure Access Administrator.
  • Application Administrator.
  • Security Administrator.
  • Global Administrator for certain initial registration tasks.

Use the least-privileged administrative role that supports the required operation. Privileged Identity Management can be used to provide temporary elevation for administrative tasks.

End-User Device

The user device must:

  • Run a supported operating system.
  • Have the Global Secure Access client installed.
  • Have internet connectivity.
  • Be appropriately registered or joined to Microsoft Entra ID, depending on the deployment scenario.
  • Be assigned to the relevant traffic profile or application.

Connector Server

The connector server must:

  • Run a supported version of Windows Server.
  • Be able to make outbound connections to the required Microsoft service endpoints.
  • Allow outbound traffic over the required ports, commonly ports 80 and 443.
  • Resolve the private resource’s DNS name.
  • Reach the private resource through the internal network.
  • Have sufficient capacity for expected traffic.
  • Be monitored and maintained.

Private Resource

The target resource must be reachable from the connector server. If the connector cannot resolve or reach the resource, Microsoft Entra Private Access cannot successfully broker the connection.


6. Configure a Private Network Connector

A Private Network Connector is the bridge between the Global Secure Access service and the private network.

Step 1: Prepare the Connector Server

Select a Windows Server located in a network that can reach the private applications.

The server should have:

  • Reliable network connectivity.
  • DNS resolution for internal resources.
  • Outbound connectivity to Microsoft services.
  • Appropriate security hardening.
  • Monitoring and maintenance procedures.

The connector does not need to be placed in a perimeter network solely for security purposes. Because the connector initiates outbound connections, inbound access from the internet is not required.

Step 2: Install the Connector

In the Microsoft Entra admin center:

  1. Open Global Secure Access.
  2. Navigate to the connectors and sensors area.
  3. Download the Private Network Connector.
  4. Install the connector software on the Windows Server.
  5. Register the connector with the tenant.
  6. Verify that the connector appears as active.

The first connector registration may require Global Administrator permissions. Subsequent registrations can generally use more limited administrative roles, depending on the operation.

Step 3: Validate Connector Diagnostics

Use the connector diagnostics tools to verify:

  • Outbound connectivity.
  • Required service endpoint access.
  • DNS resolution.
  • Connector registration.
  • Connectivity to private resources.
  • Connector health.

A connector can appear registered while still being unable to reach the target application. Therefore, registration status alone is not sufficient validation.


7. Use Connector Groups for Segmentation and High Availability

Every connector belongs to a connector group. Connectors in the same group operate together for load balancing and high availability.

A connector group can be associated with specific applications or environments.

Examples include:

  • North America connector group.
  • Europe connector group.
  • Production connector group.
  • Development connector group.
  • Corporate data center connector group.
  • Azure-hosted application connector group.

Use connector groups to:

  • Keep traffic close to the target resources.
  • Separate production and nonproduction applications.
  • Improve application segmentation.
  • Simplify troubleshooting.
  • Reduce latency.
  • Provide redundancy.

Microsoft recommends using at least two connectors in a group for high availability. If one connector becomes unavailable, another connector in the group can continue serving the application.

Example

An organization has two internal applications:

  • A production finance application in the primary data center.
  • A development application in a separate network.

The organization can create:

  • A production connector group containing two connectors that can reach the finance application.
  • A development connector group containing two connectors that can reach the development application.

The production application is then associated only with the production connector group. This reduces the risk of routing production traffic through an inappropriate connector.


8. Configure Quick Access

Quick Access is appropriate when an organization needs to provide access to a broad set of internal resources.

A typical Quick Access implementation includes:

  1. Configure a private network connector.
  2. Create or select a connector group.
  3. Define private FQDNs, IP addresses, and ranges.
  4. Assign users and groups.
  5. Link Conditional Access policies.
  6. Enable the Private Access traffic forwarding profile.
  7. Install and configure the Global Secure Access client.
  8. Test access from an assigned device.

Quick Access should be configured carefully. Broad IP ranges can unintentionally provide access to more resources than intended.

Example

An organization wants remote employees to access:

  • intranet.contoso.com
  • files.contoso.com
  • 10.20.10.0/24

The administrator can define these destinations in Quick Access. However, the administrator should confirm that the subnet does not contain sensitive systems that should require separate authorization.


9. Configure Per-App Access

Per-app access provides a more granular alternative to broad Quick Access configuration.

Step 1: Create a Connector Group

Create a connector group containing connectors that can reach the target application.

Step 2: Create a Global Secure Access Enterprise Application

Create an enterprise application representing the private application.

Step 3: Configure Application Segments

Define the application’s private destinations, such as:

  • FQDNs.
  • IP addresses.
  • Ports.
  • Protocols.
  • Application-specific network segments.

The exact application segment options depend on the supported Private Access configuration.

Step 4: Assign Users and Groups

Assign only the users and groups that require access.

Avoid assigning all users by default unless broad access is explicitly required and approved.

Step 5: Configure Conditional Access

Apply policies that can require:

  • Multifactor authentication.
  • Compliant devices.
  • Approved client applications, where supported.
  • Specific user or group conditions.
  • Sign-in risk controls.
  • Location or network conditions.
  • Authentication strength.

Step 6: Enable Private Access and Test

Enable the Private Access traffic forwarding profile, install the Global Secure Access client, and verify that assigned users can access the application while unauthorized users cannot.

Per-app access allows network requests to be routed to the configured application segment without providing unrestricted access to other resources on the private network.


10. Configure Conditional Access

Conditional Access is a major security control for Microsoft Entra Private Access.

A Conditional Access policy can require users to satisfy conditions before accessing a private application.

Common requirements include:

  • Require multifactor authentication.
  • Require a compliant device.
  • Block access from risky sign-ins.
  • Restrict access to specific user groups.
  • Require an approved authentication strength.
  • Block legacy authentication scenarios.
  • Apply different policies to different private applications.

Example Policy

A company publishes an internal payroll application through Microsoft Entra Private Access.

The company creates a Conditional Access policy that:

  • Targets the payroll enterprise application.
  • Includes the payroll department group.
  • Requires multifactor authentication.
  • Requires a compliant device.
  • Blocks access when the sign-in risk is high.

This approach is more secure than allowing anyone connected to the corporate VPN to access the payroll application.

Important Distinction

Microsoft Entra Private Access provides network access to configured resources, but the application itself may still require its own authentication and authorization.

Private Access does not eliminate the need for:

  • Application-level permissions.
  • Database permissions.
  • File-system permissions.
  • Operating system security.
  • Resource-specific authorization.

Network access and application authorization are separate security layers.


11. Configure the Global Secure Access Client

After the administrator configures the service, the client must be installed on user devices.

The deployment process generally includes:

  1. Install the Global Secure Access client.
  2. Sign in with the user’s Microsoft Entra account.
  3. Confirm that the device is registered or joined as required.
  4. Verify that the user is assigned to the Private Access profile or application.
  5. Confirm that the client is running.
  6. Test access to a configured private resource.

The client forwards traffic only for destinations included in the applicable Private Access configuration. It does not automatically send all network traffic through Private Access.


12. Configure Private DNS

Private Access relies on correct name resolution when applications are accessed by FQDN.

For example, if an application is published as:

hrapp.contoso.com

the connector server must be able to resolve that name to the correct private IP address.

Verify:

  • The connector server uses the correct DNS servers.
  • Internal DNS zones are available.
  • Split-brain DNS is configured correctly, if used.
  • The FQDN in the application segment exactly matches the destination used by the client.
  • The resolved IP address is reachable from the connector server.

A common troubleshooting mistake is to verify DNS from the administrator’s workstation while failing to verify DNS from the connector server. The connector’s DNS resolution is what matters for the connection to the private resource.


13. Security Best Practices

Use Least Privilege

Assign access to specific users and groups rather than granting broad access to all users.

Prefer per-app access when the organization needs granular authorization.

Use Conditional Access

Require MFA and compliant devices for sensitive applications. Consider stronger authentication requirements for administrative resources.

Use Separate Connector Groups

Separate production, development, and geographically distinct resources into different connector groups.

Deploy Multiple Connectors

Use at least two connectors in each connector group to reduce the risk of service interruption.

Avoid Overly Broad Address Ranges

Do not publish an entire subnet if users only need access to one application.

Broad ranges can unintentionally expose unrelated systems.

Harden Connector Servers

Apply:

  • Security updates.
  • Endpoint protection.
  • Administrative access restrictions.
  • Monitoring.
  • Backup and recovery procedures.
  • Least-privilege local administration.

Monitor Access and Connector Health

Review:

  • Connector status.
  • Authentication events.
  • Application access.
  • Conditional Access results.
  • Failed connections.
  • DNS failures.
  • Network connectivity.
  • Unexpected access patterns.

Use PIM for Administrative Roles

Use Microsoft Entra Privileged Identity Management to provide just-in-time administrative access where appropriate. This reduces standing privilege for administrators.

Treat Private Access as One Security Layer

Private Access should be combined with:

  • Application authentication.
  • Resource authorization.
  • Network segmentation.
  • Endpoint security.
  • Data protection.
  • Logging and monitoring.

14. Troubleshooting Microsoft Entra Private Access

Problem: The Client Is Installed but Traffic Is Not Forwarded

Check:

  • Whether the Private Access profile is enabled.
  • Whether the user or group is assigned.
  • Whether the client is signed in.
  • Whether the destination matches a configured FQDN or IP address.
  • Whether the client is running the expected version.
  • Whether the device is properly registered.

Problem: The Connector Is Offline

Check:

  • Windows Server availability.
  • Connector service status.
  • Outbound ports 80 and 443.
  • Firewall and proxy configuration.
  • Required Microsoft service endpoints.
  • Connector diagnostics.
  • Server resource utilization.

Problem: The Connector Is Online but the Application Is Unreachable

Check:

  • DNS resolution from the connector server.
  • Routing from the connector server to the private resource.
  • Firewall rules.
  • Application listening ports.
  • Network security groups, if the resource is in Azure.
  • Whether the application is associated with the correct connector group.

Problem: Users Receive Access Denied

Check:

  • User and group assignments.
  • Conditional Access policies.
  • Device compliance status.
  • MFA requirements.
  • Application segment configuration.
  • Whether the user is using the correct Microsoft Entra account.

Problem: Only Some Applications Work

This may indicate:

  • An incomplete application segment.
  • Incorrect FQDNs or IP addresses.
  • Missing ports or protocols.
  • Different DNS behavior between applications.
  • The application is associated with the wrong connector group.
  • The connector can reach one application but not another.

Problem: The Application Works by IP Address but Not by Name

This usually indicates a DNS or name-matching issue.

Verify:

  • The FQDN is correctly configured.
  • The connector server can resolve the FQDN.
  • The application uses the same name configured in Private Access.
  • Internal DNS records are correct.

15. Common SC-500 Exam Traps

Trap 1: Enabling the Profile Grants Access to Everything

Incorrect. Enabling the Private Access traffic forwarding profile does not automatically grant access to every private resource. The destinations must be configured and the users must be assigned.

Trap 2: Private Access Requires Inbound Ports

Incorrect. Private Network Connectors initiate outbound connections to the Microsoft service. Inbound internet access to the connector is not required.

Trap 3: Quick Access Is Always the Best Long-Term Design

Incorrect. Quick Access is useful for broad access and VPN transition scenarios, but per-app access generally provides stronger segmentation and least-privilege control.

Trap 4: Connector Registration Guarantees Application Connectivity

Incorrect. The connector must also be able to resolve and reach the private resource.

Trap 5: Private Access Replaces Application Authorization

Incorrect. Private Access provides network access. The application, operating system, database, and file system may still enforce their own permissions.

Trap 6: One Connector Is Sufficient for Production

Incorrect. Use multiple connectors in a connector group for high availability.

Trap 7: All Private Traffic Is Automatically Forwarded

Incorrect. Traffic must match the configured Private Access destinations and applicable forwarding policies.

Trap 8: A Private Application Should Always Use the Default Connector Group

Incorrect. Dedicated connector groups can improve segmentation, routing, performance, and troubleshooting.


Practice Exam Questions

Question 1

An organization wants remote employees to access several internal applications without connecting to a traditional VPN. The organization wants access decisions to be based on Microsoft Entra users, groups, and Conditional Access policies.

Which solution should the organization implement?

A. Azure ExpressRoute only
B. Azure Bastion
C. Microsoft Entra Private Access with the Global Secure Access client
D. Azure Firewall without private application configuration

Correct answer: C

Explanation: Microsoft Entra Private Access provides identity-centric access to private resources through the Global Secure Access client and private network connectors. Azure Bastion is primarily used for secure management access to Azure virtual machines, while ExpressRoute and Azure Firewall do not independently provide this application access model.


Question 2

A security engineer is configuring Microsoft Entra Private Access. The engineer has enabled the Private Access traffic forwarding profile but users still cannot access an internal application.

What should the engineer configure next?

A. A public IP address for the internal application
B. A Quick Access configuration or Global Secure Access application containing the private destination
C. An inbound internet rule to the connector server
D. An Azure VPN gateway in every user’s network

Correct answer: B

Explanation: Enabling the traffic forwarding profile alone does not identify which private resources should be routed through Private Access. The administrator must configure the destination through Quick Access or a Global Secure Access application and assign the appropriate users or groups.


Question 3

An organization has two internal applications. One is hosted in the production data center, and the other is hosted in a development network. The security team wants to prevent the development connector from being used to access production applications.

What should the organization configure?

A. One connector group containing every connector
B. A separate Conditional Access policy for the Global Secure Access client only
C. Separate connector groups associated with the appropriate applications
D. A public load balancer for each application

Correct answer: C

Explanation: Connector groups allow administrators to associate applications with specific connectors. Separate groups can improve segmentation and help ensure that production applications use only connectors that can appropriately reach the production network.


Question 4

A company wants to provide access to one internal finance application but does not want users to access other systems on the same subnet.

Which configuration best supports this requirement?

A. Add the entire subnet to Quick Access
B. Assign all employees to the Private Access profile
C. Publish the entire data center through one connector group
D. Create a dedicated Global Secure Access application with a specific application segment

Correct answer: D

Explanation: Per-app access allows the organization to define a specific private application segment rather than granting broad subnet access. This supports least privilege and application-level segmentation.


Question 5

A Private Network Connector is registered and appears online. However, users cannot connect to an internal website through Microsoft Entra Private Access.

What should be checked first on the connector server?

A. Whether the connector server can resolve and reach the internal website
B. Whether the user has an Azure subscription
C. Whether the website has a public IP address
D. Whether the user has an Azure VPN Gateway

Correct answer: A

Explanation: The connector server must be able to resolve the private resource’s DNS name and reach the resource over the internal network. A registered connector can still be unable to access a specific application.


Question 6

An organization wants to require multifactor authentication and device compliance before users can access a private payroll application.

Which control should be used?

A. Conditional Access applied to the private application
B. A public network security group rule
C. A DNS forwarding rule
D. A connector server local firewall rule only

Correct answer: A

Explanation: Conditional Access can require MFA, compliant devices, and other conditions before access to the private application is permitted. Network and firewall rules alone do not provide identity-aware access decisions.


Question 7

An organization is deploying Microsoft Entra Private Access for a business-critical application. The organization wants the application to remain available if one connector server fails.

What should the organization do?

A. Install the connector on the user’s workstation
B. Publish the application through a public IP address
C. Use only Quick Access
D. Deploy multiple connectors in the same connector group

Correct answer: D

Explanation: Connectors in the same connector group provide load balancing and high availability. Deploying multiple connectors reduces the risk that a single connector failure will interrupt application access.


Question 8

Users can access an internal application by IP address but cannot access it by its fully qualified domain name.

What is the most likely issue?

A. The user must be assigned to Azure Firewall
B. The connector server cannot correctly resolve the application’s DNS name
C. The application requires an Azure VPN gateway
D. The Global Secure Access client only supports public DNS names

Correct answer: B

Explanation: When access works by IP address but not by name, DNS resolution or FQDN configuration is a likely cause. The connector server must be able to resolve the configured FQDN to the correct private address.


Question 9

An organization is beginning a VPN replacement project and needs to provide access to a broad set of internal resources while it develops a more granular Zero Trust design.

Which configuration is most appropriate as an initial transition?

A. Quick Access
B. Azure Bastion
C. Azure DDoS Protection
D. Microsoft Defender for Storage

Correct answer: A

Explanation: Quick Access can define a broad set of private FQDNs, IP addresses, and ranges. It is useful as a transition stage, although per-app access should be considered for more granular long-term segmentation.


Question 10

A security engineer wants to ensure that users assigned to Microsoft Entra Private Access cannot automatically access every application on the internal network.

Which statement is correct?

A. Private Access always grants full subnet access
B. The Global Secure Access client automatically bypasses Conditional Access
C. Private Access can route only configured destinations, and access still depends on assignments and policies
D. Private Access disables application-level authentication

Correct answer: C

Explanation: Microsoft Entra Private Access is destination-aware and identity-aware. Users must be assigned to the relevant profile or application, and Conditional Access policies can further restrict access. Private Access does not eliminate application-level authentication or authorization.


Key Takeaways

For the SC-500 exam, remember these core principles:

  • Microsoft Entra Private Access provides identity-centric access to private resources without requiring a traditional VPN.
  • The Global Secure Access client runs on user devices and forwards traffic for configured private destinations.
  • Private Network Connectors are installed inside the private network and initiate outbound connections.
  • Quick Access provides broad private resource access and is useful during VPN transition.
  • Per-app access provides more granular, least-privilege segmentation.
  • Connector groups support application association, geographic placement, segmentation, load balancing, and high availability.
  • Enabling the Private Access profile alone does not grant access to private resources.
  • Conditional Access can require MFA, compliant devices, and other access conditions.
  • The connector server must be able to resolve and reach the private resource.
  • Private Access provides network access but does not replace application-level authorization.
  • Multiple connectors should be deployed for production availability.
  • Avoid publishing unnecessarily broad IP ranges or subnets.

Go to the SC-500 Exam Prep Hub main page

Implement conditional access for Microsoft Entra Agent ID (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for AI
      --> Implement conditional access for Microsoft Entra Agent ID


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

AI agents increasingly perform tasks that were previously completed by users or applications. They may access files, call APIs, read databases, send messages, or execute business processes. Because agents can operate autonomously and at high speed, granting them unrestricted access creates significant security risks.

Microsoft Entra Agent ID provides identity and access-management capabilities designed specifically for AI agents. Microsoft Entra Conditional Access can then evaluate the agent’s identity, context, and risk before allowing it to access protected resources.

The objective is to apply Zero Trust principles to agents:

Never trust an agent automatically. Verify the agent’s identity, evaluate its risk and context, and grant only the access it requires.

Microsoft Entra Agent ID introduces dedicated agent identities that can be governed and protected similarly to other identities, while also providing agent-specific controls and policy scenarios.


Why Conditional Access Is Important for AI Agents

Traditional applications generally operate according to predefined workflows. AI agents, however, can dynamically interpret instructions, select tools, and decide which actions to perform.

For example, an agent might:

  1. Receive a user request.
  2. Retrieve information from a business application.
  3. Call a database or API.
  4. Generate a response.
  5. Perform an additional action based on the information it discovered.

If the agent is compromised, misconfigured, or manipulated through prompt injection, it may attempt to access resources outside its intended scope.

Conditional Access helps reduce this risk by allowing an organization to define policies such as:

  • Block high-risk agent identities.
  • Allow only selected agents to access production resources.
  • Restrict agents based on security attributes.
  • Apply different policies to development and production agents.
  • Require access to occur through approved network conditions.
  • Apply different controls to autonomous agents and agents acting on behalf of users.

Conditional Access does not replace authorization. It determines whether access is permitted under specific conditions. The agent must still have the necessary permissions to access the target resource.


Microsoft Entra Agent ID Concepts

Agent identity

An agent identity is a dedicated identity representing an AI agent in Microsoft Entra ID. It provides a distinct security principal that can be authenticated, authorized, governed, and monitored.

Using a separate identity is preferable to allowing many agents to share a broad application identity because it improves:

  • Accountability.
  • Permission management.
  • Risk evaluation.
  • Access reviews.
  • Incident investigation.
  • Lifecycle management.

Agent identity blueprint

An agent identity blueprint represents the definition or source from which agent identities are created.

Conditional Access policies can be applied at the blueprint level so that agent identities created from that blueprint inherit the applicable policies. This is useful when an organization wants consistent controls across a group of related agents.

Agent user

An agent user is an identity associated with an agent for scenarios in which the agent operates on behalf of a user. This is different from an autonomous agent that acts without a user context.

The distinction matters because an organization may need different policies for:

  • Autonomous agents that act independently.
  • Agents acting on behalf of users.
  • Agents with delegated access.
  • Agents using application-only permissions.

Microsoft Entra documentation provides separate policy scenarios for autonomous agents and agents acting on behalf of users.


How Conditional Access Works for Agents

A Conditional Access policy is essentially an if-then statement:

If a specified identity attempts to access a specified resource under specified conditions, then grant access, require an applicable control, or block access.

For agent identities, the policy can evaluate information such as:

  • Which agent is requesting access.
  • Whether the agent belongs to a particular blueprint.
  • The resource being accessed.
  • The agent’s risk level.
  • Agent attributes.
  • Network or location-related signals.
  • Whether the agent is autonomous or acting on behalf of a user.

All applicable Conditional Access policies must be satisfied before access is granted. If one applicable policy blocks access, the request is blocked.


Conditional Access Policy Assignments for Agents

A Conditional Access policy generally contains three major areas:

  1. Assignments
  2. Conditions
  3. Access controls

1. Assignments

Assignments determine which identities and resources are included in the policy.

For agent policies, supported targeting options include:

  • All agent identities.
  • Selected agents acting as users.
  • Agents selected by attributes.
  • Individual agent identities.

This allows an organization to create broad policies or highly targeted policies.

2. Target resources

The policy can target the cloud applications or resources that agents are attempting to access.

For example, an organization could create a policy that applies to agents accessing:

  • Production databases.
  • Sensitive document repositories.
  • Microsoft Graph resources.
  • Business applications.
  • Administrative services.
  • High-value APIs.

The agent may be allowed to access low-risk resources while being blocked from sensitive resources unless additional conditions are satisfied.

3. Conditions

Conditions determine when the policy applies. Depending on the supported agent scenario, conditions can include:

  • Agent risk.
  • Agent attributes.
  • Network location.
  • Other applicable identity or resource context.

Agent-specific Conditional Access guidance emphasizes using risk, identity filters, and named locations rather than relying on interactive user controls.


Agent Risk and Microsoft Entra ID Protection

One of the most important capabilities is the ability to use Microsoft Entra ID Protection risk signals in Conditional Access policies.

An agent may be considered high risk because of suspicious behavior, such as:

  • Accessing unfamiliar resources.
  • Making an unusually high number of sign-in attempts.
  • Exhibiting behavior associated with a compromised identity.
  • Displaying other risk indicators detected by Microsoft Entra ID Protection.

An organization can create a Conditional Access policy that blocks agent identities identified as high risk.

Example

A company has an autonomous purchasing agent that normally accesses inventory and approved purchasing APIs. Microsoft Entra ID Protection detects that the agent is attempting to access unfamiliar resources at an unusually high rate.

A Conditional Access policy can be configured to:

  • Include all agent identities.
  • Target the relevant resources.
  • Use high agent risk as a condition.
  • Block access.

This helps prevent a potentially compromised agent from continuing to access organizational resources.


Agent Attributes and Fine-Grained Policies

Organizations can use attributes to classify agents and apply more precise controls.

Examples of useful attributes include:

  • Environment: Development, Test, or Production.
  • Department: Finance, Human Resources, or Operations.
  • Data sensitivity: Public, Internal, Confidential, or Restricted.
  • Business owner.
  • Agent type.
  • Regulatory classification.

For example, an organization might apply a policy that blocks agents classified as Development from accessing production resources.

This approach is more scalable than manually creating a separate policy for every agent. It also makes it easier to enforce consistent security standards across large agent inventories.


Important Agent-Specific Consideration: Interactive Controls

Many traditional Conditional Access policies are designed for human users. They may require controls such as:

  • Multifactor authentication.
  • A compliant device.
  • A user-approved client application.
  • A password change.
  • Acceptance of terms of use.

Agents generally cannot complete interactive controls in the same way that human users can.

For this reason, organizations should not simply apply a broad user policy to agents and assume it will work correctly. Instead, create dedicated agent policies that use controls appropriate for noninteractive or agent-based access, such as:

  • Agent identity targeting.
  • Risk-based blocking.
  • Attribute-based filtering.
  • Resource restrictions.
  • Network controls.
  • Least-privilege authorization.

Microsoft recommends creating agent-specific policies rather than relying exclusively on policies designed for users.


Autonomous Agents Versus Agents Acting on Behalf of Users

Autonomous agents

An autonomous agent operates without a user context. It may run on a schedule, respond to events, or independently perform tasks.

Examples include:

  • An agent that monitors inventory.
  • An agent that processes incoming support requests.
  • An agent that checks compliance conditions.
  • An agent that performs scheduled data analysis.

Policies for autonomous agents should focus on the agent’s own identity, permissions, risk, and resource access.

Agents acting on behalf of users

An agent acting on behalf of a user performs actions in the context of a human user or uses delegated permissions.

Examples include:

  • An assistant retrieving a user’s calendar.
  • An agent preparing a report using the user’s permitted files.
  • An agent submitting a request on behalf of an employee.

These scenarios require careful consideration of both:

  • The agent’s identity.
  • The user context and delegated permissions.

Microsoft Entra provides separate Conditional Access policy scenarios for autonomous agents and agents acting on behalf of users.


Example Conditional Access Policies

Policy 1: Block high-risk agents

Purpose: Prevent risky agents from accessing organizational resources.

Example configuration:

  • Include: All agent identities.
  • Target resources: Selected organizational resources.
  • Condition: High agent risk.
  • Access control: Block access.

This is one of the most important baseline policies for agent security.

Policy 2: Restrict development agents

Purpose: Prevent development agents from accessing production resources.

Example configuration:

  • Include: Agents with an Environment attribute of Development.
  • Target resources: Production applications or databases.
  • Access control: Block access.

Policy 3: Protect sensitive resources

Purpose: Apply stricter controls to agents accessing confidential data.

Example configuration:

  • Include: Selected agent identities or agents with a specific data-sensitivity attribute.
  • Target resources: Sensitive applications or data repositories.
  • Conditions: Applicable agent context and risk.
  • Access control: Allow only when the required conditions are satisfied.

Policy 4: Separate autonomous-agent access

Purpose: Apply policies specifically to agents that operate without user context.

Example configuration:

  • Include: Autonomous agent identities.
  • Target resources: Approved APIs and applications.
  • Access control: Permit only the intended access pattern.

How to Configure Conditional Access for Agent Identities

The exact portal experience may change as Microsoft Entra Agent ID and Microsoft Agent 365 evolve. The following process describes the core configuration approach.

Step 1: Identify the agents that require protection

Before creating policies, determine:

  • Which agents exist.
  • Which agents use Microsoft Entra Agent ID.
  • Whether each agent is autonomous or acts on behalf of a user.
  • Which resources each agent needs.
  • Who owns and sponsors each agent.
  • Which agents access sensitive or production resources.

Do not begin by applying a broad blocking policy without understanding the agent inventory and access requirements.

Step 2: Assign appropriate permissions

Conditional Access does not grant permissions by itself.

First, assign the agent only the permissions required for its tasks. Use:

  • Least-privilege permissions.
  • Narrow API scopes.
  • Specific resource assignments.
  • Access packages where appropriate.
  • Separate identities for separate agents or workloads.

Access packages can assign agent identities access to resources such as security groups, application permissions, and Microsoft Entra roles.

Step 3: Open the Conditional Access policy experience

In the Microsoft Entra admin center:

  1. Open Microsoft Entra ID.
  2. Navigate to Protection.
  3. Open Conditional Access.
  4. Create a new policy.

The exact navigation labels may vary as the portal changes.

Step 4: Select the agent identities

In the policy’s identity assignment area, select the applicable agent scope.

Possible scopes include:

  • All agent identities.
  • Specific agent identities.
  • Agents selected by attributes.
  • Agents acting as users.

Avoid accidentally including human users or unrelated workload identities when the policy is intended only for agents.

Step 5: Select target resources

Choose the applications, services, or resources that the agent policy should protect.

A policy targeting sensitive production resources is often safer and easier to test than a policy initially targeting every resource in the tenant.

Step 6: Configure conditions

Configure conditions appropriate to the scenario, such as:

  • High agent risk.
  • Agent identity attributes.
  • Network conditions.
  • Other supported context signals.

For example, a high-risk policy should use the agent risk condition rather than a human-user sign-in-risk condition.

Step 7: Configure the access control

Select the appropriate enforcement action:

  • Block access for high-risk or unauthorized scenarios.
  • An applicable grant control when the agent scenario supports it.
  • Appropriate session or network controls where available.

Do not require interactive MFA as a default solution for autonomous agents. Agents cannot generally respond to an interactive MFA challenge as a human user would.

Step 8: Start in report-only mode

Use report-only mode to evaluate the policy before enforcing it.

This helps identify:

  • Agents that would be blocked.
  • Unexpected policy matches.
  • Conflicts with existing policies.
  • Agents that require different permissions or attributes.
  • Potential business impact.

Microsoft recommends testing agent policies in report-only mode before enabling enforcement.

Step 9: Review the results

Review the Conditional Access results and determine whether:

  • The intended agents are being targeted.
  • Unintended identities are included.
  • The policy blocks legitimate operations.
  • The policy fails to protect the intended resources.
  • Existing broad policies interfere with agent access.

Step 10: Enable the policy

After testing, enable the policy and monitor its effect.

Use a staged rollout where possible:

  1. Test with a small group of agents.
  2. Review logs and operational behavior.
  3. Expand the scope.
  4. Continue monitoring for false positives and unexpected access attempts.

Conditional Access and Existing User Policies

A common mistake is assuming that a policy such as “All users must use MFA” automatically provides appropriate protection for agents.

Agent identities are not human users, and interactive user controls may not apply to them in the same way.

Organizations should:

  • Review broad policies for their impact on agents.
  • Create dedicated policies for agent identities.
  • Avoid unintentionally blocking legitimate agent flows.
  • Avoid excluding agents from security controls merely because a user-focused policy does not work.
  • Replace unsuitable controls with agent-appropriate conditions and restrictions.

The goal is not to weaken security for agents. The goal is to apply controls that are appropriate for how agents authenticate and operate.


Relationship to Other Security Controls

Conditional Access is only one layer of defense.

Microsoft Entra authorization

Authorization determines what the agent is allowed to access. Conditional Access determines whether the access is permitted under current conditions.

Both are required.

Microsoft Entra ID Protection

ID Protection supplies risk signals that can be used by Conditional Access policies, including policies that block high-risk agents.

Access packages and identity governance

Access packages help control which resources an agent can receive access to and can include approval and expiration requirements.

Microsoft Agent 365

Microsoft Agent 365 provides broader agent discovery, management, and governance capabilities. Microsoft Entra Agent ID provides the identity foundation used to manage and protect agent identities.

Microsoft Purview

Purview can help identify and govern data risks, including classification, sensitivity labels, and data protection controls. These capabilities complement Conditional Access but do not replace it.

Runtime protection

Runtime protection can inspect agent behavior or tool invocations while the agent is operating. Conditional Access is primarily an identity and access decision made before access to a resource is granted.


Best Practices

Use a unique identity for each agent

Avoid sharing one broad identity across many unrelated agents. Separate identities improve accountability and make it easier to revoke or restrict access.

Apply least privilege

Grant only the permissions required for the agent’s specific tasks. Do not use broad permissions simply because they are easier to configure.

Block high-risk agents

Create a baseline policy that blocks agent identities identified as high risk by Microsoft Entra ID Protection.

Use attributes for scale

Use attributes such as environment, department, and data sensitivity to apply consistent policies across many agents.

Separate development and production

Development agents should not automatically have access to production resources.

Test policies in report-only mode

Validate policy behavior before enforcement to reduce accidental outages.

Review existing policies

Broad policies designed for users may unintentionally block agents or fail to protect them appropriately.

Combine Conditional Access with authorization

Conditional Access cannot compensate for excessive permissions. The agent must still be granted only the access it needs.

Maintain ownership and sponsorship

Every agent should have an accountable owner or sponsor who can review its permissions, lifecycle, and continued business need.

Monitor and review continuously

Agent behavior, permissions, and risk can change over time. Periodically review:

  • Agent identities.
  • Access assignments.
  • Conditional Access results.
  • Risk detections.
  • Resource permissions.
  • Ownership and sponsorship.
  • Policy exceptions.

Common Exam Traps

Conditional Access is not the same as authorization

Conditional Access does not determine the complete set of permissions an agent has. It evaluates whether access should be allowed under specified conditions.

Agent identities are not ordinary human users

Do not assume an agent can satisfy interactive controls such as MFA prompts.

High-risk agents should generally be blocked

A common security scenario is creating a policy that blocks agent identities identified as high risk.

User policies should not be copied blindly

Policies designed for human users may not be appropriate for autonomous agents.

Report-only mode does not enforce the policy

Report-only mode evaluates and reports policy results without applying the policy’s enforcement action.

Conditional Access does not replace least privilege

An agent with excessive permissions remains dangerous even if Conditional Access is enabled.

Autonomous and delegated agents are different

An autonomous agent and an agent acting on behalf of a user may require different policy designs.


Practice Exam Questions

Question 1

What is the primary purpose of applying Conditional Access to Microsoft Entra agent identities?

A. To automatically create agent identities
B. To evaluate agent context and risk before allowing access to resources
C. To replace all agent authorization permissions
D. To train the agent to recognize malicious prompts

Correct answer: B

Explanation: Conditional Access evaluates identity, context, and risk to determine whether an agent should be allowed to access a resource. It does not create identities, replace authorization, or train the agent.


Question 2

An organization wants to prevent agents identified as high risk from accessing company resources. Which solution is most appropriate?

A. Require all agents to complete interactive MFA
B. Assign every agent the Global Administrator role
C. Disable all agent identities permanently
D. Create a Conditional Access policy that blocks high-risk agent identities

Correct answer: D

Explanation: Microsoft Entra ID Protection risk signals can be used with Conditional Access to block high-risk agent identities.


Question 3

Which targeting option is appropriate when an organization wants a Conditional Access policy to apply to every Microsoft Entra agent identity?

A. All Microsoft 365 users
B. All guest users
C. All managed identities
D. All agent identities

Correct answer: D

Explanation: Conditional Access supports targeting all agent identities. The other options target different identity categories.


Question 4

Why should organizations avoid applying human-user Conditional Access policies to autonomous agents without review?

A. Agents cannot be assigned permissions
B. Agents are not recorded in Microsoft Entra ID
C. Agents may not be able to satisfy interactive controls such as MFA
D. Conditional Access cannot block agents

Correct answer: C

Explanation: Autonomous agents generally cannot respond to interactive controls in the same way as human users. Dedicated agent policies should use appropriate identity, risk, attribute, and resource controls.


Question 5

An organization wants to prevent development agents from accessing production applications. Which approach is most scalable?

A. Require every developer to manually approve each request
B. Delete all development agents
C. Give development agents unrestricted access and monitor them
D. Use an agent attribute such as Environment and create a policy targeting development agents

Correct answer: D

Explanation: Attribute-based targeting allows organizations to apply consistent policies to groups of agents, such as blocking development agents from production resources.


Question 6

What is the recommended first enforcement stage when testing a new Conditional Access policy for agents?

A. Report-only mode
B. Permanent blocking mode
C. Global Administrator approval for every request
D. Disabling all existing policies

Correct answer: A

Explanation: Report-only mode allows administrators to evaluate the policy’s impact before enforcing it.


Question 7

Which statement best describes the relationship between Conditional Access and authorization?

A. Conditional Access grants all permissions required by the agent
B. Authorization is unnecessary when Conditional Access is enabled
C. Conditional Access evaluates whether access is allowed, while authorization determines what the agent can access
D. Conditional Access only applies after the agent has completed its task

Correct answer: C

Explanation: Conditional Access and authorization serve different purposes. Both are necessary for secure agent access.


Question 8

An autonomous agent normally accesses inventory APIs but suddenly attempts to access unfamiliar resources. Which Microsoft Entra capability can provide a risk signal for a Conditional Access policy?

A. Microsoft Entra ID Protection
B. Azure Resource Locks
C. Azure Backup
D. Microsoft Purview retention labels

Correct answer: A

Explanation: Microsoft Entra ID Protection can detect risky identity behavior and provide risk signals that Conditional Access can use to block or restrict access.


Question 9

Which statement about autonomous agents and agents acting on behalf of users is correct?

A. They always require identical Conditional Access policies
B. Autonomous agents always use delegated user permissions
C. Agents acting on behalf of users cannot access applications
D. They may require different policies because their identity and user-context models differ

Correct answer: D

Explanation: Autonomous agents operate without a user context, while delegated agents act on behalf of users. Their access and policy requirements can therefore differ.


Question 10

Which action is most consistent with a least-privilege strategy for Microsoft Entra agent identities?

A. Give every agent broad Microsoft Graph application permissions
B. Assign only the API scopes, applications, and resources required by each agent
C. Use one shared administrator identity for all agents
D. Exclude agents from all Conditional Access policies

Correct answer: B

Explanation: Least privilege means granting each agent only the permissions necessary for its intended tasks. Broad shared identities and excessive permissions increase risk.


Go to the SC-500 Exam Prep Hub main page

Analyze blast radius for security risks related to Entra Agent ID by using Defender XDR (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for AI
      --> Analyze blast radius for security risks related to Entra Agent ID by using Defender XDR


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

AI agents can access data, invoke tools, call APIs, and perform actions across an organization. If an agent identity is compromised, the impact may extend far beyond the agent itself.

For example, an agent might have permission to:

  • Read confidential documents.
  • Access a customer database.
  • Modify records in a business application.
  • Call privileged APIs.
  • Access other identities or resources.
  • Use knowledge sources containing sensitive information.

The blast radius of an agent represents the potential impact of compromising that agent identity. It helps security teams understand what an attacker might be able to reach or control by abusing the agent’s permissions, connected resources, and relationships.

Microsoft Defender XDR provides an AI agent inventory, posture-risk information, and attack-path analysis to help security teams discover agents and assess the consequences of a compromised agent identity.


What Is Microsoft Entra Agent ID?

Microsoft Entra Agent ID provides identity capabilities for AI agents. Instead of treating every agent as an unidentified application process, an organization can represent an agent with a distinct identity that can be:

  • Authenticated.
  • Assigned permissions.
  • Governed.
  • Monitored.
  • Investigated.
  • Disabled or remediated when risky.

An agent identity should be treated as a security principal with a defined owner, purpose, permission set, and lifecycle.

This is important because an AI agent may have more effective access than its name or user interface suggests. The agent’s actual risk depends on what it can access and what actions it can perform—not merely on what the agent was designed to do.


What Is Blast Radius?

The blast radius is the set of resources, identities, applications, data, and systems that could potentially be affected if an agent identity were compromised.

A blast-radius assessment asks questions such as:

  • What permissions does the agent have?
  • Which applications and APIs can it access?
  • Which data sources are available to it?
  • Can it read or modify sensitive data?
  • Can it invoke tools that perform destructive actions?
  • Can it access privileged business systems?
  • Can it reach other identities or resources through existing relationships?
  • Are there attack paths from the agent to critical assets?

Example

Suppose an AI agent has:

  • Read access to a document repository.
  • Write access to a purchasing application.
  • Permission to call an external API.
  • Access to a knowledge source containing confidential business information.

If the agent is compromised, the attacker might be able to:

  1. Read confidential documents.
  2. Extract sensitive information.
  3. Submit unauthorized purchasing requests.
  4. Use the external API to transfer data.
  5. Reach additional resources through the agent’s permissions.

The agent’s blast radius is therefore larger than the agent itself.


Why AI Agents Create Unique Blast-Radius Risks

AI agents introduce additional risk because they can dynamically determine which tools to use and which actions to perform.

Traditional applications often follow fixed workflows. Agents may instead:

  • Interpret natural-language instructions.
  • Retrieve information from multiple sources.
  • Select tools dynamically.
  • Chain several actions together.
  • Act autonomously.
  • Use permissions inherited from a user or application.
  • Operate without continuous human approval.

A compromised or manipulated agent may therefore use legitimate permissions in unintended ways.

Important AI-related risks include:

  • Over-privileged agent identities.
  • Excessive access to sensitive data.
  • Unrestricted tool invocation.
  • Indirect prompt injection.
  • Weak or missing authentication.
  • Agents that can operate without human approval.
  • Privileged access to business systems.
  • Active threats or alerts associated with the agent.

Microsoft Defender assesses agent posture using risk indicators derived from configuration, permissions, tools, runtime activity, settings, and associated security alerts.


Microsoft Defender XDR AI Agent Inventory

Microsoft Defender XDR provides a centralized inventory of AI agents in the organization.

Depending on the available integrations and supported platforms, the inventory can include agents built with:

  • Microsoft Copilot Studio.
  • Microsoft Foundry.
  • Microsoft 365.
  • Supported non-Microsoft platforms.
  • Local AI agents discovered on endpoint devices.

The inventory can provide information about:

  • Agent identity.
  • Agent type.
  • Agent configuration.
  • Connected tools.
  • Knowledge sources.
  • Risk level.
  • Risk indicators.
  • Security recommendations.
  • Related alerts.
  • Security context.

To review agents in the Microsoft Defender portal, navigate to:

Assets → AI agents → Agents

The exact portal experience may change as Microsoft’s AI security capabilities evolve.


Agent Risk Level Versus Blast Radius

These concepts are related but are not identical.

Agent risk level

The risk level represents the overall security risk associated with an agent. Microsoft Defender combines active risk indicators to determine an overall risk level.

Possible risk levels include:

  • High
  • Medium
  • Low
  • No known risk
  • Not evaluated

Risk indicators may include:

  • Weak instructions.
  • Indirect prompt-injection exposure.
  • Privileged business-system access.
  • High usage.
  • Active threats.
  • Lack of human approval.
  • Access to sensitive data.

The risk level is influenced by both the severity and combination of active indicators.

Blast radius

Blast radius focuses on the potential impact if the agent is compromised.

An agent could have a high blast radius even if no active threat has been detected. For example, an agent may be operating as designed but have broad permissions to critical systems.

Conversely, an agent may have a low blast radius but still be actively compromised.

Therefore:

Risk level describes the likelihood and seriousness of the agent’s security exposure. Blast radius describes what could be affected if the agent were compromised.

Security teams should evaluate both.


Key Risk Indicators

Microsoft Defender uses risk indicators to provide context about an agent’s exposure.

Privileged business-system access

This indicates that an agent has write access to important business systems.

Examples include:

  • Creating or modifying financial transactions.
  • Changing customer records.
  • Updating inventory.
  • Modifying business-critical configurations.
  • Accessing administrative APIs.

An agent with write access generally has a greater blast radius than an agent with read-only access.

Indirect prompt-injection exposure

An agent may retrieve content containing hidden instructions from:

  • Email.
  • Documents.
  • Web pages.
  • Knowledge bases.
  • External data sources.

The content may attempt to manipulate the agent into performing unintended actions.

This risk is especially important when the agent can access sensitive data or invoke powerful tools.

Weak instructions

Weak or incomplete instructions may fail to establish safe operating boundaries for the agent.

For example, an agent may not be clearly instructed to:

  • Refuse unauthorized requests.
  • Avoid exposing secrets.
  • Request approval before destructive actions.
  • Validate tool parameters.
  • Restrict access to approved resources.

High-usage agent

An agent used by many people may be important to business operations. A compromise could affect a large number of users or business processes.

High usage does not necessarily mean the agent is insecure, but it increases the importance of careful review.

Active threat

An active threat indicator means that security alerts are associated with the agent.

An agent with both an active threat and privileged access should receive immediate attention because the likelihood and potential impact of compromise may both be significant.


Understanding Attack Paths

An attack path is a possible sequence of relationships or permissions that could allow an attacker to move from a compromised entity to a target resource.

For an agent, an attack path might look like:

Compromised agent identity → application permission → sensitive database → confidential data

Another example could be:

Compromised agent → privileged API → business application → administrative action

Attack-path analysis helps identify indirect exposure that may not be obvious when reviewing the agent’s permissions individually.

A single permission may appear harmless, but a sequence of permissions and relationships may create a significant route to a critical asset.

Microsoft Defender graphs use nodes and edges to represent entities and relationships. Attack-path analysis can show potential routes between a source entity and a target asset.


How to Analyze an Agent’s Blast Radius

Step 1: Discover the agent

Open the Microsoft Defender portal and review the AI agent inventory.

Identify:

  • The agent name.
  • The agent type.
  • Its associated identity.
  • Its owner.
  • Its environment.
  • Its connected tools.
  • Its knowledge sources.
  • Its risk level.

The inventory is the starting point for understanding which agents exist and which require further investigation.

Step 2: Review the agent’s configuration

Examine how the agent is configured.

Important questions include:

  • Is the agent autonomous?
  • Does it act on behalf of a user?
  • Can it operate without human approval?
  • Which tools can it invoke?
  • Which applications can it access?
  • Does it have write or administrative capabilities?
  • Does it use external services?
  • Does it retrieve content from untrusted sources?

Configuration weaknesses can increase the likelihood that an agent will be manipulated or misused.

Step 3: Review permissions and identities

Determine the permissions assigned to the agent identity.

Review:

  • Microsoft Entra roles.
  • Application permissions.
  • Delegated permissions.
  • API scopes.
  • Resource access.
  • Group memberships.
  • Access packages.
  • Privileged assignments.
  • Permissions inherited through applications or users.

The goal is to determine what the agent can actually do, not merely what it is intended to do.

Step 4: Review knowledge sources

Knowledge sources can significantly increase an agent’s blast radius.

Review whether the agent can access:

  • Confidential documents.
  • Customer information.
  • Financial data.
  • Internal policies.
  • Credentials or secrets.
  • Sensitive databases.
  • External content.
  • Data belonging to multiple departments.

An agent with read access to a broad knowledge source may expose more information than expected, even if it cannot modify the underlying data.

Step 5: Review connected tools

Tools determine what actions the agent can perform.

Examples include tools that:

  • Query databases.
  • Send email.
  • Create support tickets.
  • Modify records.
  • Call external APIs.
  • Execute workflows.
  • Access storage.
  • Provision resources.

A tool with write, delete, or administrative capability can substantially increase the agent’s potential impact.

Step 6: Review blueprint configuration

Agent identity blueprints can provide a consistent way to create and manage agent identities.

Review blueprint configuration to determine whether it establishes:

  • Appropriate identity settings.
  • Required governance.
  • Permission boundaries.
  • Consistent security controls.
  • Appropriate ownership.
  • Secure defaults.

A poorly configured blueprint may create multiple agents with the same excessive permissions or weak security settings.

Step 7: Review risk indicators and recommendations

Review the agent’s active risk indicators and any available security recommendations.

Risk indicators describe the agent’s exposure. Recommendations identify actionable changes that may reduce that exposure.

A high-risk agent may not always have an available recommendation, and a lower-risk agent may still have a recommendation that should be implemented. Therefore, review the risk level and recommendations together.

Step 8: Analyze attack paths

Use the available Defender graph and attack-path capabilities to investigate possible routes from the agent to sensitive resources.

Look for paths involving:

  • Privileged identities.
  • Sensitive applications.
  • Critical databases.
  • Storage accounts.
  • Administrative roles.
  • High-value business systems.
  • External access.
  • Lateral movement.

The objective is to identify not only direct access but also indirect routes that could lead to compromise of critical assets.

Step 9: Prioritize remediation

Prioritize agents that combine several high-impact characteristics, such as:

  • High risk.
  • Privileged access.
  • Access to sensitive data.
  • Autonomous operation.
  • External exposure.
  • Active security alerts.
  • Write access to critical systems.
  • Multiple attack paths to important assets.

Defender Blast-Radius Graphs

Microsoft Defender can display graph-based views of entities and potential attack paths.

A graph generally contains:

  • Nodes, representing entities or assets.
  • Edges, representing relationships or connections.
  • Paths, representing possible routes between entities.

For an incident, investigators can select an entity and choose View blast radius when the capability is available. The graph can show highly rated attack paths and a list of reachable targets. Investigators can select a target to inspect the potential path leading to it.

What the graph can help identify

The graph may reveal:

  • A compromised identity’s reachable resources.
  • Indirect paths to critical assets.
  • Relationships between identities and applications.
  • Potential lateral movement.
  • Privilege-escalation routes.
  • Access to sensitive data.
  • Connections between an agent and other entities.

Important limitations

Blast-radius graphs are an approximation of possible attack reach.

They may be limited by:

  • The number of hops analyzed.
  • Data freshness.
  • The attack techniques modeled.
  • The viewer’s RBAC scope.
  • Missing or incomplete relationships.
  • Changes in the environment that have not yet been reflected.

The graph shows possible paths. It does not guarantee that an attacker will use every path shown.


Interpreting the Blast Radius Correctly

A blast-radius graph should not be interpreted as proof that a compromise has occurred.

Instead, it answers:

“If this identity were compromised, what resources might be reachable through known relationships and permissions?”

The graph is useful for:

  • Prioritizing remediation.
  • Identifying excessive permissions.
  • Understanding lateral movement.
  • Finding critical assets exposed through an agent.
  • Supporting incident investigation.
  • Designing Conditional Access policies.
  • Improving agent architecture.

It should be combined with:

  • Actual sign-in and activity logs.
  • Security alerts.
  • Agent configuration.
  • Permission reviews.
  • Data classification.
  • Business criticality.
  • Incident-response procedures.

Example Scenario

A company deploys an autonomous finance agent.

The agent can:

  • Read invoices.
  • Query a financial database.
  • Submit payment requests.
  • Access a shared document repository.
  • Call a payment-processing API.

Defender identifies the following risk indicators:

  • Privileged business-system access.
  • Indirect prompt-injection exposure.
  • Ability to operate without human approval.
  • Access to sensitive financial data.

An attack-path analysis shows:

Agent identity → payment API → financial system

It also shows:

Agent identity → shared repository → confidential financial documents

The security team should consider:

  1. Removing unnecessary write permissions.
  2. Requiring human approval for payment actions.
  3. Restricting the agent to approved APIs.
  4. Limiting access to financial documents.
  5. Reviewing prompt-injection protections.
  6. Applying Conditional Access to high-risk agent identities.
  7. Monitoring related alerts and activity.
  8. Reassessing the blast radius after remediation.

Relationship to Conditional Access

Conditional Access and blast-radius analysis work together.

Blast-radius analysis helps answer:

  • Which agents are high impact?
  • Which agents have privileged access?
  • Which resources should be protected?
  • Which agents should be restricted or blocked?

Conditional Access can then enforce policies such as:

  • Block high-risk agent identities.
  • Restrict selected agents from sensitive applications.
  • Separate development and production agents.
  • Apply policies based on agent attributes.
  • Restrict access to selected resources.

Microsoft Entra ID Protection can detect risky agent behavior. When an agent is confirmed as compromised, its risk can be set to High, allowing a Conditional Access policy configured to block high agent risk to prevent access to resources.


Relationship to Microsoft Defender for Cloud and Microsoft Purview

Blast-radius analysis is not the same as every other security capability.

Microsoft Defender XDR

Used for:

  • AI agent inventory.
  • Agent risk assessment.
  • Identity investigation.
  • Attack-path analysis.
  • Security alerts.
  • Incident investigation.

Microsoft Defender for Cloud

Used more broadly for:

  • Cloud security posture management.
  • Workload protection.
  • Security recommendations.
  • Cloud resource security.
  • AI workload protection.

Microsoft Purview

Used for:

  • Data classification.
  • Sensitivity labels.
  • Data security posture management.
  • Data-loss prevention.
  • Compliance and information protection.

Microsoft Entra Conditional Access

Used for:

  • Evaluating access conditions.
  • Blocking risky agent identities.
  • Restricting access to selected resources.
  • Enforcing identity-based access policies.

These capabilities complement one another. No single control provides complete protection for AI agents.


Best Practices

Use dedicated agent identities

Avoid sharing a broad identity across unrelated agents. Separate identities improve accountability and reduce the impact of a single compromise.

Apply least privilege

Grant only the permissions required for the agent’s purpose.

Minimize write and administrative permissions

Read-only access generally creates a smaller blast radius than the ability to modify or delete data.

Restrict tools

Every connected tool expands the agent’s potential attack surface. Remove tools that are not required.

Use approval gates

Require human approval for:

  • Financial transactions.
  • Data deletion.
  • Permission changes.
  • External communications.
  • Production changes.
  • Other high-impact actions.

Protect knowledge sources

Limit the data available to the agent and ensure that sensitive sources are properly secured.

Separate environments

Development and test agents should not automatically have access to production resources.

Review blueprints

Ensure that agent identity blueprints do not create agents with excessive or inconsistent permissions.

Monitor active threats

An agent with active alerts and privileged access should be investigated immediately.

Reassess after changes

Recalculate or review the agent’s exposure after changing:

  • Permissions.
  • Tools.
  • Knowledge sources.
  • Identity configuration.
  • Resource access.
  • Blueprint settings.

Treat graphs as possible paths

Do not assume that every path shown is an active attack or that every possible path is displayed.


Common Exam Traps

Blast radius is not the same as risk level

Risk level describes the agent’s overall security exposure. Blast radius describes the potential impact of compromise.

An agent does not need to be compromised to have a large blast radius

An agent may be configured with excessive permissions even when no threat has been detected.

Read access and write access are different

Write access to critical business systems generally creates a greater potential impact than read-only access.

Attack paths show possibilities

A graph shows possible routes based on known relationships and data. It does not prove that an attacker has used the route.

Conditional Access does not remove permissions

Conditional Access controls whether access is allowed under specified conditions. It does not replace least-privilege authorization.

Risk indicators and recommendations are different

Risk indicators contribute to the agent’s risk assessment. Recommendations identify available actions that may improve security posture.

A high-risk agent may not have a recommendation

Risk level and available recommendations are calculated separately.

Missing graph paths do not prove that no risk exists

Graphs have scope, freshness, and modeling limitations.


Practice Exam Questions

Question 1

What does the blast radius of a Microsoft Entra agent identity primarily describe?

A. The number of users who have interacted with the agent
B. The amount of compute capacity assigned to the agent
C. The potential resources and systems affected if the agent identity is compromised
D. The number of prompts processed by the agent

Correct answer: C

Explanation: Blast radius describes the potential impact of compromising the agent, including reachable data, applications, identities, and systems.


Question 2

Which Microsoft Defender capability provides a centralized view of AI agents and their security context?

A. Azure Cost Management
B. Azure Resource Graph only
C. Microsoft Purview retention management
D. AI agent inventory

Correct answer: D

Explanation: The AI agent inventory in Microsoft Defender provides visibility into agents, configuration, identities, risk indicators, tools, and related security information.


Question 3

An agent has no active security alerts but can modify a critical financial system. What should the security team conclude?

A. The agent has no security risk
B. The agent has a potentially large blast radius even though no compromise has been detected
C. The agent must be deleted immediately
D. The agent cannot be protected by Conditional Access

Correct answer: B

Explanation: Blast radius is based on potential impact. Privileged access can create significant exposure even when no active threat has been detected.


Question 4

Which risk indicator most directly suggests that an agent can affect important business operations?

A. High usage
B. Weak instructions
C. Indirect prompt-injection exposure
D. Privileged business-system access

Correct answer: D

Explanation: Privileged business-system access indicates that the agent can write to or otherwise affect important business systems.


Question 5

What is the purpose of analyzing attack paths for an agent identity?

A. To determine the model’s response quality
B. To identify possible routes from the agent to other resources or critical assets
C. To calculate the agent’s monthly operating cost
D. To configure the agent’s natural-language instructions

Correct answer: B

Explanation: Attack-path analysis identifies possible relationships and permission chains that could allow access to additional resources or critical assets.


Question 6

Which statement best distinguishes an agent’s risk level from its blast radius?

A. Risk level measures potential impact only, while blast radius measures prompt quality
B. Risk level applies only to human users, while blast radius applies only to applications
C. Risk level reflects overall security exposure, while blast radius reflects potential impact if compromised
D. They are two names for exactly the same measurement

Correct answer: C

Explanation: Risk level combines active risk indicators. Blast radius focuses on what could be affected if the agent identity were compromised.


Question 7

A Defender blast-radius graph displays a path from an agent to a sensitive database. What does this mean?

A. The agent has definitely been compromised
B. The database has already been accessed
C. The graph identifies a possible route based on known relationships and permissions
D. The agent must be assigned a database administrator role

Correct answer: C

Explanation: A blast-radius graph shows possible attack paths. It does not prove that compromise or access has occurred.


Question 8

Which change would most directly reduce an agent’s blast radius?

A. Remove unnecessary write permissions and restrict the agent to required resources
B. Increase the agent’s model size
C. Add more knowledge sources
D. Allow the agent to use additional administrative APIs

Correct answer: A

Explanation: Reducing permissions and limiting resource access directly reduces what the agent could affect if compromised.


Question 9

Why should security teams review an agent’s knowledge sources during blast-radius analysis?

A. Knowledge sources determine the agent’s compute pricing
B. Knowledge sources may expose confidential or sensitive information to the agent
C. Knowledge sources automatically grant Global Administrator access
D. Knowledge sources eliminate the need for identity protection

Correct answer: B

Explanation: Knowledge sources may contain sensitive information. The agent’s access to those sources can significantly increase the impact of compromise or misuse.


Question 10

Which statement about Microsoft Defender blast-radius graphs is accurate?

A. They show every possible attack path with complete certainty
B. They prove that all displayed paths have been exploited
C. They replace permission reviews and incident investigation
D. They show possible paths and may be limited by data freshness, scope, and modeled attack techniques

Correct answer: D

Explanation: Blast-radius graphs are useful approximations, but they have limitations involving data freshness, RBAC scope, hop limits, and known attack vectors.


Go to the SC-500 Exam Prep Hub main page

Manage Entra Agent ID access (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Secure compute (20–25%)
   --> Implement security for AI
      --> Manage Entra Agent ID access


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Artificial intelligence agents increasingly perform tasks that traditionally required human users or application identities. An agent may read documents, query databases, call APIs, send messages, update business systems, or perform actions autonomously.

Because an agent can access organizational resources and act on behalf of users or applications, it must be managed as an identity—not merely as a software component. Microsoft Entra Agent ID extends Microsoft Entra identity, access, governance, and security capabilities to AI agents.

For the SC-500 exam, managing Entra Agent ID access involves understanding how to:

  • Create and manage agent identities.
  • Understand agent identity blueprints.
  • Assign permissions to agents.
  • Apply Conditional Access policies.
  • Use access packages to govern agent access.
  • Monitor agent sign-ins and activity.
  • Manage owners and sponsors.
  • Detect, restrict, or disable risky agents.
  • Apply least-privilege and lifecycle controls.

Microsoft Entra Agent ID provides specialized identity constructs for AI agents and supports authentication, authorization, governance, and security controls throughout the agent lifecycle.


Why AI Agents Require Identity and Access Management

A traditional application may perform a limited set of predefined operations. An AI agent, however, may interpret instructions, select tools, retrieve information, and take actions dynamically.

For example, a customer-service agent might be able to:

  • Read customer records.
  • Search internal knowledge bases.
  • Access Microsoft Graph.
  • Update a CRM system.
  • Create support tickets.
  • Send email.
  • Access files stored in SharePoint or Azure Storage.

If that agent is compromised, manipulated, or incorrectly configured, its permissions could be abused. The security impact depends not only on whether the agent is compromised, but also on what the agent can access and what actions it can perform.

Therefore, security teams must answer questions such as:

  • What identity does the agent use?
  • Who owns and sponsors the agent?
  • Which resources can the agent access?
  • Which permissions were granted to it?
  • Are those permissions inherited from a blueprint?
  • Can the agent access resources on behalf of a user?
  • Can it act autonomously?
  • Can Conditional Access restrict its access?
  • How can the agent be disabled if it becomes risky?

The objective is to provide agents with only the access they require, for only as long as they require it.


Core Entra Agent ID Concepts

Agent identity

An agent identity is a specialized identity in Microsoft Entra ID that represents an individual AI agent.

Microsoft documentation describes an agent identity as a special service principal created from an agent identity blueprint. The agent identity represents the agent that is authorized to use the blueprint. It does not independently maintain its own credentials; the blueprint can acquire tokens on behalf of the agent identity after the appropriate consent and permissions have been granted.

An agent identity allows an organization to:

  • Give an agent a distinct identity.
  • Assign permissions to the agent.
  • Apply access policies.
  • Track sign-in activity.
  • Associate the agent with owners and sponsors.
  • Disable the agent when necessary.
  • Govern the agent independently from human users.

Example

A company deploys three instances of a sales assistant:

  • North America Sales Assistant.
  • Europe Sales Assistant.
  • Enterprise Sales Assistant.

Each instance can have its own agent identity while being created from the same blueprint. This allows the organization to manage the agents individually while also applying consistent controls to all agents created from that blueprint.


Agent identity blueprint

An agent identity blueprint is the parent definition from which agent identities are created.

A blueprint can establish common characteristics and permissions for agents of a particular type or purpose. It provides a way to apply consistent security controls across multiple agent identities.

For example, a company might create a blueprint named Customer Support Assistant. Multiple agents can be created from that blueprint for different departments or regions.

Blueprints help administrators:

  • Identify related agents.
  • View linked agent identities.
  • Manage common permissions.
  • Configure inheritable permissions.
  • Manage blueprint owners and sponsors.
  • Review audit and sign-in activity.
  • Disable the blueprint.
  • Prevent new agents from being created from a blueprint.

When a blueprint is disabled, existing agent identities created from that blueprint can also be prevented from authenticating.

Blueprint versus agent identity

ConceptDescription
Agent identity blueprintParent definition used to create and authorize agent identities
Agent identityIndividual identity representing a deployed AI agent
Blueprint permissionsPermissions that can be inherited by agents created from the blueprint
Agent-specific accessAccess assigned directly to an individual agent, such as through an access package
Blueprint ownerPerson responsible for technical administration
Agent sponsorPerson accountable for the agent’s business purpose and lifecycle

A blueprint is useful when many agents require a consistent baseline. However, organizations should still evaluate whether each individual agent needs additional permissions.


Agent user account

Some agent scenarios require an identity that can interact with services expecting a user identity. Microsoft Entra Agent ID supports an agent user account for these scenarios.

An agent user account can bridge the gap between an AI agent and services that require user-like capabilities. It is different from the agent identity itself and should be governed with appropriate security boundaries.

The key exam distinction is that an organization may encounter several related identity concepts:

  • Agent identity.
  • Agent identity blueprint.
  • Agent user account.
  • Agent service principal.
  • Human user identity.

Do not assume that every agent uses the same identity model. The appropriate identity depends on how the agent authenticates, whether it acts autonomously, and whether it acts on behalf of a user.


Viewing and Managing Agent Identities

Administrators can view agent identities in the Microsoft Entra admin center.

The general navigation is:

Microsoft Entra admin center → Entra ID → Agents → Agent identities

The agent identity list can be searched, filtered, sorted, and customized. Administrators can search by:

  • Agent name.
  • Object ID.
  • Blueprint App ID.

The details for an agent identity can include:

  • Name and description.
  • Status.
  • Parent blueprint.
  • Owners and sponsors.
  • Granted permissions.
  • Microsoft Entra roles.
  • Audit logs.
  • Sign-in logs.
  • Whether the agent uses an agent identity object or a service principal.

Viewing agent identities does not necessarily require an administrative role. Managing them generally requires the Agent ID Administrator or Cloud Application Administrator role. An agent identity owner may also manage their own agent without holding one of those administrative roles.

Important administrative roles

TaskTypical role or responsibility
View agent identitiesMicrosoft Entra user account
Manage agent identitiesAgent ID Administrator or Cloud Application Administrator
Create agent blueprintsAgent ID Developer
Configure Conditional AccessConditional Access Administrator
View Identity Protection risk reportsSecurity Administrator, Security Operator, or Security Reader
Manage lifecycle workflowsLifecycle Workflows Administrator
Manage an owned or sponsored agentAgent owner or sponsor

The exact capabilities available depend on the operation, licensing, and whether the feature is in preview.


Understanding Agent Access

Agent access should be evaluated from several perspectives.

1. Authentication

Authentication establishes the identity of the agent or the user on whose behalf the agent is acting.

Questions to consider include:

  • How does the agent obtain tokens?
  • Is the agent autonomous?
  • Does it act on behalf of a signed-in user?
  • Which authentication protocol is used?
  • Is the identity associated with the correct blueprint?
  • Are sign-in events being logged?

Authentication alone does not determine what the agent is allowed to do. Authorization and policy controls are also required.

2. Authorization

Authorization determines which resources and operations the agent can access.

Examples include:

  • Microsoft Graph permissions.
  • Application API permissions.
  • Delegated permissions.
  • Microsoft Entra roles.
  • Security group membership.
  • Access to business applications.
  • Access to storage, databases, or repositories.

An agent should not receive broad permissions simply because it might need them in the future. Permissions should be limited to the agent’s documented business purpose.

3. Resource access

An agent may have access through:

  • Permissions inherited from its blueprint.
  • Direct permissions assigned to the agent.
  • Access packages.
  • Group memberships.
  • Application roles.
  • Microsoft Entra roles.
  • User-delegated access.
  • Access to connected tools or APIs.

A complete access review must consider all of these paths. Reviewing only the agent’s direct permissions may miss access inherited from a group, blueprint, or delegated user context.


Inheritable Permissions

Agent identity blueprints can be configured with inheritable permissions.

Inheritable permissions provide a consistent permission baseline for agents created from a particular blueprint. This is useful when all agents of a specific type need access to the same application or API.

For example, all agents created from a finance-assistant blueprint might need read access to a financial reporting API.

However, inheritable permissions must be designed carefully. If excessive permissions are assigned to a blueprint, every agent created from it may inherit unnecessary access.

Recommended approach

  1. Define the agent’s business purpose.
  2. Identify the minimum required resources.
  3. Assign the narrowest available permissions.
  4. Avoid inheriting high-privilege permissions unless required.
  5. Review the permissions assigned to the blueprint.
  6. Review the permissions of each linked agent.
  7. Remove permissions that are no longer needed.

Microsoft documentation identifies limits for blueprint access configuration, including a maximum number of resource applications and enumerated scopes per resource application. Some high-privilege scopes may be blocked by platform policy and cannot be inherited.


Access Packages for Agent Identities

Microsoft Entra entitlement management can be used to govern agent access through access packages.

Access packages provide a policy-based way to assign access to resources. For agent identities, an access package can include:

  • Security group memberships.
  • Application OAuth API permissions.
  • Microsoft Graph application permissions.
  • Microsoft Entra roles.

Access packages can help organizations control:

  • Who can request access for an agent.
  • Which resources can be assigned.
  • Whether approval is required.
  • How long access remains active.
  • Whether access must be reviewed.
  • When access should expire.

An access package assignment policy can be configured for users, service principals, and agent identities in the directory. The policy can target all agents or a more specific set of identities.

Why access packages are useful

Access packages are especially valuable when an agent requires temporary or controlled access to sensitive resources.

For example, an analytics agent may need access to a restricted data source for a limited project. Instead of granting permanent broad access, the organization can:

  • Create an access package.
  • Define the required resource permissions.
  • Require approval from the agent owner or sponsor.
  • Set an expiration date.
  • Review the assignment periodically.
  • Remove access when the project ends.

This supports the principle of just enough access for just enough time.


Owners and Sponsors

Agent owners and sponsors provide accountability.

Owners

Owners are generally responsible for technical administration. They may manage:

  • Agent configuration.
  • Operational status.
  • Technical access.
  • Agent-related administration.
  • Enabling or disabling the agent.

Sponsors

Sponsors are accountable for the agent’s business purpose and lifecycle. They should help determine:

  • Why the agent exists.
  • Who is responsible for its use.
  • Whether the agent is still needed.
  • Whether its permissions remain appropriate.
  • Whether it should be retired.
  • Who should replace the sponsor if the sponsor leaves.

An agent without an accountable owner or sponsor can become an unmanaged identity with persistent access.

Organizations should establish requirements for:

  • At least one responsible owner.
  • A business sponsor.
  • Periodic access reviews.
  • Sponsor reassignment.
  • Retirement of unused agents.
  • Documentation of the agent’s purpose and data access.

Owners and sponsors can manage agents they own or sponsor through the Microsoft Entra end-user experience. They may be able to enable or disable agents and request access packages on behalf of those agents.


Conditional Access for Agent Identities

Conditional Access controls the conditions under which an agent identity can access resources.

Conditional Access policies can be used to:

  • Block all agent identities.
  • Allow only selected agents.
  • Target specific agent identities.
  • Target agent identities associated with a blueprint.
  • Block agents based on risk.
  • Apply policies to all resources.
  • Use report-only mode before enforcement.

For example, an organization could create a policy that blocks agent identities with a high agent risk level.

Conditional Access enforcement applies when an agent identity or an agent user account requests a token for a resource. It does not apply when an agent identity blueprint acquires a token to create agent identities or agent user accounts.

Report-only mode

Report-only mode allows administrators to evaluate the potential effect of a policy before enforcing it.

This is useful because a broad policy blocking all agents could disrupt:

  • Business workflows.
  • Copilot experiences.
  • Automated processes.
  • Applications that depend on agent access.
  • Agents that have not yet been migrated to the correct identity model.

A recommended deployment process is:

  1. Create the Conditional Access policy.
  2. Configure it in report-only mode.
  3. Review sign-in and policy impact.
  4. Identify agents that would be blocked.
  5. Correct unintended dependencies.
  6. Enable enforcement.
  7. Monitor the results.

Identity Protection for Agents

Microsoft Entra ID Protection can detect anomalous behavior involving agent identities.

Examples of risk signals include:

  • Unfamiliar resource access.
  • Unusual sign-in spikes.
  • Failed access attempts.
  • Other abnormal authentication or access patterns.

Administrators can review the Risky Agents report and take actions such as:

  • Confirm compromise.
  • Confirm safe.
  • Dismiss the risk.
  • Disable the agent.

When an agent is confirmed as compromised, its risk level is set to High. If a Conditional Access policy is configured to block agents with high agent risk, the agent can be blocked from accessing resources.

Important distinction

Identity Protection detects risk. Conditional Access enforces access decisions.

CapabilityPrimary purpose
Identity Protection for agentsDetect anomalous or risky agent behavior
Conditional AccessEnforce access conditions based on identity, context, and risk
Agent administrationEnable, disable, and manage agent identities
Access packagesGovern assignment and duration of resource access
Defender XDRDiscover, investigate, and assess security risks and attack paths

Do not confuse an agent being marked as risky with the agent automatically being disabled. Automatic blocking depends on the policies configured by the organization.


Disabling Agent Identities

An organization can disable access at several levels.

Individual agent

Disabling an individual agent:

  • Prevents it from accessing resources.
  • Prevents it from being issued tokens.
  • Stops the specific agent without necessarily affecting other agents.

Blueprint level

Disabling a blueprint can:

  • Prevent new agent identities from being created from that blueprint.
  • Block existing agents associated with the blueprint from authenticating.

Tenant-wide

Conditional Access can be used to block all agent identity authentication. Organizations may also use product-specific controls to prevent the creation of new agent identities.

Tenant-wide blocking should be used carefully because it can:

  • Break existing agent workflows.
  • Degrade Microsoft product experiences.
  • Cause applications to fail.
  • Encourage teams to use less visible service-principal or application identities.

A more targeted approach is generally preferable when only a subset of agents is risky.


Monitoring Agent Activity

Agent activity should be monitored throughout the identity lifecycle.

Useful sources of information include:

  • Sign-in logs.
  • Audit logs.
  • Permission assignments.
  • Blueprint configuration.
  • Owners and sponsors.
  • Access package assignments.
  • Conditional Access results.
  • Identity Protection risk reports.
  • Security alerts.
  • Agent runtime activity.

Monitoring can help answer:

  • Is the agent authenticating as expected?
  • Is it accessing resources outside its normal purpose?
  • Are permissions being changed?
  • Has the agent been disabled or re-enabled?
  • Is the agent experiencing unusual sign-in behavior?
  • Is the agent using a deprecated or unnecessary permission?
  • Is the agent still owned and sponsored?

All agent authentication and activity should be logged and reviewed according to the organization’s security, privacy, and compliance requirements.


Managing Access for Autonomous and On-Behalf-of Agents

Not all agents operate in the same way.

Autonomous agents

An autonomous agent acts independently using its own agent identity and permissions.

Examples include:

  • A monitoring agent that investigates alerts.
  • A scheduled reporting agent.
  • An automation agent that updates records.
  • A data-processing agent that runs without a user being present.

For autonomous agents, the organization must carefully control the permissions assigned directly to the agent identity.

On-behalf-of-user agents

An on-behalf-of-user agent acts using the context or permissions of a signed-in user.

Examples include:

  • An assistant that searches a user’s files.
  • An agent that creates calendar events for a user.
  • An agent that retrieves information the user is already authorized to access.

On-behalf-of scenarios require careful consideration of delegated permissions and user context. The agent should not become a way to bypass the user’s permissions.

Exam consideration

When evaluating an agent’s access, determine whether it:

  • Uses its own application permissions.
  • Uses delegated permissions.
  • Acts autonomously.
  • Acts on behalf of a user.
  • Uses an agent user account.
  • Inherits permissions from a blueprint.

The identity model affects how access should be assigned and controlled.


Recommended Least-Privilege Strategy

A secure Entra Agent ID implementation should follow these practices.

Use separate identities for separate purposes

Do not use one highly privileged agent identity for unrelated workloads.

For example, separate:

  • Customer support.
  • Financial reporting.
  • Human resources.
  • Production operations.
  • Security investigation.

This limits the impact if one agent is compromised.

Minimize permissions

Grant only the permissions required for the agent’s documented tasks.

Prefer:

  • Read-only access where possible.
  • Narrow API scopes.
  • Specific application roles.
  • Restricted resource groups.
  • Limited group memberships.
  • Time-bound access packages.

Avoid:

  • Broad directory roles.
  • Unnecessary Microsoft Graph permissions.
  • Permanent access to production systems.
  • Shared identities across unrelated agents.
  • Excessive delegated permissions.

Separate read and write capabilities

If an agent only needs to retrieve information, do not grant it write, delete, or administrative permissions.

For example:

  • A reporting agent should read data but not modify it.
  • A knowledge agent should retrieve documents but not change permissions.
  • A support agent may create tickets but should not delete customer accounts.

Require approval for sensitive operations

High-impact operations should require additional controls, such as:

  • Human approval.
  • Restricted API endpoints.
  • Separate privileged workflows.
  • Explicit access packages.
  • Just-in-time access.
  • Transaction limits.

Review inherited permissions

Review both:

  • Permissions inherited from the blueprint.
  • Permissions assigned directly to the agent.

A blueprint change can affect many linked agents, so blueprint permissions should be treated as a high-impact administrative control.

Maintain ownership and sponsorship

Every production agent should have:

  • A technical owner.
  • A business sponsor.
  • A documented purpose.
  • A defined data classification.
  • A review schedule.
  • A retirement process.

Use report-only policies before enforcement

Conditional Access and other broad controls should be tested in report-only mode where supported.

Disable unused agents

An agent that is no longer needed should be disabled or retired. Unused identities can retain access and become attractive targets.


Example Scenario

A company deploys a customer-service agent that can:

  • Read customer records.
  • Search SharePoint knowledge bases.
  • Read Microsoft Graph mail.
  • Update the CRM.
  • Access an Azure DevOps repository.
  • Call a production API.

The agent was initially configured with broad permissions to simplify development.

A security review identifies several concerns:

  • The agent has access to data unrelated to customer support.
  • It can modify production records.
  • It can read confidential email.
  • It has access to source code.
  • Its blueprint grants permissions inherited by multiple agents.
  • No formal sponsor has been assigned.

A secure remediation plan would include:

  1. Create a clearly defined business purpose.
  2. Assign a technical owner and business sponsor.
  3. Remove access to email and source code unless explicitly required.
  4. Replace broad CRM permissions with narrowly scoped roles.
  5. Separate read-only operations from write operations.
  6. Restrict production API access.
  7. Use an access package for temporary elevated access.
  8. Apply Conditional Access policies.
  9. Monitor sign-ins and risk signals.
  10. Disable the agent if compromise is suspected.
  11. Review all agents created from the same blueprint.
  12. Reassess permissions after remediation.

The goal is not merely to secure the agent’s authentication. It is to reduce the consequences of compromise by limiting the agent’s reachable resources and available actions.


Common Exam Distinctions

Entra Agent ID versus Microsoft Agent 365

Microsoft Entra Agent ID provides the identity and access foundation for agents.

Microsoft Agent 365 provides an enterprise control plane for managing and governing agents at scale, using Entra Agent ID as its identity foundation.

Agent identity versus blueprint

An agent identity represents an individual agent.

A blueprint is the parent definition from which agent identities are created and may inherit common permissions.

Access packages versus Conditional Access

Access packages govern which resources an agent can be assigned.

Conditional Access governs under what conditions the agent can access those resources.

Identity Protection versus Conditional Access

Identity Protection detects risk.

Conditional Access can use risk signals to enforce access decisions.

Disabling an agent versus removing a permission

Disabling an agent blocks its operation and token issuance.

Removing a permission reduces what the agent can access but does not necessarily stop the agent from operating.

Autonomous versus delegated access

An autonomous agent uses its own identity and permissions.

A delegated or on-behalf-of agent operates in the context of a user and must not exceed the user’s authorized access.


Exam Tips

Remember the following points:

  • Treat AI agents as identities that require lifecycle management.
  • Use agent identity blueprints for consistent management and permissions.
  • Review both inherited and direct permissions.
  • Use access packages to govern resource assignments.
  • Use Conditional Access to control access conditions.
  • Use Identity Protection to detect risky agent behavior.
  • A risky agent is not necessarily automatically disabled.
  • Owners provide technical accountability.
  • Sponsors provide business and lifecycle accountability.
  • Report-only mode helps test Conditional Access policies.
  • Disabling a blueprint can affect existing agents created from it.
  • Tenant-wide blocking can disrupt legitimate agent workflows.
  • Least privilege is especially important because agents may invoke tools and act autonomously.
  • Always determine whether the agent acts autonomously or on behalf of a user.

Practice Exam Questions

Question 1

A security administrator wants to give each deployed AI agent a distinct identity that can be managed, monitored, and disabled independently. Which capability should the administrator use?

A. Azure resource locks
B. Azure Policy initiatives
C. Microsoft Defender for Storage
D. Microsoft Entra agent identities

Answer: D

Explanation: Microsoft Entra agent identities provide specialized identities for individual AI agents. They can be assigned permissions, monitored, associated with owners and sponsors, and disabled independently.


Question 2

An organization has 50 agents created for the same business function. The security team wants to apply common permissions and manage the agents consistently. What should the team use?

A. A separate Conditional Access policy for every user
B. A shared human administrator account
C. A single Azure subscription
D. An agent identity blueprint

Answer: D

Explanation: An agent identity blueprint is the parent definition from which agent identities are created. It supports consistent configuration, permission management, and administration across linked agents.


Question 3

An agent needs temporary access to a sensitive application for a specific project. The organization wants approval, expiration, and periodic review of that access. Which capability is most appropriate?

A. Microsoft Entra access packages
B. Azure resource locks
C. Microsoft Defender Antivirus
D. Azure DDoS Protection

Answer: A

Explanation: Access packages can govern resource access for agent identities and can include approval policies, expiration, and access reviews.


Question 4

A company wants to block agent identities that Microsoft Entra ID Protection identifies as having high risk. Which control should enforce this requirement?

A. Azure Policy
B. Microsoft Defender for Storage
C. Conditional Access
D. Azure Bastion

Answer: C

Explanation: Identity Protection detects agent risk, while Conditional Access can enforce a policy that blocks agents with a high agent risk level.


Question 5

Which responsibility is most closely associated with an agent sponsor?

A. Writing the agent’s application code
B. Managing the Azure virtual network
C. Creating all Microsoft Graph permissions
D. Providing business accountability and lifecycle oversight

Answer: D

Explanation: Sponsors are accountable for the agent’s business purpose and lifecycle. They help determine whether the agent is still needed and whether its access remains appropriate.


Question 6

An administrator wants to evaluate the effect of a Conditional Access policy before blocking agent identities. What should the administrator do?

A. Disable all agent blueprints
B. Configure the policy in report-only mode
C. Delete the agent identities
D. Remove all delegated permissions

Answer: B

Explanation: Report-only mode allows administrators to evaluate policy impact and identify unintended effects before enforcing the policy.


Question 7

An agent has permissions inherited from its blueprint and additional permissions assigned directly to the agent. During an access review, what should the administrator evaluate?

A. Only the direct permissions
B. Only the blueprint permissions
C. Both inherited and direct permissions
D. Only the agent’s display name

Answer: C

Explanation: An agent’s effective access can come from multiple sources. Reviewing both blueprint-inherited permissions and direct assignments is necessary to determine the agent’s complete access.


Question 8

A security team confirms that an agent identity has been compromised. Which action immediately prevents that specific agent from being issued tokens?

A. Disable the agent identity
B. Rename the agent
C. Change the agent’s description
D. Add another owner

Answer: A

Explanation: Disabling an individual agent identity blocks access and prevents the identity from being issued tokens. Adding owners or changing descriptive information does not stop the agent.


Question 9

Which statement best describes the difference between an autonomous agent and an on-behalf-of-user agent?

A. An autonomous agent cannot access any resources
B. An autonomous agent uses its own identity and permissions, while an on-behalf-of-user agent operates in a user context
C. An on-behalf-of-user agent must always have a Microsoft Entra administrator role
D. An autonomous agent does not require authentication

Answer: B

Explanation: Autonomous agents operate using their own identity and permissions. On-behalf-of-user agents operate using the context or permissions of a signed-in user.


Question 10

An organization disables an agent identity blueprint. What is the most likely security effect?

A. Only the blueprint’s display name changes
B. All human users are disabled
C. All Azure subscriptions are locked
D. Existing agents associated with the blueprint can be prevented from authenticating, and new agents cannot be created from it

Answer: D

Explanation: Disabling a blueprint can prevent new agent identities from being created from it and can block existing agents associated with the blueprint from authenticating.


Go to the SC-500 Exam Prep Hub main page

Manage custom roles, including Azure roles and Microsoft Entra roles (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Implement governance to enforce security and regulatory compliance
      --> Manage custom roles, including Azure roles and Microsoft Entra roles


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Role-based access control (RBAC) is a fundamental component of cloud security. Rather than granting users unrestricted administrative privileges, RBAC allows an organization to assign only the permissions required to perform a particular job.

Azure and Microsoft Entra ID both support custom roles, but they are used for different purposes.

The distinction is critical for the SC-500 exam:

Azure custom roles control access to Azure resources.

Microsoft Entra custom roles control administrative access to Microsoft Entra resources and capabilities.

Although both systems use concepts such as role definitions, permissions, and role assignments, their permission models and scopes are different. Azure role permissions cannot simply be used in Microsoft Entra custom roles, and Microsoft Entra role permissions cannot be used in Azure custom roles.


1. What Is a Custom Role?

A custom role is a role that an organization creates when the available built-in roles do not provide the appropriate permissions.

The goal is normally to achieve least privilege.

For example, suppose an administrator needs to:

  • View storage accounts
  • Start and stop virtual machines
  • Read certain networking configurations

but should not be able to:

  • Delete resources
  • Assign RBAC roles
  • Modify unrelated resource types

A broad built-in role such as Owner or Contributor might provide excessive permissions.

A custom role can be created containing only the required permissions.

General principle

Use a built-in role when it appropriately meets the requirement. Use a custom role when the built-in roles cannot provide the required permissions with appropriate precision.

This avoids unnecessary custom-role proliferation and reduces administrative complexity.


2. Two Different Custom-Role Systems

For SC-500, keep these two systems clearly separated:

Azure custom roleMicrosoft Entra custom role
Primary purposeManage Azure resourcesManage Microsoft Entra resources
Authorization systemAzure RBACMicrosoft Entra RBAC
Examples of resourcesVMs, storage, networking, databasesUsers, groups, applications, enterprise applications
Permission modelAzure resource-provider operationsMicrosoft Entra resource actions
Assignment scopesAzure management-group, subscription, resource-group/resource scopesDirectory or supported resource-specific scopes
Created/managed throughAzure portal, CLI, PowerShell, REST APIMicrosoft Entra admin center, Microsoft Graph PowerShell/API
Can permissions be mixed?NoNo

The two systems are conceptually similar but technically separate.


3. Azure Custom Roles

Azure custom roles are part of Azure role-based access control (Azure RBAC).

They are used to manage access to Azure resources.

Examples include permissions involving:

  • Virtual machines
  • Storage accounts
  • Azure SQL
  • Virtual networks
  • Key Vault
  • Azure Kubernetes Service
  • Azure Container Registry
  • Other Azure resources

An Azure custom role is a collection of Azure resource permissions.

For example, a custom role might allow a support team to:

  • Read virtual machines
  • Restart virtual machines
  • Read diagnostics

while excluding:

  • Delete virtual machines
  • Modify networking
  • Assign RBAC roles

4. Azure Custom Role Definitions

An Azure role definition describes the permissions available in a role.

A custom role definition can contain properties such as:

  • Name
  • Description
  • Permissions
  • Assignable scopes
  • Role ID

The permissions section can include:

  • Actions
  • NotActions
  • DataActions
  • NotDataActions

These concepts are important for understanding how Azure custom roles are constructed.


5. Actions

Actions specify the Azure control-plane operations that the role can perform.

For example, a custom role might contain permissions that allow the principal to perform operations involving:

  • Reading resources
  • Creating resources
  • Updating resources
  • Deleting resources

The exact permissions are represented using Azure resource-provider operation names.

A permission might look conceptually like:

Microsoft.Compute/virtualMachines/read

This represents a control-plane operation involving virtual machines.


6. NotActions

NotActions specifies control-plane operations that are excluded from the permissions represented by Actions.

For example, a role could broadly allow a set of operations while excluding a particular operation.

However, be careful when interpreting NotActions.

It does not mean:

“Explicitly deny this operation under all circumstances.”

Instead, NotActions subtracts operations from the permissions granted through Actions in that role definition.

A principal might still obtain the excluded permission through another role assignment.

Exam concept

Azure RBAC permissions are additive across role assignments.

Therefore, creating a custom role with NotActions does not guarantee that the principal can never perform the excluded operation.


7. DataActions and NotDataActions

Azure also distinguishes between management-plane operations and operations against data.

DataActions

Specify data-plane operations that the role can perform.

Examples include permissions to:

  • Read blob data
  • Write blob data
  • Read other supported service data

NotDataActions

Exclude specified data-plane operations from the permissions granted through DataActions.

This distinction is especially important for Azure Storage.

For example:

A role that can manage a storage account does not automatically mean that the principal has permission to read the blobs stored in the account.

The custom role may need appropriate data-plane permissions.


8. Example Azure Custom Role

Imagine a help-desk team needs to support Azure virtual machines.

Requirements:

  • View VMs
  • Restart VMs
  • Start VMs
  • Stop VMs
  • Cannot delete VMs
  • Cannot modify networking
  • Cannot assign RBAC roles

A broad Contributor role could provide more permissions than necessary.

Instead, a custom role could be created containing only the required VM operations.

Conceptually:

Support VM Operator

Permissions:

  • VM read
  • VM start
  • VM stop
  • VM restart

Excluded:

  • VM delete
  • RBAC role assignment
  • unrelated resource-management operations

This is a classic least-privilege scenario.


9. Azure Custom Role AssignableScopes

One of the most important properties of an Azure custom role is:

AssignableScopes

This specifies where the custom role definition can be assigned.

A custom role can have assignable scopes at:

  • Management group
  • Subscription
  • Resource group

The role can subsequently be assigned at an appropriate narrower scope within those boundaries, including a resource scope where supported.

For example, a custom role could have:

/subscriptions/00000000-0000-0000-0000-000000000000

as an assignable scope.

The role would then be available for assignment within that subscription and its child scopes.


10. AssignableScopes vs. Assignment Scope

This is an important exam distinction.

AssignableScopes

Determines where the custom role definition is available to be assigned.

Role-assignment scope

Determines where the permissions actually apply to the principal.

For example:

A custom role might have an assignable scope of:

Subscription A

But the role could be assigned to a user at:

Resource Group A

The custom role is available within Subscription A, while the user’s actual permissions apply only to Resource Group A.

Exam rule

AssignableScopes limits where a custom role can be assigned; the role assignment’s scope determines where the assigned permissions apply.


11. Azure Custom Roles and Least Privilege

Custom roles can provide more precise access than broad built-in roles.

Consider three options:

Option 1 — Owner

Very broad permissions, including role assignment.

Option 2 — Contributor

Broad resource-management permissions but no RBAC role-assignment capability.

Option 3 — Custom role

Only the operations required for the user’s job.

If Option 3 satisfies the business requirement, it can provide a stronger least-privilege design.

However, custom roles should not be created simply because customization is possible.

Before creating one:

  1. Identify the exact required operations.
  2. Review existing built-in roles.
  3. Determine whether an existing built-in role is sufficient.
  4. Create a custom role only if necessary.
  5. Limit its permissions.
  6. Limit its assignable scopes.
  7. Assign it at the narrowest practical scope.

12. Who Can Create an Azure Custom Role?

Creating or updating an Azure custom role requires appropriate authorization.

The key Azure permission is:

Microsoft.Authorization/roleDefinitions/write

Among the standard built-in roles, Owner and User Access Administrator include this permission.

This is different from simply assigning an existing role.

Important distinction

A person may have permission to assign an existing role without necessarily having permission to create or modify role definitions.

This distinction can appear in SC-500 scenario questions.


13. Managing Azure Custom Roles

Azure custom roles can be created and managed using:

  • Azure portal
  • Azure CLI
  • Azure PowerShell
  • Azure REST API

For example, administrators can create a custom role through the Azure portal by defining:

  • Role name
  • Description
  • Permissions
  • Assignable scopes

Custom roles are stored in the Microsoft Entra directory associated with the Azure environment and can be shared across subscriptions that trust the same directory.


14. Azure Custom Role Limits

Custom roles should be managed carefully.

Azure supports a maximum of 5,000 custom roles per Microsoft Entra tenant under the standard Azure limit.

This is another reason to avoid creating unnecessary custom roles.

A poorly governed environment could end up with:

  • Duplicate roles
  • Nearly identical roles
  • Roles that are no longer needed
  • Roles containing excessive permissions

A good role-governance process should include periodic review and cleanup.


15. Microsoft Entra Custom Roles

Microsoft Entra ID has its own RBAC system.

Microsoft Entra custom roles are used to provide customized administrative permissions for Microsoft Entra resources and capabilities.

Examples of areas that can be managed through supported Microsoft Entra permissions include:

  • Users
  • Groups
  • Applications
  • Enterprise applications
  • Devices
  • Consent-related operations

Microsoft Entra custom roles are created from a predefined set of permissions that are enabled for custom use.


16. Microsoft Entra Custom Role Permissions

Microsoft Entra custom roles use permissions expressed as Microsoft Entra resource actions.

For example, a custom role could contain permissions such as:

microsoft.directory/applications/basic/update

or:

microsoft.directory/applications/credentials/update

These permissions are different from Azure resource-provider permissions.

Critical exam distinction

Do not confuse:

Microsoft.Compute/...

with:

microsoft.directory/...

The first represents Azure resource-management permissions.

The second represents Microsoft Entra directory permissions.


17. Microsoft Entra Custom Roles Use a Defined Permission Set

You cannot simply create an arbitrary Microsoft Entra permission.

Microsoft Entra custom roles can include permissions that Microsoft makes available for custom use.

This provides granular control while keeping the permission model within supported Microsoft Entra capabilities.

For example, an organization could create a custom role allowing an application-support team to modify selected application properties without granting them broad application-administrator privileges.


18. Example: Microsoft Entra Custom Role

Suppose an organization has an application support team.

The team needs to:

  • Read application registrations
  • Update basic application properties
  • Update application credentials

The team should not receive broad directory administration privileges.

A custom Microsoft Entra role could be created containing only the required application-management permissions.

This is a classic least-privilege scenario.


19. Microsoft Entra Custom Role Scopes

Microsoft Entra custom roles use scopes that differ from Azure RBAC scopes.

Microsoft Entra custom roles can be assigned at:

  • Directory level
  • Supported app-registration resource scope

The exact scope options depend on the Microsoft Entra resource and permission being managed.

Exam warning

Do not automatically apply the Azure RBAC hierarchy:

Management group → subscription → resource group → resource

to Microsoft Entra custom roles.

That hierarchy belongs to Azure resource authorization.


20. Creating Microsoft Entra Custom Roles

Microsoft Entra custom roles can be created using:

  • Microsoft Entra admin center
  • Microsoft Graph PowerShell
  • Microsoft Graph API

In the Microsoft Entra admin center, administrators can navigate to:

Microsoft Entra ID → Roles & admins → New custom role

They then specify:

  • Role name
  • Description
  • Permissions

and create the role.

The role can subsequently be assigned to appropriate users or groups.


21. Microsoft Entra Custom Role Prerequisites

Creating Microsoft Entra custom roles requires appropriate privileged administration permissions.

The current prerequisites include:

  • Microsoft Entra ID P1 or P2
  • Privileged Role Administrator

when creating the role through the documented administrative interfaces.

This is an important distinction from Azure custom-role creation.

Remember

Azure custom role creation

→ Azure authorization permissions such as Microsoft.Authorization/roleDefinitions/write

Microsoft Entra custom role creation

→ Appropriate Microsoft Entra administrative permissions, such as Privileged Role Administrator


22. Microsoft Entra Custom Roles Cannot Use Azure Permissions

Suppose an administrator wants to create a Microsoft Entra custom role.

They cannot add an Azure resource-provider permission such as:

Microsoft.Compute/virtualMachines/read

to the Microsoft Entra custom role.

Likewise, an Azure custom role cannot use a Microsoft Entra permission such as:

microsoft.directory/applications/basic/update

The permission models are separate.

Exam rule

Azure RBAC permissions belong to Azure RBAC roles. Microsoft Entra permissions belong to Microsoft Entra roles.


23. Azure Roles vs. Microsoft Entra Roles

This distinction deserves special attention.

Azure role

Controls access to Azure resources.

Examples:

  • Virtual machines
  • Storage accounts
  • Virtual networks
  • Azure SQL
  • Key Vault

Azure roles are implemented through Azure RBAC.

Microsoft Entra role

Controls administrative access to Microsoft Entra functionality and resources.

Examples:

  • Users
  • Groups
  • Applications
  • Enterprise applications
  • Directory configuration

Microsoft Entra roles are implemented through Microsoft Entra RBAC.

They are separate authorization systems.


24. Application Roles Are Yet Another Concept

SC-500 questions can become confusing because there is another RBAC concept:

Application roles

Application roles are defined by an application and can be used to authorize users or applications within that application.

They are not the same as:

  • Azure RBAC roles
  • Microsoft Entra administrative roles

Therefore:

Application RBAC ≠ Azure RBAC ≠ Microsoft Entra RBAC

Microsoft explicitly distinguishes application-specific RBAC from Azure RBAC and Microsoft Entra RBAC.


25. Role Definition vs. Role Assignment

This concept applies to both Azure RBAC and Microsoft Entra RBAC, although the implementations differ.

Role definition

Defines:

What permissions does the role contain?

Role assignment

Defines:

Who receives the role and at what supported scope?

For Azure RBAC:

Principal + Azure role definition + scope = role assignment

For Microsoft Entra RBAC, a role definition containing Microsoft Entra permissions is assigned to a principal at an applicable directory/resource scope.


26. Assign Custom Roles to Groups When Practical

Custom roles can be assigned to appropriate security principals.

Depending on the authorization system and supported scenario, this can include:

  • Users
  • Groups
  • Service principals
  • Managed identities

For organizational administration, assigning permissions to groups is often preferable to individually assigning the same role to many users.

For example:

Application Support Team

→ Custom Microsoft Entra Application Support role

This simplifies:

  • Access management
  • Auditing
  • Access reviews
  • User onboarding
  • User offboarding

27. Combining Multiple Roles

A user can receive multiple role assignments.

Azure RBAC permissions are effectively additive.

For example, suppose a user has:

Custom VM Operator

and:

Reader

The user’s effective permissions can include permissions from both assignments.

This has an important security consequence.

Creating a custom role with fewer permissions does not necessarily restrict a user if that user already has another role that provides broader permissions.

Example

A custom role excludes:

Microsoft.Compute/virtualMachines/delete

But the same user also has Contributor.

The user could still have VM deletion capability through Contributor.

Exam lesson

Evaluate effective permissions, not just one role definition.


28. Don’t Use NotActions as a Security Deny

This is a common conceptual trap.

Suppose a custom role contains:

Actions: *

and:

NotActions: Microsoft.Compute/virtualMachines/delete

It may appear that the user is explicitly denied the ability to delete VMs.

That’s not necessarily true.

NotActions only removes that operation from the permissions granted by that role definition.

If another role assignment grants VM deletion, the user may still delete VMs.

For an actual deny mechanism, Azure has separate authorization concepts such as deny assignments in supported scenarios.

Exam takeaway

NotActions is not the same as an explicit deny rule.


29. Custom Roles and Least Privilege

The purpose of a custom role should be to make access more precise, not simply to reproduce an overly powerful built-in role under a different name.

A good custom role should:

  • Include only necessary permissions.
  • Avoid unnecessary wildcards.
  • Use narrow assignable scopes where appropriate.
  • Be assigned at the narrowest practical scope.
  • Be assigned only to appropriate principals.
  • Be reviewed periodically.
  • Be removed when no longer required.

30. Be Careful with Wildcards

Azure custom roles support wildcard permissions.

For example:

Microsoft.Storage/*

could provide a large collection of storage-related operations.

Similarly:

*

can provide extremely broad permissions.

Wildcards can make custom roles easier to create but can undermine least privilege.

Best practice

Use specific operations when practical rather than granting a broad wildcard.

For example, if an administrator only needs to restart virtual machines, don’t automatically give that administrator every Compute operation.


31. Privileged Custom Roles

A custom role can itself become a highly privileged role.

For example, a custom Azure role that includes:

Microsoft.Authorization/roleAssignments/write

can grant the ability to create Azure RBAC assignments.

Likewise, permissions to create or modify role definitions are privileged capabilities.

Therefore, custom-role designers must evaluate not only the number of permissions but also the sensitivity of those permissions.

A small role containing a highly privileged authorization operation can be more dangerous than a larger role containing ordinary read operations.


32. Custom Roles and Privileged Identity Management

Microsoft Entra Privileged Identity Management (PIM) can be used with supported privileged role assignments to reduce standing administrative access.

Instead of giving an administrator permanent access, an organization can use an eligible assignment and require activation when the administrator needs to perform privileged work.

Possible controls include:

  • Time-limited activation
  • Approval
  • Multifactor authentication
  • Justification
  • Access reviews

This supports a broader security strategy:

Least privilege + just-in-time access + strong authentication


33. A Practical Process for Creating a Custom Azure Role

Use this process:

Step 1 — Identify the business requirement

Determine exactly what the person or workload needs to accomplish.

Step 2 — Identify the resource types

Determine which Azure resources are involved.

Step 3 — Review built-in roles

Check whether an existing built-in role already satisfies the requirement.

Step 4 — Identify exact operations

Determine the required control-plane and, if applicable, data-plane operations.

Step 5 — Build the custom role

Add only the necessary permissions.

Step 6 — Define assignable scopes

Make the role available only where it needs to be used.

Step 7 — Assign the role

Assign it to the appropriate principal at the narrowest practical scope.

Step 8 — Test effective access

Verify that required operations work and unnecessary permissions are not present.

Step 9 — Review periodically

Remove obsolete roles and permissions.


34. A Practical Process for Creating a Microsoft Entra Custom Role

Use a similar but separate process:

Step 1 — Identify the Microsoft Entra administrative task

For example:

Manage selected application-registration properties.

Step 2 — Review built-in Microsoft Entra roles

Determine whether a built-in role is sufficient.

Step 3 — Identify supported custom-use permissions

Select only the required Microsoft Entra resource actions.

Step 4 — Create the custom role

Define the role name, description, and permissions.

Step 5 — Select the appropriate scope

Use a supported directory or resource-specific scope.

Step 6 — Assign the role

Assign it to the appropriate user or group.

Step 7 — Validate effective permissions

Confirm that the administrator can perform the required operations but does not have unnecessary administrative access.


35. Common SC-500 Exam Traps

Trap 1: Azure custom roles manage Microsoft Entra users

False.

Azure custom roles manage Azure resources.

Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities.


Trap 2: Microsoft Entra custom roles can contain Azure permissions

False.

The permission models are separate.


Trap 3: Contributor can create custom Azure roles

Generally false.

Contributor does not include the permission required to create or update Azure role definitions.


Trap 4: Owner is required to assign an existing Azure custom role

Not necessarily.

The relevant requirement is permission to create the role assignment. Roles such as Owner, User Access Administrator, and Role Based Access Control Administrator can provide role-assignment capabilities in appropriate scopes.

Creating the custom role definition itself is a separate privilege.


Trap 5: NotActions explicitly denies an operation

False.

It removes operations from the permissions granted by that particular role definition.

Another role assignment could still grant the operation.


Trap 6: AssignableScopes determines where the permissions apply

Not exactly.

AssignableScopes determines where the custom role is available for assignment.

The role assignment scope determines where the permissions actually apply.


Trap 7: Custom roles automatically provide least privilege

False.

A poorly designed custom role can be overly permissive.

Least privilege depends on the permissions selected, scope, and effective role assignments.


Trap 8: A custom role replaces all built-in roles

False.

Built-in roles should generally be preferred when they appropriately satisfy the requirement.


Trap 9: DataActions are the same as Actions

False.

Actions generally represent control-plane operations, while DataActions represent data-plane operations.


Trap 10: Azure RBAC, Microsoft Entra RBAC, and application RBAC are the same

False.

They are separate authorization models serving different purposes.


36. SC-500 Comparison: Azure vs. Microsoft Entra Custom Roles

CharacteristicAzure Custom RoleMicrosoft Entra Custom Role
Authorization systemAzure RBACMicrosoft Entra RBAC
Primary targetAzure resourcesMicrosoft Entra resources/capabilities
Permission formatAzure resource-provider operationsMicrosoft Entra resource actions
Control-plane/data-plane distinctionYes, including Actions/DataActions where supportedDifferent Microsoft Entra permission model
Typical resourcesVM, Storage, SQL, NetworkUsers, groups, applications, enterprise applications
Azure management-group scopeYesNo
Azure subscription scopeYesNo
Azure resource-group scopeYesNo
Microsoft Entra directory scopeNoYes
App registration resource scopeNoSupported
Creation toolsAzure portal, CLI, PowerShell, RESTEntra admin center, Graph PowerShell, Graph API
Typical creation privilegeAzure authorization permission such as roleDefinitions/writePrivileged Role Administrator
Permissions interchangeable?NoNo

37. Exam Scenario Strategy

When a question asks you to design a custom role, work through these questions:

Question 1: What is being secured?

If it is:

  • VM
  • Storage
  • SQL
  • Network
  • Key Vault

think:

Azure RBAC

If it is:

  • User
  • Group
  • Application
  • Enterprise application
  • Directory administration

think:

Microsoft Entra RBAC


Question 2: Is there already a suitable built-in role?

If yes, use the built-in role unless there is a compelling reason not to.

If no, consider a custom role.


Question 3: What exact permissions are required?

Don’t simply choose broad permissions because they are convenient.


Question 4: What is the narrowest scope?

Use the smallest practical scope.


Question 5: Does the role include privileged authorization permissions?

Be particularly careful with permissions that allow:

  • Assigning roles
  • Creating roles
  • Modifying roles
  • Deleting roles
  • Managing other privileged security controls

38. Key Takeaways

For the SC-500 exam, remember:

  1. Azure custom roles are part of Azure RBAC.
  2. Microsoft Entra custom roles are part of Microsoft Entra RBAC.
  3. The two permission models are separate.
  4. Azure custom roles manage Azure resources.
  5. Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities.
  6. A role definition describes permissions.
  7. A role assignment grants a role to a principal at a scope.
  8. Azure custom roles can contain Actions, NotActions, DataActions, and NotDataActions.
  9. Actions generally represent control-plane operations.
  10. DataActions represent data-plane operations where supported.
  11. NotActions is not an explicit deny mechanism.
  12. Azure custom-role AssignableScopes controls where the role can be assigned.
  13. The role assignment’s scope determines where the assigned permissions apply.
  14. Built-in roles should generally be used when they meet the requirement.
  15. Custom roles are appropriate when built-in roles cannot provide the required level of precision.
  16. Avoid unnecessary wildcard permissions.
  17. Evaluate effective permissions across all role assignments, not just one role.
  18. Privileged role-management permissions require particular caution.
  19. PIM can help reduce standing privileged access.
  20. Azure RBAC ≠ Microsoft Entra RBAC ≠ application RBAC.

Practice Exam Questions

Question 1

An organization needs to create a role that allows support personnel to restart Azure virtual machines but does not allow them to delete VMs or manage networking resources. No existing built-in role provides exactly the required permissions.

What should the security engineer do?

A. Assign Owner at the resource-group scope

B. Create an Azure custom role containing only the required VM permissions

C. Assign Contributor at the VM scope

D. Create a Microsoft Entra custom role

Correct Answer: B. Create an Azure custom role containing only the required VM permissions

Explanation:
The requirement involves Azure virtual machines, so Azure RBAC is the appropriate authorization system. Because the available built-in roles do not provide the required level of precision, an Azure custom role is appropriate. The custom role should contain only the necessary VM operations.


Question 2

An administrator is creating a custom role for Azure resources. The role should be available for assignment within only one subscription.

Which property should the administrator configure?

A. NotActions

B. DataActions

C. AssignableScopes

D. Role assignment name

Correct Answer: C. AssignableScopes

Explanation:
AssignableScopes specifies the scopes where an Azure custom role definition can be assigned. It should not be confused with the scope of an individual role assignment, which determines where the permissions apply to the principal.


Question 3

A user has a custom Azure role containing NotActions that excludes deletion of virtual machines. The user also has the Contributor role at the resource-group scope.

What should the security engineer conclude?

A. The user can never delete virtual machines

B. The custom role overrides Contributor

C. Contributor becomes read-only for the user

D. The user may still be able to delete virtual machines through Contributor

Correct Answer: D. The user may still be able to delete virtual machines through Contributor

Explanation:
NotActions removes an operation from the permissions granted by that particular role definition. It does not create a universal deny. If another role assignment grants the permission, the user can still receive it through that other role.


Question 4

An organization needs to create a custom role that allows an application-support team to update selected properties of Microsoft Entra application registrations. The team should not receive broad directory-administrator permissions.

Which solution should be used?

A. Microsoft Entra custom role

B. Azure Contributor role

C. Azure custom role

D. Azure Owner role

Correct Answer: A. Microsoft Entra custom role

Explanation:
Application registrations are Microsoft Entra resources. A Microsoft Entra custom role can contain the specific supported Microsoft Entra permissions required for the application-support scenario without granting broad directory administration.


Question 5

Which statement correctly distinguishes Azure custom roles from Microsoft Entra custom roles?

A. Azure custom roles manage Microsoft Entra users, while Microsoft Entra custom roles manage virtual machines

B. Azure custom roles and Microsoft Entra custom roles use exactly the same permission model

C. Azure custom roles manage Azure resources, while Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities

D. Microsoft Entra custom roles can contain Azure resource-provider permissions

Correct Answer: C. Azure custom roles manage Azure resources, while Microsoft Entra custom roles manage supported Microsoft Entra resources and administrative capabilities

Explanation:
Azure RBAC and Microsoft Entra RBAC are separate authorization systems. Azure custom roles are used for Azure resources, while Microsoft Entra custom roles are used for supported Microsoft Entra administration scenarios.


Question 6

An Azure custom role needs to allow a service principal to read blob data from a storage account. Which type of permission is relevant to granting access to the actual blob data?

A. NotActions

B. DataActions

C. AssignableScopes

D. RoleDefinitions/write

Correct Answer: B. DataActions

Explanation:
DataActions represent data-plane operations for supported Azure services. Reading blob data is a data-plane operation and therefore requires an appropriate data-access permission rather than merely a management-plane Action.


Question 7

A security engineer wants to create an Azure custom role. Which Azure permission is directly associated with creating or updating an Azure custom role definition?

A. Microsoft.Authorization/roleDefinitions/write

B. Microsoft.Compute/virtualMachines/read

C. Microsoft.Authorization/roleAssignments/read

D. Microsoft.Storage/storageAccounts/read

Correct Answer: A. Microsoft.Authorization/roleDefinitions/write

Explanation:
Microsoft.Authorization/roleDefinitions/write is the authorization permission associated with creating or updating Azure role definitions. This is distinct from assigning an already existing role to a principal.


Question 8

A security administrator needs to create a Microsoft Entra custom role through the Microsoft Entra administrative experience.

Which role is associated with the required administrative privilege for creating the custom role?

A. Global Reader

B. Security Reader

C. Privileged Role Administrator

D. Azure Contributor

Correct Answer: C. Privileged Role Administrator

Explanation:
Creating Microsoft Entra custom roles requires appropriate Microsoft Entra administrative privileges. The documented prerequisite includes the Privileged Role Administrator role, along with the appropriate Microsoft Entra licensing.


Question 9

An Azure administrator creates a custom role with the following design:

  • Read virtual machines
  • Start virtual machines
  • Stop virtual machines
  • Delete virtual machines

The administrator assigns the role to a support group that only needs to start and stop VMs.

What should the security engineer recommend?

A. Keep the role because custom roles should contain broad permissions

B. Replace the role with Owner

C. Add more permissions so the role is easier to reuse

D. Remove the unnecessary delete permission to better follow least privilege

Correct Answer: D. Remove the unnecessary delete permission to better follow least privilege

Explanation:
The group does not need VM deletion capability. A custom role should contain only the permissions required for the business task. Removing unnecessary privileged operations reduces the potential impact of account compromise or misuse.


Question 10

A security engineer is deciding whether to create a custom Azure role or a custom Microsoft Entra role. The requirement is to allow administrators to manage selected users and groups in Microsoft Entra ID.

Which solution is appropriate?

A. Azure custom role

B. Microsoft Entra custom role

C. Azure Storage Blob Data Reader

D. Azure Contributor

Correct Answer: B. Microsoft Entra custom role

Explanation:
The requirement concerns management of Microsoft Entra users and groups rather than Azure resources. Therefore, the appropriate authorization system is Microsoft Entra RBAC, and a Microsoft Entra custom role should be considered if an existing built-in role does not provide the required permissions.


One particularly important distinction to memorize for this section is:

Azure custom role → Azure resources → Azure RBAC

Microsoft Entra custom role → Microsoft Entra resources/administration → Microsoft Entra RBAC

And for Azure custom roles, remember the three concepts that are easy to confuse on the exam: Actions/DataActions define permissions, AssignableScopes controls where the custom role can be assigned, and the role-assignment scope controls where the granted permissions actually apply.


Go to the SC-500 Exam Prep Hub main page

Implement conditional access policies (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement conditional access policies


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Microsoft Entra Conditional Access is a policy-based access-control capability that allows an organization to make access decisions based on contextual information about a sign-in.

Rather than simply asking:

“Is this user allowed to access the resource?”

Conditional Access enables an organization to ask:

“Under what circumstances should this user be allowed to access this resource, and what security requirements must be satisfied?”

Conditional Access policies can evaluate signals such as:

  • User or group
  • Target resource
  • Device platform
  • Client application
  • Network location
  • User risk
  • Sign-in risk
  • Device state
  • Authentication context
  • Other contextual signals

Based on those conditions, a policy can:

  • Allow access
  • Require additional security controls
  • Require stronger authentication
  • Require a compliant device
  • Require an approved client application
  • Apply session restrictions
  • Block access

This makes Conditional Access an important component of a Zero Trust security strategy.


1. The Basic Conditional Access Model

A Conditional Access policy can be understood as:

IF certain conditions are met
THEN apply specified access controls.

For example:

IF a user accesses Microsoft 365 from an unmanaged device
THEN require multifactor authentication.

Another example:

IF a user attempts to access an application from a high-risk sign-in
THEN block access.

A more sophisticated policy might be:

IF a privileged administrator accesses sensitive resources from outside trusted locations
THEN require strong authentication and a compliant device.

The fundamental structure is:

Assignments + Conditions → Access Controls


2. Conditional Access Policy Components

A Conditional Access policy generally contains several major components:

  1. Users and workload identities
  2. Target resources
  3. Conditions
  4. Grant controls
  5. Session controls
  6. Policy state

Understanding these components is essential for the SC-500 exam.


3. Users and Workload Identities

The first question is:

Who should the policy apply to?

Conditional Access can target users and groups.

For example, a policy could apply to:

  • All users
  • Members of a specific group
  • Administrators
  • Guest users
  • External users
  • Specific directory roles

You can also configure exclusions.

For example:

Include all users except members of the Emergency Access Accounts group.

This is extremely important for preventing administrative lockout.

Example

A company wants MFA for all employees.

The policy could be:

Include: All users
Exclude: Emergency access accounts

Grant: Require multifactor authentication


4. Workload Identities

Conditional Access also has capabilities for workload identities, such as service principals.

This is important because user-targeted Conditional Access policies shouldn’t be assumed to protect service principals.

For example:

A service principal authenticates to Azure programmatically.

A Conditional Access policy scoped only to users doesn’t provide the same control over that service principal.

Organizations can instead use Conditional Access for workload identities where applicable.

This is an important exam distinction:

User Conditional Access ≠ workload identity Conditional Access


5. Target Resources

The next question is:

What is being accessed?

Conditional Access policies can target resources such as:

  • Cloud applications
  • Microsoft services
  • Specific applications
  • All resources

Microsoft’s terminology has evolved, so you may encounter older material referring to Cloud apps or actions and newer interfaces referring to Target resources or Resources.

For exam purposes, understand the underlying concept:

Target resources identify what the policy is protecting.

Example

A company might create a policy that requires MFA only when users access:

  • Exchange Online
  • SharePoint Online
  • Microsoft Teams
  • A specific enterprise application

rather than requiring the control for every resource.


6. Conditions

Conditions determine when the policy should apply.

Common Conditional Access conditions include:

  • User risk
  • Sign-in risk
  • Device platforms
  • Locations
  • Client applications
  • Filter for devices
  • Authentication context
  • Other supported contextual signals

The important concept is:

Conditions determine whether the policy applies to a particular sign-in.


7. Device Platforms

Conditional Access can evaluate the platform being used.

Examples include:

  • Windows
  • macOS
  • iOS
  • Android
  • Linux
  • Other or unknown platforms

This allows organizations to create policies such as:

Require compliant devices when accessing corporate applications from Windows.

Or:

Block access from unsupported platforms.

However, device-platform detection is based on signals such as the user-agent information and should not necessarily be treated as a complete device-security solution. Microsoft recommends combining platform-based controls with stronger controls such as device compliance or application protection where appropriate.


8. Locations

Conditional Access can make decisions based on network location.

Organizations can define named locations to represent trusted or known network locations.

Examples include:

  • Corporate offices
  • Corporate VPN ranges
  • Approved network ranges
  • Specific countries or regions

A policy might say:

Require MFA when users sign in from outside corporate locations.

Another might say:

Block access from a specific geographic region.

Important distinction

A trusted location doesn’t automatically mean:

“This user is safe.”

It simply provides a contextual signal that can be incorporated into an access decision.


9. Named Locations

Named locations provide administrators with a reusable way to identify network locations.

For example:

Corporate Headquarters

could represent:

203.0.113.0/24

A policy could then reference Corporate Headquarters instead of repeatedly specifying the IP range.

Named locations can be useful for:

  • Trusted corporate networks
  • VPN ranges
  • Specific countries/regions
  • Other known network locations

10. Client Applications

Conditional Access can evaluate how the user is accessing a resource.

Examples include:

  • Browser
  • Mobile applications
  • Desktop clients
  • Legacy authentication clients
  • Other supported client types

This can be used to create policies such as:

Block legacy authentication.

This is an important security practice because older authentication protocols may not support modern authentication protections.


11. User Risk

User risk represents the likelihood that an identity or account has been compromised.

Microsoft Entra ID Protection provides risk information that Conditional Access can use to make access decisions.

For example:

If the user’s risk is high, require remediation or stronger authentication.

Possible responses can include:

  • Require additional authentication
  • Require risk remediation
  • Block access

Example

A user’s credentials are detected in a way that suggests the account may be compromised.

Conditional Access can detect the elevated user risk and require appropriate remediation before access is allowed.


12. Sign-In Risk

Sign-in risk represents the probability that a particular authentication request isn’t being performed by the legitimate identity owner.

This is different from user risk.

User risk

Is this user’s account likely to be compromised?

Sign-in risk

Is this particular sign-in likely to be suspicious?

This distinction is very important for the exam.


13. User Risk vs. Sign-In Risk

RiskFocus
User riskLikelihood that the identity/account is compromised
Sign-in riskLikelihood that the current authentication request is suspicious

Example

A user might have:

Low user risk

but experience:

High sign-in risk

because the current login originates from an unusual location or demonstrates suspicious characteristics.

Conversely, a user may have elevated user risk even when the current sign-in itself doesn’t appear particularly unusual.


14. Grant Controls

Once Conditional Access determines that a policy applies, it needs to determine:

What should happen?

This is where grant controls are used.

Common grant controls include:

  • Require multifactor authentication
  • Require authentication strength
  • Require device to be marked as compliant
  • Require Microsoft Entra hybrid joined device
  • Require approved client app
  • Require app protection policy
  • Require password change
  • Block access

Current Conditional Access supports combining grant controls using either:

Require all selected controls

or

Require one of the selected controls.


15. Require Multifactor Authentication

One of the most common Conditional Access controls is:

Require multifactor authentication

This requires the user to satisfy Microsoft Entra MFA requirements.

For example:

Condition:

User accesses Microsoft 365 from outside trusted locations.

Grant:

Require multifactor authentication.

Result:

Users accessing Microsoft 365 from outside the trusted location must perform MFA.


16. Authentication Strength

Conditional Access can require a particular authentication strength rather than simply requiring generic MFA.

This allows organizations to establish stronger authentication requirements.

For example, an organization might require:

  • Phishing-resistant authentication
  • A particular authentication method
  • A custom authentication-strength configuration

This is particularly useful for highly sensitive applications and privileged operations.

Exam clue

If the question says:

“Require a specific or stronger authentication method.”

Think:

Authentication strength

rather than simply:

Require MFA


17. Require a Compliant Device

Conditional Access can require the device to be marked as compliant.

This is commonly integrated with Microsoft Intune.

For example:

Users can access corporate applications only from devices that satisfy the organization’s device-compliance policies.

A device might need to satisfy requirements such as:

  • Encryption
  • Password requirements
  • Security software
  • Operating-system requirements
  • Other organizational compliance requirements

The important distinction is:

Conditional Access determines whether a compliant device is required; Intune evaluates device compliance.


18. Require Microsoft Entra Hybrid Joined Device

Conditional Access can require users to access resources only from devices that are Microsoft Entra hybrid joined.

This can be useful in organizations operating a hybrid identity environment where corporate Windows devices are joined to both:

  • On-premises Active Directory
  • Microsoft Entra ID

This is different from simply requiring an Intune-compliant device.


19. Require an Approved Client App

Conditional Access can require users to access supported resources through an approved client application.

This can help organizations control which applications are permitted to access corporate data.


20. Require App Protection Policy

Conditional Access can require an app protection policy.

App protection policies are associated with Microsoft Intune and can provide application-level protection for organizational data.

This is particularly relevant for mobile scenarios and bring-your-own-device environments.

For example:

A user can access corporate email from a personal mobile device, but the application must satisfy organizational app-protection requirements.


21. Block Access

Block access is the strongest Conditional Access decision.

If the policy applies and the block control is selected, access is denied.

For example:

Block access to corporate resources from unsupported device platforms.

Or:

Block access from a prohibited geographic region.

Block policies must be designed carefully because a misconfigured block policy can prevent legitimate users or administrators from accessing critical resources. Microsoft recommends testing and validating such policies before broad enforcement.


22. Require All vs. Require One

When multiple grant controls are selected, Conditional Access can be configured to require:

Require all selected controls

Every selected requirement must be satisfied.

Example:

Require MFA AND compliant device.

The user must satisfy both.

Require one of the selected controls

Any one of the selected requirements can satisfy the policy.

Example:

Require MFA OR compliant device.

The user needs to satisfy one of them.

Exam tip

Pay close attention to:

AND vs. OR

A question can change the correct answer simply by changing whether all controls or only one control must be satisfied.


23. Session Controls

Grant controls determine what must happen to allow access.

Session controls control what happens after access has been granted.

Examples include:

  • Sign-in frequency
  • Persistent browser session
  • Other supported session-management controls

This distinction is important.

Grant control

“You must perform MFA.”

Session control

“You must authenticate again after a specified period.”


24. Sign-In Frequency

Sign-in frequency can be used to control how often users must authenticate.

For example:

Require users to authenticate again every 8 hours.

This can help reduce the risk associated with long-lived authenticated sessions.

A more sensitive application might use a shorter sign-in frequency than a lower-risk application.


25. Persistent Browser Session

Conditional Access can control whether browser sessions remain persistent.

This can influence whether users remain signed in when they close and reopen their browser.

This is useful when an organization wants to reduce persistent authentication sessions on devices or in environments where persistent sessions aren’t desirable.


26. Policy States

Conditional Access policies have different states.

The most important are:

  • On
  • Off
  • Report-only

On

The policy is enforced.

Off

The policy isn’t evaluated for enforcement.

Report-only

The policy is evaluated for sign-ins, but its access controls aren’t enforced.

Report-only mode is extremely important when deploying new policies because administrators can evaluate the expected impact before enforcement. Results are available through sign-in logs and Conditional Access reporting capabilities.


27. Report-Only Mode

A recommended deployment pattern is:

Create → Report-only → Test → Analyze → Adjust → Enable

Report-only mode allows administrators to see how a policy would affect users without actually enforcing its grant or session controls.

For example:

A new policy requires MFA for all users accessing Microsoft 365.

Before enabling it, the administrator puts the policy into Report-only mode.

The administrator then examines sign-in activity to determine:

  • Which users would be affected
  • Which applications would be affected
  • Which users would be blocked
  • Which requirements users would need to satisfy
  • Whether exclusions are appropriate

Only after validating the results should the policy be enabled.


28. Conditional Access Sign-In Logs

The Microsoft Entra sign-in logs are one of the most important troubleshooting tools for Conditional Access.

When investigating a sign-in, administrators can determine:

  • Which policies applied
  • Which policies didn’t apply
  • Whether a policy succeeded
  • Whether a policy failed
  • What conditions were evaluated
  • Which access controls affected the sign-in

This makes sign-in logs particularly valuable when a user reports:

“I can’t access the application.”


29. The Conditional Access What If Tool

The What If tool allows administrators to simulate how Conditional Access policies would evaluate a particular scenario.

Administrators can specify factors such as:

  • Identity
  • Target resource
  • Device platform
  • Client application
  • Location
  • Other conditions

The tool then identifies the policies that would affect the simulated sign-in.

Exam clue

If the question asks:

“You need to determine which Conditional Access policies would apply to a particular user and scenario without performing an actual sign-in.”

Think:

What If


30. Conditional Access Insights and Reporting

Organizations can use Conditional Access reporting capabilities to analyze policy impact.

These capabilities can help answer questions such as:

  • How many users are affected?
  • Which policies are blocking access?
  • Which policies are requiring MFA?
  • Which policies are being triggered?
  • What would happen if a report-only policy were enabled?

This is particularly useful when several Conditional Access policies interact.


31. Multiple Conditional Access Policies

Multiple Conditional Access policies can apply to the same sign-in.

For example:

Policy 1

All users accessing Microsoft 365:

Require MFA.

Policy 2

Administrators accessing Microsoft 365:

Require compliant device.

An administrator signing in to Microsoft 365 could be subject to both policies.

Therefore, the effective access decision can depend on the combined effect of multiple policies.

Exam tip

Don’t analyze a Conditional Access policy in isolation when a question describes several policies.

Look for:

  • Includes
  • Exclusions
  • Conditions
  • Grant controls
  • Session controls
  • Other policies affecting the same sign-in

32. Exclusions Are Extremely Important

Exclusions can prevent a Conditional Access policy from applying to specific users, groups, or other supported identities.

A common example is excluding emergency access/break-glass accounts from policies that could otherwise lock out administrators.

Microsoft specifically recommends protecting emergency access accounts from accidental lockout caused by Conditional Access misconfiguration.

Important principle

Don’t blindly exclude large groups of users simply to make a policy easier to deploy.

Exclusions should be:

  • Deliberate
  • Documented
  • Minimal
  • Reviewed regularly

33. Emergency Access Accounts

Emergency access accounts are particularly important when implementing Conditional Access.

Imagine an organization creates:

All users → Block access from outside the corporate network.

If the policy is incorrectly configured, administrators might also be blocked.

An emergency access account provides a recovery mechanism.

These accounts should be:

  • Highly protected
  • Monitored
  • Used only for emergencies
  • Excluded appropriately from policies that could cause tenant-wide lockout

34. Conditional Access and Zero Trust

Conditional Access is closely aligned with the Zero Trust principles of:

Verify explicitly

Use least privilege

Assume breach

Conditional Access doesn’t simply trust a user because the user successfully authenticated.

Instead, access can depend on multiple signals.

For example:

Identity + device + location + application + risk + authentication strength

This creates a more contextual access decision.


35. Common Conditional Access Design Patterns

Pattern 1: Require MFA for all users

Users: All users
Resources: All resources
Grant: Require MFA

This establishes a foundational authentication requirement.


Pattern 2: Require MFA outside trusted locations

Users: All users
Resources: Corporate applications
Location: Any location except trusted locations
Grant: Require MFA

This reduces unnecessary MFA prompts from trusted corporate networks while requiring stronger verification from elsewhere.


Pattern 3: Require compliant devices

Users: Employees
Resources: Corporate applications
Grant: Require device to be marked as compliant

This helps ensure that corporate resources are accessed from appropriately managed devices.


Pattern 4: Protect administrators

Users: Privileged administrators
Resources: Sensitive resources
Grant: Require authentication strength and/or compliant device

This creates stronger controls for high-value identities.


Pattern 5: Block legacy authentication

Users: All users
Client app: Legacy authentication clients
Grant: Block access

This prevents older authentication methods from bypassing modern security controls.


Pattern 6: Respond to risky sign-ins

Users: Users affected by risk policy
Condition: Elevated sign-in risk
Grant: Require MFA or block access

This allows security controls to respond dynamically to risk.


36. Conditional Access and Authentication Methods

Conditional Access determines when additional authentication is required.

Authentication policies determine which authentication methods are available.

For example:

Conditional Access: Require authentication strength.

The authentication-strength configuration then determines what authentication methods satisfy that requirement.

This distinction is important.

Conditional Access

When should stronger authentication be required?

Authentication methods/authentication strength

What authentication is strong enough?


37. Conditional Access and Microsoft Intune

Conditional Access and Microsoft Intune frequently work together.

A typical pattern is:

Intune evaluates device compliance → Conditional Access requires a compliant device → Access allowed or denied

For example:

A device is:

  • Encrypted
  • Running an approved operating-system version
  • Protected by required security software
  • Meeting organizational compliance policies

Intune marks the device compliant.

Conditional Access then allows the user to access the protected resource because the policy requirement has been satisfied.


38. Conditional Access and Microsoft Entra ID Protection

Microsoft Entra ID Protection provides risk signals.

Conditional Access can use these signals to make access decisions.

This creates a relationship:

ID Protection detects risk → Conditional Access responds to risk

For example:

High sign-in risk → Require stronger authentication.

Or:

High user risk → Require remediation.


39. Conditional Access for AI and Agents

As AI workloads increasingly use identities and agents, Conditional Access can also participate in securing AI-related access scenarios.

The SC-500 material you provided specifically includes AI security topics involving:

  • Microsoft Entra Agent Identity
  • Microsoft Defender XDR
  • Copilot Studio
  • Microsoft Foundry
  • Microsoft Defender for Cloud
  • Microsoft Purview

Conditional Access should therefore be understood as part of a larger identity-centric security architecture rather than as a control that applies only to traditional human users.


40. Common Implementation Mistakes

Mistake 1: Enabling a broad policy immediately

A policy that applies to all users and all resources can have a massive impact.

Better: Use report-only mode and test first.


Mistake 2: Forgetting exclusions

A policy might unintentionally affect emergency access accounts or other critical identities.

Better: Carefully evaluate exclusions.


Mistake 3: Using block access too broadly

A block policy can cause widespread outages.

Better: Test thoroughly before enforcement.


Mistake 4: Confusing user risk and sign-in risk

These represent different security signals.

Remember:

User risk = account compromise

Sign-in risk = suspicious authentication event


Mistake 5: Assuming MFA and authentication strength are identical

Authentication strength can impose more specific authentication requirements than a generic MFA requirement.


Mistake 6: Assuming report-only means nothing is evaluated

Report-only policies are evaluated during sign-in; they simply don’t enforce their grant or session controls. Results can be reviewed in sign-in logs and reporting tools.


Mistake 7: Ignoring workload identities

A policy scoped to users isn’t automatically a policy protecting service principals.

Use workload-identity Conditional Access where appropriate.


41. Conditional Access Deployment Strategy

A good deployment strategy is:

Step 1 — Identify the security objective

Example:

Require MFA for privileged administrators.

Step 2 — Identify the users

Example:

Members of the Security Administrators group.

Step 3 — Identify the resources

Example:

Sensitive administrative applications.

Step 4 — Identify the conditions

Example:

Any location.

Step 5 — Define the grant control

Example:

Require authentication strength.

Step 6 — Define exclusions

Example:

Emergency access accounts.

Step 7 — Deploy in report-only mode

Observe the expected impact.

Step 8 — Test

Test:

  • Included users
  • Excluded users
  • Different devices
  • Different locations
  • Different applications
  • Different authentication methods

Step 9 — Review logs

Use sign-in logs and Conditional Access reporting.

Step 10 — Enable the policy

Only after validating the expected behavior.

Microsoft currently recommends using report-only mode and reviewing policy impact before enforcement.


42. SC-500 Conditional Access Quick Reference

ConceptKey point
Conditional AccessContext-based access control
Users/groupsDefines who the policy applies to
Workload identitiesControls supported non-user identities such as service principals
Target resourcesDefines what the policy protects
ConditionsDetermine when the policy applies
LocationsUses network/location context
Device platformsEvaluates device platform
User riskLikelihood that the account is compromised
Sign-in riskLikelihood that the current sign-in is suspicious
Grant controlsDetermine what is required to gain access
MFARequires multifactor authentication
Authentication strengthRequires a particular authentication strength
Compliant deviceRequires Intune-compliant device
Hybrid joined deviceRequires Microsoft Entra hybrid joined device
Approved client appRequires an approved application
App protection policyRequires an applicable Intune app-protection policy
Block accessDenies access
Session controlsControl aspects of an authenticated session
Sign-in frequencyControls how often authentication is required
Report-onlyEvaluates without enforcing grant/session controls
What IfSimulates which policies would apply
Sign-in logsShows policy evaluation for actual sign-ins
Emergency access accountsHelp prevent administrative lockout
Zero TrustConditional Access supports explicit verification and least privilege

Practice Exam Questions

Question 1

An organization wants to require MFA whenever employees access Microsoft 365 from outside the company’s trusted corporate networks.

Which Conditional Access configuration should you use?

A. Include all users, exclude trusted locations, and require MFA

B. Include trusted locations and block access

C. Include all users and require a compliant device

D. Include all users and require an approved client application

Answer: A

Explanation: The policy should target the users and apply when the sign-in originates from locations other than the organization’s trusted locations. The appropriate grant control is Require multifactor authentication.


Question 2

A security administrator wants to determine which Conditional Access policies would apply if a specific user attempted to access an application from an Android device without actually performing the sign-in.

Which tool should the administrator use?

A. Microsoft Entra audit logs

B. Conditional Access What If

C. Microsoft Defender for Cloud

D. Access reviews

Answer: B

Explanation: The Conditional Access What If tool allows administrators to simulate a sign-in scenario and determine which enabled or report-only Conditional Access policies would apply.


Question 3

An organization wants to deploy a new Conditional Access policy requiring compliant devices. Administrators want to evaluate the policy’s effect without preventing users from accessing applications.

What should they do first?

A. Enable the policy

B. Configure the policy as a block policy

C. Configure the policy in report-only mode

D. Disable all existing Conditional Access policies

Answer: C

Explanation: Report-only mode evaluates the policy without enforcing its grant or session controls. Administrators can review the results in sign-in logs and Conditional Access reporting before enabling the policy.


Question 4

A company wants administrators accessing sensitive applications to use phishing-resistant authentication rather than simply satisfying a generic MFA requirement.

Which Conditional Access control is most appropriate?

A. Require an approved client app

B. Require authentication strength

C. Require a compliant device

D. Require password change

Answer: B

Explanation: Authentication strength allows an organization to specify the strength and type of authentication required. This is more precise than simply requiring generic MFA.


Question 5

An organization wants to block users from accessing corporate applications from unknown or unsupported device platforms.

Which Conditional Access configuration should be used?

A. Require MFA

B. Require an authentication strength

C. Require a compliant device

D. Block access based on the device platform condition

Answer: D

Explanation: The policy should use the Device platforms condition to identify the relevant platforms and use Block access as the grant control. Device-platform policies should be designed carefully because platform identification alone isn’t a complete device-security control.


Question 6

A Conditional Access policy applies to all users and requires MFA. The organization’s emergency access account is also subject to the policy. A configuration error causes all administrators to be unable to satisfy the policy.

What is the primary concern?

A. The emergency account could be locked out along with other administrators

B. The policy will automatically disable MFA

C. The emergency account will become a service principal

D. Conditional Access will automatically remove the policy

Answer: A

Explanation: Emergency or break-glass accounts should be appropriately excluded from policies that could cause administrative lockout. They provide a recovery mechanism if Conditional Access is misconfigured.


Question 7

An administrator wants to require both MFA and a compliant device before users can access a sensitive application.

How should the Conditional Access grant controls be configured?

A. Require one of the selected controls

B. Require only MFA

C. Require all the selected controls

D. Use session controls instead of grant controls

Answer: C

Explanation: Because users must satisfy both requirements, the policy should use Require all the selected controls. Conditional Access supports both “require all” and “require one” behavior when multiple grant controls are configured.


Question 8

A user has a low user-risk level but the current authentication request has been identified as highly suspicious.

Which Conditional Access condition should be used to respond specifically to the current authentication event?

A. User risk

B. Sign-in risk

C. Device platform

D. Named location

Answer: B

Explanation: Sign-in risk evaluates the likelihood that a particular authentication request isn’t being performed by the legitimate identity owner. User risk, by contrast, concerns the likelihood that the user’s account or identity is compromised.


Question 9

A user reports that access to an application was denied. The security administrator needs to determine which Conditional Access policy caused the denial and why the policy applied.

Where should the administrator investigate first?

A. Microsoft Entra sign-in logs

B. Azure Cost Management

C. Azure Resource Graph

D. Microsoft Entra access reviews

Answer: A

Explanation: Microsoft Entra sign-in logs provide detailed information about Conditional Access policy evaluation for individual sign-in events, including policies that applied, succeeded, failed, or weren’t applied.


Question 10

An organization has a Conditional Access policy that applies to all users accessing a sensitive application. The policy requires MFA. The organization also has a second policy that applies only to administrators and requires a compliant device.

An administrator attempts to access the application.

What should the administrator expect?

A. Only the first policy can apply because Conditional Access policies cannot overlap

B. Only the more restrictive policy applies

C. The administrator is automatically excluded from the first policy

D. Multiple applicable Conditional Access policies can affect the sign-in

Answer: D

Explanation: Multiple Conditional Access policies can apply to the same sign-in. The administrator can therefore be subject to both the MFA requirement from the first policy and the compliant-device requirement from the second policy. This is why policy interactions must be evaluated together during deployment and troubleshooting.


Final Exam Takeaways

For the SC-500 exam, remember Conditional Access as a context-driven access decision engine:

Who + What + Conditions → Grant/Block + Session Controls

The distinctions most worth memorizing are:

  • User risk ≠ sign-in risk
  • Grant controls ≠ session controls
  • MFA ≠ authentication strength
  • User policies ≠ workload-identity policies
  • Report-only evaluates but doesn’t enforce
  • What If simulates policy applicability
  • Sign-in logs show what happened during an actual sign-in
  • Require all ≠ require one
  • Compliant device ≠ hybrid joined device
  • Block access is powerful and must be tested carefully
  • Emergency access accounts should be protected from accidental lockout
  • Multiple Conditional Access policies can affect the same sign-in
  • Conditional Access works particularly well alongside Microsoft Entra ID Protection and Intune

A useful exam mental model is:

Identify the user → identify the resource → identify the conditions → determine the required control → test the policy → monitor the result.


Go to the SC-500 Exam Prep Hub main page

Implement and configure identity for applications, including enterprise applications and app registrations (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Implement and configure identity for applications, including enterprise applications and app registrations


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Modern cloud applications need identities just as users and devices do. Microsoft Entra ID provides the identity platform that applications use to authenticate, obtain tokens, access APIs, and authorize users or workloads.

For the SC-500 exam, it is important to understand the difference between an application registration, an application object, and an enterprise application/service principal. You should also understand how to configure authentication, permissions, consent, credentials, application roles, and access controls.

A particularly important concept is that App registrations and Enterprise applications are related but serve different purposes.

Microsoft Entra represents an application through an application object and service principal objects. The application object is essentially the application’s definition or blueprint, while the service principal is the application’s local identity in a particular tenant.


1. Application Identity in Microsoft Entra ID

An application that needs to authenticate through Microsoft Entra ID generally needs to be represented in the directory.

Consider an application called Contoso Expense Manager.

The application might need to:

  • Authenticate employees.
  • Request access to Microsoft Graph.
  • Call a custom API.
  • Restrict access to members of a particular group.
  • Use certificates instead of passwords.
  • Support single sign-on.
  • Operate across multiple Microsoft Entra tenants.

Microsoft Entra provides the identity infrastructure needed to accomplish these tasks.

The two most important objects to understand are:

ObjectPrimary purpose
Application objectDefines the application and its identity configuration
Service principalRepresents an instance of the application in a specific tenant

A useful way to remember this is:

Application object = blueprint
Service principal = local instance

An application normally has one application object in its home tenant, while it can have multiple service principals, including one in each tenant where the application is used.


2. What Is an App Registration?

An app registration is the process of registering an application with Microsoft Entra ID.

When you register an application, you tell Microsoft Entra how the application should interact with the identity platform.

An app registration can define:

  • Application name
  • Supported account types
  • Redirect URIs
  • Authentication configuration
  • API permissions
  • Exposed APIs
  • Application roles
  • Client credentials
  • Certificates
  • Federated credentials
  • Other identity-related configuration

Microsoft Entra uses this information when issuing tokens and determining how the application interacts with users and APIs.

Common application types

Applications can include:

  • Web applications
  • Single-page applications
  • Mobile applications
  • Desktop applications
  • Web APIs
  • Daemon/background applications

The application type affects how authentication and credentials should be configured.


3. Application Object vs. Service Principal

This is one of the most important concepts for the SC-500 exam.

Suppose a software vendor creates a multitenant application called Contoso CRM.

The vendor registers the application in its home tenant.

That registration creates an application object.

When another organization’s tenant uses the application, Microsoft Entra creates a service principal in that customer’s tenant.

Therefore:

                  APPLICATION
                       │
                       ▼
              Application Object
              (Home Tenant)
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
       Service       Service    Service
       Principal     Principal  Principal
       Tenant A      Tenant B   Tenant C

The application object contains the application’s global/default configuration.

The service principal represents the application’s identity within a particular tenant and contains tenant-specific settings such as permissions and assignments.

Exam tip

If a question asks:

“Where does an administrator configure which users in their organization can access an application?”

Think:

Enterprise application / service principal

If it asks:

“Where does the developer configure redirect URIs, exposed APIs, or application credentials?”

Think:

App registration / application object


4. App Registrations vs. Enterprise Applications

The Microsoft Entra admin center provides separate experiences for these objects.

App registrations

App registrations primarily manage the application’s definition.

Typical activities include:

  • Registering an application
  • Configuring authentication
  • Configuring redirect URIs
  • Defining API permissions
  • Creating client secrets
  • Uploading certificates
  • Defining application roles
  • Exposing APIs

Enterprise applications

Enterprise applications primarily manage the application’s presence and access within a particular tenant.

Typical activities include:

  • Assigning users and groups
  • Managing application access
  • Configuring tenant-specific settings
  • Reviewing permissions and consent
  • Managing Conditional Access-related controls
  • Managing single sign-on configuration for applicable applications
  • Viewing sign-in information

Microsoft describes Enterprise Applications as the management experience for service principals.

Simple exam distinction

If the question says…Think…
Register an applicationApp registrations
Configure redirect URIApp registrations
Add client secretApp registrations
Add certificateApp registrations
Configure API permissionsApp registrations
Define application rolesApp registrations
Assign users to an applicationEnterprise applications
Assign groups to an applicationEnterprise applications
Control tenant-specific application accessEnterprise applications
Review application sign-insEnterprise applications
Manage a service principalEnterprise applications

5. Application IDs and Object IDs

Several identifiers can appear when working with applications.

Two particularly important identifiers are:

Application (client) ID

The Application (client) ID identifies the application.

Applications use this value when communicating with Microsoft Entra ID.

It is commonly referred to as the:

  • Client ID
  • Application ID
  • App ID

Object ID

The Object ID identifies a specific Microsoft Entra directory object.

An application object and a service principal each have their own object ID.

This distinction becomes particularly important when managing applications programmatically.

Exam warning

Do not automatically treat:

Application (client) ID

and

Object ID

as interchangeable.

They identify different things.


6. Configure Supported Account Types

When registering an application, you must determine who can use it.

Common choices include:

Accounts in this organizational directory only

This creates a single-tenant application.

The application is intended for users in the application’s home Microsoft Entra tenant.

This is commonly appropriate for an organization’s internal line-of-business applications.


Accounts in any organizational directory

This creates a multitenant application.

Users from other Microsoft Entra tenants can authenticate to the application, subject to the appropriate configuration and consent.

This is common for SaaS applications intended for customers from multiple organizations.


Accounts in any organizational directory and personal Microsoft accounts

This allows organizational accounts and supported personal Microsoft accounts.


Exam decision

If a question says:

“The application will only be used by employees of the organization.”

A single-tenant configuration is generally the appropriate choice.

If the question says:

“The application is a SaaS application that must be accessed by customers from multiple Microsoft Entra tenants.”

Think:

Multitenant application.

Microsoft Entra’s application model explicitly distinguishes single-tenant and multitenant applications.


7. Configure Authentication

The Authentication configuration of an app registration determines how users or applications authenticate.

Depending on the application type, configuration can include:

  • Platform configuration
  • Redirect URIs
  • Front-channel logout URL
  • ID token issuance
  • Access token issuance
  • Supported authentication flows

The authentication configuration must correspond to the application architecture.

For example:

  • A web application has a server component and can protect confidential credentials.
  • A single-page application executes in the browser and cannot safely store a client secret.
  • A daemon application runs without interactive user involvement.

Understanding the difference between public clients and confidential clients is important.


8. Redirect URIs

A redirect URI, also called a reply URL, specifies where Microsoft Entra ID sends the authentication response after authentication.

For example:

https://app.contoso.com/signin-oidc

The redirect URI is an important security control.

Microsoft Entra validates the redirect URI against the URIs configured for the application.

Why does this matter?

Imagine an attacker attempting to manipulate an authentication response so that it is sent to an unauthorized location.

Restricting valid redirect URIs helps prevent this type of attack.

Exam scenario

If the question says:

“Users successfully authenticate, but the application returns an error because the authentication response cannot be redirected to the application.”

Check:

Redirect URI configuration.

The redirect URI configured by the application must correspond to an allowed URI in the app registration.


9. Client Secrets

A client secret is a credential that a confidential client can use to authenticate itself to Microsoft Entra ID.

Client secrets are commonly used by:

  • Web applications
  • Daemon applications
  • Background services
  • Server-side applications

For example:

Application
│
│ client ID + client secret
▼
Microsoft Entra ID
│
▼
Access token

Security concerns

Client secrets are sensitive credentials.

They should:

  • Never be embedded in source code.
  • Never be committed to a public Git repository.
  • Be protected from unauthorized access.
  • Be rotated regularly.
  • Have appropriate expiration periods.

For Azure-hosted applications, a managed identity may eliminate the need to manage a client secret altogether.


10. Certificates

Certificates provide another way for a confidential application to authenticate.

Instead of sending a shared secret, the application proves possession of the corresponding private key.

For confidential clients, Microsoft recommends certificates over client secrets when practical because certificates provide stronger security characteristics.

A simplified model is:

Application
│
│ Certificate/private key
▼
Microsoft Entra ID
│
│ validates public key
▼
Authentication

Exam consideration

If a question asks for a more secure alternative to a client secret for a confidential application, consider:

Certificate-based authentication.


11. Federated Credentials

Federated credentials provide another approach for workload authentication.

They are particularly useful when an external workload already has an identity issued by a trusted identity provider.

Instead of storing a long-lived client secret, the workload can exchange a trusted token for a Microsoft Entra access token.

This can be especially valuable for:

  • CI/CD pipelines
  • GitHub Actions
  • Kubernetes workloads
  • Other supported external workload identity scenarios

The major security benefit is reducing the need for long-lived application secrets.


12. Managed Identities

For Azure resources that support managed identities, a managed identity is often preferable to maintaining credentials manually.

For example:

Azure Function
│
│ Managed Identity
▼
Microsoft Entra ID
│
▼
Azure Key Vault

The application does not need to store a client secret.

Microsoft explicitly recommends considering managed identities instead of manually managed service principals when an application runs on an Azure service that supports managed identities and accesses resources that support Microsoft Entra authentication.

Exam tip

If the scenario says:

“An Azure-hosted application needs to access Azure Key Vault without storing credentials.”

Think:

Managed identity.


13. API Permissions

Applications frequently need to access APIs.

For example, an application might need to access:

  • Microsoft Graph
  • Azure resources
  • A custom API
  • Another organization’s API

The app registration can specify the APIs and permissions the application requires.

There are two major permission models you should know.


14. Delegated Permissions

Delegated permissions are used when an application accesses a resource on behalf of a signed-in user.

The effective access is generally constrained by both:

  1. The permissions granted to the application.
  2. The privileges available to the signed-in user.

For example:

User
│
│ signs in
▼
Application
│
│ delegated permission
▼
Microsoft Graph

A typical example would be an application that reads a user’s profile or email while that user is actively using the application.

Exam clue

If the scenario says:

“The application accesses data on behalf of the signed-in user.”

Think:

Delegated permissions.


15. Application Permissions

Application permissions are designed for applications that operate without a signed-in user.

They are commonly used by:

  • Background services
  • Daemons
  • Scheduled jobs
  • Automation
  • Server-to-server applications

For example:

Background service
│
│ Application permission
▼
Microsoft Graph

Because application permissions can grant broad access, they require careful governance and frequently require administrator consent.

Microsoft Graph, for example, supports application permissions that allow non-interactive applications to access organizational resources.

Key distinction

DelegatedApplication
User is involvedNo user required
Runs on behalf of userRuns as the application
User context mattersApplication identity determines access
Interactive scenariosDaemon/background scenarios

Exam shortcut

“On behalf of a user” → Delegated

“As the application” → Application


16. Consent

Consent is the mechanism through which permissions requested by an application can be authorized.

There are two major concepts:

User consent

A user may be allowed to consent to certain permissions depending on tenant configuration and the permissions requested.

Admin consent

An administrator can consent to permissions on behalf of users in the organization.

Admin consent is particularly important when the requested permissions are considered privileged or when organizational policy requires administrator approval.

For example:

Application
│
│ requests Mail.Read
▼
Microsoft Entra
│
▼
Admin consent
│
▼
Permission granted

Security principle

Do not automatically grant every requested permission.

Instead:

Grant the minimum permissions necessary for the application to perform its function.

This follows the principle of least privilege.


17. Application Roles

Application roles allow an application to implement role-based authorization.

For example, an application could define:

  • Reader
  • Contributor
  • Administrator

A user or group can then be assigned an application role.

Application roles can also be assigned to service principals for application-to-application authorization.

When an appropriate role is assigned, Microsoft Entra can include the role in the token through the roles claim.

Example:

User
│
│ assigned "ReportReader"
▼
Application
│
▼
Token
│
└── roles: ReportReader

The application can inspect the claim and determine what functionality the user is authorized to perform.


18. Enterprise Application Access Control

Enterprise applications allow administrators to control who can use an application in their tenant.

For example, an organization may have 10,000 employees but only 200 should have access to a particular application.

The administrator can configure the application so that access is assigned to:

  • Specific users
  • Groups

This provides centralized control over application access.

Service principals maintain tenant-specific information such as local user and group assignments, permissions, and policies.


19. Assignment Required

An enterprise application can be configured to require users to be explicitly assigned before they can access the application.

This is useful when an organization wants to prevent every user from automatically accessing an application.

For example:

10,000 employees
│
▼
Enterprise Application
│
│ Assignment required
▼
Only assigned users/groups

This is particularly useful for sensitive applications.

Exam scenario

If the requirement is:

“Only users explicitly assigned to the application should be allowed to access it.”

Think:

Require user assignment / configure enterprise application assignments.


20. Single Sign-On

Enterprise applications can support different single sign-on approaches depending on the application.

Common technologies include:

  • OpenID Connect
  • OAuth
  • SAML
  • Password-based SSO
  • Integrated Windows authentication for appropriate scenarios

SSO allows users to authenticate through Microsoft Entra ID rather than maintaining separate authentication experiences for every application.

For modern applications, OpenID Connect and OAuth 2.0 are particularly important concepts.


21. Conditional Access and Applications

Conditional Access can be used to apply access requirements to applications.

For example, an organization might require:

  • MFA
  • A compliant device
  • A trusted location
  • Specific authentication strength
  • Risk-based controls

A simplified example:

User
│
▼
Enterprise Application
│
▼
Conditional Access
│
├── MFA required
├── Device must be compliant
└── Risk must be acceptable
│
▼
Access granted

This provides an important security layer beyond simply registering the application.


22. Application Ownership and Governance

Applications should have clear ownership.

Application owners may be responsible for:

  • Maintaining application configuration
  • Managing credentials
  • Reviewing permissions
  • Monitoring usage
  • Removing obsolete applications
  • Ensuring permissions remain appropriate

Poor application governance can create significant security risks.

For example, an organization might have:

  • Hundreds of unused app registrations
  • Expired certificates
  • Forgotten client secrets
  • Excessive API permissions
  • Applications owned by employees who have left the organization

These conditions increase the attack surface.


23. Least Privilege for Applications

Least privilege applies to applications just as it does to users.

An application should receive only the permissions it needs.

For example, suppose an application only needs to read calendar information.

Giving it permission to:

Read and write all mailboxes

would violate least privilege.

A better design is to grant the smallest permission scope necessary.

Security checklist

For every application, ask:

  1. What resources does it need?
  2. What permissions does it need?
  3. Does it need delegated or application permissions?
  4. Does it really need write access?
  5. Can a managed identity be used?
  6. Can a certificate or federated credential replace a secret?
  7. Who can access the application?
  8. Is administrator consent required?
  9. Are the permissions periodically reviewed?
  10. Is the application still required?

24. Common SC-500 Exam Traps

Trap 1: Confusing app registrations with enterprise applications

Remember:

App registration → application definition

Enterprise application → tenant-specific service principal and access management


Trap 2: Confusing application object and service principal

Remember:

Application object → blueprint

Service principal → instance in a tenant


Trap 3: Using delegated permissions for a daemon

If no user is signed in, delegated permissions generally aren’t the appropriate model.

Think:

Application permissions.


Trap 4: Using a client secret unnecessarily

If an Azure resource supports managed identity and the target resource supports Microsoft Entra authentication, a managed identity can eliminate credential management.


Trap 5: Giving an application excessive permissions

Always consider:

Least privilege.


Trap 6: Confusing Application ID and Object ID

The Application (client) ID identifies the application.

The Object ID identifies a particular Microsoft Entra object.


Trap 7: Assuming every application is single-tenant

SaaS applications frequently require multitenant configuration.


Trap 8: Treating application permissions and Azure RBAC as the same thing

Application API permissions and Azure RBAC are separate authorization mechanisms.

An application can have Microsoft Graph permissions while also having an Azure RBAC role assignment against an Azure resource.


25. SC-500 Quick Reference

ConceptRemember
App registrationDefines/registers an application
Application objectGlobal/home-tenant application definition
Service principalTenant-specific application identity
Enterprise applicationManagement experience for service principals
Application (client) IDIdentifies the application
Object IDIdentifies a particular directory object
Single tenantUsers from the application’s home tenant
MultitenantUsers from multiple Entra tenants
Redirect URIWhere authentication response is returned
Client secretCredential for confidential clients
CertificateStronger credential option for confidential clients
Federated credentialReduces need for long-lived secrets
Managed identityAzure-managed workload identity
Delegated permissionApplication acts on behalf of a user
Application permissionApplication acts without a user
Admin consentAdministrator authorizes requested permissions
Application roleRole-based authorization for an application
Enterprise application assignmentControls which users/groups can access
Conditional AccessApplies contextual access requirements
Least privilegeGrant only required access

Practice Exam Questions

Question 1

A company develops an internal web application that will only be used by employees in its Microsoft Entra tenant. The application must authenticate employees using Microsoft Entra ID.

Which configuration should you use?

A. Register the application as single-tenant
B. Register the application as multitenant
C. Create an enterprise application without an app registration
D. Configure the application to accept personal Microsoft accounts

Answer: A

Explanation:
A single-tenant application is appropriate when the application is intended for identities from the organization’s home Microsoft Entra tenant. A multitenant configuration is intended for applications that need to support users from multiple Microsoft Entra tenants.


Question 2

A SaaS vendor has developed an application that must be used by customers in hundreds of different Microsoft Entra tenants. Each customer must be able to configure access for users within its own tenant.

What should the application use?

A. A separate application registration in every customer tenant
B. A multitenant application with a service principal in each customer tenant
C. A single service principal shared across all customer tenants
D. A managed identity created in each customer tenant

Answer: B

Explanation:
A multitenant application has an application object in its home tenant and can have a service principal representing the application in each customer tenant. The customer tenant administrators manage the local service principal through Enterprise Applications.


Question 3

An administrator needs to ensure that only members of the Finance group can access a third-party enterprise application. Where should the administrator primarily configure this tenant-specific access?

A. App registrations > Authentication
B. App registrations > Certificates & secrets
C. Enterprise applications > Users and groups
D. App registrations > Expose an API

Answer: C

Explanation:
Enterprise Applications provides tenant-specific management of the application’s service principal, including user and group assignments. App registrations is primarily concerned with the application’s definition and identity configuration.


Question 4

A background service runs every night without any user interaction. It needs to access Microsoft Graph to perform its assigned task.

Which permission model is most appropriate?

A. Delegated permissions
B. User consent only
C. Application permissions
D. Interactive authentication

Answer: C

Explanation:
Application permissions are intended for applications that operate without a signed-in user. A daemon or background service is a classic example. Delegated permissions are designed for applications acting on behalf of a user.


Question 5

A web application currently uses a client secret to authenticate to Microsoft Entra ID. The security team wants to replace the secret with a stronger credential-based mechanism for the confidential application.

Which option should you consider?

A. Redirect URI
B. Application role
C. Delegated permission
D. Certificate credential

Answer: D

Explanation:
Certificates can be used by confidential clients to authenticate the application and are generally preferred over client secrets when practical. A redirect URI controls where authentication responses are returned; it isn’t an application credential.


Question 6

An Azure-hosted application needs to retrieve secrets from Azure Key Vault. The security team does not want developers to store a client secret in application configuration.

Which solution provides the best approach when the Azure services involved support Microsoft Entra authentication?

A. Use a managed identity
B. Store the client secret in source code
C. Create a second client secret with a longer expiration
D. Store the password in an environment variable

Answer: A

Explanation:
A managed identity allows an Azure resource to authenticate to supported resources without requiring developers to manage an application credential. This reduces the risk associated with storing and rotating secrets.


Question 7

An application needs to read a user’s email while the user is signed in. The application should access the data within the user’s context rather than operating independently.

Which permission model should be used?

A. Application permissions
B. Delegated permissions
C. Managed identity permissions
D. Azure resource locks

Answer: B

Explanation:
Delegated permissions allow an application to access resources on behalf of a signed-in user. Application permissions are intended for scenarios where the application operates without a user.


Question 8

A developer reports that authentication succeeds, but Microsoft Entra ID cannot return the authentication response to the web application.

Which app registration setting should you investigate first?

A. Application roles
B. API permissions
C. Redirect URI
**D. Enterprise application assignment

Answer: C

Explanation:
The redirect URI specifies where Microsoft Entra ID returns the authentication response. The URI used by the application must correspond to an allowed redirect URI configured for the application.


Question 9

A custom API defines three application roles: Reader, Contributor, and Administrator. A user is assigned the Reader role. The API needs to determine which role the user has after authentication.

Which token information should the API inspect?

A. The roles claim
B. The redirect_uri claim
C. The client secret
D. The application object ID

Answer: A

Explanation:
Application roles can be assigned to users, groups, service principals, or supported managed identities. When appropriate, Microsoft Entra ID includes assigned application roles in the token’s roles claim, allowing the application to implement role-based authorization.


Question 10

A security team discovers that an enterprise application is available to every employee, but company policy requires users to be explicitly assigned before they can use it.

What should the administrator configure?

A. Change the application’s client ID
B. Require user assignment and assign the appropriate users or groups
C. Add another redirect URI
D. Change the application from single-tenant to multitenant

Answer: B

Explanation:
Requiring assignment allows the organization to control which users or groups can access an enterprise application. This is particularly useful for sensitive applications where broad access is not appropriate.


Final Exam Takeaways

If you remember only a handful of things from this topic, remember these:

  1. App registration = application definition.
  2. Application object = blueprint for the application.
  3. Service principal = application’s identity/instance in a specific tenant.
  4. Enterprise Applications = primarily where tenant administrators manage service principals and application access.
  5. Single-tenant = one organization’s tenant.
  6. Multitenant = users from multiple Microsoft Entra tenants.
  7. Delegated permissions = application acts on behalf of a user.
  8. Application permissions = application acts without a user.
  9. Managed identity = preferred way to avoid managing credentials for supported Azure workloads.
  10. Certificates are generally preferable to client secrets for confidential clients when practical.
  11. Redirect URIs are critical to authentication configuration.
  12. Application roles enable role-based authorization.
  13. Enterprise application assignments control who can access an application.
  14. Admin consent is important for authorizing privileged application permissions.
  15. Always apply least privilege to application permissions and access.

The biggest SC-500 mental model is:

Register the application → configure how it authenticates → define what it can access → create/manage its service principal → control who can use it → enforce least privilege and Conditional Access.


Go to the SC-500 Exam Prep Hub main page

Manage OAuth permission grants and consent settings (SC-500 Exam Prep)

This post is a part of the "SC-500: Implementing End-to-End Security Controls for Cloud and AI Workloads" Exam Prep Hub.
This topic falls under these sections:
Manage identity, access, and governance (20–25%)
   --> Secure access to resources by using Microsoft Entra ID
      --> Manage OAuth permission grants and consent settings


Note that there are 10 practice questions (with answers) at the end of each section to help you solidify your knowledge of the material. Also, there are 4 practice tests with 30 questions each available from the hub's main page below the exam topics section.

Overview

Microsoft Entra ID uses OAuth 2.0 permissions and consent to control whether applications can access protected resources such as Microsoft Graph and other APIs. When an application requests access to an API, the requested permissions describe what the application wants to do, and consent is the process through which a user or administrator authorizes that access.

For the SC-500 exam, it is important to understand that OAuth permissions are not simply an application configuration detail. They are an important security control because granting an application excessive permissions can allow that application to access sensitive organizational data.

The key concepts to understand are:

  • Delegated permissions
  • Application permissions
  • User consent
  • Administrator consent
  • Tenant-wide admin consent
  • OAuth permission grants
  • User consent settings and policies
  • Admin consent workflow
  • Reviewing and revoking permissions
  • Least privilege for application permissions
  • The relationship between app registrations and enterprise applications

1. Understanding OAuth Permissions

An application normally needs permission to access a protected API. For example, an application might need to:

  • Read a user’s basic profile
  • Read a user’s email
  • Read files that a user can access
  • Read organizational directory information
  • Access mailboxes
  • Access data without a signed-in user

Microsoft Entra represents these access requirements as API permissions.

There are two fundamental permission types:

  1. Delegated permissions
  2. Application permissions

Understanding the difference is one of the most important concepts for this topic.


2. Delegated Permissions

Delegated permissions are used when an application acts on behalf of a signed-in user.

The application does not receive more authority than the combination of the permissions granted to the application and the user’s own access allows.

For example, suppose an application receives the Microsoft Graph delegated permission:

Files.Read.All

The application is acting on behalf of the signed-in user. The application can access files that the signed-in user is permitted to access.

The important idea is:

Delegated permission = application + signed-in user

The user is part of the authorization context.

Example

A user signs into a document-management application.

The application requests:

  • User.Read
  • Files.Read

The user grants consent.

The application can then call Microsoft Graph on behalf of that user, subject to the permissions that were granted and the user’s own access.

Delegated permissions are commonly used by:

  • Web applications
  • Mobile applications
  • Single-page applications (SPAs)
  • Applications where a user is actively signed in

Microsoft refers to delegated permissions as scopes or OAuth2 permission scopes.


3. Application Permissions

Application permissions are used when an application accesses an API without a signed-in user.

This is commonly referred to as app-only access.

For example, a background service might need to periodically process files or retrieve organizational information without requiring a user to be logged in.

The application authenticates using its own identity and receives permissions assigned directly to the application.

The important idea is:

Application permission = application acting as itself

Application permissions can potentially provide very broad access. For example, an application permission that allows an application to read files across an organization can provide access to data that no individual user is currently accessing.

Application permissions are commonly used by:

  • Daemon applications
  • Background services
  • Automation processes
  • Server-to-server applications

Application permissions are also called app roles or app-only permissions. They require administrator consent.


4. Delegated vs. Application Permissions

This distinction is extremely important for the SC-500 exam.

CharacteristicDelegated PermissionApplication Permission
User signed in?YesNo
Application acts on behalf of user?YesNo
Application acts as itself?NoYes
Common application typesWeb, mobile, SPADaemon, background service
Also calledScopesApp roles
User can potentially consent?Yes, depending on tenant settings and permissionNo
Administrator consent required?SometimesYes
Typical riskAccess to user’s permitted dataPotentially organization-wide access

A useful exam rule is:

If a user is present, think delegated permissions. If the application must operate without a user, think application permissions.


5. What Is OAuth Consent?

Consent is the process by which a user or administrator authorizes an application to access a protected resource.

Consider an application requesting:

“Read your email.”

The application has declared the permission it needs, but simply declaring the permission doesn’t automatically mean it can use it.

Consent establishes authorization for the requested access.

A typical user experience is:

  1. The user signs into the application.
  2. The application requests access to an API.
  3. Microsoft Entra evaluates the requested permissions.
  4. Microsoft Entra determines whether consent has already been granted.
  5. If consent is required, the user or administrator is presented with a consent experience.
  6. If consent is granted, the application can request tokens containing the appropriate permissions.

Microsoft Entra records the resulting authorization information.


6. User Consent

User consent allows a user to authorize an application to access resources on the user’s behalf.

Whether users can provide consent is controlled by the organization’s Microsoft Entra configuration.

By default, users may be allowed to consent to applications requesting permissions that don’t require administrator consent. However, administrators can restrict or disable user consent to reduce the risk of malicious or overly privileged applications.

Example

A user installs an application that requests:

Read your basic profile

If the organization’s consent policy permits the user to grant that permission, the user can approve the request.

The consent is generally associated with that user rather than automatically granting the permission to every user in the tenant.


7. Why User Consent Is a Security Concern

OAuth consent can create a significant security risk if users are allowed to authorize untrusted applications.

Consider a malicious application that appears to be a legitimate productivity application.

The application requests permission to:

  • Read email
  • Read files
  • Read contacts

A user may approve the request without understanding the implications.

The application could then potentially access sensitive information available to that user.

This is why security administrators should consider:

  • Which users can grant consent
  • Which applications can receive consent
  • Which permissions users can approve
  • Whether the publisher is verified
  • Whether the requested permissions are appropriate
  • Whether the application actually requires the requested permissions

Microsoft recommends evaluating the application, publisher, requested permissions, and business justification before granting significant permissions.


8. Configuring User Consent Settings

Microsoft Entra administrators can configure how users are allowed to consent to applications.

Organizations can use consent settings to make the environment more restrictive.

Depending on the configuration, an organization can:

  • Allow users to consent to applications
  • Restrict user consent to specific permissions
  • Allow consent only for applications from verified publishers
  • Disable user consent so that administrators must approve applications

This provides an important security control.

For example, a highly regulated organization might decide:

“Users must never independently authorize applications to access organizational data.”

The organization can configure Microsoft Entra so that administrator approval is required.

Alternatively, an organization might allow users to consent to low-risk permissions from trusted or verified applications while requiring administrator approval for more sensitive permissions.

This is an example of balancing security with usability.


9. Permission Classifications

Organizations can further control which permissions users are allowed to consent to.

Permission classifications allow administrators to identify permissions as appropriate for user consent.

For example, an organization might allow users to consent to relatively low-risk permissions while requiring administrator approval for more sensitive permissions.

This supports a least-privilege approach:

Users should be able to grant only the permissions that the organization considers appropriate for self-service approval.

This is particularly useful in large organizations where completely disabling user consent would create unnecessary administrative overhead.


10. Administrator Consent

Some permissions require administrator consent.

This is especially important for:

  • Application permissions
  • High-privilege delegated permissions
  • Permissions that expose organizational data beyond the user’s normal context

An administrator can grant consent on behalf of users.

For example, suppose an application requires:

  • User.Read
  • Group.Read.All

An administrator can review the requested permissions and grant consent for the organization if the permissions are appropriate.

After tenant-wide administrator consent has been granted, users generally don’t have to individually approve those already-consented permissions.

However, if the application later requests additional permissions, additional consent may be required.


11. Tenant-Wide Administrator Consent

Tenant-wide admin consent grants an application permission on behalf of the organization.

This is significantly more powerful than an individual user granting consent.

For example:

An administrator grants an application the delegated permission User.Read.All for all users in the tenant.

The consent applies organizationally rather than only to the administrator’s account.

This makes tenant-wide consent a significant security decision.

Before granting tenant-wide consent, administrators should verify:

  1. The application is legitimate.
  2. The publisher is trusted.
  3. The requested permissions are necessary.
  4. The permissions follow least privilege.
  5. The application’s business purpose justifies the access.
  6. The application is not requesting unrelated or excessive permissions.

Microsoft specifically recommends examining the requested permissions and publisher before granting tenant-wide consent.


12. Tenant-Wide Consent Does Not Necessarily Mean Every User Can Use the Application

A subtle but important security concept is that granting tenant-wide consent does not necessarily mean every user must be allowed to access the application.

An organization can still restrict application access by requiring users or groups to be assigned to the enterprise application.

For example:

  • Tenant-wide consent is granted.
  • User assignment is required.
  • Only members of the Finance group are assigned.
  • Only those users can access the application.

This allows administrators to separate:

“Has the organization authorized the application’s permissions?”

from:

“Which users are allowed to use the application?”

Microsoft Entra supports requiring user assignment to restrict access even when tenant-wide admin consent has been granted.


13. The Admin Consent Workflow

Organizations can configure an admin consent workflow to allow users to request administrator approval when they encounter an application that requires consent they cannot provide themselves.

The workflow provides a structured alternative to users simply receiving an error and having to figure out who to contact.

A typical process is:

  1. A user attempts to use an application.
  2. The application requests permissions.
  3. The user isn’t permitted to grant those permissions.
  4. The user submits an admin consent request.
  5. Designated reviewers receive the request.
  6. A reviewer evaluates the application and requested permissions.
  7. The reviewer approves or denies the request.
  8. The user is notified of the decision.

An important security point is that being designated as a reviewer does not automatically give the reviewer permission to grant administrator consent. The reviewer must already have the appropriate permissions to perform the consent operation.


14. Reviewing an OAuth Consent Request

When reviewing an application requesting consent, don’t simply ask:

“Do we recognize this application?”

Instead, evaluate the complete request.

1. Who published the application?

Determine whether the publisher is trusted.

Be cautious about applications that imitate well-known products or organizations.

2. What permissions are requested?

Review every permission.

Don’t approve an application simply because its name is familiar.

3. Why does the application need the permissions?

The requested permissions should support the application’s documented purpose.

For example, a reporting application might reasonably need access to reporting data.

That doesn’t automatically mean it needs access to every user’s mailbox.

4. Is the requested access excessive?

Apply least privilege.

If an application only needs read access, don’t grant write access.

If it only needs a subset of organizational data, avoid granting organization-wide access.

5. Is administrator consent actually required?

Determine whether the application could operate with lower-privilege delegated permissions instead.


15. Verified Publishers

A verified publisher provides additional information that can help administrators and users establish trust in an application.

However:

Verified publisher does not mean “automatically safe.”

Verification can increase confidence in the publisher’s identity, but administrators should still evaluate:

  • Requested permissions
  • Application purpose
  • Data being accessed
  • Business justification
  • Least privilege
  • Application behavior

Security decisions should never be based solely on the publisher verification status.


16. OAuth Permission Grants

A permission grant represents authorization for an application to access an API.

For delegated permissions, Microsoft Entra can record an OAuth2 permission grant.

A useful distinction is:

  • Delegated permission grant → OAuth2 permission grant
  • Application permission grant → app role assignment

For Microsoft Graph, for example, an OAuth2PermissionGrant represents delegated permission consent, while application permissions are represented through an appRoleAssignment.

This distinction can appear in advanced scenario questions involving Microsoft Graph or automation.


17. Managing Granted Permissions

Administrators should periodically review applications that have received OAuth permissions.

Look for:

  • Applications no longer in use
  • Excessive permissions
  • Unexpected applications
  • Permissions granted by users who should no longer have access
  • Applications from untrusted publishers
  • Permissions that are broader than the application’s business purpose

Unused or excessive permissions should be removed.

The security principle is straightforward:

Grant only what is necessary, and remove access when it is no longer necessary.


18. Revoking Consent

If an application is compromised, no longer trusted, or no longer required, administrators can revoke its previously granted permissions.

Revocation removes the authorization that allowed the application to access the protected resource.

Administrators can also limit application access through controls such as:

  • Requiring user assignment
  • Disabling user sign-in to the application
  • Removing permissions
  • Disabling or removing the enterprise application

Revoking consent should be considered part of the application’s lifecycle management, not simply an incident-response activity.


19. Updating Application Permissions

Application requirements can change.

Suppose an application originally requested:

  • User.Read

Later, the developer adds a requirement for:

  • Group.Read.All

Adding the new permission to the app registration does not automatically mean that existing users or administrators have already consented to the new permission.

The additional permission may require a new consent operation.

If the new permission requires administrator consent, an administrator must provide the required consent.

This is important when troubleshooting applications that suddenly begin displaying consent prompts or fail when requesting access tokens.


20. App Registration vs. Enterprise Application

Understanding the relationship between these two objects is important when managing OAuth permissions.

App registration

An app registration represents the application’s identity and configuration in Microsoft Entra.

It contains configuration such as:

  • Application/client ID
  • Redirect URIs
  • API permissions
  • Authentication configuration
  • Credentials or certificates
  • Exposed APIs

Enterprise application

An enterprise application is the service principal representation of an application in a particular tenant.

It is used for tenant-specific management such as:

  • User and group assignment
  • Application access
  • Permissions and consent
  • Sign-in controls
  • Enterprise application properties

A useful mental model is:

App registration = definition of the application

Enterprise application/service principal = application’s presence and management representation in a tenant

OAuth consent is closely associated with the enterprise application/service principal because the actual authorization applies within a tenant.


21. Security Principle: Least Privilege

OAuth permission management should follow the principle of least privilege.

For example, if an application only needs to read calendar information, don’t approve permissions that allow it to:

  • Modify calendars
  • Read mailboxes
  • Delete files
  • Manage users
  • Access all organizational data

The more powerful the permission, the more carefully it should be evaluated.

Application permissions deserve particular attention because they can allow an application to access organizational data without an interactive user.


22. Common SC-500 Scenarios

Scenario 1: Users should be able to authorize low-risk applications

Use appropriately configured user consent settings and permission classifications.


Scenario 2: Users must never authorize applications themselves

Configure user consent so that administrator approval is required.


Scenario 3: A user needs an application that requires admin approval

Configure the admin consent workflow so the user can submit an approval request.


Scenario 4: A background service must access Microsoft Graph without a user

Use application permissions and obtain administrator consent.


Scenario 5: A web application needs to access a user’s files

Use delegated permissions because the application is operating on behalf of a signed-in user.


Scenario 6: An application has excessive permissions

Review the application’s requested permissions and reduce them according to least privilege.


Scenario 7: An application is no longer trusted

Revoke its consent and, where appropriate, disable access to the enterprise application.


23. Important Exam Distinctions

Memorize these distinctions:

If the question says…Think…
“On behalf of the signed-in user”Delegated permission
“Without a signed-in user”Application permission
“Background service”Application permission
“User’s files”Delegated permission
“Organization-wide access”Potentially application permission or tenant-wide admin consent
“Allow users to approve low-risk apps”User consent settings
“Users cannot approve the requested permission”Admin consent
“User requests administrator approval”Admin consent workflow
“Approve for everyone in the organization”Tenant-wide admin consent
“Limit who can access the application”User/group assignment
“Remove previously granted authorization”Revoke consent
“Excessive permissions”Least privilege
“Who published the application?”Publisher/trust evaluation
“No signed-in user”Application permission
“Application acting on behalf of user”Delegated permission

24. Key Takeaways

For the SC-500 exam, remember the following:

  1. Delegated permissions allow an application to act on behalf of a signed-in user.
  2. Application permissions allow an application to act without a signed-in user.
  3. Application permissions generally require administrator consent.
  4. User consent can be controlled through Microsoft Entra user consent settings.
  5. Administrators can restrict consent based on application and permission characteristics.
  6. Tenant-wide admin consent authorizes requested permissions for the organization.
  7. Tenant-wide consent does not necessarily mean every user must be allowed to use the application; access can still be restricted.
  8. The admin consent workflow provides a structured mechanism for users to request approval.
  9. Reviewers in the admin consent workflow must have the appropriate permissions to grant consent.
  10. Always evaluate the application, publisher, permissions, and business justification before granting consent.
  11. Use least privilege when approving OAuth permissions.
  12. Regularly review and revoke unnecessary or suspicious application permissions.
  13. Adding new API permissions does not automatically mean those permissions have already been consented to.
  14. For Microsoft Graph, delegated OAuth authorization is represented by an OAuth2 permission grant, while application permissions are represented through app role assignments.
  15. Understanding the difference between an app registration and an enterprise application/service principal is important when managing application access.

Practice Exam Questions

Question 1

A company has a web application that allows employees to view documents stored in Microsoft Graph. Employees must sign in to the application, and the application should access only resources that the signed-in employee is authorized to access.

Which type of Microsoft Entra permission should the application primarily use?

A. Azure RBAC role

B. Application permission

C. Delegated permission

D. Managed identity role assignment

Answer: C. Delegated permission

Explanation

Delegated permissions are designed for applications that access resources on behalf of a signed-in user. The user’s identity is part of the authorization context.

Application permissions are intended for app-only scenarios where there is no signed-in user. Azure RBAC is used for Azure resource authorization and isn’t a replacement for Microsoft Graph OAuth delegated permissions.


Question 2

An organization wants a background service to access Microsoft Graph every night. The service must continue operating even when no users are signed in.

Which permission model should be used?

A. Delegated permissions

B. Application permissions

C. User consent permissions

D. Interactive authentication only

Answer: B. Application permissions

Explanation

The service needs to operate without a signed-in user, making this an app-only scenario. Application permissions are designed for background services, daemons, and other workloads that authenticate as the application itself.

Application permissions require administrator consent.


Question 3

A security administrator wants to prevent users from independently granting OAuth consent to applications because of concerns about malicious applications accessing organizational data.

What should the administrator configure?

A. Azure Policy

B. Azure RBAC

C. Microsoft Entra user consent settings

D. Network security groups

Answer: C. Microsoft Entra user consent settings

Explanation

Microsoft Entra user consent settings control whether and under what circumstances users can grant applications access to protected resources.

Azure Policy and Azure RBAC address different security areas and don’t control Microsoft Entra OAuth user consent.


Question 4

A user attempts to access an application that requires permissions for which the user isn’t authorized to provide consent. The organization wants the user to be able to submit the request to an administrator for review.

Which feature should be configured?

A. Application Proxy

B. Conditional Access

C. Privileged Identity Management

D. Admin consent workflow

Answer: D. Admin consent workflow

Explanation

The admin consent workflow allows users to submit requests for applications that require administrator approval.

Designated reviewers can evaluate the requests and approve or deny them. Being a reviewer does not automatically grant the reviewer permission to provide admin consent.


Question 5

An administrator is reviewing an application that requests tenant-wide permission to read organizational data. The administrator wants to determine whether the requested access is appropriate before approving it.

Which consideration should be the highest priority?

A. Whether the requested permissions follow least privilege and match the application’s business purpose

B. Whether the application has the most attractive user interface

C. Whether the application has the largest number of users

D. Whether the application was registered recently

Answer: A. Whether the requested permissions follow least privilege and match the application’s business purpose

Explanation

Tenant-wide consent can grant significant organizational access. Administrators should evaluate the requested permissions, publisher, application purpose, and whether the permissions are necessary.

The most important security principle is least privilege: grant only the access required for the application’s legitimate function.


Question 6

A company grants tenant-wide administrator consent to an application but wants only members of the Finance group to be able to use it.

What should the administrator configure?

A. Remove the tenant-wide consent

B. Require user assignment to the enterprise application

C. Convert application permissions to Azure RBAC

D. Disable all Microsoft Graph permissions

Answer: B. Require user assignment to the enterprise application

Explanation

Tenant-wide consent and application access are separate concerns.

The organization can grant the necessary consent while requiring users or groups to be assigned to the enterprise application. This allows the company to restrict application access to the Finance group.


Question 7

An application originally requested User.Read. Several months later, the developer adds Group.Read.All. Existing users begin seeing new consent requirements.

Why can this occur?

A. OAuth permissions automatically expire after six months

B. Microsoft Graph requires users to authenticate every time

C. The newly requested permission may not have been previously consented to

D. User assignment automatically removes all previous permissions

Answer: C. The newly requested permission may not have been previously consented to

Explanation

Adding a new API permission to an application does not automatically mean that users or administrators have already granted consent for that permission.

If the new permission requires consent, a new consent operation may be necessary. If it requires administrator consent, an administrator must provide the required authorization.


Question 8

A security team discovers that an application has been granted delegated permissions that are no longer required. The application is still used by the organization.

What is the best security action?

A. Grant additional permissions to ensure compatibility

B. Convert all delegated permissions to application permissions

C. Delete the Microsoft Entra tenant

D. Review and revoke unnecessary permissions

Answer: D. Review and revoke unnecessary permissions

Explanation

Unused permissions increase the application’s potential attack surface.

The correct approach is to review the permissions and remove those that are no longer necessary. This supports the principle of least privilege while allowing the application to remain in use.


Question 9

A security administrator is examining a Microsoft Graph authorization record and wants to determine whether it represents delegated OAuth consent rather than an application permission assignment.

Which object is associated with delegated OAuth permission grants?

A. OAuth2PermissionGrant

B. NetworkSecurityGroup

C. RoleAssignment

D. ConditionalAccessPolicy

Answer: A. OAuth2PermissionGrant

Explanation

For Microsoft Graph, an OAuth2PermissionGrant represents delegated permission consent.

Application permissions are represented through app role assignments.

This distinction is useful when reviewing Microsoft Graph data programmatically or troubleshooting application authorization.


Question 10

A company wants to allow users to provide consent for applications from trusted publishers when they request only specifically approved permissions. All other applications or permissions should require administrator approval.

Which approach best meets this requirement?

A. Give all users the Application Administrator role

B. Configure user consent settings and restrict which applications and permissions users can approve

C. Grant tenant-wide administrator consent to every application

D. Disable Microsoft Graph for the entire tenant

Answer: B. Configure user consent settings and restrict which applications and permissions users can approve

Explanation

Microsoft Entra user consent settings can be configured to control when users are allowed to provide consent. Organizations can use restrictive consent policies and permission classifications to permit appropriate self-service consent while requiring administrator approval for higher-risk scenarios.

Granting users administrative application-management privileges or granting consent to every application would substantially weaken the security model.


Go to the SC-500 Exam Prep Hub main page