Microsoft Fabric Administration & Security - FAQs

Yes, external users can access Microsoft Fabric content securely, as long as it is set up deliberately. The usual route is Entra ID B2B, where a supplier, client or partner is invited as a guest user and signs in with their own organisation's account. You then give them access to specific workspaces or items like any internal user, and your conditional access and row-level security rules still apply. Tenant settings control whether guests are allowed at all and what they can do, so restrict them to named security groups. For sharing data, not reports, with another organisation that also uses Fabric, OneLake external data sharing lets them read selected data in place without you copying it to them. Whichever route you use, review guest access regularly, because external accounts are the ones most often forgotten. Our article on row-level security done right covers showing each external party only their own numbers.

Yes, most serious mid-market analytics implementations need Purview. The capability that Purview provides (sensitivity labels, classification, lineage tracking, access governance) is genuinely valuable and increasingly expected by stakeholders, auditors, and regulators. Smaller implementations can get by with less; once the data estate spans multiple sources and the user base is broader than a small team, governance discipline supported by tooling becomes important. The cost of Purview is reasonable; the cost of governance failure is much higher.

Yes. Orbit is multi-tenant by design, so a group with several Fabric capacities, or a partner looking after more than one client environment, sees everything from a single view rather than logging into each one in turn.

We go into this further in Microsoft Fabric policies explained: tenant and capacity rules, allow lists, and what to set up first.

Sensitivity labels and data loss prevention (DLP) work across Microsoft Fabric through Microsoft Purview. A sensitivity label such as Confidential can be applied to a lakehouse, semantic model or report, and it follows the data downstream. A report built on a confidential model inherits the label, and so does an Excel or PDF export. Labels can carry protection, so an exported file can only be opened by people in your organisation. DLP policies scan supported Fabric items for sensitive information, such as National Insurance or card numbers, and alert or restrict when it turns up in the wrong place. Labels only help if people apply them, so set default labels by workspace or domain and make labelling mandatory for the most sensitive areas. Licensing for some protection features depends on your Microsoft 365 plan. Our data governance glossary explains the terms, and our Data Governance FAQs go further.

You audit who accessed data in Microsoft Fabric through the audit log in Microsoft Purview, which records user and admin activity across Fabric: who viewed a report, exported data, changed permissions, shared an item or altered a tenant setting. Fabric also provides an admin monitoring workspace with ready-made reports on usage and activity across the tenant. For most organisations the gap isn't the data but the habit. Logs are kept for a limited period depending on licensing, so anything you may need to evidence later should be exported to your own storage on a schedule. Decide which events matter, such as exports of sensitive data or permission changes on finance workspaces, and review them routinely, not only after an incident. Our article on observability for Azure data engineering covers the engineering side, and our Analytics Acceleration Programme includes ongoing monitoring.

You control Copilot and AI features in Microsoft Fabric through tenant settings, capacity settings and per-item settings. At tenant level, an admin decides whether Copilot is available at all, which security groups can use it, and whether data can be processed outside your geography. At capacity level, Copilot usage draws on capacity, so you can limit which capacities support it. At item level, a setting on each semantic model controls whether it can be reached through AI. This is switched on by default for users with read access, so decide deliberately which models are exposed. Copilot respects existing permissions and row-level security, so it can't show users data they couldn't already see. That makes permissions hygiene the real control: if access is too broad today, AI will make that easier to notice and to exploit. Our page on Microsoft AI and Copilot and our article on MCP, AI agents and data governance go further.

You keep Microsoft Fabric data in the UK by controlling where your capacities are created, because data in Fabric is stored in the region of the capacity the workspace is assigned to. To keep data in the UK, create your Fabric capacities in a UK Azure region, such as UK South, and assign workspaces only to those capacities. Your tenant also has a home region, set when your Microsoft 365 tenant was created, which holds some metadata. Check it in the Fabric admin portal. Some features can process data outside your geography, most notably Copilot and other AI features, which are controlled by a separate tenant setting for cross-geography processing. Decide on that setting deliberately, not by default. If you operate in more than one country, Fabric supports capacities in several regions within one tenant, so data can sit where each part of the business needs it. Our article on AI, your data and UK data protection covers the data protection side of these decisions.

You restrict access to specific tables, rows and columns in Microsoft Fabric using OneLake security, the feature that controls access to the data itself, not just to the workspace it lives in. You define roles on a lakehouse that grant access to specific tables or folders, and you can restrict those roles further to certain rows and columns. The point is consistency. The same rules are meant to apply whichever engine reads the data: Spark notebooks, the SQL analytics endpoint or Power BI through Direct Lake. That avoids having to rebuild row-level security separately in every tool. Microsoft has been rolling OneLake security out in stages, with some engines and features still in preview, so check current coverage before you rely on it for sensitive data. Until it covers every route your users take, keep the security defined in the semantic model as well. Our article on row-level security done right explains the design principles, and our Microsoft Fabric page covers how we build them in.

You secure Microsoft Fabric with Entra ID and conditional access by treating identity as the front door: every user, service and automated job signs in through Entra ID, so the controls you set there apply to Fabric too. Require multi-factor authentication for everyone. Use conditional access policies to block sign-ins from unmanaged devices or unexpected countries where that suits your organisation. Manage access through Entra ID security groups instead of named individuals, so joiners and leavers are handled in one place. For the Fabric administrator role itself, use Privileged Identity Management so admin rights are requested when needed and expire afterwards, instead of being held permanently. These controls cost little and stop most of the account-based risks that matter for a mid-market estate. Our article on AI, your data and UK data protection covers the leadership side, and our Microsoft Fabric page covers how we set it up.

Workspace roles are the first layer of security in Microsoft Fabric. There are four. Admins control everything, including who else gets access. Members can add people and share content. Contributors can create and edit items but can't manage access. Viewers can read content but can't change it. Roles apply to everything in the workspace, so a workspace should hold content that the same group of people is meant to see. Below that, individual items such as a semantic model or lakehouse can be shared on their own, and OneLake security can restrict access to specific tables, rows and columns. The common mistake is giving everyone Member or Admin because it is quicker, which quietly lets anyone reshare data. Assign roles to Entra ID groups, not individuals, and keep Admin to two or three named people per workspace. Our article on workspace sprawl and the Fabric rollout that quietly goes wrong covers the structure that makes this manageable.

Decide a workspace taxonomy before building: a naming convention, dev/test/production separation, and domains grouping workspaces by business area. Restrict who can create workspaces to a small named group, and treat each production workspace as a deliberate act with an assigned owner rather than a self-service default. Structure is cheap to decide early and expensive to impose later.

For a deeper look, see our guide to Microsoft Fabric IQ: Sort Your Definitions First.

Compared with governance in Microsoft Fabric, Unity Catalog is Databricks' answer to data governance and is genuinely strong. Fabric uses Purview for the same role. Both work. Unity Catalog is more tightly integrated into Databricks itself. Purview integrates with the wider M365 estate. Which is better depends on whether your governance perimeter is the data platform or the wider Microsoft estate.

Fabric IQ gives data and AI agents a shared set of agreed business definitions to reason over, as Microsoft's capability in Fabric for exactly that. It matters because an agent can only answer well if the business has agreed what its terms and measures mean.

Governance works in Fabric through Microsoft Purview, integrated natively with Fabric, plus three governance layers we configure explicitly: access models, regional deployment, and security alignment. Sensitivity labels, data classification, lineage tracking, and access governance all run through Purview, and Fabric workloads inherit that configuration automatically. Access models are workspace-based: read, write, and admin roles are assigned per workspace, with row-level security layered on top for report-level restriction. Regional deployment matters because a Fabric capacity is pinned to an Azure region at creation and cannot be moved later, so data residency and region are agreed before provisioning, not after. Security alignment covers tenant-level settings (external sharing, guest access, capacity admin roles) plus Entra ID conditional access, agreed with your IT and security team before go-live. The integration is meaningful: previous Microsoft data platforms required separate governance configuration for each component, and the discipline often slipped. Fabric centralises it. Purview setup, access model design, and regional and security sign-off are all part of the Establish phase in our standard implementation, not an afterthought.

Network security in Microsoft Fabric works at three levels. Private links let you restrict access to Fabric so that it is only reachable from your own network, either for the whole tenant or for individual workspaces. Managed private endpoints let Fabric connect securely to data sources that sit behind a firewall, such as an Azure SQL database or storage account, without opening them to the internet. Trusted workspace access lets specific workspaces reach firewall-protected storage using their workspace identity. Newer controls, such as outbound access protection, limit where a workspace is allowed to send data. Not every organisation needs all of this. Tenant-wide private links in particular can restrict some features and add cost, so they suit regulated or high-sensitivity estates more than a typical mid-market one. Decide based on what the data is and who would care if it leaked. Our data platform and warehouse page covers how we design these choices into a build.

Security on a Fabric warehouse snapshot is inherited live from the source warehouse. GRANT, DENY, REVOKE and UNMASK changes apply immediately regardless of the snapshot timestamp, so a user whose access is removed from the parent warehouse loses access to the snapshot at the same time.

A mid-market business needs a small, deliberate set of Fabric governance settings rather than everything the platform offers: tenant and capacity policies, a workspace structure that stops sprawl, sensitivity label coverage on the items that matter, and a monthly look at the OneLake catalog Govern area. Policies in Fabric and OneLake access audit, both announced at FabCon Europe 2026, make this easier. Our post on Microsoft Fabric policies explained lists what to set up first.

Dev, test and production workspaces should be separated for security in Microsoft Fabric by putting each stage in its own workspace, with different people allowed to change each one. Developers work freely in development. Test is where changes are checked against realistic data. Production is changed only through a controlled release, using deployment pipelines or Git integration, never by someone editing live content directly. Keep production access tight: most people should be Viewers, and only a small group, or an automated deployment identity, should be able to publish. If development uses real customer or personal data, it needs the same protection as production, so many organisations use masked or reduced data there instead. Separating the stages also lets you give development a smaller, cheaper capacity. Our articles on why Power BI changes need a release process and deploying only what changed cover the mechanics.

Service principals and workspace identity should be used for anything automated in Microsoft Fabric, so that pipelines, refreshes and deployments don't depend on a person's account. A service principal is an application identity in Entra ID that scripts and deployment tools can sign in with. A workspace identity is an identity tied to a Fabric workspace, which lets that workspace connect to protected data sources without storing passwords. The security benefit is twofold. Jobs don't break when someone leaves or changes their password, and access can be scoped tightly to what each job needs. The common failure is the reverse: production refreshes running under a former employee's account, or a shared admin login known to half the team. Keep secrets in Azure Key Vault and review which identities have access each quarter. Our article on why Power BI changes need a release process covers the deployment side.

Yes. Data in Microsoft Fabric is encrypted at rest and in transit by default, using keys that Microsoft manages, with no setup needed. For organisations that must control their own encryption keys, typically for regulatory or contractual reasons, Microsoft has been extending customer-managed key support to Fabric workspaces, using keys held in your own Azure Key Vault. With customer-managed keys, revoking the key makes the data unreadable, which gives you a hard off switch. The trade-off is operational: losing or mismanaging the key can lock you out of your own data, and some features may not yet support it. For most mid-market organisations, Microsoft-managed encryption combined with strong identity controls is appropriate. Customer-managed keys are worth it where a regulator, client contract or internal policy specifically requires them. Our article on AI, your data and UK data protection covers the wider compliance picture.

Domains in Microsoft Fabric are a way to group workspaces by business area, such as Finance, Sales or Operations, so that governance can be managed by the people who own the data. Each domain can have its own domain admins and contributors, which lets a business area manage its own workspaces within rules set centrally. Domains also make data easier to find in the OneLake catalog, and some settings, such as default sensitivity labels, can be applied per domain. For a mid-market organisation, domains are useful once you have more than a handful of workspaces or more than one team publishing data. They give a clear answer to who owns this, which is the question most governance problems come back to. Our lightweight data governance framework explains ownership in plain terms, and the Fabric rollout article shows what happens without it.

Microsoft Purview is Microsoft's data governance platform, covering sensitivity labels, data classification, lineage, glossary, and access governance. Purview integrates with Fabric, Azure data services, and Microsoft 365 to provide consistent governance across the data estate. For mid-market businesses building serious analytical platforms, Purview is the standard governance layer. The Data Governance FAQ in our library covers the governance methodology; Purview is the toolset that supports it.

Outbound access protection in Microsoft Fabric is a workspace-level security setting that controls where data in that workspace can be sent. When it is switched on, notebooks, pipelines and other items in the workspace can only connect to destinations you have approved, such as specific data sources reached through managed private endpoints. Everything else is blocked. It is designed to stop data leaving the organisation, whether through a mistake, a badly written notebook or a compromised account, without relying on every developer getting it right. It is most useful in workspaces that hold sensitive data, such as HR, finance or customer personal data. Because it blocks anything not on the approved list, turn it on deliberately and test that legitimate connections still work before you rely on it. Our article on governance in practice before AI touches your data explains why controls like this matter more as AI tools gain access to data.

The Microsoft Fabric tenant settings an admin should review first for security are the ones that control who can create things and where data can go. Start with who can create Fabric items, because the default allows everyone and that is how workspace sprawl begins. Then review export settings (to Excel, CSV and other formats), external sharing and guest access, publish to web, and whether service principals can use Fabric APIs. Check the Copilot and AI settings, including whether data can be processed outside your geography. Most settings can be applied to specific security groups instead of the whole organisation, which is almost always the better choice. Tenant settings change as Microsoft adds features, and new ones are often switched on by default, so a quarterly review is worth scheduling. Our lightweight data governance framework shows where this fits, and our free audit includes a tenant settings check.

A Microsoft Fabric administrator should be one of a small number of named, trusted people, usually two or three, and admin roles should be split so each person holds only the access they need, because the Fabric admin role controls tenant settings for the whole organisation. It is granted through Entra ID, and Global Administrators and Power Platform Administrators also hold it. Capacity admins are a separate, narrower role. They manage a specific capacity: which workspaces are assigned to it, its size, and its notifications and settings. They can't change tenant-wide security. Workspace admins sit below that and control access to their own workspace. Mixing these up is a common governance gap, for example giving someone Global Administrator just so they can resize a capacity. Use the narrowest role that does the job, and use Privileged Identity Management so admin rights are time-limited. Our Microsoft Fabric page covers how we set up administration, and our Analytics Acceleration Programme can run it for you.