Microsoft published a new setup path for Azure SQL Data Sync with a user-assigned managed identity on August 18, 2026.

The Azure Database Support post shows a sync group and its members authenticating to Azure SQL Database through Microsoft Entra ID instead of stored SQL usernames and passwords. The workflow creates a database user for the managed identity in every participating database, passes the identity resource ID to new Data Sync PowerShell parameters, and supports replacing the identity later.

This is a meaningful security improvement for a service whose existing public documentation still warns that SQL Data Sync relies on SQL authentication.

That documentation gap is the most important adoption detail. Microsoft's new engineering post requires `Az.Sql` version `6.6.0-preview` or later, while the current Learn overview and stable cmdlet reference still describe password-based authentication. Treat the UAMI path as an emerging capability whose availability and support boundary must be confirmed before production use.

Data Sync Has Historically Carried a Password Problem

Azure SQL Data Sync synchronizes selected tables and columns across Azure SQL databases and, with a local sync agent, SQL Server databases.

It uses a hub-and-spoke model. Each member exchanges changes with the hub, and a conflict policy determines whether hub or member changes win.

The service can help with distributed applications, hybrid data sharing, and keeping selected operational datasets aligned. It is not a replacement for every replication technology. Microsoft says it does not provide transactional consistency and is not the preferred tool for disaster recovery, read scale, ETL, or primary migration.

The authentication model has also been a concern. The public Learn overview currently says SQL Data Sync requires SQL authentication for hub and member connections and does not support Microsoft Entra authentication.

Static database credentials create work:

• Passwords must be generated, stored, distributed, and rotated

• Automation needs access to the secret

• Rotation can break one member while others keep running

• Secret exposure can grant direct database access

• SQL authentication does not receive MFA or Conditional Access

• Auditors need evidence for storage and rotation controls

A managed identity removes the password object from that path. Azure manages the workload identity credential, while database permissions remain explicit.

What the New Microsoft Guidance Shows

The Azure Database Support article documents `UserAssigned` authentication for both the hub and members.

For a new sync group, the example supplies:

• `HubDatabaseAuthenticationType UserAssigned`

• The UAMI Azure resource ID

For a new sync member, it supplies:

• `MemberDatabaseAuthenticationType UserAssigned`

• The same or an approved UAMI resource ID

The article then refreshes the hub schema, applies an explicit JSON schema, and starts synchronization through the familiar Data Sync cmdlets.

The architectural flow becomes:

1. Azure SQL logical servers trust Microsoft Entra authentication. 2. A user-assigned managed identity exists as an Azure resource. 3. Every hub and member database contains a user mapped to that identity. 4. That user receives the permissions Data Sync requires. 5. The sync group and members reference the identity instead of database credentials.

The same identity can be used across the participating Azure SQL databases, although the security design should decide whether one shared identity or separate identities gives the right isolation.

User-Assigned Identity Fits a Long-Lived Topology

A user-assigned managed identity has its own Azure lifecycle. It is not deleted when one database, server, or deployment host is replaced.

That makes it useful for Data Sync, where a logical synchronization relationship may outlive individual resources or automation jobs.

The identity also provides a stable object ID for database principals and a stable resource ID for infrastructure automation.

Use a dedicated UAMI for the sync topology rather than reusing an identity that also deploys infrastructure, reads Key Vault, or administers unrelated databases. A dedicated identity produces a clearer blast radius and audit trail.

Name and tag it with:

• Business owner

• Data classification

• Hub server and database

• Member scope

• Environment

• Rotation procedure

• Retirement date

Managed identity removes credential rotation, but it does not remove identity governance.

Entra Configuration Comes First

Every Azure SQL logical server involved must have Microsoft Entra authentication configured and an Entra administrator available for setup.

An authorized administrator connects to each hub and member database and creates a contained database user for the UAMI.

The user then needs the Data Sync permissions described by Microsoft's implementation guidance. The example refers to read, write, and control capabilities.

Do not copy a broad permission grant blindly into production. Determine which schema and objects Data Sync needs, test the minimum permission set, and document why each grant exists.

The important operational rule is completeness. A UAMI created only in the hub cannot authenticate to a member. A principal created in every database but missing one required permission can produce partial onboarding or runtime failure.

Keep an inventory matrix of server, database, principal, permission, and last validation result.

One Identity per Sync Object Requires Careful Rotation

Microsoft says only one UAMI can be assigned to a sync group or sync member at a time.

The documented rotation sequence grants the replacement identity access first, then updates the Data Sync object by assigning the new resource ID and removing the old identity in the same operation.

For the hub, the example uses `Update-AzSqlSyncGroup`. For a member, it uses `Update-AzSqlSyncMember`.

A safe rotation runbook should:

• Create and tag the new UAMI

• Create its user in every required database

• Grant and verify permissions

• Pause risky topology changes

• Update one sync object at a time

• Trigger and monitor synchronization

• Check for authentication errors and data lag

• Remove the old database users only after validation

• Delete the old Azure identity only after the rollback window

The absence of a password does not make rotation atomic across every database and sync member. Build a reversible sequence.

Avoid the Multiple-Identity PATCH Trap

The support post calls out a specific REST automation pitfall.

When updating schemas through the REST API, resubmitting an identity block for an object that already has its managed identity assigned can result in a `DataSyncMultipleIdentities` error.

This is exactly the sort of issue that appears when an infrastructure tool sends a complete desired-state payload while the API expects a narrower update.

Before building Terraform, Bicep deployment scripts, or a custom REST controller around the preview path:

• Capture successful create and update payloads

• Separate identity rotation from schema updates

• Use the documented field mask or PATCH behavior where available

• Test idempotent reruns

• Record the API version

• Fail on unexpected multiple-identity state

• Do not remove the working identity merely to retry a schema change

An authentication improvement should not introduce fragile control-plane automation.

Schema and Data Behavior Do Not Change

UAMI changes authentication. It does not change the core Data Sync model.

Teams still define which tables and columns participate. Data Sync uses change-tracking triggers and side tables, synchronizes each member with the hub, and applies the configured conflict-resolution policy.

The operational limitations still matter:

• Synchronization is not transactionally consistent across all databases

• Conflicts can overwrite data according to hub-wins or member-wins policy

• Trigger behavior affects whether changes are captured

• Schema changes need explicit management

• Synchronization adds workload overhead

• A failed member can accumulate lag

Do not interpret passwordless authentication as a reason to use Data Sync for a scenario it was not designed to solve.

For disaster recovery, read replicas, ETL, or migration, use the Azure service Microsoft recommends for that job.

Private Networking Is a Separate Control

Managed identity protects authentication. It does not make the network private.

Review how the Data Sync service reaches the hub and members. Existing Data Sync documentation describes service-managed private endpoints for supported Azure SQL connections, and PowerShell exposes a private-link option in established workflows.

Validate private endpoint approval, SQL firewall settings, DNS resolution, and the sync agent path for any on-premises member.

A strong design combines:

• Entra-based workload identity

• Least-privilege database permissions

• Private connectivity where supported

• Restricted public network access

• Central audit and diagnostic logs

• Monitoring for failed authentication and synchronization lag

Changing only the credential type leaves the rest of the exposure unchanged.

Documentation Lag Is a Release Signal

As of August 24, 2026, Microsoft's official pages do not tell one consistent story.

The new Azure Database Support article says UAMI support is available and provides parameters that require `Az.Sql 6.6.0-preview` or later. The general SQL Data Sync overview still says Microsoft Entra authentication is unsupported. The stable PowerShell reference currently lists database credential parameters but does not show the new UAMI parameters.

The reasonable inference is that the engineering capability is arriving ahead of the full stable documentation set.

Before production adoption, ask Microsoft to confirm:

• Whether the feature is preview or generally available

• Supported Azure regions and subscription types

• Supported hub and member combinations

• Required REST API version

• Supported Az.Sql module version

• Portal support

• SLA and support policy

• Migration path from SQL authentication

• Behavior for on-premises SQL Server members

Pin the tested preview module version. Do not allow a general `Update-Module` step to change production behavior without validation.

SQL Data Sync Has a Retirement Date

Microsoft's current Learn overview states that Azure SQL Data Sync will retire on September 30, 2027 and recommends evaluating alternative replication or synchronization solutions.

That changes the investment decision.

UAMI can reduce credential risk for a topology that must operate during the remaining service lifetime. It should not become a reason to create a large new dependency without an exit plan.

For an existing deployment, the right sequence may be:

• Reduce immediate password exposure with UAMI after support is confirmed

• Document the current sync topology and data contracts

• Select a replacement architecture

• Run the replacement in parallel

• Reconcile data and conflict behavior

• Cut over before the retirement deadline

• Remove Data Sync identities, triggers, metadata, and private endpoints

For a new project, compare alternatives before choosing Data Sync at all.

The secure short-term path and the strategic long-term path can be different decisions.

Monitoring Must Prove More Than Authentication

After onboarding the identity, trigger an initial synchronization and verify actual data movement.

Monitor:

• Sync state and last successful time

• Member-specific lag

• Authentication failures

• Permission-denied errors

• Schema refresh failures

• Conflict counts

• Rows synchronized

• Trigger and side-table growth

• Database CPU, log, and storage impact

• Changes to the UAMI and database principal

Send alerts to an owned operational queue. A sync group that authenticates correctly but has stopped moving data is still unavailable.

Use a canary row or an application-level reconciliation process for critical datasets. Control-plane status alone cannot prove business-level consistency.

Who Should Care?

Azure SQL administrators should care because Data Sync can move away from stored database passwords.

Identity teams should care because a long-lived UAMI becomes a production workload principal across multiple databases.

Security teams should care because authentication, database authorization, network access, and monitoring remain separate controls.

Platform engineers should care because preview modules and REST update behavior affect idempotent automation.

Application owners should care because the service retirement date requires a migration plan even if UAMI improves the current deployment.

Practical Cloud Engineer Takeaway

Do not switch a production sync group first.

Build a small non-production topology with one hub and one member. Confirm Microsoft Entra administrators are configured, create one dedicated UAMI, and create the database principal in both databases.

Install the exact preview Az.Sql version in an isolated automation environment. Create the sync group and member with `UserAssigned` authentication, apply a tiny schema, and test changes in both directions.

Then test failure paths: remove one database permission, disable the identity, block network access, submit a schema update without the identity block, and rotate to a second UAMI.

Capture the recovery procedure and API responses. Ask Microsoft Support to confirm the feature status for the target subscription before moving regulated or critical data.

Finally, place the experiment inside a retirement program. Record which replacement service will own the data flow before September 30, 2027.

Bottom Line

Microsoft's latest Azure Database Support guidance shows Azure SQL Data Sync authenticating its hub and members with a user-assigned managed identity.

The approach removes stored SQL passwords from the sync configuration, integrates the workload with Microsoft Entra ID, and provides an explicit identity rotation path.

It does not change Data Sync's consistency model, permissions, networking requirements, monitoring needs, or retirement date.

The public documentation currently lags the engineering announcement, and the workflow depends on a preview Az.Sql module. Validate availability and support directly, pin the working toolchain, and pilot the entire identity lifecycle before production adoption.

For existing Data Sync users, UAMI can be a valuable security bridge. Build that bridge while continuing toward the service's 2027 exit.

Sources

Microsoft Azure Database Support guidance, published August 18, 2026: https://techcommunity.microsoft.com/blog/azuredbsupport/getting-started-with-azure-sql-data-sync-using-user-assigned-managed-identity-ua/4547758

Azure SQL Data Sync overview and retirement notice: https://learn.microsoft.com/en-us/azure/azure-sql/database/sql-data-sync-data-sql-server-sql-database

Configure Microsoft Entra authentication for Azure SQL: https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure

Manage user-assigned managed identities: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/manage-user-assigned-managed-identities-azure-portal

Azure SQL Data Sync PowerShell workflow: https://learn.microsoft.com/en-us/azure/azure-sql/database/scripts/sql-data-sync-sync-data-between-sql-databases

---

Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.

Chriz Beyond Cloud with Chriz