The week of August 15-18, 2026, brings a set of focused documentation updates across Microsoft Entra ID. While there are no major product launches this week, two updates stand out as operationally significant for identity administrators: a new guided migration experience for Global Secure Access web filtering policies from V1 to V2, and tightened requirements for GitHub flexible federated identity credentials that now mandate immutable repository claims. Four additional documentation updates round out the week, covering authentication-strength policy limitations with MSA accounts, ID Protection device-block remediation behavior, sAMAccountName synchronization for Domain Services, and Windows 10 ESU service plan identifiers in the licensing reference. Here’s the full breakdown.

1. Guided Migration Experience for GSA V1-to-V2 Web Filtering

Microsoft published a new how-to article documenting the guided migration experience for transitioning Global Secure Access web content filtering (V1) policies to the web filtering (V2) object model. This is the operational counterpart to the V2 conceptual article published on August 12, and it gives administrators a concrete, step-by-step path to move their existing policies without rebuilding them from scratch.

What Changed Between V1 and V2

The V2 model introduces structural changes to how web filtering works in Global Secure Access:

  • Single policy per security profile: V1 allowed multiple web content filtering policies linked to one security profile. V2 consolidates this into a single policy containing multiple rules, each with its own action.
  • Default action: V1 policies had no default action — they only acted when a rule matched. V2 policies always produce an outcome because they define a default action that applies when no rule matches.
  • FQDN destinations: The standalone FQDN destination type is removed in V2. FQDNs are now expressed as URL destinations, following URL matching logic.
  • Feature name: “Web Content Filtering” becomes “Web Filtering” in V2.

How the Guided Migration Works

The migration experience appears as a banner on the Security Profiles page in the Entra admin center when your tenant is eligible. Security profiles are categorized into three groups:

  1. Eligible profiles: Have at least one linked V1 policy and no existing V2 policy. These can be migrated automatically.
  2. Ineligible profiles: Already contain a V2 policy alongside V1 policies. These require manual handling — you either remove the V2 policy first and then migrate, or handle the migration manually.
  3. No migration needed: Profiles without any linked V1 policies. No action required.

When you initiate migration, it processes all eligible profiles in a single operation. For each eligible profile, the migration:

  • Creates a new, enabled V2 web filtering policy
  • Adds each linked V1 policy as a rule under the V2 policy, preserving its destinations, action, and priority
  • Links the new V2 policy to the security profile and removes V1 policy links — ensuring no enforcement gap during transition

The migration action is disabled after running once to prevent duplicate migrations.

Important Caveats

  • Evaluation behavior differs across profiles: Because V1 and V2 evaluate policies differently, the combined outcome across multiple security profiles might change after migration. Review your policy structure before migrating.
  • Conditional Access references remain valid: Security profiles are referenced by GUID in Conditional Access session controls, and these references work seamlessly across the V1-to-V2 transition.
  • V1 policies can still be edited: After migration, existing V1 policies can be edited or deleted, but new V1 policies cannot be created once V2 policies exist in a profile. To return to V1 authoring, remove all V2 policies from the profile.
  • Prerequisites: Global Secure Access Administrator role is required.

This migration guide is essential reading for any organization using GSA web content filtering. Even if you’re not ready to migrate yet, understanding the V2 model and its differences from V1 will help you plan your transition strategy.

2. GitHub Flexible Federated Identity Credentials Now Require Immutable Repository Claims

Microsoft updated the preview documentation for flexible federated identity credentials (FIC) to require GitHub configurations to match the sub claim plus at least one immutable claim: repository_id or repository_owner_id. This tightening closes a security gap where federated trust could be bound to mutable repository and owner names rather than permanent identifiers.

Why This Matters

GitHub repository and owner names can be reused. If a repository is renamed or an account is deleted, another repository or account can take the same name. Federated identity credentials that rely solely on name-based subject identifiers (repo:owner/repo:ref:refs/heads/main) remain vulnerable to this reuse scenario.

Immutable identifiers — repository_id and repository_owner_id — are permanent numeric IDs assigned by GitHub that never change and are never reused, even if names do. By requiring these in flexible FIC configurations, Microsoft ensures federated trust remains bound to the original repository regardless of name changes.

What the Configuration Looks Like

A GitHub flexible FIC expression now looks like:

claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*' and claims['repository_id'] eq '456789'

To additionally bind the credential to a specific owner:

claims['sub'] matches 'repo:contoso/contoso-repo:ref:refs/heads/*' and claims['repository_id'] eq '456789' and claims['repository_owner_id'] eq '123456'

Supported operators per claim:

  • sub: eq and matches
  • job_workflow_ref: eq and matches
  • repository_id: eq
  • repository_owner_id: eq

This requirement applies regardless of whether sub uses a name-based, customized, or immutable format. Portal, Microsoft Graph, and CLI examples have all been updated to reflect the new requirement with languageVersion: 1.

Broader Context: MC1447671 Migration

This documentation update complements the earlier MC1447671 Message Center notice from August 5, 2026, which advised organizations to migrate GitHub Actions federated identity credentials to immutable subject formats. Key facts from that notice:

  • Repositories created after July 15, 2026 use immutable default subject format automatically (includes owner_id and repo_id with @ delimiter)
  • Repositories created before July 15, 2026 keep name-based format unless opted in via OIDC settings
  • Repository renames and transfers after July 15, 2026 automatically move to immutable format
  • Migration approach: create a second federated credential alongside the existing one, test, then delete the old credential

The flexible FIC requirement adds an additional layer of security on top of the immutable subject migration by validating immutable claims directly in the claim-matching expression rather than relying solely on the subject format.

If your organization uses GitHub Actions with Entra federated identity credentials, review your configurations now and ensure they include the required immutable repository claims.

3. Authentication-Strength Policies Cannot Apply to MSA-Authenticated External Users

Updated Entra ID documentation clarifies that authentication-strength policies cannot currently be applied to external users who authenticate through Microsoft personal (MSA) accounts. Administrators should use the MFA grant control in Conditional Access instead of authentication-strength policies when they need to enforce multifactor authentication for these external users.

This is a documentation clarification of an existing limitation, not a newly introduced product behavior. However, it’s important for organizations using authentication-strength policies with B2B collaboration scenarios where external users authenticate via personal Microsoft accounts (Outlook.com, Hotmail, etc.). If you’ve configured authentication-strength policies expecting them to apply to all external users, verify that your MSA-authenticated guests are covered by a separate MFA grant control policy.

4. ID Protection Device-Block Remediation Behavior Revised

The Identity Protection documentation has been updated to correct the described behavior when an Entra device is disabled as part of remediation. The revised guidance states that disabling an Entra device:

  • Blocks new token issuance for that device
  • Revokes user sessions associated with the device
  • Prompts the user to sign in again

Previous documentation also mentioned revoking device-bound refresh tokens — that language has been removed. This is a documentation correction, not a behavior change. The actual remediation behavior hasn’t changed; the documentation now more accurately describes what happens.

This update refines the August 14 “Attacker-Added Device Remediation” entry where the Identity Protection Policies article replaced “Device disablement” with “Attacker-added device” terminology. If you’ve documented the remediation scope internally (for runbooks or training materials), update those references to remove refresh token revocation language.

5. sAMAccountName Synchronization Guidance for Entra Domain Services

Synchronization documentation now includes enhanced guidance for synchronizing the sAMAccountName attribute with Microsoft Entra Domain Services. The updated page describes the synchronization flow and links to dedicated guidance for configuring sAMAccountName in Domain Services scenarios.

This is a documentation addition for an existing capability. Organizations using Entra Domain Services that need sAMAccountName attribute values for legacy application compatibility or LDAP-dependent workloads should reference the updated guidance.

6. Windows 10 ESU Service Plans Added to Licensing Reference

The Entra ID Licensing Service Plan Reference was updated on August 14, 2026 to add Windows 10 Extended Security Updates (ESU) service-plan identifiers to the Windows 365 Enterprise and Windows 365 Shared Use entries. The reference table and downloadable CSV have been updated accordingly.

Administrators who use the licensing reference for plan matching, script-based license assignment, or reporting should download the updated reference and update any internal mappings that include Windows 365 plans. No administrative action is required beyond using the updated reference data.

Summary

The week of August 15-18, 2026, is characterized by documentation refinement rather than new product launches. The standout items are the GSA V1-to-V2 web filtering migration guide — which gives administrators a concrete path to transition their policies — and the GitHub flexible FIC immutable claims requirement — which strengthens federated identity security for GitHub Actions deployments.

While documentation updates may seem less impactful than feature launches, they often have real operational consequences. The GSA migration guide determines how organizations transition their web filtering architecture, and the GitHub FIC requirement changes what trust configurations are valid. Both deserve attention from identity administrators managing these workloads.

For ongoing coverage of Microsoft Entra ID changes, follow along at https://x.com/kkaminsk and check back here for weekly updates.

This article is based on Microsoft Learn documentation updates, Entra.News Daily summaries, and M365 Message Center announcements from August 15-18, 2026. For the official Microsoft Entra releases and announcements page, visit learn.microsoft.com/en-us/entra/fundamentals/whats-new.