Grasp AI Modern Conversion Website

For a lot of teams, encryption at rest gets treated as a tick-box. If the platform says data is encrypted, the conversation ends there.

That is usually fine. Until it isn’t.

Customer-managed keys in Fabric SQL Database are now generally available, and the practical value is not that Microsoft suddenly learned how to encrypt data. Fabric was already encrypting data at rest with Microsoft-managed keys. What changes here is control. More specifically, who controls the key hierarchy, who can audit its use, and how clearly a business can map its data platform to its own governance model.

That matters more than many organisations admit.

Because as data estates become the foundation for AI, analytics and operational applications, the hard conversation is no longer whether the platform is secure in a generic sense. It is whether your controls are strong enough for your own regulators, your own internal risk posture, and your own operating model.

The challenge

Microsoft Fabric has moved quickly from an analytics platform conversation into a broader data platform one. And SQL database in Fabric is part of that shift.

It gives organisations a transactional database built on the Azure SQL Database engine, while also replicating data into OneLake in near real time for downstream analytics, reporting and AI scenarios. That is attractive because it closes a gap many teams struggle with: the gap between operational data and analytical data.

But it also raises the bar for governance.

When a platform is designed to make data easier to share across notebooks, engineering pipelines, Power BI, AI tooling and broader Fabric workloads, the security conversation cannot stop at “data is encrypted”. It has to move to “who owns the protection model, how is it enforced, and what happens when key access changes?”.

That is where customer-managed keys start to matter.

What has actually changed

With CMK support now generally available for Fabric SQL Database, organisations can use their own Azure Key Vault keys to protect SQL database data in CMK-enabled Fabric workspaces.

Under the hood, this builds on the wider Fabric workspace CMK model. Microsoft Fabric still encrypts data at rest by default using Microsoft-managed keys. CMK adds another layer by letting the organisation control the key encryption key in Azure Key Vault.

For SQL database in Fabric, Transparent Data Encryption is then automatically enabled for all SQL databases in that CMK-enabled workspace, including tempdb. According to the Microsoft Fabric announcement, this applies to both existing databases in the workspace and any new SQL databases created there going forward.

That is a bigger operational improvement than it first appears.

No one wants a security feature that depends on developers remembering one more setup step. If protection relies on manual consistency, it will eventually fail in the busiest or least governed corner of the estate. The fact that Fabric applies encryption automatically once the workspace is configured is exactly the kind of default most organisations need.

Microsoft also provides a straightforward way to verify the state using sys.dm_database_encryption_keys, which means platform teams can validate that encryption is active rather than assuming it is.

Why enterprise teams should care

The easy summary is compliance. And yes, compliance is part of it.

CMK helps when organisations need stronger evidence of key ownership, rotation control, access management and key usage auditing. If you operate in regulated sectors, or simply have internal policy requirements that say sensitive data platforms must use customer-controlled keys, this closes a meaningful gap.

But the more interesting point is architectural.

SQL database in Fabric is not just another database endpoint. It sits inside a platform that is explicitly designed to connect operational data, analytics and AI. The SQL database overview on Microsoft Learn makes that clear: the service is aimed at OLTP workloads, it automatically replicates into OneLake, and it supports patterns such as reverse ETL, translytical applications and AI development scenarios.

So if Fabric SQL becomes part of the route by which data moves into broader AI or decisioning workflows, key control becomes part of your AI readiness story too.

In my experience, many organisations talk about responsible AI at the model layer and ignore the data platform layer underneath it. That is backwards. If the platform feeding analytics and AI use cases does not align with the organisation’s governance model, adoption slows down later when security, risk and compliance teams step in.

This is why I see CMK in Fabric SQL as a foundational capability, not a flashy one. It does not create a new demo. It removes an objection.

And removing objections is often what makes adoption real.

The practical implementation reality

This is not a one-click checkbox with no surrounding work. Microsoft’s documentation is clear that there are prerequisites.

To enable customer-managed keys for a Fabric workspace, organisations need the Fabric tenant setting enabled, an Azure Key Vault configured correctly, and the Fabric Platform CMK application granted the right access to that vault. The key vault must have soft delete and purge protection enabled. The key also needs to meet Fabric’s requirements around format and supported key types.

There are a few details worth calling out because these are exactly the details that catch teams out during rollout:

CMK is enabled at the workspace level, not on a single database in isolation.
Only supported Fabric item types can exist in a CMK-enabled workspace.
Fabric checks versionless keys daily for new versions, so rotation needs planning rather than guesswork.
For SQL database in Fabric specifically, 4096-bit keys are not supported.
If key access is revoked, read and write calls to the encrypted workspace can fail within about an hour.

That last point is important.

Customer-managed keys give you more control, but control cuts both ways. If your key lifecycle process is weak, your outage process becomes part of your encryption strategy whether you intended that or not.

This is where mature platform teams separate themselves from enthusiastic pilots. Governance is not just about enabling the feature. It is about deciding who owns the vault, who approves rotation, how revocation is handled, what monitoring exists, and how application teams are told about workspace-level encryption constraints.

A better way to explain the “so what”

If I were explaining this to a senior IT leader, I would not position CMK as “Fabric now has another enterprise security feature”. That undersells it.

I would frame it like this: if Fabric is becoming one of the places where operational and analytical data converge, then CMK gives you a cleaner answer to the question of whether that convergence can happen inside your governance boundary.

That matters because many AI programmes stall for entirely predictable reasons. The technology works. The use cases are credible. But the organisation has not done the groundwork on identity, data access, lineage, retention, encryption and policy ownership.

Then six months later, the same teams that wanted rapid AI experimentation are forced to rebuild the operating model under pressure.

CMK does not solve all of that. But it does strengthen a key part of the foundation.

And foundations before innovation is still the right order.

Getting started in the real world

If this is relevant to your organisation, I would suggest a practical starting sequence.

First, identify whether Fabric SQL databases are likely to hold data that falls under stricter internal or external control requirements. Not every workload needs CMK. Some do.

Second, treat this as a joint design exercise between data platform, security and identity teams. If the workspace team can enable the setting but the Key Vault model is unclear, you are not ready.

Third, decide which workspaces should be CMK-enabled from the outset. Since unsupported Fabric items cannot be used in a CMK-enabled workspace, workspace design matters. This is not just a technical toggle. It affects tenancy and workload placement decisions.

Fourth, test rotation and revocation procedures before any executive stakeholder assumes the control is “done”. A control you have never exercised is only half implemented.

Finally, verify encryption state directly. Microsoft provides the DMV query for a reason. Use it in your operational checks and deployment validation.

A minimal example from the product guidance looks like this:

SELECT DB_NAME(database_id) AS DatabaseName, *
FROM sys.dm_database_encryption_keys
WHERE database_id <> 2;

If encryption_state_desc shows ENCRYPTED or ENCRYPTION_IN_PROGRESS, with ASYMMETRIC_KEY as the encryptor type, you have evidence that the database is protected through the configured CMK path.

What this means next

The most useful Microsoft platform announcements are often the least glamorous.

CMK for Fabric SQL Database is one of those.

It will not generate the same excitement as a new Copilot capability or model launch. But it answers a far more practical enterprise question: can we use this platform in a way that matches our own governance standards rather than just inheriting the vendor default?

For organisations trying to move faster with data and AI, that is not a side issue. It is often the gate.

My take is simple: this is the kind of feature that helps Fabric move from technically interesting to operationally acceptable inside larger organisations. And operationally acceptable is where real adoption starts.

If your team is building on Fabric today, it is worth asking a blunt question.

Are you designing for AI ambition, or for the governance reality that will decide whether that ambition survives first contact with the business?

Leon Godwin, Principal Cloud Evangelist at Cloud Direct