Transition Azure Synapse Analytics workspaces to private links before 1 August 2026

Ahmad Nafouri 45 Reputation points

We have a few questions regarding the Synapse transition to private links:

  1. Identifying impacted workspaces What is the recommended approach to identify which Synapse workspaces or environments are actually impacted? Customers are receiving the communication emails, but not all of them relay this information to us, so we currently lack visibility into which customers are affected.
    How can we validate which customers are impacted and which are not?
  2. Scope clarification The communication sent to the customers describes the in-scope scenario as “storage account / Key Vault with a managed identity and a firewall exception.” Does this change also impact Synapse workspaces that connect to a storage account fully open to the public internet (no firewall and no service-endpoint or trusted-services restrictions)? Or is the retirement strictly limited to storage accounts that rely on the trusted-services exception combined with a managed identity and are using private endpoints?
  1. Manoj Kumar Boyini 17,060 Reputation points • Microsoft External Staff • Moderator

    Hi @Ahmad Nafouri

    I hope you had a chance to review the information shared earlier, and I hope this information has been helpful! If you still have questions, please let us know what is needed in the comments so the question can be answered.

Sign in to comment

Answer accepted by question author

Smaran Thoomu 35,375 Reputation points • Microsoft External Staff • Moderator

Hi @Ahmad Nafouri

Adding a few more clarifications regarding impact validation.

The retirement mainly affects scenarios where:

  • Synapse workspace accesses Storage Account or Key Vault using Managed Identity
  • AND the target resource uses firewall restrictions with:
    • “Allow trusted Microsoft services”
    • or similar trusted-services/network exception model

Generally, environments where the Storage Account / Key Vault is fully open to public network access (no firewall restrictions, no trusted-services dependency) are not the primary scenarios impacted by this transition.

For validation, customers can check:

  • Synapse Managed Identity usage
  • Storage Account networking settings
  • Key Vault networking settings
  • Whether “Allow trusted Microsoft services” is enabled
  • Whether Private Endpoints are already configured

If Private Endpoints are already implemented between Synapse and dependent resources, then no additional migration action is typically required.

You can also review Synapse Managed Private Endpoints under:

  • Synapse Studio
  • Manage -> Managed private endpoints

to confirm whether Private Link connectivity is already configured.

Hope this helps clarify the scope further.

  1. Ahmad Nafouri 45 Reputation points

    Thank you Smaran. This is useful and helps us identify the impacted environments of our customers.

Sign in to comment

Answer accepted by question author

Manoj Kumar Boyini 17,060 Reputation points • Microsoft External Staff • Moderator

Hi @Ahmad Nafouri

This notification is part of a broader Azure security update related to Azure Synapse Analytics. It specifically targets scenarios where Synapse workspaces access Azure Storage or Azure Key Vault using managed identity combined with the “Allow trusted Microsoft services” firewall exception, which will be retired on August 1, 2026.

1.These emails are sent at the subscription level whenever Synapse-related resources or configurations are detected.
2.As a result, customers may receive notifications even if Synapse is not actively being used in all environments.

If you are actively using Synapse workspaces that rely on managed identity + trusted services firewall exception, you must migrate to Private Link (Private Endpoints) before August 2026. If your environment already uses Private Endpoints, no further action is required.

Scenarios where no action is needed

  • If you do not use Synapse Analytics or have no active workspaces
  • If associated Storage/Key Vault resources are publicly accessible (no firewall restrictions)
  • If the environment does not rely on the trusted services bypass

In these cases, no action is required, and the notification can be considered informational.

Optional validation

If needed, you can verify by checking:

  • Synapse workspaces under your subscription
  • Storage/Key Vault firewall settings (specifically whether “Allow trusted Microsoft services” is enabled)

Please let us know if you have any questions or need assistance with validation or migration planning.

Reference:
https://learn.microsoft.com/en-us/power-apps/maker/data-platform/azure-synapse-link-transition-faq

  1. Ahmad Nafouri 45 Reputation points

    Thank you Manoj. This helps us identify the impacted environments of our customers.

Sign in to comment

1 additional answer

  1. AI answer

    1. Identifying impacted workspaces

    The retirement described applies to Azure Synapse Analytics workspaces that currently rely on the trusted services capability to reach Azure Storage (ADLS Gen2) and/or Azure Key Vault using a managed identity plus a firewall exception on those resources.

    From the provided information, the recommended target state is:

    1. A Synapse workspace deployed with a Managed Virtual Network.
    2. Managed private endpoints from that workspace to the ADLS Gen2 storage account (and similarly to other PaaS resources as needed).
    3. Network settings enabled on both sides so Azure Synapse Link and other data-plane operations can continue to function:
      • On the storage account: Allow Azure services and resources to access this storage account.
      • On the Synapse workspace: Allow Azure services and resources to access this workspace.

    To identify which customer environments are impacted, the practical approach is:

    • Enumerate Synapse workspaces per customer and check:
      • Whether they are using Azure Synapse Link for Dataverse or other integrations that depend on Synapse accessing ADLS Gen2/Key Vault via managed identity.
      • Whether those storage accounts/Key Vaults are configured with firewall restrictions plus trusted services (rather than private endpoints or fully open public access).
    • Any workspace that:
      • Uses managed identity to access Storage/Key Vault, and
      • Relies on the trusted services firewall exception (instead of a managed private endpoint),
      should be treated as in scope and transitioned to:
      • Synapse workspace with Managed VNet, and
      • Managed private endpoints to the relevant storage accounts (and other PaaS resources).

    Workspaces already using a Managed VNet plus managed private endpoints to their storage/Key Vault are already aligned with the target model described and are not functionally impacted by the retirement of trusted services.

    1. Scope clarification

    The communication explicitly scopes the change to the scenario:

    “storage account / Key Vault with a managed identity and a firewall exception.”

    The transition guidance states that if a customer decides to move to private links, they must:

    1. Create a Synapse workspace with a managed virtual network.
    2. Create a managed private endpoint for the storage account (ADLS Gen2), replacing the trusted-services firewall exception.
    3. Enable the two Allow Azure services and resources to access… settings on both the storage account and the Synapse workspace so Azure Synapse Link can connect.

    This directly addresses environments that:

    • Use managed identity from Synapse to Storage/Key Vault, and
    • Depend on trusted services plus firewall rules to allow that access.

    A storage account that is fully open to the public internet (no firewall restrictions, no service endpoints, no trusted-services restriction) does not rely on the trusted-services firewall exception to allow Synapse access. Based on the description, the retirement is focused on removing that trusted-services mechanism, not on public, unrestricted storage accounts.

    Therefore, the change is scoped to:

    • Storage accounts/Key Vaults that:
      • Use firewall restrictions, and
      • Allow Synapse via the trusted services exception in combination with managed identity.

    Storage accounts that are fully public (no firewall, no trusted-services restriction) are not described as being directly in scope of this retirement in the provided material. However, for security and data exfiltration protection, the recommended pattern remains to use Managed VNet + managed private endpoints rather than public access.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer