Study Guide

Microsoft Entra roles and Azure roles are two separate role-based access control systems. Entra roles manage directory objects such as users, groups, and applications through Microsoft Graph; Azure roles manage Azure resources such as virtual machines through Azure Resource Manager. Their permissions can't be mixed in one custom role.

Built-in roles can't be changed. When none fits, create a custom role: pick permissions from the preset list (app registrations, enterprise applications, consent, devices, users, and groups), then assign it. Creating one takes at least Privileged Role Administrator, and each user with a custom role assignment needs Microsoft Entra ID P1. You can clone an existing custom role but not a built-in one.

Every assignment joins a security principal, a role definition, and a scope. The scope can be the tenant, an administrative unit, or a single resource such as a group, an enterprise app, or an app registration. You can assign roles to role-assignable groups, which must be created with that option turned on, have assigned (not dynamic) membership, and can't contain other groups.

An administrative unit is a container for users, groups, or devices. A role assigned at its scope covers only the objects in it, so regional or departmental staff can administer their own people without tenant-wide power. A role assigned without a unit applies to the whole tenant. Users can belong to several units, but units can't be nested.

A restricted management administrative unit goes the other way: it protects the objects in it, such as executive accounts or security groups that control access to sensitive apps. Only admins assigned at that unit's scope can change their Entra properties, reset passwords, or change group membership. Tenant-scoped roles, even Global Administrator, can read the objects but can't change them unless they assign themselves a unit-scoped role, which is audited.

Restricted units accept users, devices, and security groups, but not Microsoft 365, mail-enabled security, or distribution groups. Changes in other services still work for tenant admins, such as assigning licenses or changing Exchange mailbox settings.

You can create administrative units with Microsoft Entra ID Free. Each admin who holds a role scoped to a unit needs P1, and each member needs Free, or P1 if the unit uses rules for dynamic membership. Rules can add users or devices, but not groups.

Adding a group to a unit brings the group into scope, not its members. A User Administrator scoped to the unit can rename the group and change its membership, but can't reset a member's password unless that user is also a member of the unit.

Only some roles can be scoped to a unit, the ones that manage users, groups, or devices: for example Helpdesk, Password, User, Groups, License, Authentication, Privileged Authentication, and Cloud Device Administrator, and the Attribute Assignment roles. Unit-scoped roles can go to users, role-assignable groups, and service principals.

Service principals and guests don't read the directory by default, so a unit-scoped role alone doesn't work for them. Give them Directory Readers, or another role with read permissions, at tenant scope; read permissions can't be scoped to a unit.

When an admin calls Microsoft Graph, Microsoft Entra ID reads their role memberships from the wids claim in the token, collects every role assignment that applies to them, directly or through a group, and checks whether any includes the requested action at the requested scope. If none does, the action is denied.

Scope matters as much as the role. A role at a container scope, the tenant or an administrative unit, applies to the objects inside it, not the container itself. A role at a resource scope applies only to that resource; a role scoped to a group doesn't extend to the group's members.

To see what someone holds, open the user and select Assigned roles: it lists each role, its scope, and whether it's direct or inherited from a group. With P2, the page shows PIM eligible, active, and expired assignments. Roles & admins > All roles > Download assignments exports every active assignment. The Roles and administrators page can also show which roles are labeled privileged (in preview).

Every tenant starts with an initial domain such as contoso.onmicrosoft.com, which can't be changed or deleted. To add your own, go to Entra ID > Domain names > Add custom domain as at least a Domain Name Administrator, add the TXT or MX record shown to your registrar, and select Verify. DNS can take an hour or more to propagate, and a domain can be verified in only one tenant.

The primary domain is the default for new users. Any verified custom domain that isn't federated can be primary, and changing it doesn't rename existing users. After you verify a root domain, its subdomains are verified automatically in the same tenant. Microsoft Entra ID allows up to 5,000 managed domains, or 2,500 if all are federated.

You can't delete a domain while users, groups, or app ID URIs still reference it. ForceDelete renames those references to the initial domain and disables the affected accounts in the admin center, but fails with more than 1,000 references, a multitenant app, or a federated domain. Deletion runs in the background and can take up to 24 hours.

Branding needs Microsoft Entra ID P1 or P2, Microsoft 365 Business Standard, or SharePoint (Plan 1), and at least the Organizational Branding Administrator role. Configure it in Entra ID > Custom Branding. Branding doesn't apply to personal Microsoft account sign-ins.

You can set a favicon, background image and color, header and footer, banner and square logos, username hint, sign-in page text (up to 1,024 characters), and a self-service password reset link. Custom URLs in the footer or SSPR link appear as plain text, not links, and the page is public. For Microsoft and multitenant apps, branding appears after the user enters their email, unless a domain hint is in the URL.

Add browser language creates a version for users whose browser uses that language, overriding the default. Custom CSS is being retired: tenants created after January 5, 2026 don't have it, and CSS layout and positioning properties are being removed.

Tenant properties are in Entra ID > Overview > Properties: the technical contact, the global privacy contact (whom Microsoft contacts about a data breach, or Global Administrators if blank), and the privacy statement URL that guests see. Billing Administrator is the minimum role.

User settings restrict default member permissions. Set Users can register applications to No and give chosen users Application Developer; set Restrict non-admin users from creating tenants to Yes and give chosen users Tenant Creator. Restrict access to Microsoft Entra administration portal only hides common pages; it doesn't block PowerShell or Graph, so use Conditional Access for real control. Guest user access restrictions limit what guests can see.

Group settings decide whether users can create security groups and Microsoft 365 groups in portals, the API, or PowerShell, and whether owners can manage membership requests. Requesting to join a group and owner approval need P1 or P2.

Device settings control who can join and register devices, whether MFA is required to do so, and the maximum devices per user (default 50, up to 100). Microsoft recommends the Register or join devices user action in Conditional Access instead of the MFA toggle, which must be No when that policy is used. Cloud Device Administrator can change device settings.

A workforce tenant has internal members (usually employees), internal guests (local accounts with guest privileges), external members (who sign in with another organization's account but get member access, common in multitenant organizations), and external guests.

User Administrator creates users, Guest Inviter invites guests, and Privileged Role Administrator assigns roles. When creating a user, you can add them to up to 20 groups or roles and one administrative unit; external users can't join administrative units.

Deleting a user soft-deletes the account for 30 days. Restoring brings back all its properties and the licenses it had, even if that puts you over your license count. After 30 days, permanent deletion begins and can't be undone. User Administrators can delete non-admins, Helpdesk Administrators, and other User Administrators; Privileged Authentication Administrators can delete any user.

Synced users belong to on-premises Active Directory. If you delete one in Microsoft Entra ID while it still exists on-premises, the next sync can bring it back, so delete it at the source.

Security groups manage access and can contain users, devices, service principals, and other groups. Microsoft 365 groups are for collaboration and contain only users, including people outside the organization. Groups synced from on-premises are managed there, and distribution lists and mail-enabled security groups are managed in the Exchange or Microsoft 365 admin center.

Membership is Assigned, Dynamic User, or Dynamic Device. A dynamic rule such as user.department -eq "Sales" adds and removes members automatically; you can't edit their membership by hand. One rule can't mix users and devices, and device rules can't use the owner's attributes. A tenant can have up to 15,000 dynamic groups, and a rule body can be up to 3,072 characters.

Dynamic membership needs a P1 license for each unique user in dynamic groups (possessed, not necessarily assigned); device members need none. Be careful with attributes users can change themselves, because a rule is only as safe as the attribute's write permissions.

For Microsoft 365 groups, an expiration policy deletes groups that aren't renewed; active groups renew automatically, and deleted groups can be restored within 30 days. A naming policy adds prefixes or suffixes and blocks custom words, and doesn't apply to some admin roles. Both need P1 for the members.

Custom security attributes store business data such as a cost center or clearance level on users and enterprise applications (service principals). Unlike extensions, which anyone who can read the object can read, they have separate read and write permissions, so they suit sensitive data and authorization. They aren't supported in Microsoft Entra Domain Services or in SAML or JWT claims.

Global Administrators have no access by default. Attribute Definition Administrator defines attributes and Attribute Assignment Administrator assigns values; each has a reader counterpart. Attribute Log Reader and Attribute Log Administrator see the separate Custom Security audit logs.

Every attribute lives in an attribute set, which can be delegated. Sets can't be renamed or deleted, and attributes can't be deleted, only deactivated. Names are up to 32 characters with no spaces. A tenant can have 500 active attributes. Data types are Boolean, Integer, and String; Only allow predefined values can go from Yes to No but not back. Attributes can also drive Azure ABAC conditions on role assignments.

In Entra ID > Users > Bulk create (or Bulk delete), download the CSV template, fill it in, and upload it as at least a User Administrator. Keep the version row and header row as downloaded and remove the example row. For bulk create, only Name, User name, Initial password, and Block sign in are required. The Bulk operation results page shows status and a downloadable error file.

Portal bulk operations can time out if they don't finish within an hour, so split large jobs or use PowerShell. Microsoft Graph PowerShell is the module to use; the Azure AD, Azure AD Preview, and MSOnline modules are deprecated, and Get-AzureADUser becomes Get-MgUser.

Connect-MgGraph -Scopes "User.ReadWrite.All"
Import-Csv ".\NewUsers.csv" | ForEach-Object {
  New-MgUser -DisplayName $_.DisplayName -UserPrincipalName $_.UserPrincipalName `
    -MailNickname $_.MailNickname -AccountEnabled `
    -PasswordProfile @{ Password = $_.Password }
}

Microsoft Entra registration suits personal and mobile devices: the user signs in with a local or personal account and adds a work account. Microsoft Entra join suits organization-owned Windows devices (and some macOS and Linux versions), where users sign in with their Entra account and get SSO to cloud and on-premises resources. Hybrid join suits organizations that still depend on on-premises Active Directory.

Choose hybrid join when you still need Group Policy, existing imaging, or Win32 apps that use AD machine authentication. Hybrid joined devices are Windows 10 or 11 (not Home) or Windows Server 2016 to 2022, are joined by IT or Autopilot, and complete registration through Microsoft Entra Connect or AD FS. They need periodic line of sight to domain controllers.

In Entra ID > Devices, disabling a device (Intune Administrator or Cloud Device Administrator) stops it authenticating and revokes its Primary Refresh Token, and can be undone. Deleting a device is permanent and removes details such as BitLocker keys, so wipe or retire Intune-managed devices first. Viewing a BitLocker key is logged in the KeyManagement audit category.

License assignment is done in the Microsoft 365 admin center (Billing > Licenses) or with Microsoft Graph PowerShell. Group-based licensing assigns a product to a security, mail-enabled, or Microsoft 365 group, so members get the license when they join and lose it when they leave. Groups, License, and User Administrators can assign licenses. Nested groups aren't supported, and you can assign to up to 20 groups at a time.

Update-MgUser -UserId "[email protected]" -UsageLocation "FR"
$sku = Get-MgSubscribedSku -All | Where SkuPartNumber -eq "SPE_E5"
Set-MgUserLicense -UserId "[email protected]" -AddLicenses @{SkuId = $sku.SkuId} -RemoveLicenses @()

To report, the Errors & issues tab for a product lists users whose group licenses failed: too few licenses, conflicting service plans, missing dependencies, proxy address problems, or no usage location. Get-MgSubscribedSku shows each plan's counts; available licenses are ActiveUnits minus WarningUnits minus ConsumedUnits.

Open Entra ID > External Identities > External collaboration settings with a role such as External Identity Provider Administrator. Guest user access has three levels: the same as members; limited access to directory objects (the default, which blocks enumerating users and groups); and access only to their own objects, which hides other users, groups, and memberships.

Guest invite settings range from anyone, including guests, to no one. With "Only users assigned to specific admin roles", User Administrators and Guest Inviters can invite; Guest Inviter is the way to let individuals invite without a broader admin role. By default all users, including guests, can invite.

Collaboration restrictions keep either an allow list or a block list of domains, never both. Both the list and cross-tenant access settings are checked at invitation time. The policy is limited to 25 KB, and switching list types discards the old one.

External user leave settings let guests remove themselves, or require them to contact your admin or privacy contact. The setting is available only after you add privacy information in the tenant properties. The same page also turns on self-service sign-up through user flows.

To invite one guest, go to Entra ID > Users > New user > Invite external user as at least a User Administrator (or a Guest Inviter). The guest gets a UPN built from their email plus #EXT# and your onmicrosoft.com domain. If the invitation state stays Pending acceptance, resend it.

For many guests, use Bulk operations > Bulk invite: download the CSV template, fill in Email address to invite and Redirection url for each row, and upload it. Bulk operation results shows successes and failures.

When a guest accepts, Microsoft Entra ID tries, in order: an existing Microsoft Entra account, a SAML/WS-Fed IdP that matches their domain, Google for Gmail addresses, an existing Microsoft account, and then email one-time passcode (or creating a Microsoft account if OTP is off). The guest then accepts your privacy terms, and their status changes from PendingAcceptance to Accepted.

Instead of the email, you can give a guest already in the directory a tenant-specific direct link, or let them use a common endpoint such as My Apps. Guests who sign in with an alias of the invited address need the invitation email.

Two properties describe a B2B user independently. UserType, Member or Guest, says how the organization treats them, not how they sign in. Identities says where they authenticate: ExternalAzureAD for another Microsoft Entra tenant, google.com, mail for email one-time passcode, a SAML issuer URI, or your own domain for internal accounts. Change UserType only when the person's relationship to the organization changes.

When a guest needs a new email or identity provider, for example because their home account was recreated or they changed companies, reset their redemption status and reinvite them. They keep their object ID, group memberships, and app assignments. Helpdesk Administrator is the least-privileged role for this.

Guests can be added to any Microsoft Entra role, even when guest user access is restricted, and then have that role's permissions. Use least privilege and consider Privileged Identity Management for time-limited access.

By default, B2B collaboration with other Microsoft Entra organizations is allowed in both directions, B2B direct connect is blocked, MFA and device claims from other tenants aren't trusted, and no users are synced in. Settings you add for a specific organization override the defaults, and there's no limit on how many you add.

Outbound settings control whether your users can reach another organization; inbound settings control whether its users can reach yours, for all users or specific users, groups, and applications. Inbound trust settings let your Conditional Access policies accept MFA, compliant device, and hybrid joined device claims from the partner. If you trust their MFA, consider excluding external users from the ID Protection MFA registration policy.

B2B direct connect is mutual: both organizations must enable it for each other. Automatic redemption suppresses the first-time consent prompt only when the home tenant selects it outbound and the resource tenant selects it inbound. Changing these settings needs at least Security Administrator.

Cross-tenant synchronization is for organizations with several Microsoft Entra tenants. It automates creating, updating, and removing B2B users, so users reach apps in other tenants without invitations or consent prompts. It's a push from the source tenant, based on the Microsoft Entra provisioning engine, and syncs only internal members, not guests. Users arrive as external members by default. Cycles start every 40 minutes.

Each synced user needs Microsoft Entra ID P1 in the source tenant; the target needs no licenses for it. The target tenant turns on Allow user synchronization into this tenant (inbound) and automatic redemption; the source tenant turns on automatic redemption (outbound) and creates the configuration, including scope and attribute mappings. Hybrid Identity Administrator configures sync, and Security Administrator configures cross-tenant access settings.

If a user already exists as a guest in the target, sync matches and updates it, but keeps it a guest unless the Member (userType) mapping is set to Apply this mapping: Always. With group sync, scope must be Sync only assigned users and groups, and role-assignable groups can't be created. The target tenant can stop sync at any time.

Microsoft Entra accounts and Microsoft accounts work without configuration. Email one-time passcode is on by default as a fallback: a code is valid for 30 minutes, and a session lasts 24 hours. Google federation lets Gmail users sign in with Google. Facebook is available only for self-service sign-up, not invitation redemption. Setting up Google, Facebook, or SAML/WS-Fed needs at least External Identity Provider Administrator.

SAML/WS-Fed federation lets partners with any SAML 2.0 or WS-Fed IdP use their own accounts. If the host of the IdP's passive authentication URL doesn't match the partner's domain, the partner adds a DNS TXT record (DirectFedAuthUrl). The endpoint must use HTTPS, the policy takes 5 to 10 minutes to apply, and the issuer must be a valid URI. Domainless federation skips the email domain check. Between two Microsoft Entra tenants, native B2B is used rather than SAML.

The Redemption order tab in cross-tenant access settings changes which providers guests try first. Microsoft accounts and email one-time passcode are fallbacks; at least one must stay on, so turning off Microsoft accounts requires OTP. Reset the redemption status of existing Microsoft account guests to move them.

Microsoft Entra Connect includes synchronization, password hash sync, pass-through authentication, AD FS federation integration, and Connect Health monitoring. It's free with your subscription. Azure AD Connect V1 was retired in 2022, so run Connect V2, and Microsoft now suggests evaluating Cloud Sync first.

The built-in scheduler runs a sync cycle every 30 minutes by default. Get-ADSyncScheduler shows its settings, Set-ADSyncScheduler changes the interval, and Start-ADSyncSyncCycle -PolicyType Delta (or Initial for a full sync) runs one now. If you change the interval, a sync must still run at least every 7 days.

A second server in staging mode imports and synchronizes but doesn't export or sync passwords. Use it to preview configuration changes and as a standby you can switch to active if the main server fails; it has its own SQL database, and you must copy configuration changes to it yourself.

Duplicate attribute resiliency keeps one bad value from blocking an object: a duplicate UPN is replaced by a placeholder and a duplicate proxy address is quarantined, and the conflict appears in the sync error report.

Cloud Sync has two parts: provisioning agents on-premises, which make only outbound connections and update themselves, and the cloud provisioning service, which holds the configuration and runs sync every two minutes using SCIM. Several agents can run at once, so there's no single server to fail, unlike Connect Sync.

Choose Cloud Sync for multiple disconnected forests, such as after a merger, and for provisioning cloud groups back to AD, which only Cloud Sync does. Both tools support password hash sync, password writeback, Exchange hybrid attributes, and OU-based filtering.

Keep Connect Sync when you need device sync for hybrid join, pass-through authentication configuration, full attribute-based filtering, more than 150,000 objects per domain, or groups larger than 50,000 members (Connect handles up to 250,000).

The sync agent never sees clear-text passwords. It takes the MD4 hash from AD, adds a per-user salt, and runs PBKDF2 with 1,000 iterations of HMAC-SHA256; only that result goes to Microsoft Entra ID, so a stolen cloud hash can't be used for pass-the-hash on-premises. Password sync runs every 2 minutes and can't be changed.

PHS enables leaked credential detection in ID Protection for hybrid accounts (only for leaks found after you turn it on) and can serve as a backup if you federate with AD FS.

Update-MgUser -UserId "[email protected]" -PasswordPolicies "DisablePasswordExpiration"

Choose pass-through authentication when on-premises AD must check every password and enforce its own policies. Agents receive sign-in requests over outbound connections and validate them against AD; passwords aren't stored in the cloud in any form. It's free, works with Conditional Access and smart lockout, and pairs with seamless SSO. For cloud authentication in general, Microsoft recommends password hash sync.

Run at least 3 agents in production (the limit is 40 per tenant) on Windows Server 2016 or later, in the same forest as the users. They need outbound ports 80 and 443 and no perimeter network. Treat their servers as Tier 0.

PTA is tenant-wide and affects all managed domains. A Hybrid Identity Administrator enables it through Microsoft Entra Connect. When switching from AD FS, wait at least 12 hours before shutting AD FS down. Keep a cloud-only Hybrid Identity Administrator in case on-premises services fail.

Seamless SSO works with password hash sync or pass-through authentication, not AD FS. It needs domain-joined devices on the corporate network. For Windows 10 and later, SSO through the Primary Refresh Token on Entra joined, hybrid joined, or registered devices is recommended instead. It's opportunistic: if it fails, users see the normal sign-in page.

Enabling it creates a computer account named AZUREADSSOACC in each synced forest and shares its Kerberos decryption key with Microsoft Entra ID. Protect that account: only Domain Admins should manage it, and Kerberos delegation must be off. Move it to AES-256 (rolling over the key first), because AD DS changes its default from RC4 to AES-256 with the July 2026 Windows Server update.

Enabling needs domain administrator credentials for each forest (they aren't stored). Roll it out with Group Policy: add https://autologon.microsoftazuread-sso.com to users' intranet zone and enable Allow updates to status bar via script. Allow that URL through outbound proxies.

For users, Microsoft recommends cloud authentication, preferably password hash sync. Test with staged rollout, then convert each domain from federated to managed with Microsoft Entra Connect or PowerShell; conversion can take up to 60 minutes. Plan a rollback: New-MgDomainFederationConfiguration converts a domain back to federated.

Staged rollout is a temporary test for tenants with federated domains. You add security groups per feature (PHS, PTA, seamless SSO), up to 10 groups each; nested and dynamic groups aren't supported, and the first add is limited to 200 users. It needs Hybrid Identity Administrator, doesn't convert the domain, and SSPR writeback isn't guaranteed while it's on.

For applications, the AD FS application migration tool (P1 or P2, with Connect Health agents for AD FS) lists relying party apps with sign-ins in the last 30 days, marks them Ready or Needs review, and configures SAML URLs, claims, and user assignments. Migrate modern-protocol apps (SAML, OpenID Connect) first; line-of-business apps using OAuth 2.0, OpenID Connect, or WS-Fed become app registrations, and legacy-protocol apps can use Application Proxy. Test against a test instance before pointing the production app at Microsoft Entra ID.

Connect Health needs Microsoft Entra ID P1 or P2 and a Global Administrator or Hybrid Identity Administrator to install agents. Install the agent on every server you monitor: AD FS and Web Application Proxy servers, domain controllers, and the Connect server. Agents run on Windows Server 2016 to 2025, need outbound connectivity, and shouldn't sit behind TLS inspection.

For sync, it shows alerts with resolution steps, sync latency and object change trends, and an object-level sync error report grouped by category, such as duplicate attribute and data mismatch, updated every 30 minutes and downloadable as CSV. Email notifications for alerts are on by default, and sync error emails come as a daily digest.

For AD FS, usage analytics need AD FS audit logs, which are off by default: grant Generate security audits, enable application-generated auditing with auditpol, and set the AD FS audit level to verbose. Deleting a server from Connect Health stops monitoring but doesn't uninstall the agent.

The Authentication methods policy (Entra ID > Authentication methods > Policies) is where you enable methods, for all users or chosen groups; an Authentication Policy Administrator manages it. Since September 30, 2025, methods can't be managed in the legacy MFA and SSPR policies. Manage migration moves a tenant through Pre-migration, Migration in Progress, and Migration Complete; only in Migration Complete are legacy settings ignored.

Until then the policies combine: a user enabled for a method in any policy can use it, so to block a method, disable it everywhere. Security questions can still be enabled only in the legacy SSPR policy.

Microsoft recommends phishing-resistant methods: Windows Hello for Business, passkeys (FIDO2), including synced passkeys and passkeys in Authenticator, and certificate-based authentication. SMS, voice calls, email codes, and push approvals can be phished. Some methods work as a first factor (for example TAP, passkeys, CBA, SMS sign-in), others only as a second factor or for SSPR (for example voice calls).

Security defaults give Free tenants a baseline: every user registers for MFA (with no grace period since July 29, 2024), admins always do MFA, users do MFA when necessary, and legacy authentication is blocked. They're turned on for new tenants; use Conditional Access when requirements are more complex.

Certificate-based authentication lets users sign in with X.509 certificates directly against Microsoft Entra ID, without AD FS, and is free and phishing-resistant. A Privileged Authentication Administrator uploads the CAs to a PKI-based trust store (up to 250 CAs; uploading a whole PKI file needs P1 or P2). Each CA needs an internet-reachable CRL, or revoked certificates still work. An Authentication Policy Administrator sets authentication bindings (single-factor or multifactor) and username bindings.

A Temporary Access Pass is a time-limited code for onboarding passwordless methods or recovering access. By default it lasts 1 hour (maximum 8 hours; allowed range 10 minutes to 30 days), and each user has only one. Authentication Policy Administrators enable the policy; Authentication Administrators create TAPs for members, and Privileged Authentication Administrators for admins too, never for themselves. External guests can't get one.

The outline says "OAuth 2.0 tokens", but the method in Learn is OATH tokens. Microsoft Entra ID supports OATH TOTP in software (Authenticator or third-party apps) and hardware (SHA-1 or SHA-256, 30- or 60-second codes, in preview); HOTP isn't supported.

Microsoft Authenticator supports device-bound passkeys, passwordless sign-in through notifications, MFA push notifications with number matching on every push, and OATH codes. Passkeys are device-bound (such as security keys) or synced through a passkey provider; synced passkeys don't support attestation, so enforcing attestation allows only device-bound ones. Passkey profiles set attestation, passkey type, and AAGUID restrictions per group.

Report suspicious activity lets users report an MFA prompt they didn't start, which sets them to high user risk in ID Protection so risk-based policies can act. Enable it in the Authentication methods policy Settings; Microsoft managed leaves it disabled. It replaced the legacy Block/unblock users, Fraud alert, and Notifications features, which were removed on March 1, 2025.

System-preferred authentication asks users for the most secure method they registered, such as a passkey instead of SMS. It's a three-state setting: Enabled applies it to the second factor, Microsoft managed to both factors (rolling out through September 2026), and Disabled turns it off.

The legacy MFA service settings page still holds trusted IPs, verification options, app passwords, and remember MFA. Trusted IPs skip MFA from defined ranges; cloud MFA accepts only public ranges, up to 50, and Conditional Access named locations are the modern replacement. Remember MFA sets a persistent browser cookie for a number of days (Microsoft suggests 90 or fewer); it doesn't apply to B2B users, conflicts with the sign-in frequency control, and is cleared when you revoke sessions.

Enable SSPR for None, Selected (one group in the admin center), or All users. Password reset needs Microsoft Entra ID P1, and at least an Authentication Policy Administrator configures it. Pilot with a test group first.

You choose how many methods a reset requires (one or two), whether users must register at sign-in, and how often they reconfirm their details (0 to 730 days). Users must register at least one enabled method; two or more is recommended.

Accounts with admin roles follow a fixed two-gate policy: two methods and no security questions. It can't be changed and doesn't depend on the Authentication methods policy, so test SSPR as a non-admin.

Password writeback sends cloud resets and changes to on-premises AD in real time through Microsoft Entra Connect or Cloud Sync, checks them against AD's password policy, and tells the user immediately if they fail. It works with password hash sync, PTA, and AD FS, but isn't guaranteed while staged rollout is on.

Windows Hello for Business uses key-based or certificate-based authentication: the user's PIN or biometric unlocks a private key on the device, and only the public key is registered with Microsoft Entra ID or AD. There's no shared secret on a server to steal or phish. Provisioning requires a second factor before the key pair is created.

The deployment model is cloud-only, hybrid, or on-premises. For hybrid and on-premises, the trust type decides how clients authenticate to AD: cloud Kerberos trust (a TGT from Microsoft Entra Kerberos), key trust (needs certificates on domain controllers), or certificate trust (issues certificates to users). Trust types don't apply to cloud-only deployments.

Microsoft recommends cloud Kerberos trust over key trust for hybrid deployments, because it needs no PKI for users or DCs. If the Use certificate for on-premises authentication policy is set, certificate trust takes precedence, and there's no direct migration from certificate trust.

Configure it with Intune for Entra joined or hybrid joined devices enrolled in Intune, or with Group Policy for domain-joined devices without MDM. Intune's tenant-wide enrollment policy applies only at enrollment, so many organizations disable it and target a policy at a group.

Disabling (blocking sign-in) stops new sign-ins; revoking sessions invalidates refresh tokens so apps can't silently get new access tokens. Access tokens already issued last up to 1 hour by default, and continuous access evaluation lets supporting apps react in near real time. In the admin center, use Revoke sessions on the user's Overview page.

Update-MgUser -UserId $user.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $user.Id
Get-MgUserRegisteredDevice -UserId $user.Id -All | ForEach-Object {
  Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false }

User Administrator can disable non-admin users, Privileged Authentication Administrator can disable admins, and Cloud Device Administrator can disable devices. Revoking sessions also removes remembered MFA from the user's devices.

The global banned password list applies to everyone and can't be turned off. A custom list adds up to 1,000 organization-specific terms. Every change or reset is normalized (for example, lowercase and common character substitutions), fuzzy-matched against both lists, checked for the user's name and the tenant name, and scored; a password needs at least five points.

Cloud-only users get the global list with Free and need P1 or P2 for a custom list. Users synced from AD DS need P1 or P2 for both.

On-premises, install the proxy service on a domain-joined server and the DC agent on domain controllers. DCs never need internet access; the agent fetches the policy through the proxy, refreshes it hourly, and stores it in SYSVOL. Start in Audit mode, then switch to Enforced; only DCs with the agent enforce the policy.

Smart lockout locks an account for a minute after 10 failed attempts (Azure Public), longer after further failures, ignores repeats of the same bad password, and counts familiar and unfamiliar locations separately. Customizing it needs P1. With pass-through authentication, keep the Entra threshold lower and the Entra duration longer than AD's.

When a hybrid user signs in on an Entra joined or hybrid joined device, Microsoft Entra ID issues a Primary Refresh Token plus a cloud TGT for the realm KERBEROS.MICROSOFTONLINE.COM and a partial TGT for on-premises use. The partial TGT has the user's SID but no groups, so a domain controller exchanges it for a full TGT. This lets Windows Hello for Business and FIDO2 keys reach on-premises file shares and apps.

Set-AzureADKerberosServer -Domain "contoso.com" -UserPrincipalName "[email protected]" -DomainCredential $domainCred

Azure Files can use Microsoft Entra Kerberos so synced hybrid users get Kerberos tickets for SMB shares from Microsoft Entra ID. A storage account can use only one identity source, and MFA must be disabled on the Entra app that represents the storage account. Support for cloud-only identities is in preview.

A Conditional Access policy says: if a user (or workload identity) accesses a resource under certain conditions, then grant, limit, or block access. Policies apply after first-factor authentication, need Microsoft Entra ID P1 (Microsoft 365 Business Premium includes it), and risk-based conditions need ID Protection (P2). If licenses lapse, policies stay but can't be updated.

Every applicable policy must be satisfied, and a Block control ends the evaluation. Within a policy, assignments combine with AND, and grant controls default to Require all.

Plan exclusions for emergency access accounts and service accounts, and target groups, roles, or users broadly rather than listing individuals. A tenant can hold 240 policies in any state. Test new policies in report-only mode first.

The Conditional Access Optimization Agent in Microsoft Security Copilot suggests new policies and changes based on Zero Trust guidance and can apply them in one click. It needs at least P1.

Users can be All users (including B2B guests), guest or external user types, built-in directory roles, or groups (nested and dynamic membership included). Exclusions override inclusions. Roles scoped to administrative units and custom roles can't be targeted.

Target resources include apps, the Office 365 grouping (use it for Exchange, SharePoint, and Teams to avoid service dependency issues), Windows Azure Service Management API (the Azure portal and Azure Resource Manager tools such as Azure PowerShell, not Microsoft Graph PowerShell), Microsoft Admin Portals, user actions (Register security information and Register or join devices), Global Secure Access traffic profiles, and authentication context.

Network uses the public IP or Authenticator GPS; policies include or exclude named locations, trusted locations, or any location. Conditions add user and sign-in risk, insider risk, device platforms, client apps (Exchange ActiveSync and Other clients mean legacy authentication), and filter for devices.

Conditional Access for workload identities can block single-tenant service principals by location or risk. It needs Workload Identities Premium and doesn't cover managed identities or multitenant apps.

Block access stops sign-in. Grant access can require MFA, an authentication strength, a device marked compliant, a hybrid joined device, app protection (with the approved client app option), a password change, risk remediation, or terms of use. With several controls, the default is Require all; Require one of the selected controls accepts any.

Authentication strengths define which method combinations count. The built-in Multifactor authentication, Passwordless MFA, and Phishing-resistant MFA strengths can't be changed; you can create custom ones.

Require device to be marked as compliant needs a device registered in Microsoft Entra ID and marked compliant by Intune (or a supported MDM for Windows); InPrivate browsing on Windows counts as noncompliant. Microsoft announced the approved client app grant retires in early March 2026; use Require approved client app or app protection policy instead.

Require password change forces MFA and a secure password change for risky users; it must target All resources and stand alone. Require risk remediation works for any method, including passwordless, and adds authentication strength and sign-in frequency Every time. Terms of use appear as a grant once you create them.

The What If tool simulates a sign-in for a user, agent identity, or single-tenant service principal under conditions you choose, and lists which enabled and report-only policies would apply. It doesn't consider service dependencies.

Report-only mode evaluates a policy without enforcing it and records Success, Failure, User action required, or Not applied in the Conditional Access and Report-only tabs of each sign-in log entry. It can't evaluate user action policies, and compliant device policies in report-only can still prompt mobile and macOS users for a certificate.

To see why a sign-in was blocked, open the sign-in logs (Entra ID > Monitoring & health > Sign-in logs) as at least a Reports Reader, filter for Conditional Access failures, and open the Conditional Access tab. The error page's More details shows the correlation and request IDs for support.

The insights and reporting workbook shows the combined impact of policies over time. It needs sign-in logs in a Log Analytics workspace, P1, and at least Security Reader plus workspace permissions.

Sign-in frequency sets how long before users must sign in again, in hours or days, or Every time (with five minutes of clock skew). Without it, the default is a rolling 90-day window. Turn off Remember MFA before using it, because the two conflict.

Persistent browser session decides whether users stay signed in after closing the browser, and overrides the "Stay signed in?" option in company branding.

Use app enforced restrictions passes device information to apps such as SharePoint and Exchange so they can offer limited, web-only experiences on unmanaged devices. Use Conditional Access App Control routes sessions through Microsoft Defender for Cloud Apps, whose session policies can block downloads or monitor activity in real time.

Token protection accepts only device-bound session tokens, such as the Primary Refresh Token, to stop stolen tokens being replayed elsewhere. It's enforced for services such as Exchange Online, SharePoint Online, and Teams on registered or joined Windows 10 or newer devices.

Learn has no page with this bullet's exact name, so this topic covers the Conditional Access features that enforce requirements on the device itself. The compliant device and hybrid joined device grants are in the controls topic.

Filter for devices includes or excludes devices with a rule on device properties, for example device.extensionAttribute1 equals "SAW" to allow only privileged access workstations to reach the Azure portal, or trustType and isCompliant. Unregistered devices have null properties, so filters can't identify them. Extension attributes are set through Microsoft Graph.

The device state condition is deprecated; use filter for devices instead, and don't combine them. To block unsupported platforms such as Chrome OS, include any device platform, exclude the supported ones, and block. Platform detection relies on unverified user agent strings.

Critical event evaluation doesn't need Conditional Access. Exchange, SharePoint, and Teams subscribe to events such as a user being deleted or disabled, a password change or reset, MFA being enabled, an admin revoking refresh tokens, and high user risk (SharePoint doesn't support user risk). Users lose access within minutes.

Conditional Access policy evaluation lets Exchange, SharePoint, Teams, and Microsoft Graph evaluate location policies themselves, so a user who moves to a disallowed network loses access right away. Strictly enforce location policies (preview) blocks immediately when the resource sees an IP address that isn't allowed.

Because revocation is event-driven, CAE-aware sessions get tokens that last up to 28 hours; services reject tokens with a claim challenge, and clients go back to Microsoft Entra ID. Without CAE-capable clients, access tokens still last 1 hour. You can disable CAE only in a policy that targets All resources with no conditions.

An authentication context (c1 to c99) represents a level of protection, such as "trusted device". Apps apply it to sensitive resources: sensitivity labels on SharePoint sites and Teams, Defender for Cloud Apps session policies for step-up, custom apps, and PIM's On activation, require authentication context setting. A lunch menu site can stay open while a confidential site requires a managed device and terms of use.

Create contexts in Entra ID > Conditional Access > Authentication context and select Publish to apps so apps can use them. Then target the context in a policy under Target resources > Authentication context. A policy can target authentication context for users or workload identities, but not both.

Before deleting a context, make sure no app uses it (check sign-in logs), remove it from all policies, and unpublish it.

A protected action is a permission with Conditional Access policies assigned through an authentication context. When someone performs the action, they must satisfy that policy, whatever role gave them the permission. They need P1. Typical policies require phishing-resistant MFA, a privileged access workstation, or recent sign-in.

Supported areas are Conditional Access policy management, cross-tenant access settings, hard deletion of some directory objects, custom rules that define network locations, and protected action management.

Set them up in order: create an authentication context, create a Conditional Access policy that targets it and is On (not report-only), then go to Entra ID > Roles & admins > Protected actions and add permissions with that context. You need Conditional Access Administrator or Security Administrator. Out-of-order setup can cause repeated prompts.

PIM can also require Conditional Access at role activation. PIM protects getting the role; protected actions protect using the permission. Use both for the strongest coverage.

Find templates in Entra ID > Conditional Access > Create new policy from templates. They're grouped as Secure foundation, Zero Trust, Remote work, Protect administrator, Emerging threats, and AI Agents. Microsoft recommends the Secure foundation policies as a baseline for everyone, deployed as a group; they include MFA for admins and for all users, securing security info registration, blocking legacy authentication, MFA for Azure management, and requiring a compliant device.

A policy created from a template starts in report-only mode. User-targeted templates exclude only the admin who created the policy, so add your emergency access accounts before turning it on. You can export a template's JSON, edit it, and import it with Upload policy file.

ID Protection calculates user risk from signals such as leaked credentials and risky sign-in history. The leaked credentials detection matches credentials found in breaches against your tenant's valid password hashes and is always high risk; for hybrid users it works through password hash sync, and a cloud password reset remediates it.

Microsoft recommends a Conditional Access policy for all users, excluding emergency access accounts, with user risk High and Require risk remediation, tested in report-only mode first. Require risk remediation handles both password and passwordless users (a secure password change, or session revocation and sign-in again) and adds authentication strength and sign-in frequency Every time. Require password change forces a secure password change. Block needs an admin to unblock.

If a user is in several risk policies, Block wins, then Require risk remediation, then Require password change. Risk remediation isn't supported for guests. The legacy user and sign-in risk policies inside ID Protection retire on October 1, 2026; migrate them to Conditional Access.

ID Protection scores every sign-in for risk in real time and adds offline detections afterward. Examples include anonymous IP address, atypical travel, unfamiliar sign-in properties, malicious IP address, password spray, and suspicious MFA authentication approval. Most detections are premium (P2); without P2, they appear only as Additional risk detected.

Microsoft recommends requiring MFA when sign-in risk is Medium or High, with sign-in frequency Every time. Completing MFA self-remediates the risky sign-in. Users must already have an MFA-capable method registered; otherwise the policy blocks them and an admin has to help.

The ID Protection MFA registration policy prompts users at their next interactive sign-in and gives them 14 days to register; after that, they must register to sign in. Changing it needs P2 or Microsoft Entra Suite. If you trust MFA from partner tenants, consider excluding external users, or they can't satisfy both.

A registration campaign nudges users, after they complete MFA, to set up a stronger method: a passkey (FIDO2) or Microsoft Authenticator push, one method per campaign. Microsoft managed applies Microsoft's settings; Enabled lets you choose the method, users, and snoozes (0 to 14 days, and optionally registration required after 3 snoozes). For the Authenticator campaign, Authenticator's mode must be Any or Push.

Combined security information registration gives one experience for MFA and SSPR methods, in Interrupt mode during sign-in or Manage mode on the Security info page, and it's the only registration experience aware of the Authentication methods policy. Protect it with a Conditional Access policy on the Register security information user action.

ID Protection's Risky users, Risky sign-ins, and Risk detections reports show what was detected; ID Protection alerts also appear in the Microsoft Defender portal with the product name AAD Identity Protection. Full features need Microsoft Entra ID P2. Global Reader is the least-privileged role to view the risk reports (Security Reader can too); Security Operator can dismiss risk and confirm compromise; Security Administrator has full access.

Feedback matters: Confirm compromised raises user risk to high and adds an Admin confirmed user compromised detection; Confirm safe removes risk and puts the user back into learning; Dismiss marks a real but benign risk, such as a penetration test.

To remediate manually, generate a temporary password (the risk state becomes Remediated), require a password change, dismiss the risk, confirm compromise and secure the account, or unblock the user. User Administrator is the least-privileged role to reset passwords and Security Operator to dismiss risk; resetting from ID Protection needs both.

ID Protection detects risk on single-tenant, non-Microsoft SaaS, and multitenant apps, but not managed identities. Detections include leaked credentials (for example, a secret pushed to GitHub), suspicious sign-ins against a learned baseline (learned over 2 to 60 days), malicious applications, and admin confirmed service principal compromised. Full details and risk-based controls need Workload Identities Premium; without it, you still get detections with limited detail.

Security Administrator, Security Operator, or Security Reader can use the Risky workload identities report. Conditional Access Administrator can create a policy that blocks service principals by risk, which needs Workload Identities Premium.

To remediate, inventory the identity's credentials, add a new credential (Microsoft recommends X.509 certificates), remove the compromised ones, or all of them if the app is at risk, and rotate any Key Vault secrets it can reach.

Global Secure Access is Microsoft's Security Service Edge (SSE) solution: Microsoft Entra Internet Access, a secure web gateway, and Microsoft Entra Private Access, zero trust access to private apps, managed in one area of the Microsoft Entra admin center. Internet Access for Microsoft services also covers Microsoft 365 traffic.

The client captures traffic with a lightweight filter driver rather than a VPN connection, so it can coexist with other SSE and VPN products. Remote networks connect branch offices without the client.

On Windows it needs 64-bit Windows 10 (LTSC 2021 or later) or Windows 11, local admin rights to install, and a Microsoft Entra joined, hybrid joined, or registered device; on registered devices only Private Access traffic is supported (preview). Intune can deploy it silently with /quiet. On Android and iOS, it's part of the Microsoft Defender for Endpoint app, deployed with Intune; on iOS it uses a local, self-looping VPN. On macOS, approve its system extensions and transparent proxy, silently through MDM if you like.

Microsoft Entra Private Access gives users access to private apps and resources, on any port and protocol, without a VPN, with Conditional Access per app. It builds on Microsoft Entra application proxy and uses the same private network connectors.

Quick Access is one primary group of FQDNs, IP addresses, and ranges you always tunnel; it's a common first step to replace a VPN. Per-app access creates separate Global Secure Access apps so you can segment resources and apply different Conditional Access policies or user assignments. Both create an enterprise application and need a connector group with at least one active connector.

Connectors run on Windows Server 2016 or later with TLS 1.2, near the back-end resources, and make only outbound connections. Install more than one for high availability and organize them into connector groups; Application Administrator can install them.

Private Access and Internet Access are included in Microsoft Entra Suite or sold standalone, and users also need Microsoft Entra ID P1 or P2. Internet Access for Microsoft services is included in P1 or P2.

Microsoft Entra Internet Access filters web traffic by web category, URL, and FQDN, and can allow or block HTTP methods. Create a web content filtering policy (Global Secure Access > Secure), group policies into a security profile, and link the profile to a Conditional Access policy so it applies to the right users and conditions. A profile can hold many policies and link to many Conditional Access policies.

The baseline security profile applies to all Internet Access traffic in the tenant, including remote network traffic, at the lowest priority. When matching policies conflict, the most restrictive action (block) wins.

For the client to tunnel traffic, turn off DNS over HTTPS. QUIC (UDP 443) isn't supported, so blocking it forces TCP. Without TLS inspection, only SNI-based rules apply; HTTP method and source traffic type rules need it.

Traffic is matched against the Microsoft traffic profile first, then Private Access, then Internet Access; anything that matches none isn't forwarded.

The outline says "Internet Access for Microsoft 365"; Learn calls it Microsoft Entra Internet Access for Microsoft services, and it's included with Microsoft Entra ID P1 or P2. A Global Secure Access Administrator enables the Microsoft traffic forwarding profile in Global Secure Access > Connect > Traffic forwarding; its policy groups (Exchange Online, SharePoint Online and OneDrive, and Microsoft Teams) can each be forwarded or bypassed.

The compliant network check lets a Conditional Access policy require that users come through your tenant's Global Secure Access client or remote network, without maintaining IP lists, which reduces token theft and replay. Enable Global Secure Access signaling for Conditional Access, then use All Compliant Network locations. The check is specific to your tenant.

Source IP restoration passes the user's original egress IP to Microsoft Entra ID and Microsoft Graph, so IP-based location policies, ID Protection, and sign-in and audit logs see the real address rather than the proxy's. It needs the Microsoft traffic profile and is on by default for new tenants.

Conditional Access can also target the traffic profiles themselves (Microsoft traffic, private resources, internet access) with controls such as MFA or a compliant device.

In Microsoft Entra ID, workload identities are applications, service principals, and managed identities. An application object is an app's single global definition in its home tenant; a service principal is its local instance in each tenant that uses it, and is what receives permissions. A multitenant app has a service principal in every tenant that consents.

For a workload running on an Azure resource, use a managed identity: a special service principal whose credentials Azure manages, at no extra cost. For apps elsewhere, use a service principal and prefer certificates over secrets, stored in Azure Key Vault. Better still, use workload identity federation so a user-assigned managed identity or app registration trusts tokens from GitHub Actions, Kubernetes, Google Cloud, or AWS, with no secret at all.

On-premises, use a group managed service account (gMSA) wherever possible, including for load-balanced farms; a standalone managed service account (sMSA) if not; and a user account only as a last resort. Local user accounts can't authenticate to the domain.

A system-assigned managed identity is enabled on one Azure resource, has the same name, and is deleted with it. A user-assigned managed identity is its own Azure resource, with its own lifecycle, and can be assigned to many resources. Microsoft recommends user-assigned identities for Microsoft services.

Choose user-assigned when many resources share the same access, when resources are created quickly (creating many system-assigned identities can hit HTTP 429 throttling, and deleted ones count against limits for 30 days), or when role assignments must exist before the resources. Choose system-assigned when each resource needs its own identity that disappears with it.

Creating a user-assigned identity needs the Managed Identity Contributor role; choose a subscription, resource group, region, and name. Identities can be managed through the portal, ARM templates, Azure CLI, PowerShell, or REST. Their management operations appear in Azure Activity logs, and their sign-ins in the Microsoft Entra sign-in logs.

To enable or remove a system-assigned identity on a VM, you need Virtual Machine Contributor and no Microsoft Entra directory role; turn it on in the VM's Identity section at creation or later.

To attach a user-assigned identity to a VM, you need Virtual Machine Contributor on the VM and Managed Identity Operator on the identity; removing it needs only Virtual Machine Contributor. Managed Identity Contributor creates identities, and Managed Identity Operator assigns them.

Not every Azure service or resource type supports managed identities, and each adopts them on its own timeline, so check the support list. Azure Policy can assign managed identities to resources (preview).

Grant access with Azure RBAC: on the target resource, open Access control (IAM) > Add role assignment and pick the managed identity, with the least privilege the workload needs.

$r = Invoke-WebRequest -Method GET -Headers @{Metadata="true"} `
  -Uri "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https%3A%2F%2Fdatalake.azure.net%2F"
$token = ($r.Content | ConvertFrom-Json).access_token

Managed identities fall outside Conditional Access for workload identities and ID Protection risk detection, so least-privilege role assignments are the main control; they can be included in access reviews of Azure resource roles.

Each enterprise app has Enabled for users to sign in, Assignment required, and Visible to users, plus owners and notes. With Assignment required, only assigned users (and Global Administrators) can sign in. Only assigned users ever see the app in My Apps, so to show it to some users while letting everyone in, assign those users and set Assignment required to No.

Setting Visible to users to No hides the app from My Apps and the Microsoft 365 launcher (Cloud Application Administrator); hiding all Microsoft 365 apps needs a Global Administrator. A custom logo must be a 215 x 215 pixel PNG under 100 KB. The homepage URL is edited on the application object, not the enterprise app.

Tenant-level settings apply to all apps: user consent settings and the admin consent workflow (under Consent and permissions), and user settings such as whether users can register applications.

Application Administrator and Cloud Application Administrator both manage all app registrations and enterprise apps, including SSO and consent; only Application Administrator can manage application proxy. Neither manages Conditional Access.

The least-privileged choice for one app is ownership: an enterprise application owner can update that app's SSO, properties, provisioning, self-service, and assignments. Creating enterprise apps and consenting to delegated permissions need Cloud Application Administrator; consenting to Microsoft Graph application permissions needs Privileged Role Administrator.

When Users can register applications is off, Application Developer lets selected people still create app registrations, and they become owners of what they create.

Application proxy gives remote users access to on-premises web apps through an external URL after they sign in with Microsoft Entra ID, so Conditional Access and MFA apply. Private network connectors make only outbound connections on ports 80 and 443, so you don't open inbound ports or build a DMZ; Private Access uses the same connectors.

Publishing needs Microsoft Entra ID P1 or P2 and an Application Administrator. Set the internal URL (including paths for images and scripts), the external URL (the default msappproxy.net domain or a custom domain), and the connector group. Preauthentication is Microsoft Entra ID (the default, recommended) or Passthrough.

For apps that use Integrated Windows Authentication, SSO uses Kerberos Constrained Delegation: trust the connector computer for delegation to the app's SPN in AD, with the connector and app server in the same or trusting domains. Apps can also use SAML, header-based (through PingAccess), or password-based SSO.

A custom domain lets internal and external URLs match, so hard-coded links keep working; add a CNAME in external DNS, and use split-brain DNS if internal users shouldn't go through the proxy.

Add apps in Enterprise applications > New application, from the Microsoft Entra gallery of preintegrated apps or as your own non-gallery app; Cloud Application Administrator is enough. Gallery tiles show whether an app supports federated SSO and provisioning.

SSO options are federation (SAML 2.0 or OpenID Connect), password-based (Microsoft Entra ID stores and replays credentials), linked (a portal link only, useful in migrations), or disabled. For SAML, set the Identifier (Entity ID) and the Reply URL (Assertion Consumer Service URL) and often the Sign on URL, then give the app the signing certificate and login URL. Cloud Application Administrator, Application Administrator, or the app owner can configure it.

Automatic provisioning creates, updates, and removes accounts in the app as people join, move, or leave, usually over SCIM, with customizable attribute mappings.

Assign users and groups on the app's Users and groups tab. Group-based assignment needs P1 or P2 and doesn't cascade to nested groups. If the app defines no app roles, assignments get the Default Access role.

App roles are defined on the app registration (App roles > Create app role). When an assigned user signs in, the token carries a roles claim the app uses to authorize. App roles belong to the app and are removed with it; groups belong to the tenant and remain. The two can be used together. Assigning a role to a group that contains a service principal doesn't give that service principal the roles claim.

The enterprise app's owner is the least-privileged role to update assignments; Cloud Application Administrator, Application Administrator, and User Administrator can too. The outline also says "classify"; Learn doesn't define classifying assignments, and permission classifications are covered under consent.

User consent grants delegated permissions for an app to act as that user. Admin consent grants permissions for the whole organization and is required for application permissions and some delegated ones. By default, users can consent to delegated permissions that don't need admin consent.

User consent settings offer: don't allow; allow for apps from verified publishers or your tenant, for selected low-impact permissions; or allow for all apps. Low-impact permissions come from permission classifications (Low, and Medium and High in preview), which apply only to delegated permissions that don't require admin consent. Risk-based step-up consent turns risky consent requests, such as unverified multitenant apps asking for more than basic permissions, into admin consent requests.

The admin consent workflow (Consent and permissions > Admin consent settings) lets users request approval; designated reviewers get email, requests expire after a set time, and reviewers still need permission to grant consent. Privileged Role Administrator can grant tenant-wide consent for any permission; Cloud Application Administrator, Application Administrator, or AI Administrator can grant anything except Microsoft Graph application permissions. Tenant-wide consent lets all users use the app unless assignment is required.

By default, My Apps lists all of a user's apps on one page. With Microsoft Entra ID P1 or P2, a Cloud Application Administrator, Application Administrator, or app owner can create collections: named sections with a description, a list of apps in a chosen order, owners who can manage the collection, and the users and groups it's assigned to.

A collection organizes apps users can already use; it doesn't grant access. Collection changes appear in the audit logs.

An app registration defines who can sign in: single tenant (recommended for most apps), multiple Microsoft Entra tenants (for SaaS apps), any tenant plus personal Microsoft accounts, or personal accounts only. Registering in the admin center creates an application object and a service principal in your home tenant, and a globally unique Application (client) ID; with the Graph API, you create the service principal separately.

Anyone can register apps unless Users can register applications is set to No; then Application Developer is the least-privileged role, and developers become owners of what they register. New registrations are hidden from My Apps by default.

For credentials, prefer a managed identity; otherwise a certificate from a trusted CA stored in Azure Key Vault. Avoid client secrets, and use application management policies to limit or block them. Keep redirect URIs current, review unused credentials, and don't share credentials across apps.

In Entra ID > App registrations > New registration, give the app a name (you can change it, and names needn't be unique), choose supported account types, and register. Record the Application (client) ID; the app's code uses it when validating tokens.

Changes to the application object flow to its service principal in the home tenant only, and deleting the application object deletes that service principal.

Publisher verification, done with a Microsoft AI Cloud Partner Program account, adds a blue verified badge to the consent prompt and lets consent policies trust the app; with risk-based step-up consent, users can't consent to most new multitenant apps that aren't verified.

To limit an app to certain users, set Assignment required to Yes in Enterprise apps and assign users or groups. Users then can't consent, so grant tenant-wide admin consent.

A redirect URI is where the Microsoft identity platform sends tokens after sign-in. Add it on the app's Authentication page under a platform: Web, Single-page application, or Mobile and desktop. Redirect URIs must use https (except some localhost URIs), can't contain special characters such as ! $ ' ( ) , ;, and have a fixed maximum count.

Under Certificates & secrets, add a certificate (recommended), a federated identity credential, or a client secret. Secrets last at most 24 months, Microsoft suggests under 12, and the value is shown only once.

Under Token configuration, add optional claims to ID, access, or SAML tokens, including group claims; they can also be edited in the manifest's optionalClaims.

Delegated permissions (scopes) let an app act as the signed-in user and reach only what that user can. Application permissions (app roles) let a service act as itself with no user, on all data the permission covers; generally only an admin or the API's owner can consent to them.

Add them in API permissions > Add a permission, choosing Microsoft Graph or My APIs. Microsoft Graph User.Read is added by default. Application permissions for your own API appear only if it defines app roles. Grant tenant-wide consent from the app's API permissions page with Grant admin consent.

Follow least privilege: request the minimum, prefer delegated permissions where possible, and remove unused or reducible permissions.

Create them in the app registration under App roles > Create app role, with a display name, allowed member types (users/groups, applications, or both), a value that appears in tokens, and a description.

Assign roles to users and groups in Enterprise apps > the app > Users and groups; if the app defines none, assignments get Default Access. Roles that allow applications are requested by client apps as application permissions and need admin consent, which is how daemon apps get app-only access.

At sign-in, assigned roles appear in the roles claim of the token. A service principal in a group that has an app role doesn't get the roles claim through that group.

Cloud discovery compares traffic logs with the cloud app catalog, scored on more than 90 risk factors. Snapshot reports analyze logs you upload by hand (up to 20 files at once), which is also how you validate a log format. Continuous reports analyze logs sent automatically by the Defender for Endpoint integration, a log collector (Syslog or FTP), or a supported secure web gateway.

Turning on the Defender for Endpoint integration (Settings > Endpoints > Advanced features) extends discovery to managed devices anywhere and, with network protection in block mode, blocks unsanctioned apps on those devices.

Anonymization replaces usernames in uploaded logs with AES-128 encrypted values, per tenant; admins can resolve individual names when needed. Tag apps Sanctioned or Unsanctioned; unsanctioning alone only helps monitoring unless Defender for Endpoint or a supported gateway blocks it, and you can export a block script for your appliance. Discovery policies alert on new or risky apps and can tag them unsanctioned.

App connectors call the app provider's APIs over HTTPS, with admin privileges in the app, to see accounts and privileges, audit trails of user, admin, and sign-in activity, and to take governance actions. The first scan can take a while. Apps connected by API or onboarded to the inline proxy are sanctioned automatically. Microsoft 365 and Azure don't support multi-instance connectors.

Connecting Microsoft 365 adds anomaly and information protection detections, such as external sharing, OAuth app discovery, and SaaS security posture features through Secure Score. Files aren't scanned unless information protection policies are active. OAuth app visibility requires connecting Microsoft 365, Google Workspace, or Salesforce.

Use app enforced restrictions is a Conditional Access session control that passes device state (compliant or domain-joined) to supported apps, which then limit the session themselves. SharePoint and OneDrive use it for browser-only access on unmanaged devices; Exchange for Outlook on the web.

A SharePoint Administrator sets unmanaged-device access in the SharePoint admin center (Access control > Unmanaged devices): full, limited web-only, or block. Limited web-only access means browser use only, with no download, print, sync, or desktop apps, and optional browser editing. Choosing it creates a Conditional Access policy for all users and disables earlier ones created from that page. Unmanaged means not hybrid joined and not compliant in Intune.

You can build the policy yourself: target Office 365 SharePoint Online, all client apps, and Session > Use app enforced restrictions. Limiting only SharePoint can leave other Microsoft 365 services, such as Teams chat, reachable, so a policy across Microsoft 365 is more consistent.

A Conditional Access policy with the Use Conditional Access App Control session control sends users to Defender for Cloud Apps. Edge for Business gets in-browser protection; other browsers go through a reverse proxy, which adds a .mcas.ms suffix to the app URL. Policies apply per app, not per file.

You need Microsoft Entra ID P1. Apps that sign in with Microsoft Entra ID are onboarded automatically; apps using other identity providers are onboarded manually. Session and access controls support interactive SAML 2.0 SSO, and access controls also cover built-in mobile and desktop apps.

Session sign-in uses the Microsoft Defender for Cloud Apps - Session Controls enterprise application, so exclude it from Conditional Access policies that block all or selected apps.

Access policies allow or block access to an app based on user, location, device, and app, for example blocking Salesforce on unmanaged devices or blocking a native client.

Session policies allow access but control the session: Monitor only, Block activities (optionally with content inspection, such as blocking a chat message with credentials), Control file download (with inspection), or Control file upload (with inspection). Download and upload controls can block or protect files.

Because session controls work on browser sessions, pair them with an access policy that blocks native clients so users can't bypass them. Policies apply at the app level; use file filters to target specific files.

With Microsoft 365, Google Workspace, or Salesforce connected, Defender for Cloud Apps shows which user-authorized OAuth apps can reach their data, what permissions they have, who granted them, and how common they are across organizations. When app governance is enabled, this moves from the OAuth apps page to the App governance page.

Banning an app marks its permission as banned and disables the associated enterprise application; you can notify the users who granted it. Approving marks it as reviewed.

OAuth app policies alert when apps meet conditions, such as a high permission level authorized by more than 50 users, rare community use, or authorization by members of certain groups, and can revoke them. With app governance on, create them from the App governance page.

Each app's risk score is a weighted average of General, Security, Compliance, and Legal subscores, built from properties scored 0 to 10; apps with unknown properties are unscored.

Change the weighting for all apps in Settings > Cloud Apps > Cloud Discovery > Score metrics, or override one app's score with Override app score, for example for an approved app with a poor default score. If catalog information is wrong or missing, request a risk score update or suggest a change; Microsoft's team reviews it.

Entitlement management manages access to groups, Teams, apps, and SharePoint Online sites at scale, for employees and for people in other organizations. It automates request workflows, approvals, assignments, reviews, and expiration, and it can delegate the work to people who know who needs access.

A catalog holds resources and access packages. An access package bundles resource roles, such as membership of a group or an app role, and one or more policies set who can get it, who approves, and how long access lasts. Policies can let users request access, let admins assign it directly, or assign it automatically from user attributes.

Access packages don't replace other assignment methods. Use them for time-limited access to a project, access that needs approval, departments managing their own resources, and bringing in B2B users from partner organizations. Keep using dynamic groups for access everyone in a role should always have.

Core entitlement management features work with Microsoft Entra ID P2. Automatic assignment policies, custom extensions, Verified ID and ID Protection integration, and managers requesting on behalf of employees need Microsoft Entra ID Governance or Microsoft Entra Suite.

At least an Identity Governance Administrator, or a user in the catalog creator role, creates a catalog in ID Governance > Catalogs. Give it a unique name and description, choose whether it's Enabled so its packages can be requested, and choose whether it's Enabled for external users. A nonadministrator who creates a catalog becomes its first owner. User Administrators can no longer manage catalogs they don't own; give them Identity Governance Administrator instead.

Resources must be in a catalog before an access package can use them: cloud-created Microsoft 365 and security groups, enterprise applications, and SharePoint Online sites. Groups that come from on-premises AD or are Exchange distribution groups can't be added. You can also require attributes on a resource, which requestors must answer before they submit a request.

Catalog roles are Catalog owner, Catalog reader, Access package manager (creates and manages packages from the catalog's resources), and Access package assignment manager (only assigns and removes users). Catalog creator and Connected Organization Administrator apply across all catalogs. To delegate, add users or a group as catalog creators in Entitlement management > Settings, and keep Restrict access to Microsoft Entra administration portal set to No.

To add a resource, someone who isn't a Global Administrator needs both a catalog owner role and rights on the resource, such as the Groups Administrator role for groups or SharePoint Administrator for sites.

Create a package in ID Governance > Entitlement management > Access package as at least an Identity Governance Administrator, catalog owner, or access package manager. Each package is in one catalog, the General catalog by default, and can't be moved to another. A user assigned the package gets every resource role in it, so give different roles through separate packages.

The first policy sets who can get access: specific users and groups, all members, or all users including guests in your directory; specific connected organizations, all connected organizations, or all users for people not in your directory; or None, for administrator direct assignments only. One policy can't cover internal and external users together.

Approval can have up to three stages, and only one approver in a stage needs to decide. Requests not decided in the set number of days are denied. Fallback approvers step in when a manager or sponsor can't be found, and alternate approvers get requests the first approvers haven't acted on. You can also require justification, add questions for requestors, and, as a Global Administrator, require a Verified ID.

Lifecycle settings make assignments expire on a date, after 0 to 3660 days, after some hours, or never, and can allow extensions and require access reviews. Automatic assignment policies use a dynamic-group style rule on user attributes to add and remove assignments; only Identity Governance Administrators can create them, and they need ID Governance licensing. From November 3, 2026, auto-assignment rules that use the memberOf operator are quarantined.

Add policies when groups of users need different request, approval, or lifecycle settings. If more than one policy applies to a user, they choose one when they request.

Approvers get an email, or open My Access at myaccess.microsoft.com > Approvals > Pending. They see the request details and any answers to requestor questions, then approve or deny. The first approver in a stage to decide completes it for everyone in that stage. If nobody decides in time, the request expires and the user must request again.

Admins, catalog owners, access package managers, and access package assignment managers see requests on the package's Requests page, with request history showing approvers and justifications. Removing a completed request deletes only its data, not the user's access. Requests in the Partially Delivered or Failed state can be reprocessed.

Terms of use need Microsoft Entra ID P1 and a PDF. Create them in Entra ID > Conditional Access > Terms of use as at least a Conditional Access Administrator; Security Reader can read them. A tenant can have up to 40 terms.

Options include language versions chosen by the user's browser language, requiring users to expand the terms, requiring consent on every device (registered devices only, not for B2B users), and expiring consents either on a schedule or a set number of days after each user accepts. Enforce the terms with a Conditional Access policy, created from a custom template now or later, and exclude service accounts.

You can update the PDF for a language and choose Require reaccept, so users accept the new version at their next access. Other settings can't be changed; create new terms instead. The Accepted and Declined counts open per-user status, version filters, and history, and each consent is in the audit logs. Guests see the terms while redeeming their invitation.

When a request from someone outside your directory is approved, entitlement management invites them as a B2B guest without an invitation email and emails them when access is delivered. Policies for external users should require approval and set an expiration.

By default, when an external user invited through entitlement management loses their last access package assignment, they're blocked from signing in and their guest account is removed 30 days later. In Entitlement management > Control Configurations > Lifecycle of external users, you can turn off blocking or removal, or set the days before removal, even to 0. A blocked user can't request access again.

For external requests to work, set the catalog's Enabled for external users to Yes, check B2B allow and block lists and inbound cross-tenant access settings, turn on email one-time passcode for All users policies, and exclude the Entitlement Management app from Conditional Access policies that apply to guests. SharePoint, Microsoft 365 group, and Teams guest sharing must also allow guests.

A connected organization can be another Microsoft Entra directory in any Microsoft cloud, a directory federated through SAML/WS-Fed, an email domain whose users authenticate with one-time passcode, or Microsoft accounts. For a Microsoft Entra directory, users from any of its verified domains match.

Add one in ID Governance > Entitlement management > Connected organizations as at least an Identity Governance Administrator, or as a Connected Organization Administrator. Add its directory or domain and optional sponsors: internal sponsors are your members, and external sponsors are guests from that organization. Sponsors can approve requests.

Admin-created organizations are configured, and only they count for policies that allow all configured connected organizations. When a user from an unconnected organization is approved under an All users policy, a proposed connected organization is created for them automatically.

Access reviews recertify group memberships, app assignments, access package assignments, and privileged roles. Create group and app reviews in Access reviews, access package reviews in entitlement management, and Microsoft Entra and Azure role reviews in PIM.

Group and app reviews can be created by Global Administrators, User Administrators, Identity Governance Administrators, Privileged Role Administrators (role-assignable groups only), and group owners if an admin turns that on in Access Reviews > Settings.

Reviewers can be resource owners, selected users, the users themselves, or their managers, with fallback reviewers for missing owners or managers. Reviewers can't be changed after a review starts. Apps can be reviewed only when User assignment required? is Yes, and apps have no owner option.

Groups synced from on-premises AD can be reviewed, but results can't be applied to them in Microsoft Entra ID. Pilot with a small group, start without auto-apply, and customize reviewer emails. Most review features need Microsoft Entra ID Governance or Entra Suite; some work with P2.

In ID Governance > Access Reviews > New access review, choose Teams + Groups or Applications. Selecting several groups or apps creates one review each. All Microsoft 365 groups with guest users creates recurring guest reviews across groups, excluding dynamic and role-assignable groups. Scope is Everyone or Guest users only, and group reviews can target users inactive for up to 730 days.

Set reviewers, fallback reviewers, duration, start date, recurrence, and end date. Multi-stage reviews have two or three stages in sequence; you pick which reviewees move on and whether later reviewers see earlier decisions.

Upon completion: Auto apply results to resource removes denied access when the review ends. If reviewers don't respond can be No change, Remove access, Approve access, or Take recommendations. For guest-only reviews, denied guests can be removed from the resource or blocked for 30 days and then deleted from the tenant.

Decision helpers are No sign-in within 30 days and User-to-group affiliation (needs ID Governance, manager attributes, and groups of 600 users or fewer). Advanced settings add required justification, email notifications, halfway reminders, and extra email content.

Open a review in ID Governance > Access Reviews. Overview shows the current instance's progress, and Results lists each user's decision, with Stop, Reset, and Download. Nothing changes in the directory until the review completes. Stopping an instance can't be undone; to end a recurring series, change its end date.

Download results as a CSV at any point, and use Review history for earlier instances of recurring reviews. Microsoft Graph and PowerShell can list decisions, for example with Get-MgIdentityGovernanceAccessReviewDefinitionInstanceDecision.

Access review activity, such as creating, ending, approving, denying, and applying, is in the Microsoft Entra audit logs. Send the logs to Log Analytics or Event Hubs for long-term analysis and dashboards.

Reviewers open the review from the email or My Access > Access reviews. They select users and choose Approve, Deny, or Don't know, adding a reason if one is required, or select Accept recommendations. They can change decisions until the review ends, and when several reviewers decide on the same user, the last submitted decision counts.

Denied users aren't removed right away. When the review ends or is stopped, results apply automatically if Auto apply is on; otherwise an admin selects the instance in Review history and chooses Apply.

Results can't be applied to groups synced from on-premises AD, mail-enabled groups, or dynamic groups, to access that comes through nested groups, or to apps assigned through groups. Download the results and make on-premises changes there.

PIM gives just-in-time and time-bound access to Microsoft Entra roles, Azure roles, and groups. Activation can require MFA, a justification, or approval, and PIM sends notifications, supports access reviews, keeps audit history, and prevents removing the last active Global Administrator and Privileged Role Administrator. It works with Microsoft Entra ID P2, Microsoft Entra ID Governance, or Microsoft Entra Suite.

Eligible assignments must be activated before use; active assignments work without action. Either can be permanent or time-bound. Only Privileged Role Administrators and Global Administrators manage Microsoft Entra role assignments for others; Security Administrators and Global and Security Readers can view them.

Role settings are per role: activation maximum duration (1 to 24 hours), MFA or a Conditional Access authentication context on activation, justification, ticket information, approval, eligible and active assignment durations, and notifications. An authentication context with sign-in frequency Every time forces reauthentication at each activation.

Assign roles in ID Governance > Privileged Identity Management > Microsoft Entra roles > Roles > Add assignments. Assignments can't be shorter than five minutes, some roles can be scoped to an administrative unit, and a guest given a built-in role gets member-level permissions.

Subscription administrators, resource Owners, and User Access Administrators manage Azure resource role assignments in PIM. Privileged Role Administrators and Security Administrators can't see them by default; a Global Administrator can elevate access to manage subscriptions.

PIM now manages Azure resources automatically, without onboarding. In the legacy experience, you discover a management group or subscription and select Manage resource; managing a scope covers its children, the MS-PIM service principal gets User Access Administrator, and a managed resource can't be unmanaged.

Role settings are per role and per resource, with the same options as Microsoft Entra roles. Assign built-in or custom Azure roles at a management group, subscription, resource group, or resource scope, and add Azure ABAC conditions for Storage Blob Data roles.

PIM can't manage the classic Account Administrator, Service Administrator, and Co-Administrator roles, or roles inside Exchange or SharePoint RBAC. Access reviews of Azure roles are created by an Owner or User Access Administrator, and of Microsoft Entra roles by at least a Privileged Role Administrator.

PIM for Groups gives just-in-time membership or ownership of security groups and Microsoft 365 groups. Each group has two policies, one for member activation and one for owner activation, with the same options as role settings. Groups can control access to Microsoft Entra roles, Azure roles, Azure SQL, Key Vault, Intune, and apps.

Bring a group in through ID Governance > Privileged Identity Management > Groups > Discover groups. Groups no longer have to be role-assignable, but dynamic groups, groups synced from on-premises, and groups in restricted management administrative units can't be used. Up to 500 role-assignable groups are allowed per tenant.

To make a group of users eligible for a Microsoft Entra role, either make them active members and assign the group eligible to the role, or assign the role to the group as active and make users eligible members. For Exchange, SharePoint, and Purview portal roles, use the first way or PIM for Microsoft Entra roles to avoid delays.

Every eligible member or owner needs Microsoft Entra ID P2 or Microsoft Entra ID Governance. For groups that grant Microsoft Entra roles, require approval for member activation.

Users activate in ID Governance > Privileged Identity Management > My roles, completing MFA if required, optionally narrowing scope or setting a start time, and giving a reason. PIM is also in the Azure mobile app.

If a role requires approval, approvers get an email and act in Approve requests. They have 24 hours; after that, the user must request again. Approvers don't need an admin role, and Microsoft recommends at least two.

If approval is required but no approvers are chosen, active Privileged Role Administrators and Global Administrators approve. If none of them is active, nobody can approve, so set specific approvers and keep emergency access accounts.

Users can request Extend within 14 days of an assignment's end and Renew after it expires; Global Administrators or Privileged Role Administrators approve. Admins can extend directly, and users with a role through a group can't extend the group's assignment.

Resource audit shows role assignment changes, activations, and PIM policy changes for the past 30 days; My audit shows your own activity. The PIM audit is a subset of the Microsoft Entra audit logs, so use diagnostic settings to keep it longer in storage or Log Analytics.

One activation can create several CorrelationIds when approval or scheduled activation is involved. Use roleAssignmentRequestId to tie the events together, for example by querying AuditLogs where AdditionalDetails has the ID.

Security alerts include admins not using their roles, roles without MFA on activation, no P2 or ID Governance, potential stale accounts (Medium), roles assigned outside PIM (High), too many Global Administrators, and roles activated too often. Only Global Administrators, Privileged Role Administrators, Global Readers, Security Administrators, and Security Readers can read them.

Discovery and insights (preview) lists privileged role holders and offers Reduce Global Administrators, Eliminate standing access, and Review service principals to move permanent assignments to just-in-time.

Create at least two cloud-only accounts on the .onmicrosoft.com domain, not federated or synced. Give them Global Administrator as a permanent active assignment in PIM, not eligible.

Protect them with passkeys (FIDO2), which Microsoft recommends, or certificate-based authentication, using a different method from normal admin accounts. Don't tie them to one person or an employee's device, keep credentials in separate secure locations, and use a secure admin workstation.

Exclude them, through a dedicated group, from Conditional Access policies that block or restrict sign-in; report-only policies need no exclusion. Alert on every sign-in with Azure Monitor or Sentinel, review each use, and validate the accounts at least every 90 days, after IT staff changes, and when subscriptions change.

Sign-in logs cover interactive user, non-interactive user, service principal, and managed identity sign-ins; the legacy view shows only interactive ones. Open them in Entra ID > Monitoring & health > Sign-in logs as at least a Reports Reader.

Audit logs record changes to users, groups, apps and service principals, licenses, custom security attributes, and agents, with the actor, target, and old and new values. Provisioning logs show each event's identity, action, source and target systems, and status, with troubleshooting details.

Entries can't be changed or deleted. Audit and sign-in logs are kept for seven days with Free and 30 days with P1 or P2; use diagnostic settings to keep them longer.

Create settings in Entra ID > Monitoring & health > Diagnostic settings as at least a Security Administrator (Attribute Log Administrator for custom security attribute logs). Choose log categories and destinations, which must already exist. You can have several settings, and logs can take up to three days to appear.

Pick the destination by need: a storage account for cheap, rarely queried long-term retention; a Log Analytics workspace for KQL, alerts, and workbooks; an event hub to stream to a non-Microsoft SIEM such as Splunk. Sending logs to Log Analytics also turns on the Microsoft Entra connector in Microsoft Sentinel.

For event hubs, the subscription and Event Hubs namespace must be associated with the tenant. For storage, the old diagnostic settings retention option is deprecated; use Azure Storage lifecycle policies.

Query in Entra ID > Monitoring & health > Log Analytics. You need Microsoft Entra ID P1 or P2, access to the workspace (Log Analytics Reader or Monitoring Reader to view), and at least Reports Reader.

Examples from Learn: apps with the most sign-ins in seven days, risky sign-ins, the most common audit operations, and provisioning events per day by action:

SigninLogs
| where CreatedDateTime >= ago(7d)
| summarize signInCount = count() by AppDisplayName
| sort by signInCount desc

Log Analytics records each request separately, so one sign-in with a failed MFA try and a retry appears as several rows sharing a correlation ID. Group by CorrelationId and take the final status, as the admin center does.

Workbooks visualize identity data, such as sign-in health, Conditional Access impact, legacy authentication, and feature adoption. They need Microsoft Entra ID P1, a Log Analytics workspace receiving logs, and a reader role such as Reports Reader.

Open them in Entra ID > Monitoring & health > Workbooks. Public templates include Authentication prompts analysis, Conditional Access gap analyzer, Cross-tenant access activity, Multifactor authentication gaps, Risk analysis, Sensitive Operations Report, and Sign-ins using legacy authentication. You can edit a template or save your own as a private template.

Usage & insights offers app-focused reports: Microsoft Entra application activity, AD FS application activity, authentication methods activity, service principal sign-in activity, and application credential activity.

The score is a percentage recalculated every 24 hours and available to free and paid tenants. It measures adoption of recommendations such as requiring MFA for admin roles, blocking legacy authentication, and using least-privileged roles, not the chance of a breach.

Some recommendations score in full when configured; others score partially, such as MFA coverage. Statuses are To address, Planned, Risk accepted (no points, hidden), and Resolved through third party or alternate mitigation (full points).

View it in Entra ID > Identity Secure Score or the Recommendations page with the Security filter. Viewing actions needs at least Service Support Administrator, and updating their status at least SharePoint Administrator. It's the identity category of Microsoft Secure Score, whose history is in the Defender portal.