Microsoft Entra ID is adding risk-based CAPTCHA verification for SMS and voice first-factor sign-ins to reduce automated abuse. Rollout began mid-October 2026. Some users may encounter this step based on behavior. Organizations should prepare help desks, review network requirements, and encourage phishing-resistant methods like passkeys.

Microsoft Authenticator for iOS and Android will receive usability updates starting November 2026, including a refreshed home experience, clearer account restoration guidance, improved sign-in flows, and platform-specific prompts. Android improvements for restoration and battery optimization prompts will follow in January 2027. No action required.

The documentation now explains how users can change Microsoft Entra cloud passwords with FIDO2 passkeys or Windows Hello for Business, including the tenant-wide setting required to enable the experience and its limitation for on-premises password writeback.

Organizations can allow users to change cloud passwords after authenticating with a registered FIDO2 passkey or Windows Hello for Business credential, without knowing the current password or using SSPR. Temporary Access Pass isn't supported unless the user knows the existing password.

The documentation now lists Microsoft Entra CBA, FIDO2 passkeys, and Microsoft Authenticator passwordless phone sign-in notifications as methods users can use to change a cloud password without entering the current password.

The page now labels the section “Allow password change after secure sign-in” and its subsection “Enable the setting,” replacing the previous “Passwordless authentication” heading.

The documentation section describing password changes after sign-in with CBA, FIDO2 passkeys, or Authenticator passwordless notifications was revised.

The documentation updates the name of the password-change flow available after CBA, passkey, or Authenticator passwordless sign-in.

The documentation now lists certificate-based authentication, FIDO2 passkeys, and Microsoft Authenticator passwordless phone sign-in notifications as methods users can use to change their cloud password without entering their current password.

In hybrid environments, password changes made with passwordless authentication can be written to an on-premises directory when password writeback is configured.

The documentation now explains where passwords are updated for cloud-only, hybrid with password writeback, and on-premises-only environments.

The documentation now states that rollout across all clouds begins in late October 2026 and is expected to finish by the end of November 2026.

The documentation updates the section heading and setting label to “Allow password change after secure sign-in.”

The documentation now states that users need a Microsoft Entra ID P1 or P2 license to use this feature.

The documentation now uses the exact name of the secure sign-in setting related to changing cloud passwords after passwordless sign-in.

The combined MFA and SSPR registration documentation updates its passwordless sign-in reference with a link to the relevant passwordless documentation.

The callout was changed from Note to Important.

The heading “Allow password change after secure sign-in” now ends with a period.

The guidance now documents provisioning the Microsoft Authenticator Credential Registration enterprise application and excluding it from Conditional Access policies scoped to All resources to unblock passkey registration.

Microsoft will disable SMS first-factor sign-in in Microsoft Entra tenants with no successful or only unsuccessful SMS sign-ins in the past 30 days, starting mid-September to November 2026. SMS for MFA and password reset remains unaffected. Admins should review usage, notify users, and ensure alternate sign-in methods.

Microsoft Entra ID will retire Microsoft-provided SMS and voice authentication starting February 1, 2027. Organizations must migrate users to passkeys or other methods, or configure a customer-managed telecom provider before then to avoid sign-in disruptions. SMS and voice are vulnerable to attacks; passkeys are recommended.

Microsoft Authenticator for Android will improve backup and restore with clearer setup guidance and support for passkeys starting mid-January 2027. Users must enable Google One backup and screen lock. Work/school accounts aren’t backed up, and backup works only in the Android personal profile. No admin action needed.

The article now explains that system-preferred authentication considers the user’s current device and browser, prioritizes accessible local passkeys, and handles device-bound credentials such as Windows Hello for Business and macOS Platform SSO by platform.

Starting October 30, 2026, Microsoft Entra ID allows organizations to choose a supported third-party telephony provider for SMS and voice authentication via Microsoft Security Store. Microsoft-provided SMS/voice authentication retires by February 1, 2027, except for some users until July 1, 2027. Organizations manage provider relationships directly.

The documentation now explains Password, UserSecureEnclaveKey, and SmartCard registration and authentication flows, including credential handling, device proof, and PRT issuance. It also recommends UserSecureEnclaveKey for most deployments.

The documentation now shows an updated Android screenshot and describes selecting Approve or Deny instead of Yes or No for relevant number-matching prompts in Authenticator, Teams, and Outlook.

The documentation now explains that the Trusted Domain Object creates an inbound trust from the AD DS domain’s perspective. It also notes that this object isn’t required for Windows Hello for Business cloud Kerberos trust or FIDO2 sign-in; those scenarios require only the Microsoft Entra Kerberos server object.

The documentation now explains that the trust creates a Trusted Domain Object for the Microsoft Entra Kerberos realm and is inbound from the AD DS perspective. It also clarifies that the object isn't required for Windows Hello for Business cloud Kerberos trust or FIDO2 sign-in.

The documentation expands access from limited availability and updates setup links. It also clarifies that the storage account app registration must use a lowercase `cifs` identifier URI for SMB mounting on macOS.

The page title was simplified, and the role descriptions now state that the Microsoft Enterprise SSO plug-in performs device and user registration with Microsoft Entra ID. Microsoft Entra ID is described as verifying credentials and proofs and issuing the PRT.

The FAQ now states that identity provider buttons cannot be hidden. Removing a provider from a user flow prevents users from signing up or redeeming invitations with that provider, and `domain_hint` does not change this.

The documentation explains when users may encounter Arkose Labs anti-bot verification before receiving SMS messages or voice calls, including user experience, network requirements, and help-desk guidance.

Microsoft added a conceptual guide describing macOS Platform SSO registration, Secure Enclave device keys, the Platform SSO PRT, app SSO, and the roles of MDM, macOS, the Microsoft Enterprise SSO plug-in, and Microsoft Entra ID.

The article now explains that disabling sign-in sets the service principal’s `accountEnabled` property to `false` and changes Activation status to Deactivated. It also adds steps to restore tenant-local sign-in and notes that other deactivation conditions can still apply.

The documentation describes four separately manageable protections—administrator MFA, user MFA, legacy authentication blocking, and device code flow blocking—for selected Microsoft Entra ID Free tenants. It also explains how these protections work with Conditional Access and which roles can manage them.

The documentation now specifies tenant ID or the tenant’s onmicrosoft.com domain for the issuer URI, says custom verified domains aren’t supported, and requires matching onmicrosoft.com values for domain_hint. It also documents steps to refresh a user flow after provider configuration changes.

Microsoft Entra will enable users to change passwords after secure sign-in using strong credentials (passkey, FIDO2, Windows Hello) without knowing the current password or using SSPR. This feature, disabled by default, requires admin activation and will roll out globally from October to November 2026.

The documentation explains how unrestricted, synced-only, and device-bound-only profiles use platform-specific evaluation, while AAGUID-restricted and attestation-enforced profiles suppress nudges across platforms after one eligible passkey is registered.

The documentation now refers to registered passkeys and available passkey types instead of credentials in the platform-specific nudge suppression guidance and table.

The documentation now states that iOS cross-device registration does not support attestation, while Android does. Attested passkeys can also be registered through Android cross-device flows.

The documentation now states that iOS users can register attested passkeys only directly in the Authenticator app, while Android users can register them directly or through cross-device registration.

The documentation now states that Android users can register attested passkeys directly in the Authenticator app or through a cross-device registration flow. iOS registration remains direct through the Authenticator app.

The documentation now separately states that Android users can register attested passkeys through a cross-device registration flow, while iOS users register them directly in the Authenticator app.

The example now specifies a device-bound profile with attestation enforced and an eligible attested passkey. It states that the nudge is suppressed across operating systems and browsers, without using the platform table.

The example now explicitly states that User 1 signs in on macOS with Chrome and is nudged to register a compatible passkey.

The example now specifies that the user’s only registered passkey is Windows Hello for Business; the nudge is suppressed when they sign in on Windows with Chrome.

The documentation now states that Windows Hello for Business registration doesn’t follow passkey profile restrictions.

The documentation now states that Windows Hello for Business registration behavior is separate from passkey profile restrictions.

The MFA registration campaign documentation now links directly to the passkey profile eligibility guidance for the Microsoft managed registration campaign.

The documentation now states that eligible users can see nudges during interactive sign-ins that satisfy MFA. Silent SSO events, such as refresh token redemption, do not display nudges.

The documentation now covers prerequisites, PowerShell module installation, Trusted Domain Object creation, client ticket configuration, key rotation, and trust removal.

The documentation states that generally available key rotation improves reliability for incoming trust referral flows and addresses authentication failures caused when referral tickets used a secondary key.

The health scenario alerts guide now links to guidance for Agent ID interactive sign-ins and autonomous sign-ins.

The standalone article describing Kerberos server-key rotation, prerequisites, dual-key behavior, and the Set-AzureADKerberosServer procedure was deleted.

The article date was updated to October 7, 2026, and the note about gradual Microsoft-managed deployment through September 2026 was removed.

The article no longer states that the registration campaign rollout is expected to finish by the end of September 2026 or that tenant experiences may differ during the rollout.

The documentation now references MDS version 285 instead of 279 and adds five FIDO2 security key models with their AAGUIDs and capability indicators.

The article was edited for spelling, headings, and presentation while retaining its documented enforcement phases, dates, affected applications, account scope, and break-glass guidance.

The guidance now states that Microsoft Authenticator, software OATH tokens, and hardware OATH tokens count as one authentication method for SSPR, regardless of Authentication methods policy migration status.

The native authentication API reference was updated with spelling corrections. The supplied examples, links, endpoints, error details, and configuration guidance remain unchanged.

The tutorial’s code comment was corrected from “Thge” to “The” and from “rquired” to “required.”

The article fixes the spelling of “OpenID Connect” and replaces an empty .NET NuGet link with an Azure Functions API link, along with other wording corrections.

The page no longer includes the `ms.author: justinha` metadata entry.

The passwordless authentication documentation no longer includes the `author` and `ms.author` fields.

The documentation fixes minor formatting in the scope notes and corrects the image text from `HKEY_LOCAL_MACHIEN` to `HKEY_LOCAL_MACHINE`.

The username/password token acquisition article no longer includes the author, manager, and ms.author fields.

The tutorial replaces references to Zidentity and Zscaler Provisioning with Zscaler Authentication Service and updates related titles, prerequisites, app-role guidance, and provisioning steps. The page date was also updated.

The tutorial now uses single quotes in the Snowflake ALTER SECURITY INTEGRATION commands and links to Snowflake’s SAML2 security integration guide.

The tutorial now uses the Account Administrator role, reorganizes the SQL setup steps, updates Snowflake URL parameters, and links to automated user provisioning and deprovisioning.

The prerequisites now explain how incorrect DNS, subnet-to-site mappings, or site configuration can cause provisioning synchronization failures, performance issues, and intermittent connectivity. It directs administrators to correctly map agent server subnets in Active Directory Sites and Services.

The guide now clarifies that migration must start from the active Connect Sync server, identifies device synchronization as a guided-migration blocker, explains readiness results, and adds validation and support-evidence checklists.

The tutorial now emphasizes manual migration for test or pilot environments, directs eligible customers to the guided migration tool, adds scope-removal and source-anchor guidance, clarifies device migration coverage, and links related migration resources.

The article now explains that it covers configuring Device Sync in Microsoft Entra Cloud Sync, not transferring Device Sync with the guided migration tool. It links to the tool’s prerequisites.

The permissions reference now states that Application Developer role holders can update applications they own, in addition to creating application registrations independently of the user registration setting.

The documentation now states that any user can use **Download devices** to export a CSV of devices, with optional filters; without filters, all devices are included.

The documentation now specifies Microsoft Entra ID P1 or Microsoft 365 E3 for Conditional Access, and Microsoft Entra ID P2 or Microsoft 365 E5 when using agent risk-based Conditional Access with Microsoft Agent 365.

The documentation adds links and clarifies that relevant agents run on Intune-managed Windows 365 Cloud PCs, with Global Secure Access for compliant network policies. It also refines targeting, assignment, and risk-level guidance.

The documentation now uses corrected step numbering and clearer instructions for excluding agent blueprints or identities and creating custom attributes and predefined values.

The documentation now lists Microsoft 365 E7, or Microsoft Agent 365 paired with Microsoft Entra P1 or Microsoft 365 E3, instead of a general Entra ID P1 or P2 requirement.

The documentation now lists two licensing options: Microsoft 365 E7, or Agent 365 paired with Microsoft Entra P1 or Microsoft 365 E3. It also states that Agent 365 will soon be required.

The guidance now links to the Windows 365 Cloud PC for Agents introduction and the Entra Global Secure Access overview.

The documentation now says Microsoft 365 E7 protects access for both users and agents, replacing wording about governance of user and agent identities.

The tutorial received spelling and wording corrections across its SAML attribute mapping, authentication policy, testing, and account discovery sections.

The version history page was updated with spelling fixes in existing release and feature descriptions.

The guide now covers selecting Cloud Sync or Connect Sync and configuring Cloud Sync to synchronize Active Directory computer objects for Microsoft Entra hybrid join.

Changed “cancelation” to “cancellation” in the recovery job instructions.

The page no longer includes the author, manager, and ms.author metadata fields.

The documentation now identifies Microsoft Entra Global Administrators, rather than Hybrid Identity Administrators, in the default Connect Health RBAC guidance and Owner role description.

The documentation now lists the module under `C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\ADSyncConfig.psm1`.

The documentation now states that, by default, a Global Administrator account has permission to register the agent, replacing Hybrid Identity Administrator.

The documentation now requires preserving downloaded column headings, allows the examples row to remain, and identifies only Name, User name, and Initial password as required fields. The sample CSV was simplified.

The instructions now require the exact downloaded column header and allow each user row to contain either a user principal name or object ID. The examples row may remain, and User Administrator is listed as the minimum role.

The article now requires the downloaded `Object ID [objectId] Required` header to remain unchanged and says the examples row can be retained. It also documents the User Administrator prerequisite.

The article now uses a Cisco FQDN placeholder for the SAML metadata URL and emphasizes that Identifier and Reply URL examples must be verified against the intended Cisco endpoints and trusted domains.

The page’s publication date and custom metadata tags were updated.

The title no longer includes “(Preview),” and the publication date changed from August 11, 2026, to October 29, 2026.

The documentation now requires all writable domain controllers to meet specified Windows Server update levels and requires ADSyncTools version 2.6.0 or later. It also adds a warning that enforcement cannot be configured if any writable domain controller is unsupported.

The tutorial now links to Brivo’s contact page instead of its quote page for obtaining a Brivo Onair Identity Connector tenant.

The documentation states that OAuth 2.0 Authorization Code Grant is being retired for Puzzel provisioning. Affected jobs should use OAuth 2.0 Client Credentials Grant; otherwise provisioning may stop working after the deadline.

Vonage provisioning will stop supporting OAuth 2.0 Authorization Code Grant after March 31, 2027. The updated procedure generates and uses client credentials; SSO is unaffected.

Microsoft added a step-by-step tutorial for configuring automatic user and group provisioning, updates, synchronization, and deprovisioning between Microsoft Entra ID and Secure Cloud using SCIM 2.0.

New documentation explains how to inspect or remove stored source-to-target connections for provisioning jobs, including required identifiers, permissions, and recovery steps. The API is available through Microsoft Graph beta and deleting a connection does not delete either object.

A new reference lists source and target identifiers for provisioning scenarios, their required formats, and how to use them with Microsoft Graph to inspect or delete connections.

The documentation now directs administrators to a migration decision guide, guided-tool eligibility checks, or manual phased migration guidance. It also clarifies scope protection, reference validation, and migration-result verification.

The guide now distinguishes platform capability comparisons from what the guided migration tool can transfer. It identifies device synchronization as a current guided-tool blocker and adds separate guidance for guided, manual, or deferred migration paths.

The decision guide now states that Cloud Sync supports device synchronization for Microsoft Entra hybrid join. Device synchronization must be enabled separately, with updated migration guidance and configuration steps.

The guide now describes phased migration planning, including Cloud Sync device synchronization for Microsoft Entra hybrid join and prerequisite checks.

The article now helps administrators check their Microsoft Entra Connect version, evaluate Microsoft Entra Cloud Sync—including device synchronization—and find the latest upgrade guidance.

The tutorial now refers to Zscaler instead of Zscaler Authentication Service Provisioning throughout its title, prerequisites, configuration steps, and Microsoft Entra app-gallery instructions.

The tutorial now consistently refers to Zscaler ZSNet instead of Zscaler ZNet, including the title, prerequisites, gallery search instructions, and provisioning steps.

The comparison table now lists Microsoft Entra Cloud Sync as supporting Microsoft Entra hybrid join and links to Cloud Sync device synchronization instructions. The article also expands comparisons across Cloud Sync, Connect Sync, MIM, and ECMA Host.

The guide now covers configuring Microsoft Entra Cloud Sync and Connect Sync, including synchronizing Active Directory computer objects to Microsoft Entra ID for hybrid join.

The article now explains Cloud Sync as synchronizing users, groups, contacts, and devices, and links to device synchronization configuration guidance.

The comparison article now includes devices among supported synchronization scenarios and notes that Cloud Sync can synchronize computer objects for Microsoft Entra hybrid join when device sync is enabled. It also adds a comparison table and selection wizard.

The documentation adds `NormalizeDiacriticsByCulture(source, culture)`, supporting German (`de`) transliteration such as `ä` to `ae` and `ß` to `ss`.

The minimum-version deadline for Microsoft Entra Connect Sync is extended from September 30, 2026, to April 7, 2027. Version 2.5.79.0 or later is required.

The guide now consistently refers to the application, tenant, SCIM API, and gallery entry as Zscaler ZNet.

Microsoft Entra ID will retire the MemberOf rule operator by November 3, 2026. Organizations using MemberOf in dynamic groups, administrative units, or entitlement policies must replace it to avoid outdated memberships, access, and licensing issues. Action is required before this date to maintain proper functionality.

The documentation now states that the Microsoft Authenticator Credential Registration resource will be available in November 2026. It also retains the prerequisite to provision the enterprise application before excluding the resource from a Conditional Access policy.

Microsoft Entra will recognize Windows Hello for Business and macOS Platform SSO as standalone MFA factors starting early November 2026, allowing users to satisfy MFA without additional passkeys. No configuration changes are needed, but organizations should update onboarding and MFA registration guidance accordingly.

A new article explains how to consolidate selected Conditional Access policies into a policy plan, review shared conditions and generated rules, and validate the plan before enforcement. Original policies remain unchanged and continue evaluating independently.

A new guide explains how to create policy plans from templates or from scratch, configure shared conditions and exclusions, review rules in report-only mode, and enable them.

The new documentation introduces Conditional Access policy plans, which group related rules under shared targeting and conditions. Plans can centralize exclusions and support multiple enforcement scenarios; the capability is marked preview.

Microsoft Entra will allow users to register passkeys or passwordless sign-in as their first multifactor authentication method, removing the prior requirement to set up alternate MFA methods first. The phased rollout begins November 2026, aiming to simplify strong authentication adoption and reduce registration friction.

The documentation now states that baseline-scope enforcement rollout began June 15, 2026. It adds a Microsoft Graph query for finding affected Conditional Access policies and clarifies customization and sign-in review guidance.

Microsoft Entra ID will support passkey registration and sign-in for B2B users, enabling phishing-resistant MFA in resource tenants starting late October 2026. Internal guest users get Microsoft Authenticator app passkeys; external users do not. The feature is enabled by default, intersecting with SMS/voice retirement policies. No action required, but administrators should review policies.

A new guide explains how to apply Conditional Access to agents using their own user accounts, including policies for agent risk, compliant devices, and compliant networks. It also documents agent-specific targeting and prerequisites.

Added a missing space between “authentication” and “and” in the documentation.

Microsoft Entra ID will retire the MemberOf rule operator by November 3, 2026. Organizations must replace MemberOf in dynamic groups, administrative units, and entitlement policies to avoid outdated memberships, access, and licensing issues. After this date, MemberOf-based updates will stop, impacting Conditional Access and related services.

The tutorial now links to Snowflake SCIM documentation, specifies using an account administrator, explains the SQL script, emphasizes that `AAD_PROVISIONER` is case-sensitive and uppercase, and adds related authentication links.

The tutorial’s task lists were changed from numbered items to bullet points; the instructions and screenshots remain the same.

A new article explains how to configure Secure Cloud User Integration with Microsoft Entra ID using OIDC, including prerequisites, consent-based onboarding, authentication settings, fallback passwords, and SSO verification.

The documentation now describes validation for both single-tenant and multitenant OIDC applications, including configuration-specific endpoint requirements and eligibility guidance.

The page author and manager metadata were changed.

The document author was changed from hkinyunyu to HildaK-pm.

The page no longer includes the author, manager, and ms.author metadata fields.

Removed the `manager` and `ms.author` metadata fields from the OIDC protocol documentation.

The document no longer includes the author, manager, and ms.author metadata fields.

The page no longer includes the author, manager, and ms.author metadata fields.

The single sign-on documentation no longer includes the author, manager, and ms.author metadata fields.

Microsoft Entra App Gallery introduces self-service onboarding for new applications, allowing ISVs to validate SSO and provisioning integrations, manage submissions, and track status via the Microsoft Entra admin center. Public preview is available now; general availability begins mid-November 2026. No action required.

The documentation now explains that reported last activity can include incomplete sign-ins absent from sign-in logs. A timestamp does not confirm successful authentication or token issuance, and some partial activity may be misclassified as app-only during preview.

The page now directs Connect Sync users to review the decision guide, validate guided-tool prerequisites, and choose a supported guided or manual migration path. It also links the migration FAQ and separates Device Sync review from guided-tool eligibility.

The Security Defaults article no longer includes the section describing individual protections, their preview availability, roles, behavior, and management steps.

Step 1 now links to the permissions reference anchor without the `.md` suffix.

The article now explains that enabled device synchronization can sync Active Directory computer objects to Microsoft Entra ID so devices can become hybrid joined, and links to configuration steps.

The article now explains that Microsoft Entra Cloud Sync can synchronize Active Directory computer objects to Microsoft Entra ID for hybrid join and links to configuration guidance.

Corrected a spelling error and updated punctuation in the Microsoft Entra Health article.

The page no longer includes the ms.author, author, or manager metadata fields.

The documentation now says app instance property lock can be enabled for both single-tenant and multitenant apps.

The documentation now says the lock is configured for all applications, rather than all multitenant applications.

The documentation now states that tenant administrators cannot reverse Microsoft disablement by enabling tenant-local sign-in or reactivating the app registration.

The documentation now explains that Deactivated can result from tenant-local sign-in disablement, app registration deactivation, or Microsoft disablement. It also documents the related properties and clarifies that these conditions can overlap and must be remediated independently.

The article now covers application and agent creation and management. It documents the **Users can create agent blueprints** setting, which administrators can turn off to restrict agent blueprint creation to administrators and Agent ID Developers.

The documentation now links to the “Restricting who can create applications and agents” section in two references, including the application registration error guidance.

The enterprise application page received spelling corrections in its user, group, and app-role assignment guidance.

The page no longer includes the `manager` and `ms.author` metadata fields.

The daemon token acquisition documentation no longer includes the `manager` and `ms.author` fields.

The page no longer includes the author, manager, and ms.author metadata fields.

The documentation explains that tenant administrators cannot reverse Microsoft disablement by setting `accountEnabled` to `true` or reactivating the app registration. It also provides support guidance for application publishers and users.

The article now links to a sample app demonstrating passkey listing and registration with delegated permissions and warns that its deletion flow uses high-privilege application permissions and a client secret in browser code.

The Microsoft Entra External ID credential management API reference was deleted, including guidance for passkey listing and registration, delegated permissions, authentication, and sample usage.

Corrected a spelling error in the explanation of “Report-only: Failure” results for the “Require app protection policy” control.

Microsoft is updating Microsoft Defender for Office 365's Unified RBAC mapping for the Microsoft Entra Security Operator role, removing default access to email threat policies and Tenant Allow/Block List. This change starts November 2026 and requires manual permission assignment for continued access when Unified RBAC is enabled.

The documentation now emphasizes app instance lock for multitenant applications and also mentions single-tenant applications.

The documentation now states that locks apply to an application's service principal for both single-tenant and multitenant applications. Since June 2026, Enable property lock is enabled by default for new applications.

The documentation now explains that Connect Sync and Cloud Sync may coexist during a phased migration, but must not simultaneously export normal changes for the same object and attribute set. It adds links to manual migration steps and scope-removal planning.

The September row now includes an additional 99.999% value in the performance reference table.

The documentation changes the recommended acknowledgment role from Hybrid Identity Administrators to Global Administrators before stopping data collection for all registered services.

Microsoft Defender for Cloud Apps will update App Governance permissions for select Microsoft Entra roles starting mid-November 2026. Changes include role-based access control alignment with Defender XDR, affecting Cloud App Security, Compliance Administrator, and Compliance Data Administrator roles. Admins should review and update role assignments accordingly.

Microsoft Purview will enable sensitivity labels for Microsoft Entra cloud security groups starting mid-November 2026, allowing administrators to apply and enforce governance policies on these groups. Labels can be assigned via multiple platforms, cannot yet be changed once applied, and require separate tenant configuration from Microsoft 365 groups.

A new article explains how to diagnose intermittent timeouts and slow provisioning from Workday, SAP SuccessFactors, and API-driven HR integrations to on-premises Active Directory. It covers job status, provisioning agents, matching attributes, domain controllers, DNS, connectivity, and relevant logs.

The Windows hybrid-join troubleshooting page received spelling and copy edits covering TPM errors, PRT checks, and Event Viewer guidance.

The documentation corrects wording and spacing in guidance about cross-tenant access policies, guest self-service sign-up, Conditional Access sign-in frequency, and governance.

The article now distinguishes deactivating an app registration from disabling sign-in on a tenant-local service principal. It also explains that activation status includes tenant-local and Microsoft disablement, and that reactivating the app registration does not automatically restore tenant-local sign-in.

The documentation adds a tutorial for configuring Microsoft Entra agent identities to authenticate to Azure Database for PostgreSQL flexible server and access data through group-based authorization, entitlement management, and conditional access.

The page now covers agent identities and additional policy options, including custom security attributes, agent execution environments, device compliance, network locations, and agent risk. It also updates policy creation steps and links.

The documentation now refers to real-time risk information, rather than session risk information, among the signals used to determine access.

The autonomous agents policy documentation now includes a section for custom security attributes in policies.

The Agent ID documentation now uses the correct anchor for the “Allow approved agents by using custom security attributes” policy example.

The policy example link now points to the `use-custom-security-attributes` section.

The article now focuses on Conditional Access for agents using their own identities, adds prerequisites, clarifies that policies target agent identities rather than users, and recommends report-only block policies for unapproved agents.

The article now documents the enhanced object picker for selecting agent identities and blueprints, updates policy-creation steps, and notes that an Agent 365 license will soon be required.

The overview now explains policy decisions, evaluation timing, token subjects and audiences, and supported agent access patterns. It also adds links to related identity-management and policy guidance.

The overview now explains how Conditional Access evaluates the token subject and resource, and distinguishes delegated, agent-identity, and agent-user-account scenarios. Licensing and network-control requirements remain documented.

The article now covers selecting agent identities or agent user accounts, explains that conditions and controls depend on the token subject, and updates related links and terminology.

The documentation now states that Microsoft Entra ID Conditional Access for agents requires an eligible license plan, including Microsoft 365 E7 with Agent 365 and Microsoft Entra Suite. The explanatory governance phrase was removed.

The documentation now states that Conditional Access evaluates the signed-in user who is the token subject, including users targeted directly or through groups. Selecting an agent identity does not cover OBO traffic.

The documentation clarifies that Conditional Access policies targeting agent identities do not apply to on-behalf-of (OBO) traffic, because the user is the subject of that flow.

The licensing requirements now list Microsoft 365 E7, or Microsoft Agent 365 paired with at least Microsoft Entra P1 or Microsoft 365 E3.

The Microsoft Agent 365 licensing prerequisite bullet was reformatted for consistency.

The documentation now explains that globally disabling a blueprint can cause related agents in other tenants to fail or lose functionality. It also adds steps for disabling a blueprint in the Microsoft Entra admin center.

The documented procedure now uses **Disable** > **Disable in all tenants** and specifies that the impact applies to multi-tenant blueprints.

The documentation now states that when **Users can create agent blueprints** is set to **Yes**, any tenant user can create an agent identity blueprint and its principal. Otherwise, the Agent ID Developer and Agent ID Administrator roles can create them.

The Conditional Access Agent ID page now links to Microsoft Agent 365 plans and pricing instead of the Agent ID getting-started information.

The agent identity targeting documentation now links to the relevant section on Conditional Access policies and agent identity blueprints.

The documentation clarifies that policies scoped through the Users assignment do not apply to agent user accounts, regardless of whether they target all users, selected users, groups, directory roles, or external users. To protect agents, select Agents under Users, agents, or workload identities.

The documentation now identifies the agent identity, rather than the application or autonomous agent, as the subject in application-only access.

The documentation now states more clearly that an agent needs assigned OAuth delegated permissions to assist a user when accessing a target resource’s APIs.

The documentation now states that agent identities need delegated OAuth permissions for target resources, such as Microsoft Graph or an application, to assist users with API access.

The n8n agent integration page no longer includes the `author` and `ms.author` metadata fields.

The Agent ID default inactivity policy page updates links to related lifecycle policy and end-user agent management documentation.

The documentation now directs administrators to **Agent ID (Preview)** instead of **Agent IDs**, and updates the introductory wording about agent identity lifecycle risks.

The documentation describes a preview policy that notifies owners after 60 days of inactivity, disables identities after 90 days, and deletes them after 455 days. Administrators can enable it, configure its scope, and set fallback notification recipients.

The article explains how to create policies for agent identities, including periodic reconfirmation, minimum sponsor requirements, inactivity monitoring, notifications, grace periods, and enforcement actions. The capability is in preview.

The documentation now identifies the resource role as applying to an AI agent’s service principal or agent ID and adds numbered steps for selecting API permissions, permission type, required permissions, and updating the configuration.

Starting November 4, Microsoft Entra will stop automatically granting the AgentIdentity.CreateAsManager permission to agent blueprints. Admin consent will be required for agents to create identities. This change, rolling out worldwide in November 2026, enhances control and auditability of agent identity creation.

Adds a how-to article explaining Health Monitoring signals and alerts, log correlation, impact criteria, troubleshooting, and prerequisites for autonomous agent sign-ins. The monitoring and alerts are documented as being in preview.

A new how-to explains how to interpret Health Monitoring signals, correlate agent properties with sign-in and audit logs, and mitigate common failures. It also identifies the relevant non-interactive sign-in logs and documents licensing and role prerequisites.

The documentation corrects spelling errors, including “credentials,” and adds missing punctuation to a step describing token credentials and Azure SDK clients.

The documentation now describes blocked highly privileged directory roles for agent identities without the obsolete custom-role restriction wording.

The agent identity overview revises wording about automatically assigning identities to Microsoft Copilot Studio agents and creating the related identity blueprint.

Starting November 4, 2026, default users in Microsoft Entra can create agent blueprints unless administrators disable this via the "Users can create agent blueprints" setting. Admins can restrict this by toggling the setting to No in the Entra admin center before rollout completes in late November.

The overview’s guidance on managing agent identities and viewing their access and activity information was updated.

The documentation now describes the linked guidance as covering delegated and application permissions for Microsoft Graph and applications.

The documentation now describes a real-time Identity Protection detection for suspiciously added authentication methods. It raises user risk and can trigger configured risk-based policies; the page lists Microsoft Entra ID P2 as required, pending confirmation.

The documentation now lists the `suspiciousCredentialAddition` risk event type instead of `TBD` and revises the detection description. Metadata and customer intent were also updated.

The risk detection table now lists Atypical travel as “Real-time” instead of “Offline.” Its Premium requirement and unlikelyTravel identifier are unchanged.

The page no longer includes the `ms.author` and `author` metadata fields.

The documentation now describes adaptive learning for new users’ sign-in behavior and says detection is calculated in real time, replacing the previous learning-period and offline-calculation details.

To strengthen your organization's security posture, Microsoft created a new Microsoft‑managed Conditional Access (CA) policy—Require risk remediation for high‑risk users—in your tenant, along with a new security group for this policy. This policy uses Microsoft Entra ID Protection to identify users at high risk and prompts them to self‑remediate through adaptive risk remediation, allowing users to resolve their own risk without administrator intervention.

The documentation no longer includes the note that nested group drift is excluded and that reports compare assignments with users directly assigned to a group.

The heading for license requirements when requesting on behalf of agent identities no longer includes “(preview).”

The identity governance use-cases page no longer labels the Microsoft Entra Agent ID governance topic as “preview.”

The documentation now links to the Microsoft Graph accessDriftSummary API and separately identifies review through the Microsoft Entra admin center. The page date was also updated.

The entitlement management reports documentation now uses an updated link for the List accessDriftSummary API.

The page title and heading for Microsoft Entra SAP IAG integration no longer include “(Preview).”

The article’s licensing guidance was updated. It states that the tenant needs at least as many licenses as governed member (non-guest) users, including users who request, approve, or review application access.

The documentation date was updated, and the report description now refers to users and agent IDs when explaining direct access and active assignment mismatches.

The documentation adds postapproval extensions with deferred outcomes and asynchronous validation before assignment provisioning. It also describes collecting attributes such as cost center and project code, along with the required Graph permissions and endpoint configuration.

The documentation describes integrating SAP Access Control with Microsoft Entra entitlement management to govern SAP business roles through catalogs, access packages, and My Access. It covers SAP BTP, Cloud Connector, prerequisites, licensing, and status reconciliation.

The documentation now clarifies that multiple automatic assignment policies for one access package are supported only when users do not match multiple policies simultaneously.

Corrected spelling in the guest user licensing and governance documentation, including “governance-related.”

The entitlement management dynamic approval article received spelling corrections covering custom extensions, Logic Apps, approval setup, and HTTP trigger configuration.

Added a missing space after the bold “Prerequisite roles:” label. The linked role requirements are unchanged.

The documentation no longer includes the `author` and `ms.author` metadata fields.

The documentation now directs sponsors to manage guests in My Account at myaccount.microsoft.com, using the Sponsored guests item in the left navigation instead of My Access.

The new page documents the preview experience for reviewing guests, extending or ending sponsorship, and sponsoring eligible unsponsored guests. It also explains policy-driven lifecycle behavior.

The documentation describes configuring guest scopes, lifecycle rules, notifications, precedence, and automated disable or deletion actions for external users.

The page replaces the Mississippi Division of Medicaid customer example with the Digital Security and Resilience team at Microsoft and updates the accompanying wording and link.

The entitlement management overview removes “preview” from references to assigning groups and API permissions to agents, and from the related license-requirements heading.

The overview heading and linked page title now refer to “Identity governance for agent identities” and “Governing agent identities,” with the “preview” label removed.

The documentation now states that direct cross-tenant user synchronization requires Microsoft Entra ID P1, while synchronizing a group and its members requires Microsoft Entra ID Governance or Microsoft Entra Suite for each synchronized user in the source tenant.

The documentation now lists P1 with Microsoft 365 E3, E5, or E7; P2 with E5 or E7; and Governance capabilities with Microsoft Entra Suite and Microsoft 365 E7. The agent identity licensing reference was also updated.

The documentation link was updated from guidance for all multitenant applications to guidance for all applications.

The entitlement management scenarios documentation no longer labels “Govern access for agents” as preview.

The Entra ID Governance integrations table now lists Secure Cloud and distinguishes Zscaler ZSNet from Zscaler with separate links.

The overview page now uses a more specific section link and clearer descriptions of automated provisioning, SSO just-in-time provisioning, and additional application integrations.

The documentation updates wording across deployment scenarios, entitlement management, access reviews, separation of duties, birthright assignment, and Logic Apps guidance without changing the described capabilities or procedures.

Updated October 19, 2026: We have identified that this message did not reach it's intended audience. You can safely disregard this message, and we apologize any confusion this may have caused.

The page now explains self-service sign-up through a user flow and invitation redemption through a custom OIDC provider using the domain_hint authorization parameter.

The article now highlights testing the user flow as the primary next step and adds links for adding applications, managing custom attributes, and routing invited users to an external identity provider.

The page title and description now use Microsoft Entra External ID terminology. Passkey sample links were updated from listing and registration to sign-in and management, and the sample table was revised.

The page now describes administrator-controlled passkey provisioning with the FIDO2 provisioning APIs and identifies the sample as testing-only with high-privilege permissions.

The documentation now describes a sample where signed-in customers list and register their own passkeys. It warns that the deletion flow uses high-privilege permissions and a client secret, so the sample is for test tenants only.

The documentation now states that SMS is unavailable only for first-factor authentication in external tenants, indicating availability for self-service password reset. SMS remains available for second-factor verification at additional cost.

The Android custom headers tutorial no longer includes the author, manager, and ms.author metadata fields.

Microsoft Entra External ID applications can use the credential management API to let signed-in customers list and register passkeys. The reference covers delegated authentication, permissions, and setup.

The documentation now directs applications to use the credential management API, with low-privilege delegated permissions, so signed-in customers can list and register their own passkeys.

The custom policies guidance now includes a screenshot of the Migration Policy Analyzer UI and updated author metadata.

The migration partners page now lists Fortytwo and updates its publication date.

The Edgile listing now links to its Microsoft Entra External ID page instead of its previous blog post.

The user-creation example replaces the source tenant ID with its primary domain name in the issuer value and defines the new placeholder with an example domain.

The custom policy analysis article no longer includes the `author` and `ms.author` metadata fields.

The overview now states that a Microsoft Entra ID P1 license is required on the configured tenant to change the default redemption order, in addition to configuring trust or scoped access settings.

The documentation now states that changing the default redemption order, like configuring trust or access settings, requires Microsoft Entra ID P1 on the configured tenant.

New guidance explains how to use the domain_hint parameter to route invited external-tenant users to configured OpenID Connect, SAML/WS-Federation, or social identity providers. It covers prerequisites, invitations through Microsoft Graph or the admin center, and custom invitation emails.

The documentation now clarifies that invited users from another Microsoft Entra tenant use the default redemption flow unless an application explicitly routes them to a custom OIDC provider. The related link was also updated.

SharePoint One-Time Passcode (SPO OTP) authentication will retire starting mid-October 2026, transitioning external sharing and authentication to Microsoft Entra B2B. This change affects all Microsoft 365 tenants, requiring guest accounts for external users and enabling consistent governance and Conditional Access across SharePoint and OneDrive.

The page now links to a sample for listing and registering passkeys and documents delegated permissions for those operations. It also warns that deletion uses high-privilege application permissions and a client secret in browser code.

A new article compares three identity verification patterns: Verified ID credentials, direct REST API claims, and OIDC federation. It explains partner-based proofing, External ID authentication, setup considerations, and handling of longer-running verification journeys.

A new article explains configuring traffic acquisition, Allow and Block firewall rules, security profiles, and enforcement verification for client traffic in Microsoft Entra Internet Access. It also lists required roles, licensing, forwarding profiles, and client prerequisites.

The documentation now states that the Internet Access traffic forwarding profile does not acquire DNS traffic in preview. Wildcard acquisition rules and FQDN destinations do not enable DNS acquisition, so cloud firewall policies do not filter DNS traffic.

The documentation now states that Internet Access traffic forwarding does not acquire DNS traffic in preview, including with wildcard rules. Cloud Firewall cannot filter DNS queries; FQDN rules apply to connections to named destinations.

The documentation now explains that acquisition rules determine which traffic is forwarded, while cloud firewall policies allow or block it. It adds client and remote-network configuration links, wildcard acquisition examples for TCP and UDP, bypass and routing precedence details, and QUIC limitations.

The article title and heading now explicitly focus on configuring cloud firewall for remote networks.

The page now documents a scenario where Global Secure Access handles private application and Microsoft 365 traffic while Netskope captures internet traffic. It includes configuration, verification, and traffic-testing steps for Windows and macOS.

The service connection link text now uses “configuring” instead of the misspelled “configurating.”

The documentation now explains that Continue is a preview default action used when no enabled enforcement rule matches. It passes evaluation to the next applicable security profile in priority order, while Allow and Block stop V2 evaluation. It also adds cross-profile examples and clarifies Baseline and V1 behavior.

The Private Access operations page no longer includes the row describing a connector offline condition, related Sentinel analytics guidance, or the Windows service check.

The documentation now notes that switching to v2 is non-reversible, while previous configurations carry over without changes to end-user traffic.

A new guide explains how directly connected local resources can remain reachable while Private Access is enabled, including routing behavior, prerequisites, and configuration steps.

Version 2.2.79, released September 29, 2026, adds over-the-air sensor updates, enhanced Kerberos security and diagnostics, SID-based service matching, and corrected wildcard matching.

The guide now consistently spells “Multi-Geo,” including correcting a typo in the Japan region limitation.

A new how-to explains configuring Microsoft Entra Private Access with Infoblox Threat Defense, including prerequisites, DNS bypasses, internal domains, category filters, endpoint groups, and security policies.

The Microsoft Entra Verified ID updates page now lists HYPR as an API-based integration partner.

The Entra Verified ID identity verification partners page now lists HYPR, with a link to HYPR documentation and a description of its integration for workforce identity verification.

The FAQ now uses “towards” instead of the misspelled “torwards” in its soft-deleted objects quota guidance.

Example 3 now clearly describes creating the `JoinedData` claim by joining `extensionattribute1` with `-ext` for JWTs issued to linked service principals.

The documentation now states that tenant administrators or Microsoft can revoke application credentials, including credentials stolen or added by a threat actor.

A new guide explains revoked-credential error codes, how to inspect tokenRevocations on applications and service principals using Microsoft Graph beta, and how to assess revocation effects and possible compromise.

The guide removes the Preview label and documents that workload identities are reusable only when their Application API host matches the provisioning app’s SAP SuccessFactors API host. It also adds the Application ID URI format and compatibility details for the September 15, 2026 update.

The required Microsoft Entra Connect version changed from 2.5.79.0 to 2.6.84.0 or later. The documentation also now requires application-based authentication to maintain directory synchronization and avoid service disruptions.

The documentation now consistently labels the Continue default action as “in preview” and describes how unmatched traffic passes to the next applicable security profile.

The page no longer includes the `author` and `ms.author` metadata fields.

The documentation no longer includes the `author` and `ms.author` fields.

The PowerShell prompt now correctly refers to the `IPv4Preferred` registry key instead of `IPv4Preffered`.

The article metadata field was corrected from `ms.reviwer` to `ms.reviewer`; the topic classification remains unchanged.

The article title and preview notice for configuring custom headers were removed.

The configuration instructions now direct administrators to Global Secure Access > Connect > Explicit Forward Proxy instead of Session management.

The documented path changed from Global Secure Access > Session management > Explicit Forward Proxy to Global Secure Access > Connect > Explicit Forward Proxy.

The release notes now document Web sign-in support, Conditional Access sign-in frequency for Private Access applications, updated firewall behavior, clearer forwarding-profile names, private-network bypass changes, and other improvements.

The page no longer includes the `author` and `ms.author` metadata fields.

The configuration guide no longer includes the note that a special Entra Admin Center link might be needed during the September 2026 rollout to view custom header details in Global Secure Access traffic logs.

The instructions now direct administrators to Global Secure Access > Connect > Explicit Forward Proxy, replacing the previous Session Management path and tab selection.

The page’s `author` and `ms.author` metadata fields were removed.

The documentation adds Performance mode, which routes user traffic to the connector with the lowest measured network latency. It also clarifies that connector load balancing applies only to Microsoft Entra Private Access applications, not application proxy applications.

The fifth Netskope coexistence scenario is now correctly numbered as item 5.

The documentation corrects “Web respositories” to “Web repositories” in an example of security rules.