SC-500 Microsoft Entra ID Access: PIM, Conditional Access, MFA, App Identity and Managed Identities

Privileged Identity Management (PIM) replaces standing privileged access with just-in-time access: a user who is eligible for a role holds nothing until they activate it, the activation lasts a limited time, and every activation is recorded in the PIM audit history. PIM needs Microsoft Entra ID P2 or Microsoft Entra ID Governance licences for the users it covers.

Every PIM assignment answers two separate questions, and keeping them apart is the key to most PIM scenarios:

So "no standing privilege" means eligible; "access must end on a known date without a manual cleanup" means time-bound. A contractor who occasionally needs a role for three months gets a time-bound eligible assignment. An active time-bound assignment still gives standing access until the end date, and an access review only re-checks who should keep an assignment periodically — neither removes standing privilege on its own.

Emergency access accounts are the deliberate exception

Microsoft recommends at least two cloud-only emergency access (break-glass) accounts that stay permanently active Global Administrators. If every Global Administrator were eligible, activation would depend on MFA, Conditional Access and approvers; an outage of any of those could leave nobody able to administer the tenant. Day-to-day administrators become eligible; the break-glass accounts stay active, are excluded from the policies that could lock them out, use a strong credential such as a FIDO2 passkey, and are monitored with alerts on every sign-in. Any eligible assignment, with or without approval, makes the account depend on PIM activation, which defeats the purpose of an emergency account.

Role settings control what activation requires and how long it lasts, separately for each role, without touching who is eligible. They are configured per Microsoft Entra role, per Azure resource role, and per group in PIM for Groups.

• Activation maximum duration (1 to 24 hours for Microsoft Entra roles) caps how long each activation lasts. Shortening it reduces how long privileged access stays live after each activation; it does not affect eligibility.
• Assignment expiration settings (allow permanent eligible / active assignments, or expire them after a set period) control how long the assignment lasts, not each activation.
• On activation, require multifactor authentication asks for MFA — but if the user already completed MFA earlier in the session, PIM may not prompt again, and it does not control which method was used.
• On activation, require Microsoft Entra Conditional Access authentication context links activation to an authentication context. A Conditional Access policy targeting that context can then require an authentication strength such as phishing-resistant MFA, so the user must step up at activation even if they signed in earlier with a password and a push notification. The two activation options are alternatives — choose one.
• Require justification and require ticket information record why the role was activated; the ticket number is captured for audit but not validated against a ticketing system.
• Require approval to activate sends each request to the approvers you name (users or groups); if you name none, privileged role administrators and global administrators approve.
• Require MFA on active assignment applies when an administrator creates an active assignment — it is not an activation control.

Notification settings send emails when roles are assigned or activated, so security staff see elevations as they happen.

PIM for Azure resources and PIM for Groups

PIM covers more than Microsoft Entra roles: it can make Azure RBAC role assignments (Owner, Contributor, User Access Administrator and any other Azure role) eligible at management group, subscription, resource group or resource scope, and it can make group membership or ownership eligible through PIM for Groups.

• PIM for Azure resources — developers who need Owner on a production subscription a few times a month get an eligible Owner assignment at the subscription scope, with the same activation, approval and audit features used for Entra roles. A custom Microsoft Entra role cannot grant Azure resource permissions (Entra roles and Azure roles are separate systems), and an RBAC condition only narrows what an assignment allows — neither gives just-in-time activation.
• PIM for Groups — when one group carries access (Azure role assignments on several subscriptions, an Entra role on a role-assignable group, app assignments), make membership of that group eligible. Activating membership grants everything the group holds at once, and when the group's access changes later you change the group's assignments, not each user's. Making every underlying role eligible per user would multiply the administration.

Do not confuse PIM with just-in-time VM access in Microsoft Defender for Cloud, which opens network ports on a VM for a limited time. It controls network reachability, not role membership.

A Conditional Access policy is an if-then rule evaluated after first-factor authentication: if the assignments match (users, target resources, conditions) then the access controls apply (block, or grant with requirements, plus session controls). Policies that match are combined, and every requirement of every matching policy must be met. Conditional Access requires Microsoft Entra ID P1.

Two tools test a policy before it hurts anyone, and they answer different questions:

Assigning a policy to a pilot group or test user does enforce it on those users; it limits the blast radius but is not a no-impact measurement. A past sign-in's Conditional Access tab only shows what happened to sign-ins that already occurred; to predict the outcome for a sign-in that has not happened yet, use the What If tool with the user, app, location and device conditions you want to test.

Avoiding tenant lockout

Microsoft's guidance for broad policies (all users, all resources, compliant device, block by location) is to exclude the emergency access accounts and to run the policy in report-only mode first. Excluding a whole directory role or a trusted location leaves a large hole in the policy rather than a narrow, monitored exception, and adding MFA as an alternative grant changes the policy's meaning instead of protecting against lockout.

Conditions narrow when a policy applies. The ones this topic leans on most are client apps, locations and device filters (sign-in and user risk conditions come from Microsoft Entra ID Protection and need P2).

• Client apps → legacy authentication. The client apps condition separates modern clients (Browser and Mobile apps and desktop clients) from legacy authentication (Exchange ActiveSync clients and Other clients, such as older mail protocols using basic authentication). Legacy protocols cannot perform MFA, which is why password-spray attacks target them. A policy with the legacy client app types selected and Block access stops them while modern Outlook and browser clients keep working. A sign-in risk condition only catches what ID Protection scores as risky.
• Named locations. An IP ranges location lists public IPv4/IPv6 ranges (for example, office egress addresses) and can be marked as trusted; every named location is reusable by any policy, and marking one trusted lowers the sign-in risk calculated by ID Protection and makes it match the "All trusted locations" condition. A countries location matches by country (from the IP address, or GPS from Authenticator) and cannot be marked trusted. Requiring MFA except from the offices means: create the trusted IP ranges location first, then exclude it in the policy.
• Filter for devices matches device attributes (for example, model, operating system, or extension attributes) to include or exclude specific devices, such as privileged access workstations.
• Device platforms match the operating system reported by the client; "unknown platforms" catches unusual clients, not legacy protocols.

Grant controls decide what a user must satisfy to get in; session controls shape what happens after.

Authentication strengths

An authentication strength is a grant control that names which method combinations are acceptable, which plain "Require multifactor authentication" does not — a push notification relayed by an adversary-in-the-middle phishing kit satisfies "MFA". Microsoft provides three built-in strengths, and you can create custom ones:

When a requirement lists exact methods (for example, "passkeys or Windows Hello for Business, and nothing else"), only a custom strength matches; the built-in strengths each allow more. Authentication strengths can also be required through an authentication context — the mechanism PIM activation and sensitive app actions use for step-up.

Session controls

• Sign-in frequency sets how often users must reauthenticate (a number of hours or days, or every time). "Reauthenticate every 4 hours on unmanaged devices" is a sign-in frequency session control in a policy scoped to those devices.
• Persistent browser session only decides whether a browser session survives closing and reopening the browser; it does not set an interval.
• Continuous access evaluation (CAE) lets supporting resources (such as Exchange Online and SharePoint Online) revoke access in near real time after critical events such as user disablement, password reset or a network location change. Customising CAE (for example, strict location enforcement) refines that behaviour — it is not a reauthentication timer.
• App enforced restrictions and Conditional Access App Control pass device state to supported apps or route sessions through Microsoft Defender for Cloud Apps for in-session control.

The Authentication methods policy is the one place where you enable methods and choose which users and groups may register and use them, for both sign-in and self-service password reset (SSPR). Management of methods in the legacy MFA and SSPR policies ended on 30 September 2025, so methods are now enabled only in the Authentication methods policy.

The division of labour is: the methods policy enables a method for a group (for example, passkeys for an IT-Pilot group while others keep their current methods); Conditional Access requires it (through an authentication strength). An authentication strength cannot make a method available to users who are not enabled for it, and Conditional Access does not enable methods.

Temporary Access Pass (TAP)

A Temporary Access Pass is a time-limited passcode, issued by an administrator, that satisfies strong authentication. Its main job is passwordless onboarding: a new hire who is never given a password signs in with a TAP and registers a passkey, Windows Hello for Business or Authenticator. It also recovers users who lost their only strong method.

TAP settings in the methods policy include:

• Minimum lifetime and maximum lifetime — the range an issuer may choose from. The maximum is what stops anyone issuing a pass that lasts longer than policy allows.
• Default lifetime — only the pre-filled value; an issuer can change it within the minimum/maximum range.
• One-time use — when set, each pass works for a single sign-in.
• Length — the number of characters in the pass.

Self-service password reset recovers an existing password-based account by proving registered methods; it assumes the user has already registered, so it cannot bootstrap the first credential.

Passwordless and phishing-resistant methods

Passwordless methods replace the password with something the user has plus a PIN or biometric; phishing-resistant methods additionally bind the sign-in to the real site's origin, so a relayed or proxied sign-in fails. Not every passwordless method is phishing-resistant.

Two distinctions decide most scenarios:

• Shared or roaming workstations need a credential that travels with the user — a passkey on a security key or in Authenticator. Windows Hello for Business is phishing-resistant but tied to the PC it was provisioned on.
• Smart cards and PIV/CAC cards map to Microsoft Entra certificate-based authentication (CBA), which validates the user's certificate directly against certificate authorities uploaded to Entra ID. Organisations use it to stop federating with AD FS just for smart-card sign-in. Whether a CBA sign-in counts as single-factor or multifactor depends on the CBA binding rules; only multifactor CBA satisfies the phishing-resistant strength.

An app registration is the application object — the app's global definition, which lives in its home tenant; an enterprise application is a service principal — the app's local instance in each tenant that uses it.

Consequences you are expected to reason with:

• When a customer's administrator consents to a multitenant app, a service principal is created in the customer tenant — not a copy of the application object.
• A vendor changing a redirect URI or replacing a credential does it once in the app registration in its own tenant; every customer's service principal follows it.
• Supported account types decide who can sign in: this organizational directory only (single-tenant), any organizational directory (multitenant), optionally plus personal Microsoft accounts. To let a partner's users sign in with their own work accounts, with the partner's admins consenting and no accounts created in your tenant, make the app multitenant. Inviting them as B2B guests would create guest accounts in your directory that you then manage.

Controlling who can use an enterprise application

Three properties on the enterprise application decide who can sign in and who sees the app:

By default (Assignment required = No) any user in the tenant can sign in to an app. API permissions describe what the app may call, and app roles describe what an already-signed-in user may do inside it, so neither restricts who can sign in; setting Assignment required to Yes and assigning the right group does. Owners of an app registration manage its configuration — ownership is not access.

Group assignment is not transitive. Assigning a group to an app covers its direct members only; members of a group nested inside the assigned group are not treated as assigned. Assign the nested group itself (group-based assignment requires Microsoft Entra ID P1 or higher).

An app registration authenticates as itself with a client secret, a certificate or a federated identity credential, and Microsoft recommends moving away from secrets.

• Client secret — a string password. It can be copied from wherever it is stored, it expires and must be rotated, and shortening its life or moving it into Key Vault still leaves a long-lived secret that something must read.
• Certificate — the app proves possession of a private key by signing a client assertion. The private key can sit in a protected certificate store (or HSM) and is never sent anywhere. Use it for workloads outside Azure that have no managed identity and no external identity provider, such as a service on an on-premises server that is not Azure Arc-enabled.
• Federated identity credential (workload identity federation) — the app trusts tokens issued by an external OpenID Connect identity provider for a specific subject (for example, a GitHub Actions workflow for a given repository and branch or environment, a Kubernetes service account, or another cloud's workload identity). The workload exchanges its own token for a Microsoft Entra token, so no secret is stored and nothing needs rotating. Adding the credential to the existing app registration keeps the role assignments already granted to its service principal. A federated credential needs a real OIDC issuer — it cannot trust a host name.

For code running on Azure resources, a managed identity (below) is simpler still; federated credentials exist for workloads that run elsewhere.

Consent is how an app gets permission to call an API: a user consents for themselves to delegated permissions, or an administrator consents on behalf of the whole organization. The consent settings decide which requests users may approve on their own.

• Delegated permissions act on behalf of a signed-in user (for example, Mail.Read reads that user's mail). Low-impact delegated permissions can be user-consented if the settings allow it; high-privilege ones need admin consent.
• Application permissions act as the app itself with no user present, across the whole tenant, and always need admin consent.

User consent settings (Enterprise applications > Consent and permissions) map to built-in app consent policies:

Microsoft also offers a Microsoft-managed recommended setting. With Microsoft Graph PowerShell you assign a policy by adding managePermissionGrantsForSelf.<policy-id> to the default user role permissions of the authorization policy; removing it is the same as "Do not allow".

Permission classifications define what "selected permissions" means: you classify specific delegated permissions (commonly User.Read, openid, profile, email, offline_access) as low impact. If a verified publisher's app asking only for such permissions still sends users to an admin, those permissions have not been classified — classify them rather than widening consent to all apps.

Admin consent workflow and reviewing existing grants

The admin consent workflow lets users who cannot consent request an app from the consent prompt itself, and routes each request to designated reviewers who approve or deny it, with the decision recorded. You choose the reviewers (users, groups or roles), whether they get email notifications, and how many days a request stays open. It is the tracked alternative to users emailing the help desk when user consent is disabled or restricted. (Entitlement management access packages are a separate feature: they bundle access to resources such as groups, apps and SharePoint sites for request and approval, rather than governing app consent.)

Changing settings does not revoke existing grants

Consent settings and app consent policies apply to future consent requests only. A grant that already exists — for example, a user's delegated Mail.Read consent to a malicious multitenant app — keeps working until you remove it. Responding to an illicit consent grant means:

1. Stop new tokens: set Enabled for users to sign in to No on the app's enterprise application (tokens already issued remain valid until they expire, so act quickly).
2. Remove the grant: review the app's permissions on its enterprise application and delete the delegated permission grant (an oauth2PermissionGrant; application permissions are app role assignments) with Microsoft Graph or PowerShell.
3. Investigate what the app accessed using the sign-in and audit logs.

A multitenant app's registration lives in the publisher's tenant, so there is nothing to delete under your App registrations, and removing the user's app assignment does not stop an app that does not require assignment.

A managed identity is a Microsoft Entra identity that Azure creates and manages for an Azure resource, so code on that resource gets tokens without any credential to store or rotate. There are two types:

The "access granted in advance" case matters: a system-assigned identity does not exist until its resource is created, so its role assignment can only be made afterwards, by someone allowed to create role assignments. When resources are created and deleted constantly, or the security team must grant data access ahead of time through a change process, they pre-authorize a user-assigned identity once and the pipeline simply attaches it, so the pipeline needs only permission to assign that identity to its resources (Managed Identity Operator), not permission to create role assignments.

Using a managed identity

• Getting a token: code asks a local endpoint — on a VM, the Azure Instance Metadata Service (IMDS) endpoint; on App Service and Functions, the platform's local identity endpoint — usually through the Azure Identity SDK. No secret or certificate is ever visible to the code.
• Authorization is separate. A token proves who the resource is, not what it may do. The identity still needs an Azure RBAC role assignment on the target (for example, Storage Blob Data Reader for blobs, Key Vault Secrets User for secrets) or the target's own data-plane permissions. A token followed by HTTP 403 means the role assignment is missing. Managed identities need no client secret and no consent prompt for Azure resource access. (For Microsoft Graph, an administrator grants a managed identity application permissions directly as app role assignments, for example with PowerShell.)
• Azure SQL Database authorizes at the data plane: a Microsoft Entra admin must be set on the logical server (so it can resolve Entra identities), then a contained database user is created with CREATE USER [name] FROM EXTERNAL PROVIDER and given a database role such as db_datareader. Azure RBAC roles like SQL DB Contributor manage the database resource, not its data, and making the app's identity the server's Entra admin would give it far more than least privilege.
• Where they don't apply: managed identities exist only for Azure resources (and Azure Arc-enabled servers). A workload on a non-Arc on-premises server uses a certificate credential, and a workload with its own OIDC tokens (such as GitHub Actions) uses a federated identity credential.

Granting the identity access to Key Vault in depth, and creating custom roles, belong to the sibling topics on Key Vault and governance.