David Zebrowitz Director, Data & Analytics Consulting Services
Share this article

On August 1, 2026, many Azure Synapse workspaces will lose the network path they currently use to reach their own storage and secrets, and they will stop functioning for those operations until they are migrated. Determining whether your environment is affected takes only a few minutes. The remediation is a planned, no-downtime migration to a new workspace, and there is still time to complete it in an orderly way if the work begins now.

What leaders need to know

The deadline is firm. On August 1, 2026, Synapse workspaces that rely on the retiring path will lose access to their storage or Key Vault, and those workspaces will stop functioning for the affected operations.

This is the common configuration, not an edge case. The at-risk setup is the ordinary outcome of following the security-conscious Synapse Link installation. Organizations that hardened their environment are more likely to be affected, not less.

For many organizations, the remediation is a rebuild. The required setting can only be enabled when a workspace is created, so affected environments need a new workspace and a migration rather than a configuration change.

Microsoft Dynamics 365 customers are directly affected. Organizations using Synapse Link for Dataverse, including Finance and Supply Chain and the customer engagement apps, represent the largest affected population.

There is still time if work begins now. The migration can run in parallel with no downtime, provided it is planned well ahead of the deadline rather than in the final weeks.

What is being retired

Today a Synapse workspace commonly reaches an Azure Storage account or an Azure Key Vault using a managed identity together with a firewall exception. That exception is the trusted-services allowance, and it permits the Synapse service to reach the storage or Key Vault firewall because Microsoft treats it as a first-party service. On August 1, 2026, that allowance is removed.

The replacement is private networking. Instead of a firewall exception, the workspace reaches storage and Key Vault through a managed virtual network using managed private endpoints. This is a stronger security model. The hard part is the work required to get there.

The change does not degrade gracefully. If no action is taken, the paths that depend on the trusted-services exception will stop working, and a workspace that cannot read its storage or its secrets cannot operate. This is a deadline that interrupts production workloads, not an optional cleanup.

Why this change impacts the typical installation, not edge cases

It is natural to assume that only heavily hardened environments are affected. In practice, the opposite is true. The at-risk configuration is the ordinary result of following the installation guidance carefully.

When an organization stands up Synapse Link for Dataverse, Microsoft's guidance directs it to set the landing storage account firewall to Selected networks. That is the appropriate next step after the wizard completes, because the storage account should not remain open to the public internet. Trusted Azure services are then allowed through so that Synapse can continue to reach the account. That combination, a restricted firewall together with the trusted-services exception, is precisely the pattern being retired.

The population at risk is therefore not the organizations that did something unusual. It is the majority that followed the security-conscious installation. A fully open storage account, which is technically unaffected, typically appears only on demonstration tenants or in environments where the firewall was never tightened.

Why the remediation is usually a rebuild

The setting that enables managed private endpoints is the managed virtual network on the workspace. That property can only be enabled when the workspace is created. Microsoft does not provide a way to enable it on a workspace that already exists.

Azure Synapse managed virtual network settings screenshot

Figure 1 - Synapse Managed Virtual Network is not enabled

As a result, if a workspace was not created with the managed virtual network enabled, this is not a setting that can be changed in the portal. The practical remediation is to deploy a new workspace with the managed virtual network enabled from the outset and migrate the existing work onto it. Every Synapse workspace also has an associated primary storage account that holds its saved queries, pipelines, and related artifacts; which is part of why repointing an existing workspace is not straightforward.

How to determine whether you are affected

This assessment can be performed today, at no cost, in a few minutes, and it establishes whether your environment is affected.

First, identify the relevant storage account. This is the landing storage account for your Synapse Link, confirmed in the Power Apps maker portal under Azure Synapse Link for Dataverse, then the link entry, then Details. Copy the value shown under Storage Account.

With the correct account name, run the following Azure CLI query. Reader access on the storage account is sufficient for it to return cleanly.

az storage account show --name <landingStorageAccount> --query "{publicNetworkAccess:publicNetworkAccess, defaultAction:networkRuleSet.defaultAction, bypass:networkRuleSet.bypass, privateEndpoints:length(privateEndpointConnections)}" -o table

Interpret the result against three cases:

  • If you see defaultAction: Deny with bypass: AzureServices and privateEndpoints: 0, and the paired workspace has no managed virtual network, then the workspace is at risk and a rebuild is required before August 1, 2026. Confirm the managed virtual network status on the workspace Overview page in the Azure portal.
  • If you see defaultAction: Allow, then the firewall is not load-bearing, there is no trusted-services bypass to retire, and this specific change does not affect you.
  • If you see a private endpoint already in place and the workspace already has a managed virtual network, then you have already migrated and there is nothing to do here.

The middle case warrants a caveat. If the storage account accepts public traffic from all networks, the retirement does not affect you on August 1, 2026; but the only reason it does not is that the account is currently open to all networks, which is a risk worth addressing in its own right. Once you properly restrict it to selected networks, you return to the at-risk pattern. A fully open account defers the deadline; it does not remove the underlying work. We would still recommend planning a move to the private-networking model on a measured timeline, so the account can be locked down without working against a deadline.

To confirm the same condition in the portal, open the storage account's Public network access page. The at-risk state is Public network access set to Enable with the scope set to Enable from selected networks. On the workspace side, open the Overview page. If Managed virtual network reads No, that is the property that cannot be changed after creation, and it is the reason a rebuild may be required.

One further caveat applies to the storage check. The same trusted-services logic applies to any Azure Key Vault the workspace reaches through a firewall. If your storage account proves to be open, but a firewalled Key Vault is reached by Synapse as a trusted service, that path is on the same timeline, so confirm both.

Two common but incorrect conclusions

Two readings of the portal appear reassuring and are not.

The first concerns public network access. Seeing “Enabled” on that setting is not the same as wide open. Selected networks still shows as Enabled, because the public endpoint exists, but it sits behind a restricted firewall, and that restricted-plus-trusted-services state is precisely the at-risk pattern.

The second concerns a private endpoint on the storage side. If your team added a customer-side private endpoint to the storage account, it is reasonable to assume that covers the workspace. It does not. A workspace without a managed virtual network still routes its traffic over the public endpoint using the trusted-services bypass, so a private endpoint added on the storage side does not carry the Synapse traffic. The endpoint that matters is a managed private endpoint from the workspace, and that requires the managed virtual network that cannot be added later.

Who is most affected

The organizations most affected are Microsoft Dynamics 365 customers that use Synapse Link. The retirement reaches Synapse Link for Dataverse broadly, including both Finance and Supply Chain and the customer engagement apps, so no organization should assume it is exempt. Many of these teams are not primarily Azure specialists. They adopted Synapse Link because it was the supported path for bringing Dynamics 365 data into a lake, not to take on Synapse networking.

Many of these same customers were recently moved off Export to Data Lake and onto Synapse Link or Fabric Link. Organizations that chose Synapse Link completed the migration they were directed to make, and those without the managed virtual network enabled now face another one soon after.

What the remediation involves

Because the managed virtual network can only be enabled when a workspace is created, the remediation is to stand up a new workspace with it enabled and migrate the existing work onto it. There is no in-place setting that removes this requirement.

This does not require an outage. The new workspace can run in parallel with the existing one, which continues to operate until the organization chooses to cut over. The deadline requires a rebuild, but it does not require downtime, so the work can be planned deliberately rather than compressed into a high-risk maintenance window near the deadline.

The scope of the rebuild depends on what was built. A workspace that only uses Synapse Link and external tables to read from a storage account is a contained move. A workspace with dedicated SQL pools and a large set of pipelines is a substantial migration that requires testing. Because the effort is not uniform, it should be assessed against your actual environment.  The largest source of effort and risk is usually downstream: a new workspace typically means a new endpoint hostname, and every connection pointed at the previous one must be identified and repointed.

How Alithya can help

The diagnosis above is yours to run. The rebuild and migration are a different matter. The difference between a controlled, no-downtime cutover and a last-minute effort comes down to planning and experience.

Our Microsoft Azure and Data practice has developed remediation plans for precisely this change. Our Synapse Readiness Assessment confirms exactly where your environment stands, maps your downstream exposure, and delivers a migration plan and an estimate scoped to your actual workspace(s). From there, we can execute the parallel migration and the repointing with you, on a timeline that protects your operations and clears the August 1, 2026 deadline with room to spare.

Contact us to learn how Alithya can help with your Synapse Workspace remediation.

 

Prepared by the Alithya Data and Azure practice. Technical claims verified against Microsoft Learn as of June 2026.

References