{"id":7175,"date":"2026-02-10T13:16:22","date_gmt":"2026-02-10T18:16:22","guid":{"rendered":"https:\/\/andreas-wolter.com\/?p=7175"},"modified":"2026-02-12T16:59:44","modified_gmt":"2026-02-12T21:59:44","slug":"2602_sqlserver2025_end_of_policybasedaccesscontrol","status":"publish","type":"post","link":"https:\/\/andreas-wolter.com\/en\/2602_sqlserver2025_end_of_policybasedaccesscontrol\/","title":{"rendered":"SQL Server 2025 and the End of Purview Access Policies: A Step Back from Cloud-Native IAM?"},"content":{"rendered":"\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-m0cxh8ps-b436bfd83c58dcaefb8d2f5a99fe2116\">\n#top .av-special-heading.av-m0cxh8ps-b436bfd83c58dcaefb8d2f5a99fe2116{\npadding-bottom:10px;\n}\nbody .av-special-heading.av-m0cxh8ps-b436bfd83c58dcaefb8d2f5a99fe2116 .av-special-heading-tag .heading-char{\nfont-size:25px;\n}\n.av-special-heading.av-m0cxh8ps-b436bfd83c58dcaefb8d2f5a99fe2116 .av-subheading{\nfont-size:15px;\n}\n<\/style>\n<div  class='av-special-heading av-m0cxh8ps-b436bfd83c58dcaefb8d2f5a99fe2116 av-special-heading-h3 blockquote modern-quote  avia-builder-el-0  el_before_av_textblock  avia-builder-el-first '><h3 class='av-special-heading-tag'  itemprop=\"headline\"  >SQL Server 2025 and the End of Purview Access Policies: A Step Back from Cloud-Native IAM?<\/h3><div class=\"special-heading-border\"><div class=\"special-heading-inner-border\"><\/div><\/div><\/div>\r\n\r\n<section  class='av_textblock_section av-m0cxgkjy-c935304b4106b45214698f40e83a9894 '   itemscope=\"itemscope\" itemtype=\"https:\/\/schema.org\/BlogPosting\" itemprop=\"blogPost\" ><div class='avia_textblock'  itemprop=\"text\" ><p>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\u2014a notable first in recent SQL Server versions.<\/p>\n<p>The full list is available here: <a href=\"https:\/\/learn.microsoft.com\/en-us\/sql\/sql-server\/what-s-new-in-sql-server-2025?view=sql-server-ver17&#038;preserve-view=true\" target=\"_blank\" rel=\"noopener\">Discontinued services and deprecated features<\/a><\/p>\n<p>One item deserves particular attention: <strong>Purview access policies.<\/strong><\/p>\n<p>This feature had only reached GA in November 2022(<a href=\"https:\/\/techcommunity.microsoft.com\/blog\/microsoft-security-blog\/microsoft-purview-devops-policies-enter-ga-simplify-access-provisioning-while-pr\/3674057\" target=\"_blank\" rel=\"noopener\">Microsoft Purview DevOps policies enter GA: Simplify access provisioning while protecting your data<\/a> )<\/p>\n<h2><a name=\"_Toc221614203\"><\/a>What Purview access policies were meant to solve<\/h2>\n<p>The intent of the feature is best illustrated by the following diagram:<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-large wp-image-7176\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_diagram-1030x475.jpg\" alt=\"\" width=\"1030\" height=\"475\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_diagram-1030x475.jpg 1030w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_diagram-300x138.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_diagram-768x354.jpg 768w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_diagram-705x325.jpg 705w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_diagram.jpg 1200w\" sizes=\"auto, (max-width: 1030px) 100vw, 1030px\" \/><\/p>\n<p><em>Source: <a href=\"https:\/\/techcommunity.microsoft.com\/blog\/azuresqlblog\/private-preview-controlling-access-to-azure-sql-at-scale-with-policies-in-purvie\/2945491\" target=\"_blank\" rel=\"noopener\">Private Preview: controlling access to Azure SQL at scale with policies in Purview<\/a><\/em><\/p>\n<p>Disclaimer: I worked extensively on this feature during <a href=\"https:\/\/andreas-wolter.com\/en\/resigned-program-manager-security-microsoft-azure-data\/\">my time at Microsoft on<\/a>, along with several others. But this post is not sentimental\u2014it is based on a question about the product\u2019s strategy,<\/p>\n<p>DevOps policies were the <strong>first step toward integrating the SQL Server engine into a cloud-native IAM model<\/strong>.<\/p>\n<blockquote><p>\u201cOne policy to control them all\u201d.<\/p><\/blockquote>\n<p>The idea was to define RBAC-style roles that could <strong>grant access<\/strong> across all SQL Server Instances and SQL databases <strong>at subscription or resource-group scale<\/strong>.<\/p>\n<p>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.<\/p>\n<p>DevOps policies were the first permissions exposed to external policy control. The primary use case was read-only access to system objects, typical for:<\/p>\n<ul>\n<li>Performance monitoring tools<\/li>\n<li>Junior DBAs<\/li>\n<li>Support staff<\/li>\n<li>Security auditing<\/li>\n<\/ul>\n<h2><\/h2>\n<h2><a name=\"_Toc221614204\"><\/a>Why Purview? \u2013 Why not Azure RBAC?<\/h2>\n<p>Purview was not the original plan\u2014it didn\u2019t even exist at the time.<\/p>\n<p>The logical choice was <strong><a href=\"https:\/\/learn.microsoft.com\/en-us\/azure\/role-based-access-control\/overview\" target=\"_blank\" rel=\"noopener\">Azure RBAC<\/a><\/strong>, but there was no budget to integrate with it. The relevant teams were fully focused on Entra ID.<\/p>\n<p>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.<\/p>\n<h2><a name=\"_Toc221614205\"><\/a>Why did we start with DevOps policies (read-only access to system objects for Performance Monitoring and Security Auditing) and not access to data?<\/h2>\n<p>We were under no illusion that DevOps policies alone would drive Purview adoption.<\/p>\n<p>However, after spending significant time on internal architecture, we needed to deliver a <strong>minimal but real use case<\/strong>. Performance monitoring had the smallest permission surface.<\/p>\n<p>The architecture is described here: <a href=\"https:\/\/techcommunity.microsoft.com\/blog\/azuresqlblog\/revamped-sql-permission-system-for-principle-of-least-privilege-and-external-pol\/3639399\" target=\"_blank\" rel=\"noopener\">Revamped SQL Permission system for Principle of Least Privilege and external policies \u2013 internals<\/a><\/p>\n<p>Time constraints forced a choice:<\/p>\n<ul>\n<li>Read access to system objects<\/li>\n<li>OR SELECT on user tables only (no views, procedures, or functions)<\/li>\n<\/ul>\n<p>I chose the read-only access to system objects. Rolling out \u201cSELECT on tables only\u201d 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.<\/p>\n<h2><a name=\"_Toc221614206\"><\/a>Why did Microsoft decide to kill this project?<\/h2>\n<p>I can\u2019t provide an official statement, but I\u2019ve spoken with people involved.<\/p>\n<p>Two facts stand out:<\/p>\n<ul>\n<li>Almost everyone from the original Purview and SQL PM teams has left.<\/li>\n<li>Customer adoption of the feature was very low.<\/li>\n<\/ul>\n<p>Given Purview\u2019s <strong>complex setup and limited adoption<\/strong>, this is unsurprising. I would not recommend customers deploy Purview solely for two DevOps policies.<\/p>\n<p>Additionally, the Purview team has shifted focus toward Data Catalog and MIP labels, ending support for SQL access policies.<\/p>\n<p>From that perspective, the decision is understandable.<\/p>\n<p>What\u2019s missing, however, are two key considerations:<\/p>\n<p>1. What is the long-term goal of policy-based access control?<\/p>\n<p>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.<\/p>\n<p>The long-term vision was to allow any SQL permission to be governed by external policies\u2014and eventually, if desired, eliminate SQL authentication entirely.<\/p>\n<p>2. Are there alternatives to Purview?<\/p>\n<p>If Purview is the blocker, why not switch providers?<\/p>\n<p>The architecture was explicitly designed to be policy-provider agnostic. Purview is not the only option. We made sure of that.<\/p>\n<h2><a name=\"_Toc221614207\"><\/a>Is there an alternative?<\/h2>\n<p>The Documentation suggests using fixed server roles instead.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-7178 alignnone\" src=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_discontinued.jpg\" alt=\"\" width=\"772\" height=\"309\" srcset=\"https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_discontinued.jpg 772w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_discontinued-300x120.jpg 300w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_discontinued-768x307.jpg 768w, https:\/\/andreas-wolter.com\/wp-content\/uploads\/2026\/02\/2602_Purview-access-policies_discontinued-705x282.jpg 705w\" sizes=\"auto, (max-width: 772px) 100vw, 772px\" \/><\/p>\n<p>This is incorrect.<\/p>\n<p>Server roles are per-server and require logins on each instance. And SQL Server permissions alone do not have a concept of Separation of Duties.<\/p>\n<ul>\n<li><strong>Server roles are per server<\/strong> and require a login at each server.<\/li>\n<li><strong>The policy-based access works <u>across servers<\/u><\/strong>, covering all servers within a subscription if you wish \u2013 that is the whole point of the feature: scale.<\/li>\n<li><strong>Policies do not require a SQL login<\/strong>. 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.<\/li>\n<li><strong><em>Separation of Duties<\/em><\/strong>:<\/li>\n<\/ul>\n<p>The workflow for assigning RBAC roles in Purview is intentionally split into two steps:<\/p>\n<ul>\n<li>Step 1: Define the policy<\/li>\n<li>Step 2: Approve (publish) the policy<\/li>\n<\/ul>\n<p>This enforces Separation of Duties, as two different personas are involved in the process of granting access.<\/p>\n<h2><a name=\"_Toc221614208\"><\/a>Why I think this is a strategic mistake<\/h2>\n<p>Customers managing hundreds and thousands of SQL servers and databases &#8211; cloud and on-prem &#8211; 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. The \u201cPowerShell to remote into SQL after Deployment\u201d-approach does not <strong>scale<\/strong> well, and lacks the <strong>central visibility<\/strong> of who has access to which database.<\/p>\n<p>In addition to that, the workflow that was designed in Purview supports <strong>Separation of Duties<\/strong>, which has been a long-time ask from customers with critical systems.<\/p>\n<p>Vendors like Google and Amazon have for good reasons invested in IAM for their database offerings.<\/p>\n<p>If cloud is a priority, <strong>cloud-integrated access control must be part of the strategy<\/strong>.<\/p>\n<h2><a name=\"_Toc221614209\"><\/a>My advice to the Microsoft product team<\/h2>\n<p>Even with the discontinuation of access policies, the architecture is still in place. It is used by the <a href=\"https:\/\/learn.microsoft.com\/en-us\/purview\/legacy\/how-to-policies-data-owner-azure-sql-db\" target=\"_blank\" rel=\"noopener\">Data owner policies<\/a> and even by Fabric workspace roles behind the scenes (albeit with a very hacky implementation).<\/p>\n<p>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\u2014including on-prem ones.<\/p>\n<p>&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;&#8212;-<\/p>\n<p><span class=\"break-words tvm-parent-container\"><span dir=\"ltr\"> What do you think? Is integrated access control overrated?<\/span><\/span><\/p>\n<p><span class=\"break-words tvm-parent-container\"><span dir=\"ltr\">How and where do you want to define access to databases across your subscription?<\/span><\/span><\/p>\n<p>Andreas<\/p>\n<\/div><\/section>\r\n\r\n<div  class='hr av-baku8u-c77559299fb7cb036a9bcb2d27e7c839 hr-default  avia-builder-el-2  el_after_av_textblock  el_before_av_social_share '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\r\n\r\n<div  class='av-social-sharing-box av-5n5vpa-78ffdd9d224b4a246af65bdc00dce900 av-social-sharing-box-default  avia-builder-el-3  el_after_av_hr  el_before_av_hr  av-social-sharing-box-fullwidth'><div class=\"av-share-box\"><h5 class='av-share-link-description av-no-toc '>Share article<\/h5><ul class=\"av-share-box-list noLightbox\"><li class='av-share-link av-social-link-facebook' ><a target=\"_blank\" aria-label=\"Share on Facebook\" href=\"https:\/\/www.facebook.com\/sharer.php?u=https:\/\/andreas-wolter.com\/en\/2602_sqlserver2025_end_of_policybasedaccesscontrol\/&#038;t=SQL%20Server%202025%20and%20the%20End%20of%20Purview%20Access%20Policies%3A%20A%20Step%20Back%20from%20Cloud-Native%20IAM%3F\" aria-hidden=\"false\" data-av_icon=\"\ue8f3\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Facebook\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Facebook<\/span><\/a><\/li><li class='av-share-link av-social-link-twitter' ><a target=\"_blank\" aria-label=\"Share on Twitter\" href=\"https:\/\/twitter.com\/share?text=SQL%20Server%202025%20and%20the%20End%20of%20Purview%20Access%20Policies%3A%20A%20Step%20Back%20from%20Cloud-Native%20IAM%3F&#038;url=https:\/\/andreas-wolter.com\/en\/?p=7175\" aria-hidden=\"false\" data-av_icon=\"\ue8f1\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on Twitter\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on Twitter<\/span><\/a><\/li><li class='av-share-link av-social-link-linkedin' ><a target=\"_blank\" aria-label=\"Share on LinkedIn\" href=\"https:\/\/linkedin.com\/shareArticle?mini=true&#038;title=SQL%20Server%202025%20and%20the%20End%20of%20Purview%20Access%20Policies%3A%20A%20Step%20Back%20from%20Cloud-Native%20IAM%3F&#038;url=https:\/\/andreas-wolter.com\/en\/2602_sqlserver2025_end_of_policybasedaccesscontrol\/\" aria-hidden=\"false\" data-av_icon=\"\ue8fc\" data-av_iconfont=\"entypo-fontello\" title=\"\" data-avia-related-tooltip=\"Share on LinkedIn\" rel=\"noopener\"><span class='avia_hidden_link_text'>Share on LinkedIn<\/span><\/a><\/li><\/ul><\/div><\/div>\r\n\r\n\n<style type=\"text\/css\" data-created_by=\"avia_inline_auto\" id=\"style-css-av-4ofg9q-c2108540b480aba02923089240a3a176\">\n#top .hr.hr-invisible.av-4ofg9q-c2108540b480aba02923089240a3a176{\nheight:50px;\n}\n<\/style>\n<div  class='hr av-4ofg9q-c2108540b480aba02923089240a3a176 hr-invisible  avia-builder-el-4  el_after_av_social_share  el_before_av_comments_list '><span class='hr-inner '><span class=\"hr-inner-style\"><\/span><\/span><\/div>\r\n\r\n<div  class='av-buildercomment av-284ftq-f5a1564cd6b8ffad6ce835e2d40de4b7  av-blog-meta-author-disabled av-blog-meta-html-info-disabled'><div class=\"av-buildercomment-unapproved\"><span>The last comment needs to be approved.<\/span><\/div><\/div>","protected":false},"excerpt":{"rendered":"","protected":false},"author":4,"featured_media":7176,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[57,383],"tags":[206],"class_list":["post-7175","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-security-en","category-sql-server-2025","tag-sql-security"],"_links":{"self":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/7175","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/comments?post=7175"}],"version-history":[{"count":4,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/7175\/revisions"}],"predecessor-version":[{"id":7184,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/posts\/7175\/revisions\/7184"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media\/7176"}],"wp:attachment":[{"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/media?parent=7175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/categories?post=7175"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/andreas-wolter.com\/en\/wp-json\/wp\/v2\/tags?post=7175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}