TL;DR
Microsoft Fabric now lets you encrypt selected workspaces with your own keys in Azure Key Vault (CMK). You keep ownership of the cryptographic root of trust—rotation, audit, and revocation—on top of Microsoft’s default encryption. Practically, that means fewer audit exceptions, clearer incident response, and a stronger data-governance story when rolling Fabric out at scale.
What this changes?
Closes common audit gaps. Many frameworks require “customer control over encryption keys” or equivalent compensating controls. CMK gives you that control while preserving managed-service efficiency.
Clean separation of duties. Security can own keys and policies in Key Vault; data teams keep building in Fabric—no awkward overreach.
Revocation leverage. If you must suspend access (breach, exit, legal hold), revoking the key renders a CMK workspace unreadable within ~60 minutes—this is the kind of concrete behavior auditors look for. (Power BI’s related BYOK feature documents a ~30-minute unreadable window, a useful precedent.)
How Fabric CMK works (in one minute)
- Envelope encryption. Fabric still encrypts data at rest with a Microsoft-managed data-encryption key (DEK). Your Key Vault key (KEK) then encrypts that DEK. Keys never leave Key Vault; you control permissions, logging, and lifecycle.
- Scope = workspace. You enable CMK per workspace after a one-time tenant setup. Existing and new items in that workspace are encrypted with your key.
- Operational behaviors.
- Rotation: uses a versionless Key Vault key URI; Fabric picks up new versions on its daily check—leave the old version enabled ~24h to avoid a gap.
- Revocation: remove access in Key Vault; reads/writes fail within ~60 min until access is restored.
What’s in scope today
CMK is in preview, available in all public regions, and supported for these item types: Lakehouse, Environment, Spark Job Definition, API for GraphQL, ML model, Experiment, Data Pipeline, Dataflow, Industry solutions.
Not covered / not protected by CMK:
- Lakehouse column names, table format/compression, and SQL endpoint (and when CMK is enabled no Lakehouse SQL endpoint is created).
- Spark temp/shuffle/spill data and certain logs/metadata.
Compliance value, mapped to actions
- Key ownership & auditability → Proves control for “encryption at rest” + “key management” controls; you can show Key Vault access logs and rotation runbooks.
- Revocation control → Satisfies exit/incident-response scenarios with demonstrable, time-bounded unreadability. (Power BI BYOK precedent strengthens your audit narrative.)
- Least privilege → Use the Fabric Platform CMK service principal with Key Vault Crypto Service Encryption User role (wrap/unwrap only). Keeps blast radius small.
Architecture & governance patterns we recommend
1) Segment by data criticality
Create CMK-enabled workspaces only for sensitive domains (PII, finance, clinical, M&A). Keep general analytics in standard workspaces to avoid unnecessary constraints.
2) Plan for the Lakehouse SQL endpoint caveat
Because CMK suppresses the Lakehouse SQL endpoint, choose one of these patterns:
- Build semantic models off Warehouse or other non-CMK data products, and keep the sensitive Lakehouse in a CMK workspace as a governed source.
- Land sensitive data in a CMK Lakehouse; transform/export into a non-CMK workspace for serving via SQL endpoint where needed.
3) Separate key management from data ownership
Security/Ops owns Key Vault; Data Platform owns Fabric. Enforce soft-delete + purge protection and RSA/RSA-HSM keys
4) Don’t mix with Power BI BYOK on the same capacity
Fabric CMK workspaces can’t be moved to capacities with BYOK, and you can’t enable CMK where BYOK is already on—decide your enterprise standard up front.
High Level Rollout blueprint
Phase 0 – Policy & guardrails
- Approve when CMK is mandatory (e.g., regulated datasets, cross-border restrictions).
- Define rotation cadence (e.g., annual + ad-hoc on incident) and revocation playbook.
Phase 1 – Tenant & Key Vault setup
- Enable the Encryption tenant setting (preview) so workspaces can use CMK.
- Setup Customer-managed keys for Fabric workspaces
- Use a versionless key URI; ensure soft-delete & purge protection are on.
Phase 2 – Workspace enablement
- Move sensitive items (supported types only) into a dedicated CMK workspace; enable CMK and monitor encryption status until “Active.”
Phase 3 – Operate
- Rotate keys: publish a new key version, wait ~24h, then disable the prior version.
- Monitor Key Vault audit logs for wrap/unwrap events; alert on anomalies.
- Test revocation quarterly to validate the ~60-minute unreadable behavior and comms process.
Limitations & gotchas
- Preview feature; plan for change control. Trial capacities aren’t supported.
- Key Vault firewall not supported (today). If you need network isolation, track roadmap; don’t enable the KV firewall with CMK yet.
- Item coverage is not universal; unsupported items block CMK enablement in that workspace. Keep footprints clean.
Decision quick-guide
Choose CMK when:
- Regulatory/commercial contracts mandate customer-controlled keys.
- You want provable revocation as part of exit/IR plans.
- Sensitive datasets justify the Lakehouse SQL endpoint trade-off.
Stick to default encryption when:
- Data is low-risk, or you rely heavily on Lakehouse SQL endpoints in that workspace.
- You’re early in Fabric adoption and don’t yet need key ownership.
FAQ (for your security & audit teams)
Is CMK available in my region?
Yes—all public regions (preview).
Can we mix Fabric CMK and Power BI BYOK?
Not in the same motion. CMK workspaces can’t move to BYOK capacities, and vice-versa. Decide your standard per environment.
What if we revoke the key by mistake?
Fabric calls to the CMK workspace will fail within ~60 minutes. Restore Key Vault permissions to reinstate access. Build a break-glass SOP.
Does CMK protect Spark temp/shuffle data?
No. It protects supported item data at rest; Spark spill/shuffle and certain metadata/logs are out of scope today.
The Blue Owls’ recommendation
Start small and strategic: pilot CMK on one high-sensitivity domain, validate your rotation/revocation runbooks, and finalize the workspace segmentation pattern for Lakehouse SQL endpoint needs. From there, expand CMK to other domains as governance matures. We can package this as a landing-zone add-on to your Fabric rollout (tenant setting, Key Vault hardening, automation, and an auditor-ready SOP pack).
Leave a Reply