Secure access to resources by using Microsoft Entra ID

An administrator activates the Global Administrator role for two hours, signs in with a passkey, is challenged for a compliant device, opens a reporting app that reads her mailbox through Microsoft Graph (the API through which applications read and write tenant data), and starts a function app that writes to a storage account. Five separate Microsoft Entra ID controls just made five separate decisions, and the whole of this page is those five.

This page covers the identity slice of the domain. Its sibling page on Azure Key Vault deals with where a workload's secrets, keys, and certificates are stored, and the governance page describes Azure role assignments, Azure Policy, and compliance reporting over resources. Here the subject is Microsoft Entra ID itself: who holds a privileged role and for how long, which credential proves a user, what must be true at the moment of sign-in, what an application may do with data, and how code authenticates when no person is involved.

Control	Question it answers	Where you configure it
Assignment	Is this role standing, or activated for a task?	Privileged Identity Management[1]
Credential	Which methods may this user register and use?	Authentication methods policy[2]
Condition	What must be true about this sign-in?	Conditional Access[3]
Consent	What may this application do with data?	Permissions and consent[4]
Workload identity	How does code prove who it is?	Managed identities[5]

Those five names are used the same way in every section, table, and figure below. The figure below traces one access path through them: a person meets the first four in order, while code with no signed-in user takes the workload-identity path to the same resource.

Two properties of this model matter more than any individual feature. First, the controls are configured independently, so satisfying one says nothing about another. An eligible role still has to survive the Conditional Access policy that guards the sign-in used to activate it, and an application with tenant-wide consent still needs a user who is permitted to sign in to it.

Second, the model does not evaluate the way the rest of Azure does, and the shared vocabulary hides the difference. Azure role-based access control (RBAC) is additive: effective permissions are the union of every assignment at every applicable scope, so adding an assignment can only widen access. That model is taught on the governance page. Conditional Access is the opposite shape: every policy that applies must be satisfied, and one policy using the block control ends the sign-in. Network rule sets on the storage and networking pages introduce yet a third shape, priority-ordered rules where the first match wins. Three different evaluation models share the words allow, deny, and policy, and reading one page's rule into another is a reliable way to get a question wrong.

An eligible assignment is not a weaker role, it is no role at all until the assignee activates it. Privileged Identity Management (PIM) offers exactly two assignment types for a Microsoft Entra role or an Azure resource role: an active assignment carries the role continuously from the moment it is made, and an eligible assignment carries nothing until the user completes the activation steps configured for that role (Privileged Identity Management^[1]). Just-in-time privilege is that difference and nothing more: no component watches for a risky moment and elevates the user, the grant is simply time-boxed and has to be asked for. The figure below follows one elevation from eligible, through the gates, to expiry.

The gates on activation

Role settings, also called PIM policies, decide what an activation request has to survive (Configure Microsoft Entra role settings in PIM^[6]). Four are commonly confused, and only one of them stops anybody:

• On activation, require multifactor authentication asks the user to prove possession of a second factor. Users might not be prompted at all if they already authenticated with strong credentials or completed multifactor authentication (MFA) earlier in the session, so this setting does not guarantee a fresh challenge.
• On activation, require Microsoft Entra Conditional Access authentication context points the activation at a Conditional Access policy, which is how you demand a specific method, a device marked compliant in Microsoft Intune, or terms of use. To force reauthentication on every activation, the policy targeting that authentication context sets sign-in frequency to Every time under session controls. Even then, a 10-minute window applies after one reauthentication, during which activating another eligible role does not prompt again, and that window spans Microsoft Entra roles, Azure resource roles, and PIM for Groups.
• Require justification on activation records a business reason. It is an audit artifact, not an approval: nobody reads it before the role is granted.
• Require approval to activate is the only setting that puts a human between the request and the privilege. Select at least one approver, and Microsoft recommends at least two. For Microsoft Entra roles, if no approver is configured, active Privileged Role Administrators and Global Administrators become the default approvers.

Two durations that look alike

Activation maximum duration caps how long a single elevation stays active before it expires, from 1 to 24 hours. Expire eligible assignment after (and its active counterpart) caps how long the assignment itself exists, in days or months. A request to limit each elevation to four hours is answered by the first setting; the second would only decide when the person stops being eligible at all, leaving each individual elevation as long as ever.

Where the settings apply

Role settings are defined per role, and all assignments for the same role follow them; the settings of one role are independent of another's. For Azure resource roles there is a second axis: settings are defined per role and per resource, and the docs are explicit that settings configured at a higher level such as a subscription are not inherited at a lower level such as a resource group (Configure Azure resource role settings in PIM^[7]). Configuring an approval requirement once at the top of a subscription and assuming every resource group beneath it inherits the gate leaves those child scopes wide open, which is why the same role settings have to be configured at each resource where eligible assignments exist. Three lines are worth carrying out of all this: approval is the only setting that interposes a human, Activation maximum duration is the only one that bounds a single elevation, and for Azure resource roles neither of them reaches a scope where it was not configured.

Privilege that was justified in March is not automatically justified in September. Three PIM features deal with privileged access once it exists: an access review, which asks whether the access is still needed, notification settings, which decide who hears about activity on a role, and audit history, which records what was already done with it.

Scope a review to the assignments that matter

Access reviews for Microsoft Entra roles and Azure resource roles are created inside PIM, and the setting that decides what lands in front of the reviewer is assignment type: eligible assignments only, active assignments only, or all active and eligible assignments (Create an access review of Azure resource and Microsoft Entra roles in PIM^[8]). A review of a role whose privileged access is all eligible finds nothing if it was scoped to active assignments only.

Three further settings decide what the review is worth. Reviewers can be selected users, the assignees themselves, or their manager with a fallback reviewer. Auto apply results to resource removes denied access automatically when the review ends; leave it disabled and the decisions sit there until an administrator applies them by hand. If reviewers don't respond decides the fate of unreviewed assignments, and its options run from no change through remove access to taking the system recommendation, which is based on whether the user signed in during the last 30 days. Reviews of more than one role create one review per role.

Route notifications to people who will act

Each role's Notifications tab controls who hears about activity on it. You can clear the default recipient checkbox to stop mails going to the built-in audience, add specific addresses separated by semicolons, or do both. Critical emails only narrows a given notification type to messages that require immediate action, so an approver keeps the mail asking them to approve an extension request but not the routine reminder to extend an assignment.

Keep the evidence

PIM's audit history records assignments and activations, and can be reviewed in the portal or downloaded for internal or external auditors (View audit history for Microsoft Entra roles in PIM^[9]). Treat them as a set: the eligible assignment limits standing privilege, the access review removes what is no longer needed, the notifications put activity in front of someone who will act on it, and the audit history is what you hand an auditor who asks who held Global Administrator on a given day and what they did with it.

A Conditional Access policy is an if-then statement made of assignments, which decide when the policy applies, and access controls, which decide what happens when it does (Build Conditional Access policies^[3]). The minimum enforceable policy is a name, users or workload identities, target resources, and a grant or block control; everything else narrows it.

Assignments have four parts, and all configured assignments are combined with AND, so every one of them must match before the policy does anything:

• Users include or exclude all users, groups, directory roles, or guests. Policies targeting roles or groups are evaluated when a token is issued, so a user added to a targeted group is not subject to the policy until they get a new token.
• Target resources are cloud applications, user actions, or authentication contexts, the last being the hook that PIM activation uses.
• Network covers IP ranges and countries, some of which you can mark as trusted locations.
• Conditions add sign-in risk and user risk from Microsoft Entra ID Protection, device platform, client apps, and device filters. Device platform comes from the user agent string, an unverified source, so it is a usability signal rather than a security boundary.

Access controls come in two families. Grant either blocks access outright or grants it subject to controls such as require multifactor authentication, require authentication strength (a named set of methods that will satisfy the policy, covered in Require the right method with authentication strength below), require a device marked compliant, require a Microsoft Entra hybrid joined device, require an approved client app or app protection policy, require a password change, or require terms of use. Multiple selected controls default to requiring all of them; the alternative is requiring one of them. Session controls then shape what the granted session may do, including sign-in frequency, persistent browser session, app-enforced restrictions, and Conditional Access App Control through Microsoft Defender for Cloud Apps.

Enforcement runs in two phases, and the second one is where the exam questions live. Phase 1 collects session details for both enabled and report-only policies. Phase 2 identifies unmet requirements: if any applicable policy is configured with the block control, enforcement stops there and the user is blocked; otherwise the user is prompted for the outstanding grant controls in a fixed order until every policy is satisfied. The figure below traces that evaluation.

Two consequences are worth stating plainly, because they are what distractors are built from. There is no priority number on a Conditional Access policy: you cannot place a permissive policy above a restrictive one, the way a first-match-wins network rule set works on the storage and networking pages. And a grant in one policy never cancels a block in another, because the policies are combined, not ranked. When one specific identity must be exempt, the exemption is an explicit exclusion inside the policy that would otherwise catch it, since an exclusion always beats that identity's inclusion in the same policy.

A tenant-wide Conditional Access policy can lock every administrator out of the tenant in one save, and the two defences are a rehearsal and an escape hatch.

The rehearsal is report-only mode, a policy state in which conditions are evaluated on every sign-in and the results are written to the sign-in logs, but no user is blocked and required controls are not enforced; report-only policies that require a compliant device can still prompt macOS, iOS, and Android users to select a device certificate, so a prompt during report-only evaluation is not a control being enforced (Conditional Access report-only mode^[10]). Open a sign-in in Entra ID > Monitoring & health > Sign-in logs, select the Conditional Access tab, and each policy shows as satisfied, failed, or not applied for that specific sign-in. To ask the question ahead of any real sign-in, the What If tool on the same Conditional Access blade evaluates a hypothetical user, application, and condition set against your current policies. Neither is the same as reading audit logs after enforcement begins, which tells you what already broke.

The escape hatch is a set of emergency access accounts, also called break-glass accounts: cloud-only accounts with a strong credential, not tied to any one person's device or phone, excluded from the broad policies so a misconfiguration cannot lock everyone out (Manage emergency access accounts^[11]). Excluding them is not a hole in the policy so much as the reason the policy can be strict at all, and the practice is paired with monitoring: alert on every sign-in by those accounts, because a legitimate one is rare.

PIM has its own version of the same trap. If every Privileged Role Administrator and Global Administrator holds only an eligible assignment, approval is required to activate, and no approver is configured, nobody can approve anybody and the tenant is locked out: the default approvers from the elevation section are the active holders of those roles, and this tenant has none. Emergency access accounts plus explicitly named approvers are what prevent it.

The takeaway is a sequence, not a preference: create the policy in report-only mode, exclude the emergency access accounts, read the Conditional Access results in the sign-in logs or model them in What If, and only then turn the policy on.

A script that authenticates with its own credentials is not a user, and a Conditional Access policy scoped to users never sees it. Applications and service principals sign in with a client credential and cannot perform multifactor authentication, so the user-facing controls have no meaning for them; the answer is Conditional Access for workload identities, which is assigned to service principals directly (Conditional Access for workload identities^[12]).

The feature is deliberately narrow, and its limits are what questions are built on:

• It applies to single-tenant service principals registered in your own tenant. Microsoft and third-party SaaS applications, including multitenant apps, are not covered.
• Managed identities are not covered by these policies either. Where a managed identity needs oversight, the documented alternative is to include it in an access review and to keep its role assignments minimal.
• A service principal can be a member of a group, but a policy assigned to that group is not enforced for it. The service principal must be assigned to the policy directly as a workload identity.
• Block access is the only available grant control. The supported conditions are location, service principal risk from Microsoft Entra ID Protection, and authentication context.
• Creating or modifying these policies requires Workload Identities Premium licensing.

Results appear under Sign-in logs > Service principal sign-ins, where each entry has its own Conditional Access tab, and the policy can be saved in report-only mode first exactly as a user policy can.

Adding the application owner's user account to an all-users policy does nothing for the application, because the account and the service principal are different identities making different token requests. Where the workload runs on an Azure host, the stronger move is to replace the script's stored credential with a managed identity, which is the subject of the last section on this page.

A user can only sign in with a credential they were allowed to register. The authentication methods policy is where that permission is granted: an Authentication Policy Administrator enables each method and targets it at all users or at specific groups, under Entra ID > Authentication methods > Policies (Manage authentication methods^[2]). Methods enabled there can generally be used anywhere in Microsoft Entra ID, for both sign-in and password reset, with a few methods inherently limited to one or the other. Two legacy policies under multifactor authentication settings and password reset settings once managed some of the same methods; since 30 September 2025, authentication methods can no longer be managed in them.

Match the method to the job

Not every method can do every job, and the capability table is the fact a scenario question turns on (Microsoft Entra authentication overview^[13]). Primary authentication is a first factor, secondary authentication is the MFA step, and the third column covers self-service password reset (SSPR) and account recovery. The list below is a selection, not the full table:

Method	Primary	Secondary (MFA)	SSPR / recovery
Password	Yes	No	No
Passkey (FIDO2)	Yes	MFA	No
Windows Hello for Business	Yes	MFA, when a passkey is registered	No
Microsoft Authenticator passwordless	Yes	No	No
Microsoft Authenticator push notifications	Yes	MFA	SSPR
Certificate-based authentication	Yes	MFA	No
Temporary Access Pass	Yes	MFA	No
Verified ID	No	No	Account recovery

Two rows in that table are the ones people get wrong. Microsoft Authenticator passwordless sign-in is a primary method only, while Authenticator push notifications also serve as a second factor and for SSPR. Primary only describes where a method sits in a sign-in, not what it proves: passwordless phone sign-in is never the second step after a password, and it still satisfies the multifactor and passwordless MFA strengths in the overview table. Verified ID is an identity verification capability rather than an authentication method: it provides cryptographic proof of identity for account recovery and cannot be used for sign-in, MFA, or SSPR.

Bootstrapping the first strong credential

A new user, or one who has lost their phone, has no usable method to authenticate with, which is what a Temporary Access Pass (TAP) solves. A TAP is a time-limited passcode, configurable for a single use or for multiple sign-ins during its validity, that lets a user sign in and register a passwordless method such as a passkey or Windows Hello for Business (Configure a Temporary Access Pass^[14]). It is enabled and targeted in the same authentication methods policy, and although a TAP can be created for any user, only users in scope of the policy can sign in with one. Pass lifetimes run from 10 minutes to 30 days, with a default lifetime of 1 hour and a default maximum of 8 hours, and when a one-time TAP is used to register a passwordless method the registration must be completed within 10 minutes of that sign-in.

Handing the user a permanent password instead achieves the opposite of the goal: it creates a phishable credential that outlives the onboarding, where the TAP expires on its own and never becomes a standing secret.

Enabling a method and requiring one are different jobs done by different features. The authentication methods policy from the previous section decides what a user may register; an authentication strength is a Conditional Access grant control that decides which of those registered methods will satisfy this particular policy (Conditional Access authentication strengths^[15]).

Three built-in strengths ship, and they cannot be modified: Multifactor authentication strength, Passwordless MFA strength, and Phishing-resistant MFA strength. A custom strength lets you name the exact combinations you accept. Phishing resistance is the sharpest line here, and it is a property of the method, not of the number of factors: the built-in phishing-resistant strength admits a passkey (FIDO2 security key), Windows Hello for Business or a platform credential, and multifactor certificate-based authentication, because each requires an interaction between the credential and the sign-in surface. A password plus an SMS code, a voice call, or a push notification satisfies MFA strength and fails phishing-resistant strength. The strength table in the overview above lists each method against all three strengths.

Three behaviours around the control catch people out:

• Require multifactor authentication and Require authentication strength cannot both be used in one Conditional Access policy, because the built-in multifactor authentication strength is the equivalent of the older control.
• A strength does not restrict the user's initial authentication. Conditional Access is evaluated after that first authentication, so a user can still type a password and is then required to complete a phishing-resistant method before continuing.
• A strength grants nothing by itself. If passkeys were never enabled for the target group in the authentication methods policy, the users in scope have no way to satisfy a phishing-resistant requirement, and the result is a support queue rather than security.

The strength control is also how the PIM activation gate becomes specific. Point a role's On activation, require Microsoft Entra Conditional Access authentication context setting at an authentication context, then write one Conditional Access policy for that context requiring the strength you want, as described in the elevation section above. That combination, rather than the plain MFA-on-activation setting, is what forces a nominated credential at elevation time.

Adding an application to a tenant can create two directory objects, and knowing which one a setting lives on answers a whole family of questions. The app registration is the global definition of the application: its application (client) ID, redirect URIs, credentials, the APIs it exposes, the permissions it requests, and its app-role definitions. The enterprise application is the service principal, the local instance of that application inside one tenant, and it holds everything tenant-specific: single sign-on, provisioning, user and group assignment, the Assignment required property, Conditional Access, and consent (Application and service principal objects^[16]).

The figure below shows how the objects relate. A multitenant application has one app registration in its home tenant and a separate service principal in every tenant that uses it; a gallery SaaS application you add has only a service principal in your tenant, because its registration lives with the vendor (What is application management^[17]). Deleting the service principal removes your tenant's instance along with its assignments and consent, and leaves the registration of a multitenant or gallery application untouched. You cannot configure per-tenant single sign-on or user assignment on an application that has only a registration and no service principal in your tenant, and editing your local enterprise application never changes the vendor's global definition.

Who may sign in to the application

On the enterprise application, Assignment required = Yes means only explicitly assigned users and groups can sign in to it; No means any user in the tenant can (Assign users and groups to an application^[18]). Group-based assignment requires Microsoft Entra ID P1 or P2, while assigning individual users works on the Free tier.

Group assignment has one behaviour that surprises almost everyone: it does not cascade through nested groups. Members of a subgroup of an assigned group receive no access, so each group that needs access is assigned directly, or its users are. App roles are declared in the app registration's manifest, assigned on the enterprise application, and emitted in the token's roles claim, the claim an application reads to decide what the caller may do inside it; where no app role is defined, Microsoft Entra assigns the well-known Default Access role.

Assignment answers who may sign in and, when the application exposes app roles, what role the assignee receives. What the application may then call is decided by consent, the subject of the next section, and an application that requires assignment must have its permissions consented by an administrator even where the tenant's user consent policy would otherwise let a user self-consent.

Requesting a permission and holding it are different states, and consent is the step between them. An application declares the permissions it wants on its app registration; nothing is granted until a user or an administrator consents, which creates the actual grant object in the tenant, the OAuth permission grant (Overview of permissions and consent^[4]).

There are two kinds of permission, and the difference decides who is even allowed to consent. Delegated permissions, also called scopes, are used when the application acts on behalf of a signed-in user: both the application and the user must be authorized, so the application can never reach data the user could not reach personally. Application permissions, also called app roles, are used when the application acts as itself with no user present, in a daemon or background service, and the application can then reach any data the permission covers across the tenant. Because there is no user whose privileges could bound it, only an administrator can consent to an application permission. The term app role appears in two senses on this page: here it names a permission the application itself holds, while in One application, two objects above it names a role the application defines for its own users. The figure below traces the resulting decision.

Converting an interactive workload to application permissions merely to stop a consent prompt therefore trades a bounded permission for an unbounded one, which is the opposite of least privilege.

Tune what users may consent to

The tenant's user consent setting has three positions (Configure how users consent to applications^[19]):

• Do not allow user consent, where only administrators consent.
• Allow user consent for apps from verified publishers, for selected permissions, the low-impact policy, which permits consent only to applications from a verified publisher or registered in your own tenant, and only to the permissions you have classified as low impact. Classifying those permissions is a prerequisite, not an option: with nothing classified, users can consent to nothing.
• Allow user consent for apps, which permits consent to any permission that does not itself require administrator consent.

Restricting consent without an escalation path just moves the problem to the help desk, so pair it with the admin consent workflow: a blocked user submits a justification from the consent prompt, and designated reviewers, who hold Global Administrator, Cloud Application Administrator, or Application Administrator, grant or deny the request (User and admin consent^[20]).

Preauthorize what the whole organization needs

Where a line-of-business application is meant for everyone, granting tenant-wide administrator consent to its delegated Microsoft Graph permissions creates the grant once for the organization, and users stop seeing the prompt entirely unless the application later requests a permission nobody has consented to. Adding permissions to the registration alone never achieves this, and neither does telling each user to consent when user consent is disabled: the permission list on a registration is a request, and the grant is a separate object created by the act of consenting. Cloud Application Administrator and Application Administrator can grant consent for most permissions, while permissions that grant privileged directory access require Privileged Role Administrator or Global Administrator (User and admin consent^[20]).

The safest client secret is the one that was never created. A managed identity is a service principal in Microsoft Entra ID whose credentials Azure issues and rotates for you, at no extra cost, so code running on a supported Azure host can request a token for a target service without a secret anywhere in its configuration (Managed identities for Azure resources^[5]).

Mechanically the flow is short, and the figure below traces it. Code calls the Azure Identity library or the Microsoft Authentication Library (MSAL), which contacts the identity endpoint local to the host, at the Azure Instance Metadata Service address 169.254.169.254^[21] for a virtual machine. The endpoint is reachable only from inside the resource, the request carries a Metadata: true header and a resource parameter naming the audience such as https://storage.azure.com/, and Microsoft Entra ID returns a JSON Web Token. The target service must support Microsoft Entra authentication for any of this to help.

Choose the identity type by lifecycle

A system-assigned managed identity is created on one Azure resource, shares that resource's lifecycle so deleting the resource deletes the identity, and cannot be shared with anything else. It is the better answer when the audit trail must name the exact resource that acted, and when access should disappear with the workload.

A user-assigned managed identity is a standalone Azure resource with its own lifecycle: it can be attached to many hosts, survives the deletion of any of them, and can be granted permissions before the workload it will serve even exists. Microsoft's own arithmetic makes the operational case: four virtual machines reaching two storage accounts need eight role assignments with system-assigned identities and two with one shared user-assigned identity (Managed identity best practice recommendations^[22]). A resource can carry a system-assigned identity and one or more user-assigned identities at the same time, and when a token request names no identity, the identity endpoint defaults to the system-assigned one where it exists, so a role granted only to a user-assigned identity comes back as an authorization failure rather than an authentication error (Managed identities FAQ^[23]). With no system-assigned identity and two or more user-assigned identities, the request must name one.

Authenticating is not authorizing

Enabling an identity on a host proves who the caller is; it grants no access to anything. Every downstream resource needs its own role assignment for that identity, at the narrowest scope that permits the required data operation, and the role-assignment mechanics themselves are covered on the governance page. Two operational details follow from the same model: managed identity tokens are cached by the platform for around 24 hours and carry group and role membership as claims, so changes made through group membership can take hours to take effect, which is why Microsoft recommends assigning roles directly to a user-assigned identity when changes must apply quickly. And role assignments are not removed when an identity is deleted, leaving orphaned assignments that show as "Identity not found" until someone clears them.

Because the host is the credential, anyone who can run code on that host can use every identity attached to it. A managed identity does not make a shared build agent safe to grant Key Vault access; it moves the trust boundary to the host.

Outside Azure, and the last resort

Workloads that do not run on a supported Azure host, such as GitHub Actions, another cloud, or Kubernetes off Azure, can use workload identity federation^[24] with a user-assigned managed identity or app registration. The workload trades a token issued by the external platform for a Microsoft identity platform access token, so nothing has to store a secret. A maximum of 20 federated identity credentials can be added to one application or user-assigned managed identity.

Where none of that is possible, a confidential client falls back to a credential on its app registration: Microsoft recommends a certificate over a client secret before an application goes to production, and a client secret's lifetime is limited to 24 months with an expiration under 12 months recommended (Add and manage app credentials^[25]). Whichever credential you use, track its expiry, because the failure mode of a forgotten secret is a production outage at an hour nobody chose.

SC-500 questions on this objective are short scenarios that name a symptom and ask for the one setting that fixes it. Sorting them by which of the five controls the stem is really about is faster than reading the options first.

Privileged access. A stem that says elevation must be authorized by someone else is asking for Require approval to activate with named approvers; requiring justification is the distractor that records a reason and grants the role anyway. A stem that caps how long an elevation lasts is Activation maximum duration, not Expire eligible assignment after, which only ends the eligibility. A stem where a policy was set on a subscription and a resource group behaves differently is the per-role, per-resource rule: Azure resource role settings do not inherit downward. A stem demanding reauthentication at every activation needs an authentication context plus a Conditional Access policy with sign-in frequency set to Every time, and even that carries the 10-minute window across activations.

Conditional Access. Where two policies disagree, the block wins and there is no priority order to reorder. Where one identity must be exempt, the answer is an exclusion inside the policy. Where the stem says "validate the impact before enforcing", the answer is report-only mode plus the sign-in logs, or the What If tool; reading audit logs after turning the policy on is the trap. Where the caller is a script or a daemon, a user-scoped policy does not apply, adding the owner's account changes nothing, and Conditional Access for workload identities with the service principal assigned directly is the fix, unless the identity is a managed identity, which those policies do not cover at all.

Credentials. "Only phishing-resistant methods" means the built-in Phishing-resistant MFA strength, not Require multifactor authentication, and it means enabling passkeys for those users in the authentication methods policy first, since a strength provisions nothing. A Temporary Access Pass is the answer to bootstrapping or recovering a passwordless credential; it satisfies MFA strength but is in neither the passwordless nor the phishing-resistant built-in strength. When the stem lists what a method must do, check the capability table: Microsoft Authenticator passwordless is primary authentication only, and Verified ID does account recovery and nothing else.

Applications. Users seeing a consent prompt when user consent is disabled means the delegated permissions need tenant-wide administrator consent; adding permissions to the registration is not a grant. A background job that needs data with no user signed in means application permissions with administrator consent. Restricting which staff can open an application means Assignment required = Yes with direct assignments, and members of nested groups still need their own assignment. Editing the enterprise application never changes a multitenant application's global definition, which lives on the registration in its home tenant.

Workload identity. A stored client secret on an Azure host is replaced by a managed identity, system-assigned when the identity should die with the resource and the audit trail must name it, user-assigned when several hosts share permissions or the permissions must exist before deployment. A workload outside Azure gets a federated identity credential instead. And whenever the stem says the code authenticates but cannot read the target, the missing piece is the role assignment on the target resource, not anything on the source.