Can You Actually Build a Production Fabric Platform with Private Links?

Microsoft Fabric Private Links route traffic to Fabric through a private connection rather than the public internet, with the option to block public access entirely at the tenant or workspace level. For organisations with explicit regulatory requirements for network isolation, they are the right architectural control.

The challenge is that the feature set, as of mid-2026, carries constraints that interact in non-obvious ways with the patterns common to enterprise Fabric platforms: on-premises data ingestion, multi-environment CI/CD promotion, metadata-driven ELT, and mixed-SKU capacity estates. Understanding those constraints before design commitments are made is the purpose of this post.

This is not an argument against Private Links. It is a map of the gap between what the feature can do today and what a full enterprise implementation typically needs — so that you can make an informed choice between accepting the current constraints, deferring Private Links until the feature matures, or adopting layered controls that work for your environment.

First: There Are Two Different Things Called "Private Links" in Fabric

Fabric has two distinct Private Link implementations:

Tenant-level locks down everything. Workspace-level gives you surgical, per-workspace control. The limitations are different for each — and some of them are significant enough to be outright dealbreakers depending on your architecture.

The Core Question: Can You Build a Solid Enterprise Platform on Fabric With Private Links?

Let me work through both scenarios honestly.

Tenant-Level Private Link: The On-Premises Data Problem

For most enterprise data platforms, data doesn't live entirely in Azure. There are on-premises source systems — ERPs, CRMs, operational databases — that need to feed into Fabric through On-Premises Data Gateways (OPDGs).

Enable tenant-level Private Links, and your OPDGs become officially unsupported. The current documentation is explicit: on-premises data gateways "aren't supported and fail to register when Private Link is enabled" — you cannot set up a new gateway while Private Link is on. An already-registered OPDG may continue to function for data ingestion if Block Public Internet Access is not enabled at the Fabric tenant level AND the gateway VM has outbound internet access permitted by the customer's own network controls — a separate dependency from Microsoft's platform setting. Microsoft provides no support for this configuration, and it fails entirely once internet is blocked.

Organisations that enable Private Links with the intent of blocking the public internet — the most common deployment goal — make OPDG ingestion a hard blocker. Deployments of Private Links without internet blocking (for data residency or attack surface reduction without full isolation) may preserve OPDG function, but that configuration is unsupported and should be treated as transitional. The guidance from Microsoft is to replace OPDGs with VNet Data Gateways, which do work with Private Links — but this is a meaningful infrastructure change, not a configuration tweak. An OPDG runs on-premises and makes an outbound internet connection to Fabric — all it needs is a VM and outbound internet access. A VNet Data Gateway runs inside an Azure VNet, which means on-premises systems must be reachable from Azure via ExpressRoute or Site-to-Site VPN. For organisations that chose OPDGs precisely because they had no Azure networking footprint, that connectivity doesn't exist yet. Establishing it involves Azure VNet design, network team engagement, and — in the case of ExpressRoute — commercial circuit provisioning that can take weeks or months. The gateway migration itself is the easy part; getting to a point where it's possible is the actual project.

Workspace-Level Private Link: Closer, But Still Missing Key Pieces

Workspace-level Private Links (GA October 2025) are more surgical and don't inherit the OPDG problem — they're documented as the co-existence model for organisations that need private connectivity without breaking gateway-based ingestion. But the feature gaps matter:

Fabric SQL Database is not supported. As of May 2026, workspace-level Private Links do not support Fabric SQL Database. This is a significant gap for metadata-driven ELT patterns where a SQL database acts as a control table or orchestration store — a common pattern in production Fabric platforms. Tenant-level Private Links do support SQL Database, but that brings you back to the OPDG problem above. (A roadmap item for SQL DB support in workspace PL was listed for early 2026 and has not shipped as of May 2026. Verify current status before treating future support as a given.)

Deployment Pipelines are not supported. If your workspace is assigned to a Deployment Pipeline — one of two primary promotion mechanisms in Fabric alongside Git integration — you cannot restrict inbound public access on that workspace. Restricting access is also blocked for any workspace that contains a workspace assigned to a pipeline. The status of Git integration-based workflows under workspace-level PL restriction is not confirmed in current documentation and should be verified before assuming it as an alternative path.

The Fabric portal is blocked for restricted workspaces. When a workspace blocks public inbound access, the Fabric portal shows "Access Restricted" for requests that don't originate from the workspace's associated private endpoint. Users who aren't on the private network (VPN, ExpressRoute) cannot access the workspace through the portal at all.

Important architectural constraint: workspace-level Private Links are a data plane inbound control. The Fabric administrative plane — Admin REST APIs, tenant settings, capacity management — remains accessible over the public internet and is governed separately by Fabric tenant settings and Entra ID permissions. Organisations that treat Private Links as a full administrative isolation boundary should document compensating controls for administrative access, as the feature does not provide it.

Capacity Metrics App support is undocumented. For tenant-level Private Links, the Capacity Metrics App is explicitly noted as not supporting Private Links. For workspace-level, the documentation is silent — no confirmation either way. In practice, this is a meaningful blind spot: without the Capacity Metrics App, capacity monitoring requires alternative tooling.

The Fabric portal requires tenant-level Private Links for private routing. Workspace-level PL covers API and data plane access to the workspace, but the Fabric portal application (app.fabric.microsoft.com) itself requires a tenant-level Private Link to be routed privately. Users on workspace-level PL without tenant-level PL can still reach the portal over the public internet — but cannot reach restricted workspace content from outside the private network.

What Most Organisations Actually Do: Conditional Access

In practice, the organisations I've seen evaluate this problem carefully tend to land on Conditional Access as their primary inbound control — not Private Links.

Conditional Access through Microsoft Entra ID provides:

• MFA enforcement for all Fabric access
• Device compliance requirements (Intune-enrolled, compliant OS, security patches)
• Network location restrictions — limit access to corporate IP ranges or named locations
• Risk-based access — block sign-ins flagged as high-risk

It doesn't provide network-level isolation — authenticated users still access Fabric over the public internet — but for many enterprise security frameworks it addresses the primary risk surface: identity, device compliance, and network location. And critically, it doesn't break anything.

One caveat worth flagging: Conditional Access is an identity and location control — it doesn't provide network isolation. If your organisation has a specific requirement for network-level isolation from a compliance or security standpoint, check with your security team before treating Conditional Access as sufficient. For most Fabric data platform workloads it's the right starting point, but it's worth having that conversation explicitly rather than assuming.

The key trade-off to understand with Conditional Access is scope: you cannot target Fabric alone. Policies must target all services in Microsoft's documented dependency list for Fabric (Power BI Service, Azure Data Explorer, Azure SQL Database, Azure Storage, Azure Cosmos DB), which can introduce complexity if your policies are already finely tuned per service. For non-interactive workloads consuming Fabric via Power Automate, Logic Apps, or custom application identities, validate that CA Named Location restrictions apply uniformly across those authentication paths — service principal flows can behave differently from user-interactive flows.

Paired with workspace-level IP Firewall rules, Conditional Access provides layered identity and network location controls that satisfy a broad range of enterprise security requirements. Verify coverage across direct OneLake storage access, XMLA endpoints, and SQL analytics endpoints — IP Firewall applicability varies by access path.

When Private Links Do Make Sense

Private Links aren't the wrong answer — they're the right answer for a narrower set of scenarios than the documentation might suggest:

• Pure cloud-to-cloud architectures with no on-premises dependencies and no OPDG reliance
• F SKU workspaces with straightforward workloads that don't need Deployment Pipelines or Fabric SQL Database
• Specific regulatory mandates that explicitly require network-level isolation rather than just identity-based controls
• Reporting/read-heavy workspaces where Power BI limitations are acceptable — for tenant-level PL these include no PDF export, no email subscriptions, and no Copilot. For workspace-level PL, Copilot support is not currently documented; verify before assuming availability.

If any of your enterprise patterns include on-premises ingestion via OPDG, metadata-driven ELT with a control database, Deployment Pipeline-based promotion, or multi-SKU capacity estates — evaluate the full limitations picture before committing.

The Full Limitations Comparison

For reference, the table below maps documented limitations across both Private Link types. "Not documented" means no official confirmation either way — do not assume support.

The limitations list above will get shorter over time — workspace-level Private Links only went GA in October 2025 and the feature is actively evolving. Several items on this list have roadmap entries; readers should verify current status before making architecture decisions based on assumed future support.

The limitations that are structural rather than temporary — the OPDG/tenant-PL incompatibility, the Deployment Pipeline restriction, the portal routing dependency on tenant-level PL — aren't going to disappear with a minor update. If your platform doesn't have a hard network isolation requirement, Conditional Access paired with workspace-level IP Firewall gives you strong controls without the current constraints. If network isolation is a firm requirement, the path forward is to design around the limitations: VNet Data Gateways in place of OPDGs, Git-based CI/CD in place of Deployment Pipelines, and a phased rollout starting from workspaces with no PL-incompatible dependencies.

The limitations list will change. Design principles should not.

If you've implemented Private Links successfully in a production enterprise environment — particularly with on-premises data sources or Deployment Pipelines — I'd genuinely like to hear how you approached it.

Sources: Microsoft Learn — Inbound access overview, Tenant-level Private Link (last updated May 4, 2026), Workspace-level Private Link overview, Workspace-level Private Link supported scenarios (last updated May 16, 2026), Conditional Access in Fabric, Custom live pools overview. Last verified May 2026.

Brad Coles is a Senior Consultant and Data Engineering Capability Lead at Synechron Australia, specialising in Microsoft Fabric and modern data platform engineering. Connect on LinkedIn.

Found this useful? ☕ Buy me a coffee — no ads, no paywalls, just sharing what I learn.