SQL Server 2025 and the End of Purview Access Policies: A Step Back from Cloud-Native IAM?

SQL Server 2025 was released at the end of last year. While most attention has gone to new features, this release also discontinued several existing ones—a notable first in recent SQL Server versions.

The full list is available here: Discontinued services and deprecated features

One item deserves particular attention: Purview access policies.

This feature had only reached GA in November 2022(Microsoft Purview DevOps policies enter GA: Simplify access provisioning while protecting your data )

What Purview access policies were meant to solve

The intent of the feature is best illustrated by the following diagram:

Source: Private Preview: controlling access to Azure SQL at scale with policies in Purview

Disclaimer: I worked extensively on this feature during my time at Microsoft on, along with several others. But this post is not sentimental—it is based on a question about the product’s strategy,

DevOps policies were the first step toward integrating the SQL Server engine into a cloud-native IAM model.

“One policy to control them all”.

The idea was to define RBAC-style roles that could grant access across all SQL Server Instances and SQL databases at subscription or resource-group scale.

The key benefit was scale: instead of executing SQL scripts against every instance (and dealing with outages, drift, or newly created servers), access could be centrally managed via policies.

DevOps policies were the first permissions exposed to external policy control. The primary use case was read-only access to system objects, typical for:

• Performance monitoring tools
• Junior DBAs
• Support staff
• Security auditing

Why Purview? – Why not Azure RBAC?

Purview was not the original plan—it didn’t even exist at the time.

The logical choice was Azure RBAC, but there was no budget to integrate with it. The relevant teams were fully focused on Entra ID.

At the same time, a new product (codename Babylon) was being built to provide unified visibility for data assets. That product became Microsoft Purview. The Purview team provided strong engineering support, which ultimately led to access policies being implemented there.

Why did we start with DevOps policies (read-only access to system objects for Performance Monitoring and Security Auditing) and not access to data?

We were under no illusion that DevOps policies alone would drive Purview adoption.

However, after spending significant time on internal architecture, we needed to deliver a minimal but real use case. Performance monitoring had the smallest permission surface.

The architecture is described here: Revamped SQL Permission system for Principle of Least Privilege and external policies – internals

Time constraints forced a choice:

• Read access to system objects
• OR SELECT on user tables only (no views, procedures, or functions)

I chose the read-only access to system objects. Rolling out “SELECT on tables only” would have been misleading: real applications also need views, stored procedures, and write access. No customer would want to work with a split connection model per application just to fit a partial policy model for one of them.

Why did Microsoft decide to kill this project?

I can’t provide an official statement, but I’ve spoken with people involved.

Two facts stand out:

• Almost everyone from the original Purview and SQL PM teams has left.
• Customer adoption of the feature was very low.

Given Purview’s complex setup and limited adoption, this is unsurprising. I would not recommend customers deploy Purview solely for two DevOps policies.

Additionally, the Purview team has shifted focus toward Data Catalog and MIP labels, ending support for SQL access policies.

From that perspective, the decision is understandable.

What’s missing, however, are two key considerations:

1. What is the long-term goal of policy-based access control?

DevOps policies were never meant to be the end state. They were proof that the architecture works. Roles covering user objects, DDL, and broader SQL operations were already defined and waiting for implementation.

The long-term vision was to allow any SQL permission to be governed by external policies—and eventually, if desired, eliminate SQL authentication entirely.

2. Are there alternatives to Purview?

If Purview is the blocker, why not switch providers?

The architecture was explicitly designed to be policy-provider agnostic. Purview is not the only option. We made sure of that.

Is there an alternative?

The Documentation suggests using fixed server roles instead.

This is incorrect.

Server roles are per-server and require logins on each instance.

• Server roles are per server and require a login at each server.
• The policy-based access works across servers, covering all servers within a subscription if you wish – that is the whole point of the feature: scale.
• Policies require no Login to be created in SQL. They are truly cloud-native. This is how IAM for cloud resources should work. Server roles are just standard SQL roles that you can assign members to once you have a login in SQL.

Why I think this is a strategic mistake

Customers managing hundreds and thousands of SQL servers and databases – cloud and on-prem – have the constant challenge to keep access to those systems tight and yet manageable. Running SQL commands with PowerShell to deploy Logins and permissions, hoping that all servers are online is unsatisfying and inefficient. And it lacks the central visibility of who has access to which database.

Vendors like Google and Amazon have for good reasons invested in IAM for their database offerings.

If cloud is a priority, cloud-integrated access control must be part of the strategy.

My advice to the Microsoft product team

Even with the discontinuation of access policies, the architecture is still in place. It is used by the Data owner policies and even by Fabric workspace roles behind the scenes (albeit with a very hacky implementation).

Rather than removing the feature, consider Azure RBAC as the policy provider. It is the natural IAM system for Azure resources, and the policy-integration within the SQL engine technically supports alternative policy sources—including on-prem ones.

————————————————————————————————————————-

What do you think? Is integrated access control overrated?

How and where do you want to define access to databases across your subscription?

Andreas