The first week of August 2026 delivers a packed set of Microsoft Entra ID updates that touch hybrid identity, group security, authentication migration, Conditional Access, and workload identity federation. The standout: Entra Cloud Sync finally supports device synchronization, removing one of the last major blockers for organizations migrating off Connect Sync. Let’s break down everything identity admins need to know.

Entra Cloud Sync Device Sync (Public Preview)

The biggest news this week is the public preview of device sync for Microsoft Entra Cloud Sync. Until now, organizations that needed to synchronize Active Directory computer objects to Entra ID for hybrid join were stuck on Entra Connect Sync. This was one of the most cited blockers preventing migration to the cloud-native Cloud Sync architecture.

What It Does

Device sync uses a dedicated AD2AADDeviceSync job within an existing AD-to-Entra Cloud Sync configuration. After synchronization, devices can become Microsoft Entra hybrid joined, enabling Conditional Access, device-based compliance, and SSO scenarios that depend on hybrid join state.

Prerequisites

  • Microsoft Entra Provisioning Agent version 1.1.1107 or later
  • An existing AD to Microsoft Entra ID Cloud Sync configuration
  • Your Entra tenant ID and verified domain (federated domain for federated environments, otherwise *.onmicrosoft.com)
  • Enterprise Admins access for Service Connection Point (SCP) configuration in each AD forest
  • Hybrid Identity Administrator role to configure device sync

How to Enable

Via Entra admin center:

  1. Sign in as Hybrid Identity Administrator
  2. Navigate to Entra ID → Entra Connect → Cloud sync
  3. Select your AD to Microsoft Entra ID configuration
  4. Go to Properties → Basics → Edit
  5. Enable device sync → Apply

Via Microsoft Graph API:

Create a synchronization job with templateId set to AD2AADDeviceSync:

POST https://graph.microsoft.com/beta/servicePrincipals/{spId}/synchronization/jobs
Content-Type: application/json

{
  "templateId": "AD2AADDeviceSync"
}

Then start the job:

POST https://graph.microsoft.com/beta/servicePrincipals/{spId}/synchronization/jobs/{jobId}/start

You can also provision individual devices on demand through the admin center or Graph API for testing.

Synced Device Attributes

Entra AttributeAD AttributeMapping Type
AccountEnableduserAccountControlExpression
DeviceIdobjectGUIDDirect
DeviceOSTypeoperatingSystemExpression
DeviceTrustTypeNone (always ServerAd)Expression
DisplayNamedisplayName, dNSHostNameExpression
OnPremiseSecurityIdentifierobjectSidDirect
RegisteredOwnerReferencemS-DS-CreatorSIDOnce
SourceAnchorobjectGUIDDirect
UserCertificateuserCertificateDirect

Why This Matters

Microsoft has been clear: Cloud Sync is the strategic direction for hybrid identity. Connect Sync versions are on a rolling retirement, and version 2.5.79.0 or later is mandatory by September 30, 2026 to keep syncing. With device sync now in preview, the migration path is finally open for organizations that previously couldn’t move because of device sync dependencies.

Migration approach: Deploy Cloud Sync side-by-side with Connect Sync, pilot device sync for a subset OU, validate hybrid join flows, then gradually decommission Connect Sync.

Security Group Nesting Controls (disableNesting Property)

Microsoft quietly added a disableNesting property to security groups in Entra ID, giving administrators a way to prevent nested group memberships on critical groups. The feature is available now through the Graph v1.0 endpoint, though the Entra admin center UI doesn’t yet expose it.

How It Works

When disableNesting is set to true on a security group:

  • Users, service principals, and devices can still be added as members
  • Attempts to add another group as a member are blocked
  • Nesting is blocked if either the target group or the prospective member group has disableNesting set to true
  • The property can only be set at group creation time — it cannot be updated after creation

Graph API Examples

Create a new security group with nesting disabled:

$RequestBody = @{
    displayName = "Privileged Access Group"
    securityEnabled = $true
    mailEnabled = $false
    mailNickname = "PrivilegedAccess"
    disableNesting = $true
    description = "Security group with nesting disabled"
}
New-MgGroup -BodyParameter $RequestBody

Filter for groups with nesting disabled:

Get-MgGroup -Filter "securityEnabled eq true and mailEnabled eq false and disableNesting eq true" -All

Read the property (must explicitly request it via $select):

GET https://graph.microsoft.com/v1.0/groups/{id}?$select=id,displayName,disableNesting

New Permission

Microsoft created a granular Group-NestingSupport.ReadWrite.All permission specifically for managing this property, alongside the broader Group.ReadWrite.All.

Use Cases

  • Privileged access groups — Prevent hidden escalation through nested membership chains
  • Regulatory/compliance-controlled resources — Simplify access reviews with flat membership
  • Executive access groups — Ensure explicit, auditable membership
  • Groups subject to access reviews — Eliminate complexity in attestation

SMS/Voice Migration Temporary Opt-Out API

On August 1, Microsoft shipped the beta Graph API opt-out procedure for the automatic passkey enablement and Registration Campaign rollout. This gives organizations with their own transition plans a temporary window to delay the September 1 changes.

What the Opt-Out Does

Setting optOutSettings.passkeyDynamicMigration to true via the beta Graph API temporarily excludes your tenant from:

  • Automatic passkey enablement for SMS/voice users
  • The default Registration Campaign behavior that pushes passkey registration

What It Does NOT Do

  • Does not prevent the February 1, 2027 retirement of Microsoft-provided SMS/voice
  • Does not re-enable retired SMS/voice methods
  • Does not disable passkeys or phishing-resistant methods
  • Does not exempt you from your own Conditional Access policies

The opt-out window runs from September 1, 2026 through February 1, 2027. There is no opt-out from the February retirement.

Supporting Tooling

Microsoft published the entra-sms-voice-usage-analyzer PowerShell script on GitHub for inventorying users still on SMS/voice authentication. Run this before deciding whether to use the opt-out:

# Requires Global Reader, Authentication Policy Administrator, or Security Reader role
# Available at: https://github.com/microsoft/entra-sms-voice-usage-analyzer

Recommendation

Use the opt-out only if you have a structured transition plan. Microsoft clearly wants tenants on passkeys. If you do opt out, use the extended window to deploy passkey-ready platforms, update Conditional Access to prefer phishing-resistant strengths, and run user communication campaigns.

MC1223829: Conditional Access Improved Enforcement for Resource Exclusions

Microsoft is closing a gap in Conditional Access enforcement where applications requesting only baseline scopes with at least one resource exclusion were not being properly processed. The rollout started in early August and should complete by mid-August 2026.

Impact Assessment

Most tenants won’t notice any change. However, if you have applications that fit the profile — requesting baseline scopes with at least one exclusion — they may encounter Conditional Access enforcement for the first time. Check if MC1223829 appeared in your tenant’s Message Center.

Admin Actions

  1. Inventory CA policies with resource exclusions (especially “All cloud apps” with specific exclusions)
  2. Use the What If tool to simulate sign-ins to excluded resources
  3. Prefer explicit app-targeted policies over “All apps with exclusions” where different enforcement is needed
  4. Document resource-specific policies to prevent shadow bypasses

Hardening GitHub and GitLab Federated Credentials

Microsoft published new guidance on hardening federated credentials used by GitHub Actions and GitLab CI for Entra ID workload identity federation. This is important for any organization using OIDC federation to enable secretless Azure deployments from CI/CD pipelines.

Key Recommendations

Restrict federation scope: Limit federated identity credentials to specific repositories and branches, not entire organizations. A broad subject match like repo:myorg:* is dangerous; use repo:myorg/myapp:ref:refs/heads/main instead.

Apply least privilege: Grant federated CI apps only the Graph permissions they need (e.g., Application.ReadWrite.OwnedBy rather than Application.ReadWrite.All).

Use Conditional Access for workload identities: Create CA policies that allow federated workloads without interactive MFA but restrict issuance to known issuers and claims.

GitHub Actions Pattern

Configure an Entra app registration with a federated identity credential:

  • Issuer: https://token.actions.githubusercontent.com
  • Subject: repo:{owner}/{repo}:ref:refs/heads/{branch}
  • Audience: api://AzureADTokenExchange

The GitHub Actions workflow requests an OIDC token, exchanges it with Entra ID for an access token, and uses that to call Microsoft Graph or Azure Resource Manager — no stored secrets required.

Global Secure Access: Egress IP Ranges and DCA Coexistence

Two new documentation updates help organizations deploying Global Secure Access alongside existing security tooling.

Egress IP Ranges

Microsoft now publishes dedicated outbound egress IP ranges for GSA. These should be:

  • Marked as trusted/known locations in Defender for Cloud Apps
  • Incorporated into firewall and proxy allowlists
  • Used in Conditional Access named locations for network-based policies

DCA Coexistence Guidance

New documentation explains how GSA and Defender for Cloud Apps can coexist without double proxying. This is critical for organizations using both solutions — without proper configuration, DCA may treat GSA egress IPs as external traffic, losing shadow IT visibility and session control effectiveness.

Admin action: Import GSA egress IP ranges into DCA as corporate locations, then verify that CA + DCA integrated policies correctly include GSA traffic.

SCIM Provisioning: Secretless Authentication with Workload Identity Federation

SCIM provisioning documentation has been updated to include secretless authentication using workload identity federation. This aligns with the April 2026 announcement about SCIM provisioning apps moving to modern authentication methods.

What Changed

SCIM clients can now authenticate to Entra ID using federated credentials instead of long-lived client secrets. The SCIM protocol itself remains unchanged — what changes is how the provisioning engine authenticates:

  1. Register an Entra app with a federated identity credential (e.g., GitHub OIDC)
  2. The SCIM workload obtains an OIDC token from the external IdP
  3. It exchanges that token for an Entra access token via token exchange
  4. SCIM provisioning proceeds with short-lived, non-secret-based tokens

This eliminates a significant risk: SCIM integrations often run as service principals with non-rotated client secrets.

New Tenant-Estate Architecture Series

Microsoft published a seven-part tenant-estate architecture series covering:

  • Primary tenants — The central identity authority
  • Collaborating production tenants — Multi-tenant production scenarios
  • Isolated critical-system tenants — When to separate
  • Business-partner isolation — B2B and external identity patterns
  • Nonproduction tenants — Dev/test/staging strategies
  • Hybrid identity — Connecting on-premises AD with Entra ID

This is essential reading for any organization with complex tenant topologies.

MC1435782: Custom CSS Positioning Properties Retirement

A formal Message Center notification (MC1435782) confirms the retirement timeline for custom CSS positioning properties in company branding:

  • July 21, 2026: Tenants not already using positioning properties can no longer configure them
  • October 26, 2026: Positioning properties retired globally
  • Later 2027: Full custom CSS retirement planned

Affected properties: position (top/right/bottom/left/z-index), margin, transform, opacity, overflow, filter, pointer-events, clip-path, mix-blend-mode, translate

Check your branding configuration via Graph Explorer and remove affected properties before the October deadline.

Action Summary

ChangeAction RequiredTimeline
Cloud Sync device syncEvaluate for Connect Sync migrationPreview now
Security group disableNestingApply to privileged groupsAvailable now
SMS/voice opt-out APISet if you have a transition planBefore Sept 1, 2026
MC1223829 CA enforcementCheck affected appsMid-August 2026
GitHub/GitLab hardeningAudit and restrict federation scopeImmediate
GSA egress IPsImport into DCA and firewallsBefore GSA deployment
SCIM workload identityMigrate from static secretsPer integration
CSS positioning retirementRemove affected propertiesBefore Oct 26, 2026

What This Means for Your Organization

August 2026 continues Microsoft’s relentless push toward cloud-native identity, phishing-resistant authentication, and secretless workload identity. The Cloud Sync device sync preview is the headline for hybrid identity teams — it finally removes the “we can’t migrate because of devices” objection. The security group nesting controls and workload identity federation hardening guidance demonstrate Microsoft’s commitment to giving admins the tools to enforce least privilege across both human and non-human identities.

If you’re still on Connect Sync, now is the time to start planning your Cloud Sync migration in earnest. And if you haven’t started your passkey rollout, the temporary opt-out API gives you a window — but use it wisely, because February 2027 is a hard deadline with no exceptions.

Follow @kkaminsk on X for daily Microsoft Entra ID updates and identity security insights.