If you’ve worked with Power Pages for any length of time, you already know the security story has always been a bit awkward.

On one side, you had Portal security, which had web roles, page permissions, table permissions, contacts, and portal authentication. On the other hand, you had Dataverse security, which had users, security roles, privileges, access levels, teams, and business units. These two different security models have been sitting beside each other like relatives at a wedding who are technically on the same side but clearly do not speak much.

Microsoft’s 2026 Wave 1 release-plan item matters because it appears to be a serious attempt to clean that up. Not with some grand dramatic “everything you knew is wrong” rewrite, but with something more useful: unifying the underlying authorization model so Power Pages users and roles are represented in Dataverse-native structures as well. That is potentially important. It is also very easy to overstate, so let’s not do that.

Let’s explore how Power Pages security works in a nutshell, going forward — and whether this update is actually a big deal.

Current Power Pages Security

First, a quick reminder of how Power Pages security works today: The current-state Power Pages security is a portal-specific layer. Authenticated portal users are represented as contacts, not as ordinary Dataverse system users in the normal internal-app sense. Access is then controlled through web roles, which are associated with page permissions and table permissions. Microsoft’s docs are pretty explicit about this structure.

Page permissions control access to the site’s content surface: pages, child pages, and even associated web files. In other words, can the user reach this part of the site at all?

Table permissions control access to Dataverse data through the portal. So when a portal user works with forms, lists, or portal-driven access to table data, the relevant authorization is not just “Well, it’s in Dataverse, so Dataverse will sort it out.” In the documented current model, Power Pages uses table permissions tied to web roles to control that access.

That has always been the thing people muddle. They hear “Dataverse” and “roles” and assume the whole story is just standard Dataverse security. This has never been the case – remember, this at one point was Adxstudio Portals and a bit of a hack. Now, it’s core to the Microsoft stack. But despite that, the security model stayed relatively unchanged.

Dataverse Security

Meanwhile, Dataverse security is its own beast. It’s the core platform model for internal access to apps, tables, records, and operations. It is built around system users, teams, security roles, privileges, access levels, ownership, and business units. Security roles are cumulative. Team membership can add access. Record visibility depends not just on whether someone has a privilege, but how deep that privilege goes and whether the record sits within their access path.

That is why Dataverse security is more “enterprise” and is structurally native (rather than something, again, that basically started as a 3^rd-party hack). It is the platform’s own internal authorization model, as opposed to something that needs to be both queried by and enforced by an external application.

So, before this update, the awkward truth was simple: Power Pages security was securing Dataverse-backed data, but it was not primarily using the same security machinery as standard Dataverse app security. That overlap made the whole thing harder to explain than it maybe should have been.

What Microsoft Announced

Microsoft’s release plan item says this feature will merge Power Pages web roles and site users with Dataverse security roles and system users, creating a unified authorization model. It says the business value is centralizing authorization in Dataverse, reducing redundant checks in Power Pages, improving performance, enhancing auditing, improving governance, and lowering operational overhead.

It also states a few specific mechanics:

• Each Power Pages user will be stored in both the System User table and the Contact table (!)
• The System Managed User Type column identifies these Power Pages users as C2 User
• Each Power Pages web role will be represented in both the Security Role table and the Web Role table
• Existing contact and web role records will automatically sync with the system user and security role tables
• No migration is required (!)
• No changes are required for makers, and existing security configurations remain intact

That is the explicit part. For the careful inference, this strongly suggests Microsoft is not deleting the familiar Power Pages concepts overnight. It looks much more like they are backing or mirroring those concepts with Dataverse-native representations, so the model becomes more unified under the hood while staying familiar on the surface. That is an inference, but it is the most reasonable one given the “no migration” and “no changes required for makers” language.

Before vs. After

Before this update, a Power Pages user was, in practical terms, a portal contact with web roles, and those web roles connected to page permissions and table permissions. A normal Dataverse user was a system user with security roles and the rest of the Dataverse privilege model.

After this update, at least based on what Microsoft has published so far, a Power Pages user is still a contact but is also represented as a system user, and a Power Pages web role is still a web role but is also represented as a security role.

Note that it is not a documented claim that every part of Power Pages security suddenly becomes identical to ordinary Dataverse internal-app security. Microsoft has not published enough to justify that leap. And we’ve all been bitten by assuming Microsoft was doing more with an update that turned out relatively minor. So, the honest framing is this:

• Before: two overlapping security worlds
• After: still likely two recognizable sets of concepts, but with a much tighter shared backbone in Dataverse

What This Means in Practice

For existing Power Pages customers, the main message from Microsoft is reassuring: You don’t need to do anything right away; Microsoft explicitly says existing contact and web role records will sync automatically, no migration is required, and existing data security configurations remain intact. So, if you already have a working portal, the default assumption should be: Keep your current security model, test carefully when the feature arrives, and pay attention to how your reporting, integrations, and custom admin practices interact with the new dual representation.

It also goes without saying that “No migration required” is not the same thing as “You should never test anything.” If you have custom automation, reporting, or governance processes that rely heavily on contact/web role assumptions, you would be foolish not to validate them once this rolls out.

For new Power Pages implementations, I would not recommend some dramatic new pattern based on wishful thinking. Build according to the current documented best practice. Use Power Pages security properly. Understand web roles, page permissions, and table permissions. Do not assume the new model means you can suddenly ignore portal security concepts and just think like an internal Dynamics security admin. Microsoft has not said that. What you should do instead is design with the expectation that the platform is moving toward a more Dataverse-native authorization backbone, which means cleaner governance and potentially better long-term alignment.

In summary, existing customers can probably keep everything basically the same, while new implementations should still follow current Power Pages security design, just with an eye toward the platform becoming less weird over time.

Does This Matter?

Is it actually a game-changer? Does it matter at all? For end users and site visitors, this will probably be mostly invisible unless it improves performance, consistency, or reduces weird access bugs. Microsoft does mention better performance and faster data operations, but there is not enough public detail yet to know how noticeable that will be in real environments.

For makers, the short-term effect may also be modest because Microsoft explicitly says no changes are required, and existing configurations stay intact. But for admins, consultants, and architects? This could be a meaningful improvement. Why? Because those are the people who pay the tax for conceptual duplication. They are the ones who have to explain the split, document the split, govern the split, troubleshoot the split, and defend the split to confused clients who reasonably ask why portal security and Dataverse security don’t line up more cleanly.

So, my verdict is this: It is less a flashy revolution and more a long-overdue structural cleanup that could have strategically big benefits.

Power Pages Security in a Nutshell: Going Forward

• Power Pages security concepts are not disappearing overnight. Microsoft says current configurations remain intact.
• The underlying authorization story is becoming more Dataverse-native. Power Pages users and roles will also exist as system users and security roles.
• This matters most for governance, auditing, and admin sanity. That is where the real payoff likely sits.
• Existing customers should mostly stay the course, but test. No migration does not mean no validation.
• New implementations should still follow the documented current model. Build with web roles, page permissions, and table permissions properly, while recognizing that Microsoft is clearly trying to unify the platform underneath.

Sources

• Microsoft Learn – Unify Power Pages authorization by merging web role with Dataverse security role
• Microsoft Learn – Power Pages security
• Microsoft Learn – Set page permissions
• Microsoft Learn – Set table permissions in Power Pages
• Microsoft Learn – Security concepts in Microsoft Dataverse
• Microsoft Learn – Assign security roles

---