IT Admin Security Engineer Data Architect — This page provides a comprehensive, layered security guide for Microsoft Fabric: from identity and workspace access to data-level controls, OneLake security, information protection, and monitoring.
Defense-in-Depth Security Model
Microsoft Fabric implements a layered security approach — every layer adds protection so that no single breach compromises your entire estate. Click any layer to jump to its section.
Security and monitoring go hand in hand. For audit log pipelines, alert patterns, capacity monitoring, and Azure Monitor integration, see the dedicated Monitoring & Observability page.
Defense-in-depth means no single layer is sufficient on its own. Even if an attacker bypasses identity controls, workspace isolation, data-level security, and network restrictions each provide additional barriers. Implement all layers for a robust security posture.
Identity & Access Management
Microsoft Entra ID is the single identity provider for all Fabric access — every request is authenticated before it reaches any resource.
🔑 Microsoft Entra ID
All Fabric authentication goes through Entra ID. Users sign in with organizational accounts, and every API call requires a valid Entra token.
- Single Sign-On (SSO) — seamless access across Fabric, Power BI, and Microsoft 365
- Multi-Factor Authentication (MFA) — enforce MFA for all users, especially admins
- Entra ID Groups — assign workspace roles and security policies to groups, not individuals
🚦 Conditional Access
Use Entra ID Conditional Access policies to control how and from where users access Fabric.
- Location-based — restrict to trusted networks or named locations
- Device compliance — require Intune-compliant or domain-joined devices
- Session controls — enforce sign-in frequency, block persistent sessions
- Risk-based — step-up MFA for risky sign-ins detected by Entra ID Protection
🤖 Service Principals
Use service principals for automation and CI/CD pipelines instead of user accounts.
- Enable "Service principals can use Fabric APIs" in admin portal
- Assign to security groups for scoped access
- Use certificates over secrets — shorter rotation, no password leaks
- Apply Conditional Access policies to restrict where they operate
🔗 Managed Identities
Managed identities enable credential-free authentication from Fabric to Azure resources.
- System-assigned — lifecycle tied to the Fabric resource
- User-assigned — reusable across multiple resources
- Use for connecting to ADLS, Key Vault, SQL without storing credentials
Workspace Identity
Each Fabric workspace can have an automatically managed workspace identity — an Entra ID service principal tied to the workspace lifecycle. It enables credential-free, secure access from Fabric items to external Azure resources without managing secrets or certificates.
🪪 What It Is
- A managed Entra ID service principal automatically created for the workspace
- Authenticates the workspace (not a user) when accessing external resources
- Credentials managed entirely by Fabric — no secrets or certificates to rotate
- Automatically deleted when the workspace is removed
- Registered in the tenant's Entra ID as an app registration you can assign RBAC roles to
⚙️ How to Enable
- Open workspace Settings → Identity
- Toggle "Workspace identity" to On
- Copy the generated Application (client) ID and Object ID
- On the target Azure resource (e.g., ADLS Gen2), assign RBAC roles using the identity's Object ID
- Configure Fabric items to use "Workspace Identity" as the authentication method
Supported Scenarios
| Fabric Item | Scenario | Notes |
|---|---|---|
| OneLake Shortcuts | Connect to ADLS Gen2 (including firewalled accounts) | Most common use case; supports resource instance rules |
| Data Pipelines | Copy data to/from protected storage accounts | Supports both Copy Activity and Dataflow sources |
| Copy Jobs | Ingest data from firewalled ADLS into Lakehouse | Uses workspace identity for authentication |
| Dataflows Gen2 | Transform data from secured external sources | Available in workspace identity–enabled connectors |
| T-SQL COPY INTO | Bulk load into Fabric Warehouse from firewalled storage | Specify CREDENTIAL = 'WorkspaceIdentity' |
| Semantic Models | Import mode from ADLS behind firewalls | Added in 2025; supports trusted workspace access |
| Spark Notebooks | Read/write to ADLS using workspace identity token | Use mssparkutils.credentials.getToken() |
Trusted Workspace Access
Trusted workspace access allows Fabric to securely connect to firewall-enabled or private-endpoint–only Azure storage accounts — without opening public network access.
🔒 How It Works
- Storage account has public access disabled (firewall-only)
- Add a resource instance rule on the storage account that trusts the specific Fabric workspace
- Workspace identity authenticates with Entra ID and presents the workspace's identity token
- Azure Storage validates the token against the resource instance rule and grants access
No VNet, private endpoint, or IP whitelisting required from the Fabric side.
🛡️ Configuration Steps
- Enable workspace identity (see above)
- On the storage account → Networking → Resource instance rules
- Add rule: Resource type =
Microsoft.Fabric/workspaces - Specify the workspace's ARM resource ID
- Assign RBAC (e.g.,
Storage Blob Data Contributor) to the workspace identity's Object ID - In Fabric, configure the connection with "Workspace Identity" auth
OnCopy & OnWrite Access Patterns
📥 OnCopy (Read from firewalled storage)
- Fabric reads data from ADLS behind a firewall during copy/ingest operations
- Requires
Storage Blob Data Readerrole on the workspace identity - Used by: Shortcuts, Copy Activity, T-SQL COPY INTO, Dataflows Gen2
- Data is copied into OneLake — subsequent reads don't hit the external source
📤 OnWrite (Write back to firewalled storage)
- Fabric writes results or exports data back to protected ADLS accounts
- Requires
Storage Blob Data Contributorrole on the workspace identity - Used by: Data Pipelines (sink), Spark notebooks, Warehouse CETAS
- Supports incremental write patterns for ETL/ELT pipelines
Limitations & Known Issues
- F SKU only — workspace identity is not available on Trial, Premium Per User (PPU), or P SKU capacities
- No personal workspaces — "My Workspace" cannot have a workspace identity
- One identity per workspace — you cannot create multiple identities for a single workspace
- Identity name = workspace name — the identity's display name always matches the workspace name and cannot be customized
- Admin role required — only workspace Admins can enable/manage the identity
- RBAC propagation delay — after assigning roles, allow up to 5 minutes for changes to take effect
- No cross-tenant support — workspace identity can only access resources in the same Entra ID tenant
- Do NOT modify the app registration — deleting or renaming the Entra ID service principal/app registration behind the identity will break Fabric functionality (adding API permissions is safe)
- Implicit trust within workspace — anyone with a workspace role (Member, Contributor) can assume the identity for supported operations; follow least-privilege workspace role assignments
- Connector coverage is evolving — not all Fabric connectors support workspace identity authentication yet; check the latest docs for your specific data source
- Contributor role removed (July 2025) — workspace identity no longer gets automatic Contributor access; admins must explicitly assign roles on target resources
- Don't use personal user accounts for scheduled refreshes, pipelines, or automated processes — if that user leaves, all dependent workloads break
- Don't forget to add the resource instance rule on the storage account — RBAC alone won't bypass the firewall
- Don't confuse workspace identity with managed identity for Azure resources — workspace identity is Fabric-specific
Workspace Security
Workspaces are the primary security boundary in Fabric — they determine who can access, create, and manage artifacts.
Built-in Workspace Roles
| Role | Permissions | Typical Assignment | OneLake Access |
|---|---|---|---|
| Admin | Full control: manage access, delete workspace, configure settings | Workspace owners, IT admins | Full |
| Member | Create, edit, delete artifacts; publish reports; share items | Data engineers, developers | Full |
| Contributor | Create and edit artifacts, but cannot share or manage access | Analysts, junior developers | Full |
| Viewer | View and interact with artifacts (read-only) | Business users, stakeholders | Restricted by data access roles |
Admin, Member, and Contributor roles have full read/write access to all OneLake data in the workspace. Only the Viewer role is restricted by OneLake data access roles. Design your workspace access carefully — don't give Member/Contributor access to users who should only see a subset of data.
Workspace Isolation Patterns
🏗️ Environment Separation
Separate workspaces for Dev → Test → Prod. Each environment has its own access list, ensuring developers can't accidentally modify production data.
🏢 Domain Boundaries
Organize workspaces into Fabric Domains (Finance, Marketing, HR). Domain owners control governance policies for all workspaces in their domain.
🔒 Sensitivity Tiers
Create separate workspaces for sensitive vs. non-sensitive data. Apply stricter Conditional Access and audit policies to high-sensitivity workspaces.
⚡ Capacity Isolation
Assign critical workspaces to dedicated capacities. This provides resource isolation and ensures one team's heavy workloads don't impact another's.
Use Entra ID security groups for role assignments instead of individual users. This makes access auditable, scalable, and easy to update when team members change.
Item-Level Permissions
Beyond workspace roles, you can grant granular permissions on individual items — reports, semantic models, warehouses, and more.
Permission Types
| Permission | What It Allows | How It's Granted |
|---|---|---|
| Read | View and interact with the item | Sharing dialog, app audience, direct link |
| ReadAll | Access the underlying data in OneLake (files and folders) | Item permissions panel |
| ReadData | Query data via SQL analytics endpoint | Item permissions panel |
| Write | Edit the item (notebooks, reports, pipelines) | Workspace role (Contributor+) or item-level grant |
| Reshare | Share the item with other users | Sharing dialog option "Allow recipients to share" |
| Execute | Run pipelines or notebooks | Item permissions panel |
Sharing & Distribution
📤 Direct Sharing
Share individual items with specific users or groups. Choose whether recipients can reshare or build on the data. Use sparingly — it creates hard-to-audit one-off permissions.
📱 Fabric Apps
Package reports and dashboards into an app with defined audiences. Apps provide a curated, read-only experience — the recommended way to distribute content to business users.
🏷️ Endorsement Signals
- Promoted — workspace members mark items as reliable and ready for use
- Certified — designated reviewers certify items meet governance standards
Endorsed items appear with badges in search, making trusted data easy to find.
If you find yourself sharing dozens of items individually, you probably need to redesign your workspace structure. Prefer workspace roles + apps over per-item sharing. Run the access review in Admin Portal quarterly to clean up stale permissions.
Data-Level Security
Control exactly which rows, columns, and objects each user can see — even when they have access to the item itself.
Row-Level Security (RLS)
RLS filters data at query time so users only see rows they're authorized to access. Available in Power BI semantic models and Fabric Warehouse.
-- Create a security predicate function CREATE FUNCTION dbo.fn_security_predicate(@Region AS nvarchar(50)) RETURNS TABLE WITH SCHEMABINDING AS RETURN SELECT 1 AS result WHERE @Region = USER_NAME() OR USER_NAME() = 'admin@contoso.com'; -- Apply security policy to a table CREATE SECURITY POLICY RegionFilter ADD FILTER PREDICATE dbo.fn_security_predicate(Region) ON dbo.SalesData WITH (STATE = ON);
Define roles and DAX filter expressions in Power BI Desktop. Test with "View as role" before publishing. RLS is enforced in the Power BI service, apps, and embedded scenarios — but not when querying the underlying lakehouse directly.
Column-Level Security (CLS)
CLS restricts access to specific columns using standard SQL GRANT and DENY statements in Fabric Warehouse.
-- Deny access to salary column for a specific role DENY SELECT ON dbo.Employees(Salary, SSN) TO [LimitedAccess]; -- Grant access to only specific columns GRANT SELECT ON dbo.Employees(EmployeeId, Name, Department) TO [LimitedAccess];
Object-Level Security (OLS)
OLS hides entire tables or columns from specific users in Power BI semantic models. Unlike CLS which returns an error, OLS makes the object completely invisible — users don't even see it in field lists.
- Configure OLS in Tabular Editor or XMLA endpoint
- Define roles with
Nonepermission on specific tables or columns - Users in that role won't see the objects in reports, DAX queries, or metadata
Dynamic Data Masking (DDM)
DDM masks sensitive data in query results without changing the stored data. Non-privileged users see masked values; privileged users see the original. Available in both Fabric Warehouse and Lakehouse SQL analytics endpoint.
-- Mask email column with partial masking ALTER TABLE dbo.Customers ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()'); -- Mask phone with custom partial mask (show last 4 digits) ALTER TABLE dbo.Customers ALTER COLUMN Phone ADD MASKED WITH (FUNCTION = 'partial(0,"XXX-XXX-",4)'); -- Full mask on SSN (returns "xxxx") ALTER TABLE dbo.Customers ALTER COLUMN SSN ADD MASKED WITH (FUNCTION = 'default()'); -- Grant UNMASK to privileged roles GRANT UNMASK ON dbo.Customers TO [PrivilegedAnalysts];
DDM, RLS, CLS, and OLS are complementary, not alternatives. A robust setup uses RLS to filter rows, CLS to restrict columns, DDM to mask remaining sensitive values, and OLS to hide objects from Power BI users who shouldn't see them at all.
Data Security Decision Matrix
| Requirement | Mechanism | Where | Hides Metadata? |
|---|---|---|---|
| Users see only their own rows | RLS | Warehouse, Semantic Model | No |
| Hide specific columns from a role | CLS | Warehouse | No (error on access) |
| Hide tables/columns from field lists | OLS | Semantic Model (Tabular Editor) | Yes |
| Show masked values (e.g., XXX-XX-1234) | DDM | Warehouse, Lakehouse SQL Endpoint | No (shows masked) |
| Restrict access to lakehouse folders | OneLake RBAC | OneLake | Yes |
OneLake Security
Fine-grained access control at the storage layer — restrict users to specific folders and tables within a lakehouse.
OneLake data access roles provide folder-level and table-level RBAC directly in OneLake. Security is enforced at the storage layer across all compute engines — including Spark, SQL endpoint, and Power BI Direct Lake. This feature is now generally available (GA) as of early 2026, with unified enforcement across the Fabric platform.
How OneLake Data Access Roles Work
📂 Define Roles
Create custom security roles in the lakehouse security panel. Each role specifies which folders and tables it grants access to.
- Navigate to Lakehouse → Manage OneLake security
- Create a new role (e.g., "Sales Analysts")
- Browse and select specific folders or tables to include
👥 Assign Users
Add Entra ID users or security groups to each role. Users can belong to multiple roles — access is additive (union of all role permissions).
- Assign via the security panel UI or REST APIs
- Use Entra ID groups for scalable management
- Changes take effect within minutes
🔒 Enforcement
Access is enforced at the OneLake storage plane for supported items and engines.
- Spark notebooks respect folder restrictions
- SQL analytics endpoint respects table restrictions
- Power BI Direct Lake respects the same boundaries
- OneLake file explorer and APIs also enforce roles
OneLake RBAC Architecture
Key Limitations & Considerations
| Consideration | Details |
|---|---|
| Applies to Viewer role only | Workspace Admin, Member, and Contributor roles bypass OneLake RBAC — they always have full data access |
| F SKU required | OneLake data access roles require Fabric capacity (F SKU) or Power BI Premium (P SKU) |
| Additive permissions | If a user belongs to multiple roles, they get the union of all permissions (most permissive wins) |
| No deny rules | You can't explicitly deny access — only grant. Structure roles carefully to avoid over-permissioning |
Combine OneLake RBAC with medallion architecture: restrict the Raw/Bronze layer to data engineers, Silver to analysts with domain-specific roles, and Gold to all business users. This aligns data maturity with access control naturally.
Information Protection
Classify, label, and protect data throughout its lifecycle with Microsoft Purview and Data Loss Prevention policies.
Sensitivity Labels
Microsoft Purview sensitivity labels (e.g., "Public," "Internal," "Confidential," "Highly Confidential") can be applied to Fabric artifacts to classify and protect data.
🏷️ How Labels Work
- Applied to lakehouses, warehouses, semantic models, reports, and more
- Labels flow downstream automatically — a labeled lakehouse passes its label to reports built on it
- Labels can enforce encryption on exported files (Excel, PDF, PowerPoint)
- Labels are visible in workspace lists, search results, and lineage views
⚙️ Configuration
- Define labels in the Microsoft Purview compliance portal
- Set auto-labeling policies to automatically apply labels based on content patterns (e.g., credit card numbers, SSNs)
- Enable mandatory labeling in Fabric admin portal — fully enforced for Power BI items, with expanding support for other Fabric items
- Control who can apply or change specific labels with label scoping
Data Loss Prevention (DLP)
DLP policies detect and protect sensitive data in Fabric, preventing accidental exposure or exfiltration.
- Real-time scanning — automatically detects sensitive data leaving OneLake or being shared externally
- Policy tips — show inline warnings when users interact with sensitive data
- Block actions — prevent sharing, export, or download of highly sensitive items
- Alert admins — send notifications when DLP rules are triggered
- DLP is AI-aware — policies apply to Copilot interactions and AI-generated content
- ML-based detection — automatic identification of sensitive content patterns beyond regex rules
Encryption & Key Management
🔐 Encryption at Rest
All data stored in OneLake is encrypted at rest using Microsoft-managed keys by default. For regulated workloads, enable customer-managed keys (CMK) to retain control of your encryption keys via Azure Key Vault.
🔒 Encryption in Transit
All communications use TLS 1.2+ encryption. This applies to user-to-Fabric, Fabric-to-data-source, and inter-service traffic within the platform.
Copilot & AI Data Boundaries
Fabric Copilot respects all existing security controls: sensitivity labels, RLS, CLS, workspace roles, and DLP policies. Copilot only surfaces data the current user is authorized to see. Additionally:
- Tenant isolation — Copilot never accesses data from other tenants
- Data boundaries — data stays within your geographic region for AI processing
- Purview DSPM for AI — monitor AI prompts, responses, and flag risky behavior with full audit trail
- Copilot audit logging — all Copilot queries and data access events are captured in the unified audit log for compliance review
- Labeled data protection — Copilot won't surface content from "Highly Confidential" items to unauthorized users
Audit your permissions and labeling strategy before rolling out Copilot. Over-permissioned content is the #1 source of AI data security incidents. Ensure sensitivity labels are applied, DLP policies are active, and workspace access is properly scoped.
Network Security
Control network traffic to, from, and within Fabric using private connectivity, managed networks, and zero-trust architecture.
🔒 Inbound — Users to Fabric
- Azure Private Link — route all traffic through private endpoints in your VNet
- Conditional Access — enforce device compliance, location, MFA
- Tenant restrictions — prevent data exfiltration to unauthorized tenants
🔗 Outbound — Fabric to Data
- Managed Private Endpoints (MPE) — Fabric connects to resources through Azure backbone
- VNet Data Gateways — bridge to on-premises or VNet-isolated resources
- Trusted Workspace Access — firewalled storage trusts specific Fabric workspaces
🛡️ Internal — Between Services
- Managed VNets — Spark runs in Fabric-managed VNets with controlled egress
- Service tags — NSG rules using
DataFactoryandPowerBItags - Encryption in transit — TLS 1.2+ for all communications
Network Decision Quick Reference
| Scenario | Approach | SKU Min |
|---|---|---|
| Corporate-only access to Fabric | Private Link + block public | F64 |
| Spark reads from firewalled ADLS | Managed Private Endpoints | F64 |
| OneLake shortcuts to firewalled storage | Trusted Workspace Access | F2 |
| On-premises SQL connectivity | VNet Data Gateway | F2 |
| Full zero-trust posture | Private Link + MPE + Managed VNet + CA | F64 |
For detailed architecture diagrams, step-by-step Private Link setup, DNS configuration, managed VNet guidance, and a full networking decision matrix, see the dedicated Networking Security → page.
📚 Learn More
Fabric Security Overview ↗ Private Links ↗📎 See Also
Networking Security (Full Guide) →Monitoring & Audit
Continuous monitoring, audit trails, and threat detection to ensure your security controls are working and to investigate incidents.
📋 Unified Audit Logs
Fabric logs all user and admin activities to the Microsoft 365 Unified Audit Log.
- Track who accessed, modified, shared, or deleted artifacts
- Export data, report views, refresh operations, and admin settings changes
- Query logs via the Purview compliance portal or PowerShell
- Retain logs per your Microsoft 365 retention policies
🛡️ Microsoft Defender for Cloud Apps
MDCA provides real-time threat detection and policy enforcement for Fabric.
- Anomaly detection — flag unusual download patterns, mass data exports, or suspicious sign-ins
- Session controls — proxy user sessions to enforce real-time DLP during access
- Activity policies — alert on specific high-risk actions (e.g., sharing to external users)
- Integrates with Microsoft Sentinel for SIEM correlation
📊 Admin Portal Monitoring
The Fabric Admin Portal provides built-in monitoring dashboards.
- Usage metrics — who's accessing what, how often
- Capacity metrics — monitor throttling, CU consumption, and performance
- Audit settings — manage what gets logged and who receives alerts
- Tenant settings — review and restrict feature toggles across the organization
🔍 Fabric Monitoring Workspace
Fabric's built-in monitoring workspace collects operational metrics into an Eventhouse.
- Query logs with KQL for deep analysis
- Build custom dashboards for pipeline runs, Spark jobs, refresh status
- Set up Activator alerts for real-time notifications on anomalies
- Correlate operational data with security events
- Forward Fabric audit logs to Microsoft Sentinel for centralized security monitoring and automated incident response
- Enable MDCA policies — at minimum: unusual data download, risky sign-in, mass sharing detection
- Review admin portal weekly — check tenant settings, new workspace creation, and external sharing activity
- Automate alerts — use Activator or Logic Apps to notify security teams of critical events
Putting It All Together
See how all 8 security layers work together in a real scenario — a multinational company deploying Fabric for regional sales analytics.
Contoso Corp has three sales regions — EMEA, Americas, and APAC. Regional analysts should only see their own region's data. A central analytics team needs full access. Customer PII (emails, phone numbers) must be masked for most users. The platform ingests data from an on-premises SQL Server via a gateway and must meet enterprise compliance requirements.
SG-Sales-EMEA, SG-Sales-Americas, SG-Sales-APAC, and SG-Analytics-Central.
Apply a Conditional Access policy requiring MFA for all Fabric access and blocking sign-ins from non-compliant devices.
Create a service principal SP-Sales-ETL for automated data pipelines — no interactive user required.
Sales-Dev and Sales-Prod. The central analytics team gets Contributor on both.
Regional groups get Viewer on Prod only — they never see Dev. The ETL service principal gets Contributor on Prod for automated loads.
Both workspaces are assigned to the "Sales" domain for governance and to a dedicated F64 capacity to prevent noisy-neighbor issues.
ReadData permission to the data science team for ad-hoc SQL queries, without granting workspace access.
All production semantic models carry the "Certified" endorsement badge.
[Region] = USERPRINCIPALNAME() mapped via a security table, so EMEA analysts see only EMEA rows.Column-Level Security: The
ProfitMargin column is restricted — only SG-Analytics-Central can see it.Dynamic Data Masking:
CustomerEmail shows as jXXX@XXX.com for regional analysts; the central team sees full values.
/raw/ folder (landing zone with unmasked PII) is restricted to SP-Sales-ETL only.
The /curated/ folder is accessible to all analyst groups (with RLS still enforced at the query layer).
This ensures even users with SQL endpoint access or Spark notebooks cannot read raw files directly.
No single layer is sufficient on its own. An EMEA analyst in this scenario is protected by: identity (MFA + group membership) → workspace (Viewer role, Prod only) → item (app audience) → data (RLS filters EMEA rows, CLS hides margins, DDM masks email) → OneLake (no raw folder access) → labels (export restrictions) → network (private connectivity) → monitoring (anomaly alerts). Compromise of any one layer still leaves 7 others enforcing protection.
Quick Reference
| Layer | Contoso Config | Protects Against |
|---|---|---|
| Identity | Entra groups, CA + MFA, SPN for ETL | Unauthorized access, credential theft |
| Workspace | Dev/Prod split, Viewer for regions | Accidental edits, environment leakage |
| Item Permissions | App audiences, ReadData sharing | Over-sharing, uncontrolled discovery |
| Data Security | RLS by region, CLS on margins, DDM on email | Cross-region data leakage, PII exposure |
| OneLake | /raw/ ETL-only, /curated/ for analysts | Direct file access bypassing query-layer controls |
| Info Protection | Confidential label, DLP export block | Data exfiltration, unmanaged device risk |
| Network | Private Link, managed VNet, trusted access | Man-in-the-middle, public internet exposure |
| Monitoring | Log Analytics, Defender alerts, Purview scans | Undetected breaches, compliance drift |
Security Hardening Checklist
Track your Fabric security posture across all layers. Progress is saved in your browser.