Microsoft Fabric Customer-Managed Keys Without Analytics Outages

Executive summary

Microsoft Fabric already encrypts data at rest with Microsoft-managed keys. Workspace-level customer-managed keys (CMK) add a second control: the enterprise owns the key-encryption key in Azure Key Vault or Managed HSM and can control its rotation, access, and revocation. That is valuable when a policy, regulator, or customer contract requires the organization to control encryption keys. It is not a blanket upgrade for every workspace.

The hard enterprise problem is implementing that control without creating a new availability risk. A Fabric workspace cannot enable CMK if it contains unsupported items, and a CMK-enabled workspace can create only supported items. Some transient data and metadata remain outside workspace CMK protection. Power BI semantic models use a separate, capacity-level bring-your-own-key (BYOK) mechanism. A revoked workspace key causes reads and writes to fail within 60 minutes, and key rotation has a documented propagation window. These boundaries turn a seemingly simple encryption setting into an architecture, identity, operations, and continuity decision.

The right approach is to define an encryption policy by data class, separate compatible workloads into deliberate workspace zones, govern workspace CMK and Power BI BYOK as related but distinct controls, automate inventory and status evidence, and test rotation, revocation, and recovery before production. The objective is not "CMK everywhere." It is demonstrable coverage for the data that requires customer-controlled encryption, with explicit exceptions and a recovery path that the business can trust.

The enterprise problem: key control can become an outage control

For many regulated organizations, encryption at rest is only part of the requirement. The security team may also need to prove that the organization controls the key, can rotate it, can audit its use, and can withdraw service access. Workspace CMK in Fabric addresses that need through envelope encryption: Fabric data remains encrypted by a Microsoft-managed data-encryption key, while the enterprise's key-encryption key in Azure Key Vault wraps that data key. The customer key does not leave Key Vault. Microsoft's workspace CMK documentation explains this model and its operational boundaries.

The control is powerful because revocation is consequential. Microsoft states that revoking the key causes read and write calls to the encrypted workspace to fail within 60 minutes. That is useful for an exit or security response, but the same mechanism can interrupt pipelines, notebooks, warehouses, APIs, and downstream reporting if a key is disabled accidentally, an access assignment is removed, or a rotation is mishandled.

The central leadership question is therefore:

How can we meet customer-controlled encryption requirements in Fabric while keeping analytics available, proving the scope of protection, and avoiding an operational dependency that no team owns end to end?

This matters now because Microsoft's current Fabric guidance supports workspace CMK across all paid F SKUs, while trial capacities are excluded. The feature also exposes portal and REST API operations for assignment, inspection, and reset. That makes systematic enterprise adoption possible, but only after the organization resolves workspace compatibility, Power BI coverage, ownership, and recovery.

Representative enterprise scenario

The following is a representative scenario, not a YuniQ customer case or a claim of achieved results.

A financial-services group is moving customer, transaction, service, and risk analytics into Fabric. Its policy requires customer-controlled encryption for regulated data at rest. The initial proposal is to enable one key on every production workspace.

An inventory reveals four complications:

1. Engineering workspaces contain lakehouses, notebooks, pipelines, warehouses, and Power BI content together.
2. Two workspaces use Mirrored Dataverse, which Microsoft lists as incompatible with workspace CMK.
3. The security team assumes the workspace key also protects Power BI semantic models, but Power BI uses capacity-level BYOK for that purpose.
4. The Key Vault team rotates keys independently from the Fabric operations team and has no Fabric-specific validation or recovery runbook.

Enabling CMK directly would either fail because of unsupported items or force a hurried workspace reorganization. Even if activation succeeded, the enterprise could still overstate its coverage and later turn a routine key operation into a reporting outage.

The solution is to make encryption an explicit platform contract before switching it on.

Root causes and business consequences

Encryption requirements are expressed too broadly

"Use customer-managed keys" does not identify which data, processing stage, workspace, item, or residual store must be covered. It also does not define whether customer key control is mandatory, preferred, or unnecessary for each data class. Without that translation, teams either apply CMK indiscriminately or leave material gaps.

The business consequence is weak assurance. Auditors receive screenshots rather than a repeatable inventory that links classified data to workspaces, keys, owners, status, and exceptions.

Workspace design ignores encryption compatibility

Workspace CMK has an architectural constraint: it cannot be enabled where unsupported items already exist, and unsupported items cannot subsequently be created there. Supported items currently include lakehouses, warehouses, notebooks, environments, Spark job definitions, pipelines, dataflows, copy jobs, SQL databases, mirrored databases, Graph, and several other workloads. Microsoft also identifies exceptions, including Mirrored Dataverse and Mirrored Azure Databricks Catalog. The authoritative list can change, so it should be evaluated from the current supported-item documentation , not copied permanently into a design standard.

The business consequence is rework. A workspace built around team convenience can become impossible to encrypt without moving items, changing dependencies, and retesting the data product.

Power BI is mistaken for part of the same control plane

Workspace CMK and Power BI BYOK solve related requirements at different scopes. Microsoft describes workspace CMK as protection for Fabric items such as lakehouses, pipelines, and notebooks, while Power BI BYOK protects imported semantic-model data at the capacity level. Microsoft currently documents the option to use the same or separate keys across these controls as preview functionality, and the controls are not interchangeable. Microsoft's end-to-end Fabric security guidance makes the scope distinction explicit.

The business consequence is a false assurance boundary: the organization reports that a workspace is under customer-controlled encryption while its semantic model is governed by a different mechanism or remains under platform-managed keys.

Key administration and analytics operations are separated without a shared runbook

Separation of duties is healthy. Disconnected operations are not. The Key Vault administrator can affect Fabric availability, the Fabric workspace administrator can bind a production workspace to a key, and the identity administrator provisions the Fabric Platform CMK service principal. Each action crosses a team boundary.

The business consequence is slow recovery. When jobs fail after a key event, responders first have to discover which team changed what, which workspaces depend on the key, and whether restoring access is sufficient. Microsoft notes a specific recovery wrinkle: SQL database in Fabric does not automatically revalidate the key after access is restored and requires manual revalidation.

Coverage is inferred instead of measured

The encryption page can show `Active`, `In progress`, or `Failed`, and Fabric emits audit operations for applying, disabling, and getting workspace encryption. Fabric also provides REST APIs to assign, inspect, and reset workspace encryption; the Assign Workspace Encryption API requires a workspace admin caller and a versionless Key Vault identifier.

If these signals are not collected, platform owners cannot answer basic questions: Which regulated workspaces are active? Which are stuck? Which key is assigned? Which exception expires next month? Which change preceded a failure?

Why common approaches fall short

"Turn it on tenant-wide and let workspace admins handle it"

The tenant setting is a prerequisite, not a complete governance model. Microsoft states that it is disabled by default. Once it is enabled, workspace administrators can configure CMK; if it is later turned off, existing CMK workspaces remain encrypted, but administrators can no longer enable or disable CMK on workspaces. The associated keys must remain active. Microsoft's encryption tenant-setting documentation describes this behavior.

An enterprise therefore needs an approval and ownership process around the setting. Otherwise, local administrators can create long-lived dependencies on keys without central lifecycle evidence.

"Use one vault and one key for everything"

A single key is easy to describe but creates a large blast radius. Revocation for one legal entity, workload, or incident can stop unrelated analytics. Conversely, a unique key for every workspace can overwhelm the operating model. Key granularity should follow policy boundaries, ownership, recovery objectives, and acceptable shared failure domains.

"Rotate immediately, then disable the old version"

Fabric requires a versionless key URI and checks Key Vault daily for a new key version. Microsoft advises waiting 24 hours after creating the new version before disabling the older one. Ignoring that window can make the workspace temporarily inaccessible. Rotation must be a staged production change, not merely a Key Vault housekeeping task.

"CMK protects everything the workload touches"

It does not. Microsoft documents exclusions such as data on Spark cluster temporary disks during shuffle, spills, or RDD caching; attached libraries; some pipeline, copy-job, machine-learning, and experiment metadata; and certain warehouse query caches. These exclusions do not make CMK ineffective. They mean the security architecture must document residual exposure and use complementary controls such as least privilege, network controls, workload isolation, logging, and data minimization.

"Key revocation is our recovery plan"

Revocation is a containment mechanism. It is not a complete incident-response plan. It can prevent Fabric from reading and writing protected content, but the organization still needs decision authority, impact assessment, stakeholder communication, evidence capture, service restoration, SQL database revalidation where applicable, and reconciliation of missed processing.

A practical Microsoft Fabric solution

1. Convert policy into an encryption coverage matrix

Start with data classes and obligations, not workspaces. For each data product, record:

This matrix prevents a control objective from collapsing into a binary workspace flag. It also gives security, privacy, platform, and product owners a shared artifact for design and assurance.

2. Inventory compatibility before changing topology

Use the Fabric APIs and administrative inventory to enumerate production workspaces and items. Join that inventory to data classification, business criticality, workspace owner, capacity, region, downstream dependencies, and current encryption status. For every candidate workspace:

• compare all item types with Microsoft's current supported list;
• identify unsupported or incompatible items;
• map upstream and downstream workspace dependencies;
• identify semantic models and the capacity that hosts them;
• record trial capacity use, because workspace CMK requires a paid F SKU;
• locate pipelines, connections, shortcuts, notebooks, and external stores that can carry regulated data beyond the workspace.

The output should be a compatibility decision: enable in place, reorganize, use an external CMK-protected store through a shortcut, accept Microsoft-managed encryption with a documented exception, or redesign the workload.

3. Establish purpose-built workspace zones

A robust topology separates encryption compatibility from report-consumption convenience:

```text Regulated sources | v +---------------------------------------------+

+---------------------------------------------+ | | governed data-product interface v +---------------------------------------------+

+---------------------------------------------+

Control plane alongside both zones: Entra roles -> Key Vault/HSM -> CMK APIs -> Audit -> Alerts -> Runbooks ```

This is a reference pattern, not a universal rule. If an unsupported workload is essential, Microsoft also documents a pattern in which data remains in a CMK-protected external store and Fabric accesses it in place through OneLake shortcuts. ADLS Gen2 shortcuts can support writes, while Microsoft documents read-only behavior for S3 and Google Cloud Storage shortcuts in this security pattern. The design must account for the external platform's access, networking, auditing, availability, and cost model.

4. Design the key hierarchy and separation of duties

Choose key boundaries deliberately. A practical baseline is separate production and non-production keys, with further separation where legal entities, regions, regulatory policies, or recovery objectives differ. Avoid both extremes: one enterprise-wide key with an excessive blast radius and thousands of per-item keys that cannot be operated reliably.

Fabric requires a versionless RSA or RSA-HSM key in Key Vault or Managed HSM, with soft delete and purge protection enabled. The Fabric Platform CMK application needs key permissions that support `get`, `wrapKey`, and `unwrapKey`. Microsoft's guidance identifies the Key Vault Crypto Service Encryption User role as an appropriate option. A 4,096-bit key is not supported for SQL database in Fabric, so cryptographic standards must be reconciled with the workload inventory before activation.

Separate these responsibilities:

Azure recommends soft delete, purge protection, automated rotation, policy enforcement, diagnostics, and documented recovery for Key Vault. Those controls should be part of the platform baseline, not project-specific follow-up. See Secure your Azure Key Vault and Key Vault policy integration .

5. Treat activation and rotation as releases

Activation should use the same discipline as a production deployment:

1. Freeze incompatible item creation in the target workspace.
2. Confirm the vault, key type, URI, identity, RBAC, firewall exception, soft delete, and purge protection.
3. Verify that the workspace inventory contains only supported items.
4. Enable CMK in a production-shaped non-production workspace.
5. Wait for every item to reach `Active`; investigate any `Failed` result.
6. Execute read, write, refresh, pipeline, notebook, API, and downstream report tests.
7. Confirm audit events and operational alerts.
8. Activate a low-criticality production ring, observe it, then expand.

For rotation, create a new version under the same versionless key identifier. Keep the old version enabled for at least the documented 24-hour propagation period, verify every assigned workspace, run business-path tests, and only then disable the old version under the organization's key-retention policy.

6. Build a closed-loop control system

The platform team should poll workspace encryption status through the Fabric APIs and maintain an evidence table with at least:

• workspace and capacity IDs;
• business owner and technical owner;
• required coverage class;
• assigned versionless key identifier;
• current status and last successful observation;
• last rotation, recovery test, and exception review;
• Power BI BYOK requirement and capacity assignment;
• unresolved unsupported-item or residual-exposure findings.

Alert on `Failed`, unexpected reset or disable operations, missing status, drift from approved key assignments, a key approaching rotation, or a regulated workspace lacking a current recovery test. Retain the Fabric audit events `ApplyWorkspaceEncryption`, `DisableWorkspaceEncryption`, and `GetWorkspaceEncryption` with Key Vault diagnostic logs and change records so investigators can reconstruct the sequence.

7. Rehearse revocation and recovery

Test in an isolated production-shaped environment. The exercise should prove:

• who can authorize revocation;
• how quickly reads and writes fail;
• which upstream and downstream processes surface useful errors;
• how alerts reach the correct owners;
• how key access is restored;
• how SQL database keys are manually revalidated when required;
• how missed pipeline windows are replayed and reconciled;
• how the organization demonstrates that service and data are consistent afterward.

Do not deliberately revoke a production key merely to demonstrate control unless the business has approved the interruption and a carefully bounded test. A non-production rehearsal plus evidence from configuration, monitoring, and access reviews is usually a safer control test.

Phased implementation roadmap

Phase 1: Define and discover

• Translate regulatory, contractual, and internal policy into the encryption coverage matrix.
• Inventory Fabric items, capacities, semantic models, data classes, external stores, identities, and dependencies.
• Identify unsupported combinations and document residual CMK exclusions.
• Assign business, platform, security, identity, and key-management owners.

Exit gate: Every in-scope data product has an approved coverage decision, accountable owner, and compatibility disposition.

Phase 2: Design and prove

• Design workspace zones and key boundaries by environment and risk domain.
• Configure a non-production Key Vault or Managed HSM baseline.
• Establish the Fabric Platform CMK application access and tenant setting under change control.
• Prove enablement, status collection, rotation, revocation, restoration, audit, and business reconciliation in a representative workload.

Exit gate: The control works end to end, documented exclusions are accepted, and recovery meets the target established in Phase 1.

Phase 3: Reorganize and pilot

• Move unsupported items to appropriate workspaces or redesign their storage path.
• Separate Power BI content where the topology requires distinct capacity-level BYOK.
• Update dependencies, deployment processes, monitoring, and support ownership.
• Pilot a low-criticality production data product and observe at least one complete operational cycle.

Exit gate: The pilot remains available, all in-scope items report `Active`, business results reconcile, and audit evidence is complete.

Phase 4: Roll out by risk ring

• Prioritize regulated but recoverable workloads before the most critical services.
• Activate CMK in controlled waves with preflight and rollback decisions.
• Verify item status and business paths after every workspace activation.
• Track exceptions with an owner, rationale, compensating controls, and expiry date.

Exit gate: Target coverage is achieved with no unowned exceptions or unresolved failed states.

Phase 5: Operate and assure

• Run rotation as a scheduled release with the documented overlap window.
• Review access, key assignment, workspace drift, and BYOK coverage regularly.
• Rehearse recovery after material platform, topology, or runbook changes.
• Report coverage, failures, exceptions, and recovery evidence to risk owners.

Exit gate: CMK is part of normal platform operations rather than a one-time compliance project.

Governance, security, adoption, and cost considerations

Governance

Maintain one authoritative mapping from policy obligation to data product, workspace, key, and evidence. Require a design review before a CMK workspace accepts a new item type or dependency. Time-bound exceptions and review them against the current Microsoft support matrix, because feature support can change.

Security

CMK complements rather than replaces identity, least privilege, network isolation, data classification, sensitivity labeling, and audit. Protect key-administration roles through privileged access controls and monitor both successful and failed key operations. Restrict human access to the key plane, and avoid putting business data or secrets in names and metadata that are not covered by workspace CMK.

Resilience

The key is now on the critical path for analytics. Protect it accordingly. Enable soft delete and purge protection, retain recoverable versions according to policy, document vault recovery, and maintain contact paths across security, identity, Key Vault, Fabric, and application teams. Align the key blast radius with the business recovery objective.

Adoption

Workspace owners need a clear catalog of permitted item types and a request path for exceptions. Data engineers and BI teams must understand why engineering and consumption artifacts may sit in different workspaces. Support teams need failure signatures and runbooks, not a generic instruction to contact security.

Cost

Workspace CMK is supported on paid F SKUs, not trial capacities. Cost planning should also include Key Vault or Managed HSM operations, logging retention, monitoring, duplicated non-production environments, topology changes, regression testing, and the operational effort of rotations and assurance. The biggest avoidable cost is emergency redesign after a mixed-use workspace reaches production.

Success metrics

Use metrics that prove control and service health together:

Avoid reporting only the number of CMK-enabled workspaces. A rising count can hide unsupported business paths, stale evidence, excessive blast radius, or semantic-model gaps.

How YuniQ can help

YuniQ's Microsoft Fabric consulting and implementation services align with the work needed to operationalize CMK without overstating what encryption alone delivers.

• Strategy and readiness: YuniQ describes current-state platform and workload diagnostics, capacity planning, workspace topology, and security, governance, and operating-model design. Those activities can establish the encryption coverage matrix, compatibility inventory, key boundaries, and accountable operating model.
• OneLake and data architecture: YuniQ's service page includes enterprise information architecture, domain workspaces, medallion data layers, lakehouse-versus-warehouse optimization, and shortcut design. Those capabilities are relevant when mixed-use workspaces must be reorganized or when externally encrypted data should remain in place.
• Governance, security, and DevOps: YuniQ lists Microsoft Entra ID least-privilege design, Purview integration, lineage, Dev/Test/Prod separation, Git CI/CD, auditable logging, monitoring, and capacity alerts. These are complementary controls around CMK activation, evidence, release discipline, and residual risk.
• Implementation and validation: YuniQ describes iterative delivery of pipelines, transformations, data products, semantic models, and CI/CD controls, along with automated reconciliation and parallel-run validation for migrations. That supports a controlled pilot and business-path verification when workspace topology changes.
• Team enablement and handover: YuniQ explicitly includes team enablement, handover, and governance in its implementation offering, which is important because CMK succeeds only when security, identity, key-management, platform, and product teams can operate it together.

The useful engagement is not simply enabling a setting. It is producing an approved scope, compatible architecture, proven deployment, observable control, and recovery runbook that enterprise owners can sustain.

Practical next steps

1. Select one regulated data product and write its end-to-end encryption coverage matrix.
2. Inventory every Fabric item, semantic model, capacity, external store, and dependency in its path.
3. Compare the workspace contents with Microsoft's current CMK support and exclusion list.
4. Decide whether to enable in place, reorganize workspaces, apply Power BI BYOK, use an external CMK-protected shortcut pattern, or record a time-bound exception.
5. Build a non-production proof that includes activation, rotation, status monitoring, revocation, recovery, and business reconciliation.
6. Approve a risk-ring rollout only after owners sign off on residual exposure and recovery evidence.

The executive test is simple: can the organization show exactly what the customer key protects, what it does not protect, who can change it, how a failure is detected, and how service is restored? If any answer depends on tribal knowledge, the encryption control is not yet production-ready.