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:
- Sign in as Hybrid Identity Administrator
- Navigate to Entra ID → Entra Connect → Cloud sync
- Select your AD to Microsoft Entra ID configuration
- Go to Properties → Basics → Edit
- 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 Attribute | AD Attribute | Mapping Type |
|---|---|---|
| AccountEnabled | userAccountControl | Expression |
| DeviceId | objectGUID | Direct |
| DeviceOSType | operatingSystem | Expression |
| DeviceTrustType | None (always ServerAd) | Expression |
| DisplayName | displayName, dNSHostName | Expression |
| OnPremiseSecurityIdentifier | objectSid | Direct |
| RegisteredOwnerReference | mS-DS-CreatorSID | Once |
| SourceAnchor | objectGUID | Direct |
| UserCertificate | userCertificate | Direct |
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
disableNestingset 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
- Inventory CA policies with resource exclusions (especially “All cloud apps” with specific exclusions)
- Use the What If tool to simulate sign-ins to excluded resources
- Prefer explicit app-targeted policies over “All apps with exclusions” where different enforcement is needed
- 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:
- Register an Entra app with a federated identity credential (e.g., GitHub OIDC)
- The SCIM workload obtains an OIDC token from the external IdP
- It exchanges that token for an Entra access token via token exchange
- 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
| Change | Action Required | Timeline |
|---|---|---|
| Cloud Sync device sync | Evaluate for Connect Sync migration | Preview now |
| Security group disableNesting | Apply to privileged groups | Available now |
| SMS/voice opt-out API | Set if you have a transition plan | Before Sept 1, 2026 |
| MC1223829 CA enforcement | Check affected apps | Mid-August 2026 |
| GitHub/GitLab hardening | Audit and restrict federation scope | Immediate |
| GSA egress IPs | Import into DCA and firewalls | Before GSA deployment |
| SCIM workload identity | Migrate from static secrets | Per integration |
| CSS positioning retirement | Remove affected properties | Before 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.