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

Microsoft Fabric Private Links look great on paper. Route all Fabric traffic over Microsoft's backbone, block the public internet, and check the "network isolated" box for your compliance team. In practice, almost no enterprise deployments I've come across have actually gone down this path — and the ones that evaluated it have generally landed on Conditional Access instead.

This post is an honest look at why. Not to dismiss Private Links — they have real use cases — but because the gap between what Private Links promise and what they currently deliver for a real enterprise workload is significant, and it's not obvious from the documentation until you've spent time mapping it out.

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 (the VM can still reach public Fabric endpoints outbound), but Microsoft provides no support for this configuration and it will fail entirely once internet is blocked.

In practice, most organisations enable Private Links precisely to block the public internet — which makes OPDG ingestion a hard blocker. 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.

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 Q1 2026 roadmap item was listed for SQL DB support in workspace PL; it has not shipped as of the time of writing.

Deployment Pipelines are not supported. If your workspace is assigned to a Deployment Pipeline — the standard mechanism for promoting content through DEV, UAT, and PROD environments — 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. For teams that rely on Deployment Pipelines for their CI/CD workflow, this is a direct conflict.

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. Note: admin APIs remain publicly accessible — it's the portal itself that's restricted, not the administrative plane.

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 still requires tenant-level Private Links for full access. This compounds the above — workspace-level PL covers API access to the workspace, but the Fabric portal (app.fabric.microsoft.com) itself requires a tenant-level Private Link to be accessible from a private-only network. If you're using workspace-level PL without tenant-level PL, your users still need public internet access to reach the portal.

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 the majority of enterprise security requirements, it covers the controls that actually matter. And critically, it doesn't break anything.

The key trade-off to understand with Conditional Access is scope: you cannot target Fabric alone. Policies must cover all five services Fabric depends on (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.

Paired with workspace-level IP Firewall rules for additional network control, Conditional Access gives most organisations a workable and maintainable security posture without the architectural constraints that come with Private Links.

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 (no PDF export, no email subscriptions, no Copilot) are acceptable

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. But right now, for most enterprise Fabric implementations, Conditional Access is doing the heavy lifting, and Private Links are being deferred until the feature gaps close.

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.