SC-300 Cheat Sheet

A Microsoft Entra role grant always binds three things: a role definition (a bundle of permissions), a security principal (a user, a role-assignable group, or a service principal), and a scope where they apply. Built-in role definitions are authored by Microsoft and have a fixed permission set you cannot edit; a custom role reuses the same preset permission list. You create the definition once and can assign it many times at different scopes.

Using Microsoft Entra built-in roles costs nothing, but every user holding a custom role assignment requires Microsoft Entra ID P1. Granting access with a custom role is a two-step process: assemble a role definition from the preset permission list, then create a role assignment that binds it to a principal at a scope. Reach for a custom role only when no built-in role matches the least-privilege need.

Trap Assuming custom roles are free like built-in roles, or that they need P2; P2 buys PIM and eligible assignments, not the right to use a custom role.

Built-in Microsoft Entra role definitions are fixed and cannot be modified. When a built-in role grants too much or too little, the answer is a custom role assembled from the same preset permission list, not an attempt to trim or extend a built-in one.

Trap Editing or cloning a built-in role's permissions to fit a narrower need; built-in definitions are read-only, so a custom role is the only path.

Microsoft Entra roles govern the directory (users, groups, apps, domains) via Microsoft Graph; Azure RBAC roles govern Azure resources (VMs, storage) via Azure Resource Manager. By default a Global Administrator has no access to Azure resources and an Owner cannot manage directory users. The only built-in bridge is a Global Administrator toggling Access management for Azure resources, which grants User Access Administrator at the Azure root scope.

Trap Expecting a Global Administrator to manage Azure subscriptions, or an Owner to manage directory users, without the Access management for Azure resources toggle.

Entra directory role assignments are made through the Microsoft Entra admin center, Microsoft Graph PowerShell (New-MgRoleManagementDirectoryRoleAssignment), or the Microsoft Graph API. Azure CLI is not supported for Entra roles; az role assignment create targets Azure RBAC on Azure resources, a different system.

Trap Using az role assignment create to grant a directory role; that command is for Azure RBAC, not Microsoft Entra roles.

A role assignment carries one of three scope types: tenant (org-wide, the default and broadest), an administrative unit, or a single Microsoft Entra resource. A resource scope can be a group, an enterprise application, or an app registration, which lets you grant management of one object without a tenant-wide grant.

Trap Picking a subscription or resource group as the resource scope; an Entra resource scope is a group, enterprise application, or app registration, never an Azure subscription or resource group (that is Azure RBAC).

A role assigned at a container scope (the tenant or an administrative unit) grants permissions over the objects inside the container but not the container object itself. A role assigned at a resource scope grants permissions over that object only and does not reach through to a group's members. In Graph this shows in the scope string: /administrativeUnits/{id} means manage the AU's members, while a bare /{id} means manage that object itself.

Trap Assigning a role at a single group's resource scope and expecting it to reach that group's members; a resource scope grants the object only, so use an administrative unit (or add the users directly) to manage members.

A principal's effective Entra permissions are the union of every role assignment they hold at every applicable scope, so you compute access by adding grants together. A narrower assignment never subtracts from a broader one. To audit who has what, list role assignments in the admin center (downloadable as CSV) or via the List unifiedRoleAssignments Graph API.

Trap Assuming a narrow scoped assignment limits or overrides a broader tenant-scope grant the same user already holds; permissions only add.

An administrative unit (AU) is a Microsoft Entra container that holds only users, groups, or devices, used to scope a directory role to part of the org (for example a Helpdesk Administrator over one region). AUs cannot be nested, so model overlap by adding an object to multiple flat AUs (a user can be in both Seattle and Marketing). A user in no AU who is given a tenant-scoped role has tenant-wide scope.

Trap Trying to nest one administrative unit inside another; AUs are flat, so use multiple memberships for overlapping structure.

Adding a group to an administrative unit puts the group object in scope, so an AU-scoped User Administrator can rename the group and edit its membership, but cannot reset passwords or edit profiles of the users inside it. To manage those users, add them to the AU directly as members. This is the most tested AU subtlety.

Trap Adding only a group to an AU and expecting the scoped admin to reset its members' passwords; the members must be added to the AU directly.

Creating administrative units is free, but using one requires Microsoft Entra ID P1 for each AU administrator assigned a role over the AU scope, and Microsoft Entra ID Free for each AU member. If you populate the AU with a dynamic membership rule, each AU member then requires P1. The Privileged Role Administrator creates AUs and assigns AU-scoped admins.

Trap Assuming every AU member needs Entra ID P1; members are Free, only the AU administrator needs P1 unless the AU uses a dynamic membership rule (then each member needs P1).

An AU scope is offered only for roles whose permissions touch users, groups, or devices, such as User Administrator, Groups Administrator, Helpdesk Administrator, Authentication Administrator, License Administrator, and Cloud Device Administrator, plus any custom role with at least one user/group/device permission. AU-scoped permissions that act on users (password reset, auth methods) apply only to non-administrator targets within the AU.

Trap Expecting to AU-scope a tenant-wide role like Global Administrator, or expecting an AU-scoped Helpdesk Administrator to reset another admin's password; only user/group/device roles can be AU-scoped and they act on non-administrator targets only.

A restricted management administrative unit protects sensitive objects so only admins explicitly assigned at that AU scope can modify the contained objects' Entra properties. Even a tenant Global Administrator or Privileged Role Administrator is blocked from changing those objects unless they first self-assign a role at the AU scope, which is an auditable event. Those two roles can still manage the AU container itself.

Trap Using a regular administrative unit to protect executive accounts; a regular AU still lets tenant-scoped admins reach in, so only a restricted management AU walls them off.

A restricted management administrative unit supports only users, devices, and security groups as members; Microsoft 365 groups, distribution groups, and mail-enabled security groups are not supported. The restricted-management flag must be set when the AU is created and is immutable afterward, so you cannot convert a regular AU into a restricted one or back.

Trap Adding a Microsoft 365 group to a restricted management AU, or expecting to flip an existing AU to restricted; the member types are limited and the flag is creation-time only.

A tenant allows at most 100 restricted management administrative units. Objects inside one cannot be managed by Microsoft Entra ID Governance features (PIM, entitlement management, lifecycle workflows, access reviews). Deleting a restricted management AU can take up to 30 minutes to lift protection from its former members. Only directory operations are blocked; related Microsoft 365 actions (Exchange mailbox, Intune policy, SharePoint, license assignment) still work. It needs P1 per AU admin, Free per member.

Trap Expecting PIM, access reviews, or entitlement management to manage objects inside a restricted management AU; those Entra ID Governance features cannot reach restricted-AU members.

Every Microsoft Entra tenant ships with an initial domain like contoso.onmicrosoft.com that you cannot rename or delete. To give users friendly sign-in names, add your own DNS name as a custom domain and set it as the primary (default) domain so new users get UPNs like alain@contoso.com.

Trap Trying to delete or rename the onmicrosoft.com initial domain; you can only add a custom domain and mark it primary.

To add a custom domain you create a TXT or MX DNS record (recommended TTL 3600 seconds) at your registrar, then select Verify in the Microsoft Entra admin center as at least a Domain Name Administrator. A given domain name can be verified in only one directory at a time, so to move it you must delete it from the old tenant first. Microsoft Entra ID and Microsoft 365 share the same tenant domain list.

Trap Using a CNAME record to verify domain ownership, or trying to verify a domain already verified in another tenant; verification is TXT or MX and exclusive to one directory.

You cannot delete a custom domain from a tenant while users, groups, or applications still use that domain (for example in their UPNs). Reassign or remove the dependent objects first, then delete the domain. Because Entra ID and Microsoft 365 share the domain, the same dependency rule applies across both.

Trap Trying to delete a custom domain while users still carry UPNs on it; the delete is blocked until every dependent user, group, or app is reassigned off that domain first.

Customizing the Microsoft Entra sign-in page (background, favicon, header/banner/square logos, sign-in text, footer, layout) requires Microsoft Entra ID P1 or P2, or Microsoft 365 Business Standard, or SharePoint Plan 1. The minimum role to configure it is Organizational Branding Administrator. There is one default sign-in experience plus optional per-browser-language overrides that replace the default for matching languages.

Trap Assuming Global Administrator is the role needed to customize branding, or that branding is free; the minimum role is Organizational Branding Administrator and it needs P1/P2 (or qualifying M365/SharePoint).

Company branding does not apply to personal Microsoft accounts. For B2B cross-tenant sign-ins the guest sees their own home tenant's branding, not the resource tenant's. External URLs in the sign-in experience render as non-clickable text, sign-in page text is capped at 1,024 Unicode characters, and custom CSS is unavailable for tenants created after January 5, 2026 (older tenants keep it).

Trap Expecting your organization's branding to appear when a B2B guest signs in; the guest sees their home tenant's branding instead.

By default a member user can register applications and create security and Microsoft 365 groups. User settings let you set Users can register applications, Users can create security groups, and Users can create Microsoft 365 groups to No. A User Administrator can still create groups even when end-user creation is turned off, so the switch limits ordinary members, not admins.

Trap Assuming turning off group creation also blocks a User Administrator; admins with the role can still create groups regardless of the setting.

Setting Restrict non-admin users from creating tenants to Yes limits creation of new Microsoft Entra tenants to holders of the Tenant Creator role; otherwise any member user can create a tenant (and becomes its Global Administrator). Tenant creation is always recorded in the audit log under Create Company.

Trap Assuming Global Administrator is the role that lets a user still create tenants once the restriction is on; it is the Tenant Creator role that grants the exception, not Global Administrator.

The Restrict access to the Microsoft Entra admin center switch adds browsing friction for non-admins but is explicitly not a security measure: it does not block PowerShell or Microsoft Graph and does not apply to users with an admin role. To actually block non-admin access to management endpoints, use a Conditional Access policy targeting the Windows Azure Service Management API.

Trap Relying on the Restrict access to the Microsoft Entra admin center toggle as a security boundary; it leaves Graph and PowerShell open, so enforce with Conditional Access on the Windows Azure Service Management API.

Guest user defaults are governed by Guest user access restrictions, which can grant guests the same access as members or restrict them to only their own directory objects. A device setting can restrict users from self-service recovering BitLocker keys for their owned devices, forcing them to contact the helpdesk. These tenant-wide toggles shape what every guest or device owner inherits.

Trap Assuming guests get the same directory access as members by default; the default Guest user access restrictions level limits guests, and tightening it to own-objects-only is a deliberate setting.

With Microsoft Entra ID P2 and Privileged Identity Management, a role assignment can be eligible (the user activates it just-in-time and time-boxed) rather than active (permanent standing access). This is how privileged effective permissions are minimized at the high end; assigning a role to a role-assignable group instead of individuals requires Entra ID P1.

Trap Assuming Microsoft Entra ID P1 enables eligible, just-in-time PIM assignments; eligible (activate-on-demand) role assignments require P2 and PIM, while P1 only covers role-assignable groups.

A role assigned at administrative-unit scope (for example User Administrator or Groups Administrator) applies its permissions only when managing the objects that are members of that AU. It cannot touch tenant-level configuration. The scope is a management boundary, not a visibility boundary: administrative units apply scope only to management permissions and do not prevent the admin from using default user permissions to browse other users, groups, or resources outside the AU.

Trap Assuming the AU scope hides or blocks read/browse access to objects outside the AU

To create or convert an administrative unit to dynamic membership via the Microsoft Graph API (POST or PATCH /directory/administrativeUnits), set membershipType to Dynamic, supply the membershipRule expression, and set membershipRuleProcessingState to On to activate rule evaluation. Setting membershipRuleProcessingState to Paused stops updating membership dynamically while keeping the rule and current members.

Trap Omitting the /directory/ prefix on the v1.0 path; the documented v1.0 endpoint is /directory/administrativeUnits

A dynamic membership rule for an administrative unit targets users OR devices, never both, and dynamic AUs do not support group rules. To automatically maintain both users and devices, create two AUs: one with a Dynamic User rule and one with a Dynamic Device rule. Dynamic AU membership requires one Microsoft Entra ID P1 license per unique member; you don't have to assign the licenses to those users, but the tenant must hold at least enough licenses to cover them.

Trap Trying to add groups to, or mix users and devices in, a single dynamic AU

An Entra group is defined by two separate axes: its type (Security or Microsoft 365) sets the purpose, and its membership type (Assigned or Dynamic) sets how members get in. You pick both when you create the group, so 'a dynamic security group' and 'an assigned Microsoft 365 group' are both valid combinations. Treating type and membership as one menu is the usual source of wrong answers.

A Security group manages access to resources, roles, and apps and can contain users, devices, service principals, and other groups (nesting). A Microsoft 365 group is for collaboration (shared mailbox, SharePoint, Planner) and can contain users only. So whenever you need to group devices or service principals, it has to be a Security group.

Trap Putting devices into a Microsoft 365 group; it accepts users only, so a device-targeting group must be a Security group.

When you want membership to fill automatically from attributes, you choose Dynamic User or Dynamic Device, and a single dynamic group can only be one of them. A device rule may reference device attributes only, so you cannot build a device group from the owner's department. 'All Sales staff' and 'All Windows laptops' are therefore two separate groups.

Trap Writing one dynamic rule that mixes user and device attributes to cover both; a dynamic group is users-only or devices-only, and device rules see device attributes only.

A dynamic group's membership is governed entirely by its rule, so an owner or admin cannot add or remove individual members the way they can in an Assigned group. To change who is in it you edit the rule, which requires the Groups Administrator, Intune Administrator, or User Administrator role. If you need manual control over exactly who is a member, use an Assigned group.

Trap Trying to remove one user directly from a dynamic group; only the rule controls membership, so you must change the rule or switch to an Assigned group.

Dynamic membership rules are a paid feature: every member who benefits needs a Microsoft Entra ID P1 license. The free Entra tier gives you Assigned groups only. A malformed rule, rather than erroring, simply leaves the group empty, so test the rule after editing.

Group-based licensing attaches one or more product licenses to a security group; members are licensed automatically when they join and lose the license when they leave, and Entra recomputes within minutes. It requires Microsoft Entra ID P1 (or a qualifying Microsoft 365 Business Premium / Office 365 E3-and-higher plan) for every benefiting user, and you must hold at least one license per unique member of the group. You can disable individual service plans within a product when you assign it.

Group-based licensing does not flow through nested groups: only the direct, first-level members of the licensed group receive the license, and members of a sub-group do not. To license everyone, either flatten the membership or license each group directly. This is a favorite distractor because nesting works for access but not for licensing.

Trap Licensing a parent group and expecting members of nested sub-groups to inherit it; group-based licensing honors first-level members only.

A license cannot be assigned to a user until that user has a Usage location set, because some services are restricted by country; a user without one inherits the directory's location. Forget it and the license assignment fails. This is the first thing to check when a license assignment errors.

Trap Assigning a license to a freshly created user that has no Usage location; the assignment fails until the Usage location is set.

Since September 1, 2024 the Microsoft Entra admin center and the Azure portal no longer expose license assignment in their UI; user and group license assignment is done in the Microsoft 365 admin center. Microsoft Graph and PowerShell still assign licenses, so scripted and bulk workflows are unaffected. An answer telling you to assign the license in the Azure portal UI is testing this change.

Trap Choosing 'assign the license in the Microsoft Entra admin center / Azure portal' UI; since September 2024 that UI is gone and assignment happens in the Microsoft 365 admin center (or Graph/PowerShell).

Custom security attributes are business-defined key-value pairs you assign to Microsoft Entra objects, but the supported targets are users and enterprise applications (service principals) only. They are organized into attribute sets and typed as Boolean, integer, or string (single or multi-value, free-form or predefined), and you can use them to drive attribute-based access control (ABAC). Unlike directory extensions, which anyone who can read the object can read, custom security attributes hold sensitive data behind their own RBAC.

Custom security attributes are gated by a dedicated set of roles, and Global Administrator and other admin roles cannot read, define, or assign them until granted one. Attribute Definition Administrator is the minimum to create attributes; Attribute Assignment Administrator is the minimum to assign values; matching Reader roles grant read-only access. These can be scoped at the tenant or at a single attribute set.

Trap Assuming Global Administrator can read or assign custom security attributes; by default it has no access, so you must grant an Attribute Definition or Attribute Assignment role explicitly.

The custom security attributes feature is included free in all editions of Microsoft Entra ID, so it does not require P1 or P2. A tenant can hold up to 500 active attribute definitions. That free-tier status is worth remembering because so many other group and licensing features on this topic do require P1.

Microsoft Entra registration (Workplace join) is for bring-your-own-device and mobile scenarios: the user keeps signing in with a personal or local account and only attaches a work identity for access. Microsoft Entra join is for organization-owned devices, where the user signs in with their Entra work account, and it suits cloud-only or hybrid organizations. Both produce a device object in Entra ID and both can be governed by Conditional Access; the deciding line is ownership and the sign-in account, not the operating system.

Trap Joining a user-owned personal device to get it work email and Conditional Access; personal devices should be Entra registered, and join is reserved for organization-owned hardware.

Microsoft Entra join supports all Windows 11 and Windows 10 devices except Home editions, Windows Server 2019+ VMs in Azure (Server Core excluded), macOS 13 or newer, and several Linux editions. It is provisioned through the Out-of-Box Experience, bulk enrollment, or Windows Autopilot. Windows Home cannot be Entra joined, which is a common distractor.

Trap Expecting to Microsoft Entra join a Windows Home edition device; Home editions are not supported, only Pro/Enterprise/Education and the listed macOS and Linux builds.

Microsoft Entra hybrid join takes a device that is already joined to on-premises Active Directory and also registers it with Entra ID, so it keeps Group Policy and on-premises AD authentication while gaining cloud SSO and Conditional Access. It is the migration option for organizations not yet ready for cloud-only Entra join, and it is configured through Microsoft Entra Connect. Reach for it when existing AD-domain-joined Windows devices must come under Conditional Access without re-imaging.

Device join and registration establish the device's identity in Entra ID, but they do not place the device under management policy. MDM enrollment, typically Microsoft Intune, is a separate step that enforces compliance like encryption and password rules. This is why a Conditional Access 'require compliant device' control can still block a device that is Entra registered but never enrolled.

Trap Assuming an Entra registered or joined device automatically satisfies a 'require compliant device' Conditional Access control; compliance comes from separate Intune enrollment, not from the device identity alone.

The Microsoft Entra admin center provides Bulk create, Bulk invite, Bulk delete, and Bulk restore operations, each driven by a CSV template you download, fill in, and upload. Use it to onboard or offboard many users at once without scripting. For repeatable or pipelined automation you move to PowerShell or Microsoft Graph instead.

The current PowerShell tooling for Entra users, groups, licensing, and devices is Microsoft Graph PowerShell (for example Connect-MgGraph, New-MgUser, New-MgGroup). The older MSOnline and AzureAD modules are deprecated and retired, so scripts built on Connect-AzureAD or the MSOnline cmdlets should be migrated. An exam answer naming AzureAD or MSOnline cmdlets is usually the wrong, dated choice.

Trap Reaching for the AzureAD or MSOnline PowerShell modules to script Entra changes; both are retired, and Microsoft Graph PowerShell (Connect-MgGraph, New-MgUser) is the supported tooling.

A user that originates in on-premises Active Directory and flows up through Microsoft Entra Connect Sync or Cloud Sync is a synced user, with onPremisesSyncEnabled set and most properties read-only in Entra ID. You change a synced user's name, attributes, or group membership in on-premises AD, and the change syncs up. Cloud-only and guest (B2B) users, by contrast, are edited directly in Entra.

Trap Trying to edit a synced user's attributes directly in the Microsoft Entra admin center; synced properties are read-only in the cloud and must be changed in on-premises AD.

To target applications dynamically with a Conditional Access policy, tag them with a custom security attribute and add a filter for applications under Target resources (Select resources, then Edit filter). Conditional Access filters for applications only work with custom security attributes of type String; other data types such as Boolean are not supported by the policy filter even though they can be defined. Filters are evaluated at token-issuance runtime, not configuration, so newly tagged apps are covered automatically without editing the policy.

Trap Selecting a non-String attribute (for example Boolean) for the filter; only String is supported

A deleted user remains available in a soft-deleted state for up to 30 days, and after 30 days it is permanently deleted. Using the Microsoft Graph API: list deleted users with GET /directory/deletedItems/microsoft.graph.user, restore one with POST /directory/deletedItems/{id}/restore, and permanently remove one with DELETE /directory/deletedItems/{id}. After a permanent delete the account cannot be recovered.

Trap Sending DELETE to /users/{id} again to purge it instead of DELETE /directory/deletedItems/{id}

To stop a user from signing in while keeping the account, send PATCH /users/{id} with accountEnabled set to false; this is exactly what the Block sign in toggle does in the admin center. For an app running without a signed-in user, User.EnableDisableAccount.All plus User.Read.All is the least privileged combination of application permissions to update accountEnabled.

Trap Deleting the account or removing licenses when only a sign-in block was needed

Enrollment with Microsoft Intune or mobile device management for Microsoft 365 requires device registration. If you've configured either of these services, the Users may register their devices with Microsoft Entra ID setting is set to All and None becomes unavailable.

Trap Expecting to disable registration with None while Intune is configured

The New-MgGroupMember Microsoft Graph PowerShell cmdlet adds a member to a group. Pass the target group's object ID to -GroupId and the user's (or directory object's) object ID to -DirectoryObjectId. It maps to the POST /groups/{group-id}/members/$ref Microsoft Graph API.

Trap Reaching for retired AzureAD module cmdlets like Add-AzureADGroupMember instead of the Graph cmdlet

Get-MgSubscribedSku reports each licensing plan's ConsumedUnits (licenses already assigned to users) and PrepaidUnits.Enabled (active purchased licenses). Licenses still available to assign equal PrepaidUnits.Enabled minus ConsumedUnits.

Trap Reading ConsumedUnits as the licenses remaining rather than the licenses already assigned

POST /users (and the New-MgUser cmdlet) requires accountEnabled, displayName, mailNickname, userPrincipalName, and passwordProfile at a minimum. In PowerShell, supply -PasswordProfile a hash table containing a Password key (and optionally ForceChangePasswordNextSignIn). Creating a user needs the User.ReadWrite.All (or Directory.ReadWrite.All) permission.

Trap Omitting mailNickname, which is required even though it is easy to overlook

The Authentication methods policy in Microsoft Entra ID is the single tenant-wide place to turn each method on or off and target it to specific users and groups, covering passkey (FIDO2), Microsoft Authenticator, certificate-based authentication, Temporary Access Pass, SMS, voice, OATH tokens, and email OTP. It is the modern replacement for legacy per-user MFA and Security Defaults, with a migration toggle to move off them. Plan from this policy first to decide who registers which strong method, then enforce when MFA is required separately in Conditional Access.

Trap Using legacy per-user MFA's Enabled/Enforced state to require MFA today; that control predates Conditional Access and is being retired in favor of the Authentication methods policy plus Conditional Access.

Microsoft's phishing-resistant tier is a fixed list: Windows Hello for Business, passkeys (FIDO2 security keys and synced passkeys), passkeys in Microsoft Authenticator, Platform Credential for macOS, and certificate-based authentication. They resist remote phishing because the credential is cryptographically bound to the device and cannot be replayed from a stolen password or code. Authenticator push and passwordless phone sign-in are strong but still phishable, so they sit one tier below.

Trap Treating Microsoft Authenticator push approval as phishing-resistant; it is strong MFA but a real-time phishing or MFA-fatigue attack can still defeat it, so it is not in the phishing-resistant tier.

SMS, voice call, and OATH one-time codes are the lowest tier Entra accepts and should be a fallback only, used when phones are restricted or stronger methods are unavailable. They are vulnerable to SIM-swap, interception, and phishing because the secret travels to the user and can be relayed. OATH tokens (hardware or software TOTP generators) are second-factor only and never serve as a primary credential.

A Temporary Access Pass (TAP) is a time-limited passcode an admin issues so a new or locked-out user signs in once and registers a strong method such as a passkey or Windows Hello for Business, never using a password. It is the canonical onboarding and recovery path because it lets you stand up phishing-resistant credentials before the user has any. For federated domains a TAP is preferred over federation, so the user authenticates in Entra ID rather than being redirected to the on-premises identity provider.

The TAP policy ships with a minimum lifetime of 1 hour, a maximum of 8 hours, a default of 1 hour, and a default length of 8 characters; all lifetimes can be configured from 10 minutes up to 30 days (43,200 minutes) and length from 8 to 48 characters. One-time use defaults to False, meaning a TAP is reusable within its validity unless you enforce one-time use tenant-wide. An Authentication Policy Administrator manages the policy, while an Authentication Administrator or Privileged Authentication Administrator creates individual passes.

When a user signs in with a one-time (single-use) TAP to register a passwordless method like a FIDO2 key or phone sign-in, the registration must complete within 10 minutes of sign-in. A reusable multi-use TAP has no such window and can be entered again during its validity, which is why long device-enrollment flows often use either two single-use passes or one multiuse pass. This 10-minute limit reflects MFA enforcement during credential registration, not the TAP lifetime itself.

Trap Assuming a one-time TAP stays usable for its full lifetime to register a passkey; passwordless registration with a single-use TAP must finish within 10 minutes of sign-in or it fails.

You can add a Temporary Access Pass to an internal guest (a user object whose UserType is Guest but who has methods registered in your tenant), but adding one to an external guest account returns an error. An external guest instead signs in to the resource tenant with a TAP issued by its home tenant, and only if cross-tenant access settings are configured to trust MFA from that home tenant. So a TAP is a same-tenant onboarding tool, not a way to bootstrap an external partner.

Trap Issuing a TAP to an external guest to onboard a partner; external guest accounts are rejected, and their MFA must come from their home tenant under cross-tenant access trust.

A passkey based on FIDO2 can be a hardware security key, a synced passkey, or a passkey stored in Microsoft Authenticator, and all forms are phishing-resistant and capable of primary (first-factor) authentication. The credential is a device-bound key pair verified cryptographically, so there is no shared secret an attacker can phish. Enable it in the Authentication methods policy and target the populations that need the strongest sign-in.

Certificate-based authentication (CBA) lets users authenticate with an X.509 certificate or smart card directly against Microsoft Entra ID, with no AD FS in the path, as a phishing-resistant first factor. It is the natural choice when an organization already operates a PKI and wants to reuse those certificates. CBA is configured in the Authentication methods policy along with certificate-authority and username-binding settings.

Trap Assuming certificate-based authentication still requires AD FS; modern Entra CBA validates the certificate directly in the cloud without a federation server.

Windows Hello for Business provisions an asymmetric key pair, preferably protected by the device TPM, that is unlocked by a local PIN or biometric gesture which never leaves the device. Because the password is not used in the sign-in, it is phishing-resistant; the PIN is device-local, not a network secret. A user with a registered passkey can even use Windows Hello for Business as a step-up MFA credential.

Trap Thinking the Windows Hello PIN is a weaker password sent to Entra ID; the PIN only unlocks a local TPM-bound key and is never transmitted, which is why Hello is phishing-resistant.

Self-service password reset (SSPR) requires each user to register at least one authentication method, and the admin policy then requires one or two registered methods to perform a reset. Accounts holding an Azure administrator role are automatically forced onto a stronger two-method reset policy regardless of the tenant setting. SSPR cuts helpdesk password tickets by letting users reset their own password after verifying with their registered methods.

The SSPR feature itself is available on Microsoft Entra ID Free, but password writeback, which carries a cloud password reset back to on-premises Active Directory for federated, pass-through-authentication, or password-hash-synced users, requires Microsoft Entra ID P1. Without writeback a hybrid user's reset would not reach their on-premises account. So a scenario that resets passwords for synced users implies the P1 writeback requirement.

Trap Picking SSPR alone for synced on-premises users without enabling password writeback; the cloud reset would not flow back to their AD account, and writeback requires Entra ID P1.

SSPR exists to let a user reset a forgotten password, which is recovery, and it never satisfies a Conditional Access requirement for multifactor authentication at sign-in. MFA, SSPR, and Password Protection are three separate controls: MFA adds a factor, SSPR restores access, and Password Protection enforces password quality. Keep them distinct when a question offers SSPR as a way to meet an MFA requirement.

Trap Selecting SSPR to satisfy a Conditional Access MFA grant; SSPR is recovery, so it cannot count as the second factor a sign-in policy demands.

Microsoft Entra Password Protection applies a global banned password list, built from Microsoft's own attack telemetry, to every tenant automatically with nothing to enable, and it cannot be turned off or viewed. It blocks known weak base terms and their variants at password change or reset. For cloud-only users the global list is covered by Microsoft Entra ID Free.

On top of the global list you can add a custom banned password list of up to 1,000 organization-specific base terms such as brand, product, and location names, which are combined with the global list at validation. Add only key base terms, not every variant, because the algorithm expands them automatically. The custom list requires Microsoft Entra ID P1 or P2.

Trap Adding every weak variant like Contoso!1 and Contoso@London to the custom list; you list only the base term Contoso, and normalization plus fuzzy matching block the variants, within a 1,000-term cap.

Password Protection normalizes a new password (lower-cases it and undoes substitutions like 0 to o, 1 to l, $ to s, @ to a), fuzzy-matches it against the banned lists at an edit distance of 1, substring-matches the user and tenant name for terms at least four characters, then scores it: each banned term found is one point and each leftover character is one point. The password is accepted only if it totals at least 5 points. So a password packed with banned terms and few extra characters is rejected even if it is long.

To enforce the same banned-password rules on on-premises password changes, install the Microsoft Entra Password Protection DC agent on domain controllers plus the proxy service that relays policy from Entra ID. This on-premises deployment requires Microsoft Entra ID P1, and you can run it in Audit mode to log what would be blocked before switching to Enforced mode. Tenant-name substring matching is skipped when validating on a domain controller.

Trap Expecting cloud Password Protection to cover on-premises AD password changes automatically; you must deploy the DC agent and proxy on-premises (Entra ID P1) for domain password changes to obey the rules.

On-premises Microsoft Entra Password Protection supports an Audit mode that evaluates and logs which password changes would be rejected without actually blocking them, and an Enforced mode that blocks them. Run Audit first to gauge user impact, then move to Enforced once you understand the blast radius. The mode is a setting pushed from Entra ID through the proxy to the DC agents.

Microsoft Entra Kerberos gives passwordless users (FIDO2 or Windows Hello for Business) single sign-on to on-premises Active Directory resources by creating an AzureADKerberos computer object that appears as a read-only domain controller but maps to no physical server. Microsoft Entra ID uses it to issue a partial Kerberos ticket-granting ticket (TGT) at sign-in, which the on-premises AD completes for resource access. Without it, a Microsoft Entra joined user can sign in but loses SSO to AD-secured resources like file shares.

Cloud Kerberos trust, powered by Microsoft Entra Kerberos, is Microsoft's recommended deployment model for hybrid Windows Hello for Business because it skips the certificate infrastructure that key trust and certificate trust require. You enable Microsoft Entra Kerberos, then set the Use Windows Hello for Business and Use cloud trust for on-premises authentication policies. It is the lowest-overhead path to phishing-resistant Windows sign-in with on-premises SSO.

Trap Choosing certificate trust for a new hybrid Windows Hello rollout to get on-premises SSO; it needs PKI, whereas cloud Kerberos trust delivers the same SSO without certificate plumbing and is the recommended model.

If the Use certificate for on-premises authentication policy is enabled on a device, certificate trust takes precedence over cloud Kerberos trust, so cloud Kerberos trust silently will not apply. There is also no direct migration path from certificate trust to cloud Kerberos trust; you must delete the Windows Hello container (certutil -deletehellocontainer) and re-provision. Leave the certificate policy Not configured on machines you want on cloud Kerberos trust.

Trap Enabling cloud Kerberos trust while the certificate-for-on-premises-auth policy is still on; certificate trust wins, so cloud Kerberos trust never takes effect on that device.

When an account is compromised, the immediate containment action is to disable the account to block new sign-ins and revoke its refresh tokens and sessions (for example Revoke-MgUserSignInSession) so issued tokens stop working and the user must reauthenticate. Resetting the password alone does not invalidate existing refresh tokens, so the attacker keeps access until those tokens expire. Method rotation and investigation come after containment, not before.

Trap Resetting the compromised user's password as the first and only response; a password reset does not revoke existing refresh tokens, so you must also revoke sessions to cut the attacker's live access.

Security Defaults is a free, tenant-wide on/off baseline that forces all users to register and use MFA, with no per-group scoping and no per-app conditions. The moment you need to require MFA for some users, apps, or risk conditions but not others, you turn Security Defaults off and use the Authentication methods policy with Conditional Access. The two cannot run together with Conditional Access policies enabled.

Trap Keeping Security Defaults to apply MFA only to admins or only to risky sign-ins; Security Defaults has no scoping, so granular requirements need Conditional Access instead.

In a Passkey (FIDO2) passkey profile, set Enforce key restrictions to Yes and add the approved models' Authenticator Attestation GUIDs (AAGUIDs) to an allow or block list. Key restrictions set the usability of specific models or providers for both registration and authentication, so if you remove an AAGUID you previously allowed, users who already registered that method can no longer use it for sign-in. Attestation enforcement is different: it is checked only at registration, so users who registered a passkey without attestation aren't blocked from sign-in if you set Enforce attestation to Yes later.

Trap Enforce attestation (verifies the vendor at registration) is a separate control from key restrictions (the AAGUID allow/block list). Tightening attestation later does not block already-registered keys, but tightening key restrictions does — removing an allowed AAGUID stops previously registered keys of that model from signing in.

A custom authentication strength (Authentication methods > Authentication strengths) lets you pick an exact method combination and, in the Passkeys (FIDO2) advanced options, allow only specific AAGUIDs. Require it in a Conditional Access policy targeting one app so only the approved key model satisfies that app, while the built-in Phishing-resistant MFA strength (which also accepts Windows Hello for Business and Microsoft Entra certificate-based authentication) still applies elsewhere.

Trap The built-in Phishing-resistant MFA strength is predefined and can't be modified or narrowed to one vendor or one method; when the scenario says only a specific FIDO2 model is allowed, you need a custom strength with the AAGUID, not the built-in tier.

Read every Conditional Access policy as "if these signals match, then enforce these controls." The assignments are the if (users, target resources, network, conditions), and the access controls are the then (grant or block, plus session controls). All assignments in one policy combine with AND, so each one you add narrows the policy; an over-scoped policy with too many conditions simply never fires.

Trap Assuming an assignment you add only adds reach; every assignment ANDs, so adding one more condition can stop a policy from ever matching.

Multiple Conditional Access policies can apply to one sign-in, and the user must satisfy every applicable policy, not just one. If one policy requires MFA and another requires a compliant device, the user does both. A Block grant in any matching policy overrides all the grants, so block always wins.

Trap Treating policies as OR so satisfying one is enough; they AND across policies, and a single Block policy denies regardless of what others would grant.

Inside one Grant block, 'Require all the selected controls' ANDs them (MFA and compliant device) and is the default for multiple controls, while 'Require one of the selected controls' ORs them (compliant device or MFA). The phase-2 prompt order is fixed: MFA, then compliant device, then hybrid joined, then approved client app, then app protection policy, then password change, then terms of use.

Require authentication strength names an allowed set of methods (for example phishing-resistant MFA) rather than 'any second factor,' so reach for it on high-value targets and admin actions. Plain Require multifactor authentication accepts any registered second factor. Authentication strengths let one grant control demand specifically phishing-resistant credentials.

Trap Using Require multifactor authentication when the requirement is phishing-resistant; plain MFA accepts SMS or a push, so you need Require authentication strength to force FIDO2 or certificate-based methods.

Require device to be marked as compliant trusts an Intune compliance evaluation and works across Windows, macOS, iOS, and Android; Require Microsoft Entra hybrid joined device only checks that the device is joined to both on-premises AD and Entra, with no health assessment. A stem about 'managed and healthy' wants compliant; one about 'domain-joined corporate Windows' wants hybrid joined.

Trap Choosing Require hybrid joined device when the goal is Intune-managed and healthy; hybrid join proves domain membership but performs no compliance check, so a non-compliant domain device still passes.

Legacy authentication protocols cannot perform MFA, so they are the most common path around an MFA policy. Block them with a Conditional Access policy whose client-apps condition selects the legacy/other clients and whose grant control is Block. This closes the bypass that an MFA-for-all-users policy alone leaves open.

Filter for devices is a condition that includes or excludes devices by a rule over device-object attributes: trustType (AzureAD = Entra joined, ServerAD = hybrid joined, Workplace = registered), isCompliant, deviceOwnership (Personal or Company), model, operatingSystem, and the customer-set extensionAttribute1 through extensionAttribute15. The privileged-access-workstation pattern blocks access except where device.extensionAttribute1 equals SAW.

For an unregistered device every attribute is null, so a positive operator (Equals, In, StartsWith) never matches it and the filter does not apply. To target unregistered devices, use a negative operator (NotEquals, NotIn, NotStartsWith), which evaluates true against the null value. This is why PAW exclusion rules are written with -ne rather than -eq.

Trap Writing a device filter with a positive operator to catch unmanaged devices; an unregistered device has null attributes, so only a negative operator applies the rule to it.

Target resources (formerly cloud apps) has three flavors: cloud apps (Microsoft and Entra-integrated apps), user actions, and authentication context. Only two user actions exist: Register security information and Register or join devices. Group Microsoft 365 services under the Office 365 app instead of targeting Exchange or SharePoint individually, because their dependencies otherwise leave coverage gaps.

Trap Targeting Exchange Online or SharePoint Online individually for an M365 MFA policy; service dependencies mean only the Office 365 grouping covers all the related metadata and child services.

Conditional Access can use sign-in risk and user risk as conditions, but the scoring comes from Microsoft Entra ID Protection, which is why risk-based conditions require Entra ID P2. Conditional Access itself is a P1 capability. So a policy can act on 'High user risk,' but only ID Protection decides what counts as high.

Trap Assuming Conditional Access detects risk on its own; it only reads a risk level supplied by Entra ID Protection, and that pairing is what needs Entra ID P2.

Once grant controls are satisfied, session controls apply. Sign-in frequency overrides the default rolling 90-day session with a fixed hours/days interval or 'Every time' for sensitive actions. Persistent browser session governs 'Stay signed in?'. App-enforced restrictions pass device state to Exchange Online and SharePoint Online only. Conditional Access App Control routes the session through Microsoft Defender for Cloud Apps.

Sign-in frequency 'Every time' forces reauthentication when the session is evaluated, factoring in five minutes of clock skew, not whenever the browser closes and reopens. Before enabling sign-in frequency, disable 'Remember MFA on trusted devices' or the two settings prompt users unexpectedly. The default user sign-in frequency is a rolling window of 90 days.

Trap Believing 'Every time' reauthenticates on every browser restart; it re-prompts only on session evaluation with a five-minute clock-skew buffer, so closing and reopening the browser does not necessarily prompt.

CAE turns token issuance into a two-way conversation so a resource can reject a non-expired token in near real time. Critical event evaluation needs no Conditional Access policy and works in any tenant, firing on: user deleted or disabled, password changed or reset, MFA enabled for the user, admin revokes all refresh tokens, and high user risk from ID Protection. The resource returns a 401 plus claim challenge and the client bypasses its cache.

Trap Shortening token lifetimes to enforce a disablement faster; Microsoft replaced that 'blunt object' approach with CAE, which revokes on the critical event instead of waiting for expiry.

Because CAE evaluates risk and policy continuously, CAE-aware sessions stop honoring static token lifetimes and the access token grows to long-lived, up to 28 hours. Revocation is driven by critical events, not a clock, so the long token improves stability without weakening security. Without CAE-capable clients the default access token lifetime stays 1 hour.

Trap Assuming CAE shortens token lifetime; it lengthens it to up to 28 hours because critical events, not expiry, now drive revocation.

CAE has insight only into IP-based named locations, not country/region locations or MFA-trusted-IPs; coming from those, CAE will not enforce the location change. If the sum of all IP ranges in location policies exceeds 5,000, Entra falls back to a one-hour token for the location-change flow while still enforcing other events. CAE also does not support guest users, and Strict Location Enforcement removes the standard tolerance for an allowed-egress-IP mismatch.

Trap Configuring a country/region named location and expecting CAE to enforce a move in real time; CAE only understands IP-based named locations.

An authentication context is a tag (display name plus a read-only ID in the range c1 to c99, up to 99 per tenant) that you select as a target resource in a Conditional Access policy and then attach to a specific resource: a SharePoint site, a Microsoft Purview sensitivity label, a Defender for Cloud Apps session policy, a custom app, or a PIM role's On activation setting. You must tick 'Publish to apps' or the context is invisible to downstream resources.

Trap Creating an authentication context but leaving 'Publish to apps' unchecked; an unpublished context cannot be assigned to any resource and the protection never takes effect.

Protected actions attach a Conditional Access authentication context to a small set of high-impact Entra permissions, enforcing the policy when the user performs the action rather than at sign-in or role activation. The protectable set includes managing Conditional Access policies (create/delete/basic update), cross-tenant access settings, hard-deleting directory objects, and managing named locations. The intended pattern is to require phishing-resistant MFA before deleting a CA policy. Protected actions need Entra ID P1.

Protected actions apply an access requirement (such as step-up MFA) to performing a permission; they are not an authorization control and do not block a permission based on identity or group membership. Who can do something is a role-assignment decision. Protected actions differ from PIM role activation, which enforces a policy when a user activates a role; the two combine for stronger coverage.

Trap Using protected actions to stop a specific user or group from holding a permission; that is an authorization decision made by role assignment, while protected actions only add a step-up requirement to performing the action.

Report-only is a policy state (alongside On and Off) that evaluates the policy on each sign-in and logs what it would have done without enforcing grant or session controls, so users are never prompted or blocked. Review impact in the sign-in log's Report-only tab, the Conditional Access insights workbook (needs Entra ID P1 and a Log Analytics workspace), or the Policy impact view. It is the standard way to measure blast radius before turning a policy On.

A report-only policy logs one of four results per sign-in: Report-only: Success (controls already satisfied), Report-only: Failure (conditions matched but a non-interactive control or block was not satisfied), Report-only: User action required (conditions matched but the user would have been prompted, and report-only never prompts), and Report-only: Not applied (conditions did not match). Report-only does not work for the User Actions scope.

Trap Reading 'Report-only: User action required' as a failure; it means the conditions matched and the policy would have prompted the user, but report-only mode suppresses the prompt.

Policy templates deploy Microsoft-recommended policies grouped into categories (Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats), and each template is created in report-only mode by default. A template's user exclusion only excludes the policy's creator, so after creating one you must edit it to exclude your other break-glass accounts. You can export a template's JSON and re-import it for programmatic deployment.

Trap Assuming a template already excludes all your emergency accounts; it excludes only the creating admin, so you must add break-glass exclusions after creating it.

Exclude emergency-access (break-glass) accounts and service principals from every Conditional Access policy so a misconfiguration cannot lock out all administrators. A break-glass account that is itself caught by a faulty MFA or device policy defeats its purpose. Service accounts are noninteractive and should be replaced with managed identities where possible, with workload-identity Conditional Access used to target service principals.

Trap Applying a require-MFA-for-all-admins policy without excluding the break-glass account; if the policy misfires, the recovery account is locked out along with everyone else.

Group membership and policy changes can take up to a day (optimized to about two hours for some policy updates) to propagate to resources like Exchange Online and SharePoint Online. To apply a change immediately to a user, revoke their sessions with Revoke-MgUserSignInSession in Microsoft Graph PowerShell or Revoke Session on the user's profile, which forces fresh evaluation on the next token request.

Trap Waiting for a policy or group-membership change to apply on its own when it must take effect immediately; revoke the user's sessions to force re-evaluation rather than waiting up to a day for propagation.

When you target directory roles in a Conditional Access policy, only built-in roles are honored; the policy is not enforced for administrative-unit-scoped or custom roles. Policies targeting roles or groups are also evaluated only when a token is issued, so a user newly added to a targeted role is not subject to the policy until their next token, not retroactively.

Trap Expecting a Conditional Access policy that targets a custom or administrative-unit-scoped role to enforce; only built-in directory roles are supported as a target.

The persistent browser session control (Never persistent / Always persistent) can only be saved when target resources is set to All resources (formerly All cloud apps). Browser session persistence is governed by a single authentication session token shared across all tabs in the browser, so it can't be scoped to one app; the control requires selecting all cloud apps as a condition.

Trap Sign-in frequency can target specific apps, but persistent browser session cannot; the fix when the control won't save is to widen target resources to All resources, not to change the session control.

Require token protection for sign-in sessions cryptographically binds the session token to the device (using the device-bound Primary Refresh Token) to stop token replay. It currently supports native applications only — browser-based applications are not supported. Enforcement is generally available on Windows 10+ devices that are Entra joined, hybrid joined, or registered (preview on iOS/iPadOS and macOS), and it can be enforced for Exchange Online, SharePoint Online, and Microsoft Teams (plus Azure Virtual Desktop and Windows 365 on Windows). Because browsers aren't covered, the policy should target the Mobile apps and desktop clients client-app condition.

Trap Browser sessions are unaffected by token protection (not supported); if users report the web app is unprotected while the desktop app is protected, that is expected behavior, not a misconfiguration.

The Conditional Access What If tool evaluates which policies would apply to a chosen user under conditions you specify (device platform, IP address or country, app) without the user signing in and without enforcing anything. It includes both enabled and report-only policies and explains why policies do not apply. It does not test for Conditional Access service dependencies (for example a Teams sign-in that also depends on Exchange Online), so a user can still be blocked by a dependency policy the tool reports as not applying.

Trap What If ignores service dependencies; if it shows no blocking policy yet the user is still blocked, suspect a policy on a dependent service (such as Exchange Online behind Teams).

To require MFA only off the corporate network, set the network condition to include Any location and exclude All trusted locations, then define the office IP ranges as a named location and select Mark as trusted location. The All trusted locations exclusion applies only to locations that carry the trusted designation, so an unmarked named location still triggers MFA. Sign-ins from trusted named locations also improve the accuracy of Microsoft Entra ID Protection's risk calculation.

Trap Creating the named location is not enough; if users on the corporate network are still prompted, the named location was not marked trusted and therefore is not covered by the All trusted locations exclusion.

Before enabling strictly enforce location policies for continuous access evaluation, use the Continuous Access Evaluation Insights workbook to find sessions where the IP address seen by Microsoft Entra ID differs from the IP address seen by the resource, then add all known organizational egress IPs to IP-based named locations. Split-tunnel network configurations cause these mismatches and will otherwise block users once strict enforcement is on.

Trap The discrepancy is between Entra ID's detected IP and the IP address (seen by resource) value; compare against your named locations and add egress IPs first rather than disabling the policy.

To allow access but block only files containing sensitive data, use the Conditional Access App Control session control with a Defender for Cloud Apps session policy whose session control type is Control file download (with inspection) or Control file upload (with inspection), then set the action to Block. Content inspection scans the file and blocks only matches, leaving non-sensitive transfers allowed. Block activities is the control type for in-session actions like print and copy.

Trap Setting Control file download (with inspection) with a Block action and no file filter blocks every download, including non-sensitive ones; selective blocking requires the inspection-based file filter so only sensitive matches are blocked.

When an authentication strength policy applies to external Microsoft Entra users, enable Trust multifactor authentication from Microsoft Entra tenants in your inbound cross-tenant access settings. The resource tenant then accepts MFA claims completed in the guest's home tenant, so acceptable home-tenant methods satisfy the strength without forcing the guest to register new credentials in your tenant.

Trap Without inbound MFA trust, B2B guests can't satisfy the strength with their home-tenant MFA; the fix is the cross-tenant trust setting, not changing or relaxing the authentication strength.

In Microsoft Entra ID the workload identities are applications, service principals, and managed identities. A managed identity is a special type of service principal whose certificate Azure issues, stores, and rotates, so there is no secret for you to handle or leak. Your code obtains a Microsoft Entra access token for the identity and presents it to any service that supports Entra authentication, and managed identities cost nothing extra.

Pick a workload identity from where the code runs and what it is. Use a managed identity when the workload runs on an Azure resource that supports one, because nothing can be stolen. Use an app registration with a service principal when the workload runs outside Azure or needs API permissions and consent. Reserve a user account for a human and a group managed service account (gMSA) for on-premises Windows services authenticating to on-prem Active Directory.

Trap Using a user account with a stored password to run an unattended service or daemon; user accounts are for humans, and a workload should use a managed identity or service principal instead.

A group managed service account (gMSA) is a Windows account in Active Directory Domain Services whose password Active Directory creates and rotates automatically. It secures on-premises Windows services that authenticate over Kerberos to on-prem AD. It issues no Microsoft Entra token, so it is never the right choice for an Azure resource calling another Azure service.

Trap Choosing a managed service account for an Azure-to-Azure call; a gMSA only works against on-prem Active Directory, so a managed identity is the Azure answer.

A system-assigned managed identity is enabled directly on one Azure resource, and Azure creates a service principal tied to that resource's lifecycle. Only that resource can request tokens with it, and when you delete the resource Azure deletes the identity automatically. It can never be shared with another resource, so each resource that needs one gets its own.

A user-assigned managed identity is created as its own Azure resource and managed separately from anything that consumes it. The same identity can be attached to many resources, and its lifecycle is independent, so it survives until you delete it explicitly even when no resource uses it. Microsoft recommends user-assigned as the default managed-identity type for most scenarios.

Trap Assuming a user-assigned identity disappears when its last resource is deleted; it is a standalone resource you must delete yourself.

A user-assigned identity and its role assignments can be created before the resource that consumes them, so a deployment that needs access while provisioning succeeds. A system-assigned identity does not exist until its resource exists, so its role assignments cannot be granted in advance, and a deployment that needs access during creation can fail. This pre-provisioning ability is a common reason to choose user-assigned.

Trap Relying on a system-assigned identity for access that must exist before the resource is deployed; the identity is created with the resource, so the role assignment cannot be made in time.

When several resources do the same job and need the same permissions, attaching one shared user-assigned identity means a role is assigned once instead of per resource. Microsoft's example: four virtual machines reaching two storage accounts need eight role assignments with system-assigned identities but only two with a shared user-assigned identity. Fewer distinct identities and assignments cuts management overhead.

Creating many resources quickly, each with its own system-assigned identity, can exceed the Microsoft Entra object-creation rate limit and fail with HTTP 429. A single pre-created user-assigned identity needs only one service principal, so it sidesteps the limit. This makes user-assigned the recommendation for ephemeral or rapidly recycled compute.

Trap Giving every node in a rapidly scaling fleet its own system-assigned identity; the burst of Entra object creations can hit the rate limit and return HTTP 429.

Deleting a resource removes its system-assigned identity, but the identity keeps counting toward your Microsoft Entra directory object limit until it is fully purged after 30 days. Rapidly creating and deleting resources with system-assigned identities can therefore push you toward that limit even though the identities look gone. A shared user-assigned identity avoids the churn.

Use a system-assigned identity when the requirement is to log which specific resource carried out an action rather than which identity, since a shared user-assigned identity cannot tell two resources apart in the logs. Also choose system-assigned when permissions should be removed automatically as the resource is deleted. These two cases are where system-assigned beats the otherwise-recommended user-assigned.

Resources that support managed identities can have a system-assigned identity and one or more user-assigned identities at the same time. This lets you apply shared permissions through a user-assigned identity while keeping resource-specific permissions on the system-assigned one. The code chooses which identity to use when it requests a token.

A managed identity has no access until you assign it an Azure RBAC role at the scope of the target, for example Storage Blob Data Reader on a storage account. Creating or enabling the identity and granting the role are two separate steps. Skipping the role assignment is the most common cause of a managed-identity call returning 403 Forbidden.

Trap Enabling a managed identity and expecting it to reach the target without a role assignment; with no RBAC role at the target scope the call returns 403.

Code on an Azure resource gets a Microsoft Entra token by calling the Azure Instance Metadata Service at http://169.254.169.254/metadata/identity/oauth2/token with the header Metadata: true and a resource parameter naming the target audience. The endpoint is link-local and answers only from inside that resource, so no credential leaves the host. Microsoft Entra ID returns a JWT access token, and the SDK's DefaultAzureCredential or MSAL normally makes this call for you.

When a resource carries more than one user-assigned identity, a token request must include the client_id (or resource/object ID) of the identity you want, because Azure cannot otherwise tell which one to use. A request that omits it on a multi-identity resource is ambiguous and fails. A single-identity resource needs no client_id.

Trap Omitting client_id when requesting a token on a resource with several user-assigned identities; the request is ambiguous and fails until you specify which identity.

A managed identity's token is cached by the Azure infrastructure for roughly 24 hours, and group or role-membership claims live inside that token, so changing a managed identity's group or role membership can take hours to take effect and cannot be forced to refresh sooner. To make permission changes apply quickly, assign the role directly to a user-assigned identity instead of adding or removing it from a Microsoft Entra group.

Trap Removing a managed identity from an Entra group to revoke access immediately; the cached token keeps the old claims for hours, so assign permissions directly to the identity when changes must be instant.

Role assignments are not removed automatically when a managed identity is deleted; the orphaned assignment shows as Identity not found in the portal and keeps consuming the per-subscription role-assignment limit until you delete it by hand. Cleanup of a managed identity therefore means removing both the identity and its dangling role assignments.

Trap Deleting a managed identity and assuming its role assignments went with it; they remain as Identity not found and still count against the role-assignment limit.

A managed identity only works on an Azure resource, so a workload running outside Azure (GitHub Actions, another cloud, or Kubernetes off Azure) cannot use one. Such a workload authenticates as a service principal from an app registration, and workload identity federation lets it exchange an external token for a Microsoft Entra token with no stored secret. A client secret or certificate is the fallback when federation is not available.

Trap Trying to assign a managed identity to compute that runs outside Azure; managed identities only attach to Azure resources, so an app registration with federation is the credential-free choice.

A managed identity can act as a federated identity credential (FIC) on a Microsoft Entra application through workload identity federation, which keeps the app credential-free. There is a limit of 20 federated identity credentials when managed identities are used as the FIC on a single Entra application. Beyond that you split across applications.

Enabling a system-assigned identity on a VM (or attaching any identity) needs Virtual Machine Contributor on the VM, with no extra directory role. Attaching a user-assigned identity additionally needs Managed Identity Operator on that identity (it holds the assign/action permission). Creating a user-assigned identity needs Managed Identity Contributor.

Trap thinking Virtual Machine Contributor alone is enough to attach a user-assigned identity

To let a managed identity read secrets, grant the least-privileged data-plane role Key Vault Secrets User (RBAC model) or, under the Vault access policy model, an access policy with Get (and List). RBAC roles such as Key Vault Secrets User only take effect when the vault uses the Azure RBAC permission model; on a vault using access policies they grant nothing and reads return Forbidden.

Trap assigning Owner or Contributor (management-plane) and expecting it to grant data-plane secret reads, or mixing an RBAC role with the access-policy model

Deleting a user-assigned managed identity does not remove it from the resources it was assigned to; the stale reference remains on every VM and must be cleaned up manually (for example with az vm identity remove). After deletion the identity can no longer obtain tokens, so dependent code stops authenticating.

Trap expecting the reference to be removed automatically from assigned VMs when the identity is deleted

Subject matching for a federated identity credential is exact, so one credential trusts exactly one subject (for example repo:org/repo:environment:Production). To trust an additional branch or environment, add another credential; when you hit the 20-credential-per-identity limit, use a flexible federated identity credential whose claims-matching expression covers many subjects with a single credential.

Trap trying to wildcard or list multiple branches inside one ordinary credential's subject value

Access packages, catalogs, and connected organizations are part of Microsoft Entra ID Governance, so they require the Microsoft Entra ID Governance or Microsoft Entra Suite subscription for every governed user, including requestors and approvers. A few individual capabilities operate with Microsoft Entra ID P2, but a Free or P1-only tenant cannot run the access-package machinery. Terms of use is the one exception, needing only Entra ID P1.

Trap Assuming Microsoft Entra ID P2 alone unlocks access packages; the access-package feature requires the ID Governance tier, and only a few sub-capabilities work on P2.

An access package is a named bundle of resource roles a person needs, drawn from three resource types: membership in Entra security and Microsoft 365 groups (and their Teams), assignment to enterprise applications, and membership in SharePoint Online sites. A requestor asks for the package once and Entra provisions every role inside it as a single time-limited assignment. Because licensing, Azure RBAC, and Entra roles can ride on a group inside the package, one request can deliver far more than the three literal resource types.

A catalog is the container and delegation boundary that holds resources plus the access packages built from them. An access package lives in exactly one catalog and lists the resource roles it grants. An assignment policy attaches to an access package and is the only object that sets the rules: who can request, approval stages, duration, and whether an access review recertifies. One access package can carry several policies.

A resource must be in a catalog before any access package can grant a role on it, and groups must be cloud-created (Entra security or Microsoft 365 groups). A group synced from on-premises Active Directory cannot be added because Entra cannot edit its membership, and an Exchange Online distribution group cannot be added either. The fix is to create a cloud security group or configure group writeback, not to change a permission.

Trap Trying to add an on-premises AD-synced security group as a catalog resource; Entra cannot modify its membership, so you must use a cloud-created group or group writeback.

Each assignment policy names one audience: For users in your directory, For users not in your directory, or None (administrator direct assignments only). A single policy cannot mix internal employees and external partners, so collaboration scenarios need two policies on the same access package, one per audience. When multiple policies apply to a requestor, they pick which policy to request against.

Trap Assuming one policy can grant the same access package to both employees and external partners; internal and external audiences each need their own policy on the package.

Entitlement management has tenant-wide roles (Catalog creator, Connected Organization Administrator) and per-catalog roles (Catalog owner, Catalog reader, Access package manager, Access package assignment manager). A Catalog creator builds and owns new catalogs but cannot see catalogs it does not own; an Access package manager creates and edits packages and policies in one catalog; an Access package assignment manager can only add or remove users on existing packages. Pick the narrowest role that covers the task.

To grant a delegated administrator broad entitlement-management rights at the tenant level, assign the Identity Governance Administrator directory role. The User Administrator role can no longer create catalogs or manage access packages in catalogs it does not own, so it is the deprecated answer for these tasks. Global Administrator and Identity Governance Administrator can manage all of entitlement management by default.

Trap Reaching for User Administrator to configure catalogs or access packages; that role can no longer create catalogs or manage packages it does not own, so use Identity Governance Administrator.

Outside of Global Administrator, adding a group, app, or site to a catalog requires a directory role that can administer the resource plus the Catalog owner role on that catalog. For example, Groups Administrator plus Catalog owner adds groups; SharePoint Administrator plus Catalog owner adds sites; Application Administrator plus Catalog owner adds apps. A resource owner can add their own resource with just Catalog owner.

An assignment policy can require up to three approval stages. Only one approver in a stage needs to approve for the request to advance, but if any approver in a stage denies it first, or no one acts, the request terminates and access is not granted. Approvers can be specific users or groups, the requestor's Manager, or, for external requestors, an Internal sponsor or External sponsor; an approver cannot approve their own request.

Trap Assuming all approvers in a stage must approve; only one approver per stage is needed to advance, but a single denial in the stage ends the request.

Each approval stage has a Decision must be made in how many days setting, and a request not approved in that window is automatically denied, forcing the user to re-request. Fallback approvers receive the request when the manager cannot be resolved from the Manager attribute. Alternate approvers receive it when the primary approvers do not act, but enabling alternate approvers requires the request timeout to be at least four days, because forwarding can only happen a day after the request starts.

Trap Confusing fallback approvers with alternate approvers; fallback covers a missing manager, while alternate approvers receive a forwarded request only after the primary approvers fail to act.

An assignment policy's lifecycle settings set an expiration (a duration, or no expiration) and can require a recurring access review that recertifies the assignments the package handed out. Reviewers confirm or revoke each assignment on the configured cadence. Combining a finite duration with a recurring review is how standing access is kept from lingering past need.

A connected organization is an external organization you have a relationship with, specified one of four ways: another Microsoft Entra directory in any Microsoft cloud, a non-Microsoft directory federated via SAML/WS-Fed, a domain whose users authenticate with email one-time passcode, or a Microsoft account such as live.com. A not-in-directory policy can then scope requests to specific connected organizations or all configured connected organizations.

A configured connected organization was created or approved by an admin and is in scope for any policy targeting all configured connected organizations. A proposed organization is auto-created when an All users policy approves someone who belongs to no existing connected organization; it is not in scope for all-configured policies and can only be used by policies that target it specifically. Leaving a proposed social-identity org marked configured can silently widen who an all-configured policy admits.

Trap Treating a proposed connected organization as in scope for an all configured connected organizations policy; only configured organizations are, and proposed ones must be targeted specifically.

When a not-in-directory policy approves an external requestor and the catalog is Enabled for external users, entitlement management uses the B2B invite process to create a guest account but sends no invitation email; the user instead gets the access-delivered email. The B2B allow/blocklist still applies, so a blocked domain cannot be invited until the list is updated. The catalog setting only governs self-service requests, not direct admin assignment.

The lifecycle of external users setting controls cleanup when a B2B guest brought in by entitlement management loses their last access package assignment. The default is to block sign-in and remove the account after 30 days; you can change Number of days before removing external user from directory (set 0 to delete immediately), or block without removing, or do neither. It only governs guests that entitlement management invited or that were converted to governed, so a pre-existing guest is left in place.

Trap Assuming the lifecycle cleanup deletes any guest who loses access; it only removes guests that entitlement management invited or that were explicitly converted to governed, leaving pre-existing guests untouched.

The catalog setting Enabled for external users (Yes by default on a new catalog) decides whether users from connected organizations can self-request the catalog's packages. It is not required for an administrator to directly assign an external user to a package; that path is governed by the access package's own policy. To lock down external self-service, set this to No and avoid not-in-directory request policies.

A terms of use (ToU) policy is a PDF you upload and present at sign-in; the user must accept it before the targeted apps load. It is enforced as a Conditional Access grant control, not as a setting on an access package, so you scope it with Conditional Access assignments. You can require users to expand the document, demand per-device acceptance, and report on who accepted or declined.

Trap Looking for a terms of use toggle inside the access package or catalog; ToU is a separate object enforced through a Conditional Access grant control.

Unlike the rest of entitlement management, terms of use requires only Microsoft Entra ID P1, a lower bar than the ID Governance tier. A tenant can hold no more than 40 terms of use policies. You can set consents to expire on a schedule or after a fixed number of days, localize the PDF per language, and upload a new version, but you cannot modify an already-uploaded document.

Trap Assuming terms of use needs the ID Governance license like access packages; it works on Entra ID P1, and the tenant cap is 40 ToU policies.

Entitlement management grants standing, time-limited assignments to resources like groups, apps, and sites. For just-in-time activation of privileged Entra or Azure admin roles (eligible then activate), use Privileged Identity Management instead. The two are complementary: PIM elevates admin roles on demand, while access packages bundle and time-box resource access.

Trap Reaching for an access package to give just-in-time elevation of an admin role; that is Privileged Identity Management, since access packages grant standing resource assignments, not eligible-then-activate role elevation.

A policy can require requestor justification and collect custom requestor questions (short text, multiple choice, or long text) that are shown to approvers to inform the decision. You can also require approver justification, which is visible to other approvers and to the requestor. Catalog resources can additionally require attributes that the requestor must answer before the request can be submitted.

An automatic assignment policy assigns an access package by an attribute-driven membership rule (like a dynamic group), adding or removing assignments as the attribute changes. Creating one needs at least the Identity Governance Administrator role; catalog owners and access package managers can manage everything else but cannot add this policy type.

Trap Catalog owner or Access Package Manager looks sufficient because they manage the package, but neither can create an automatic assignment policy.

On an access package's Separation of duties tab you list incompatible access packages or incompatible security groups. A user who already holds an assignment to an incompatible package, or is a member of an incompatible group, is then blocked from requesting that package. Configure the incompatibility on the package you want to protect.

Trap This is request-time prevention only, not a Conditional Access or access-review control.

To force re-acceptance you edit the terms, select Update for the language, upload the new PDF, and enable Require reaccept. Users who already accepted are not prompted for the new version until their existing session expires, so they keep working under the old acceptance until then.

Trap It is not an enforcement bug; deleting and recreating the terms (or creating a new one) is the way to force an immediate prompt.