Power Platform governance: the guidance has not caught up

If you sat down today to build a Power Platform governance model and did the sensible thing, which is to read Microsoft’s own security and governance guidance first, you would be told to set up the Center of Excellence Starter Kit.

That page was updated on 14 August 2026. The CoE Starter Kit page has said since May that the kit is no longer actively maintained and that issues are no longer reviewed or addressed.

Both pages are current. They disagree. And that is a reasonable thing to lead with, because it tells you something about the state of Power Platform governance right now: the platform has moved faster than the guidance describing how to govern it, and anyone following the documentation literally will build on a foundation that is being withdrawn.

The rest of the guidance holds up well. This is about separating the parts that do from the part that does not.

Governance starts with a setting nobody chose

Before any of the frameworks, there is one line in the documentation that determines more about your tenant’s risk position than any policy you will write:

In the default environment, all users in a tenant are granted access to the Environment Maker role.

Everyone. By default. That is not a misconfiguration to find, it is how the platform ships, and it means the default environment is not a sandbox that happens to be permissive. It is a production environment that every licensed person in the organisation can build in.

This is why the guidance is right to say environments are the first thing to understand rather than the first thing to configure. Environments are the containers for everything: apps, flows, connections, Dataverse. Get the environment strategy wrong and every subsequent control is applied to the wrong boundary.

There is a related myth worth killing here, because it makes governance conversations harder than they need to be. Microsoft states it plainly: Power Apps and Power Automate do not give users access to any data they do not already have access to. Low-code tooling does not widen the permission surface. What it does is make existing access easier to use, easier to combine, and considerably easier to move somewhere nobody is looking. The governance problem is real but it is a visibility and combination problem rather than a privilege escalation one, and framing it correctly changes what you build to solve it.

Three access layers, and one that swaps underneath you

Access inside an environment is controlled at three levels: environment roles, resource permissions on individual apps and flows, and Dataverse security roles where a Dataverse database exists.

The behaviour that catches teams out is what happens at the boundary between them. When Dataverse is created in an environment, the Dataverse roles take over control of security for that environment, and all existing environment admins and makers are migrated across. Your access model is not extended by adding Dataverse. It is replaced.

There is a subtler trap in what each role type will accept. In an environment without Dataverse, the environment role can be assigned to a user, a group or the whole tenant. In an environment with Dataverse, the environment role accepts users only.

If your access model runs on Entra groups, as most mature ones do, adding Dataverse to an environment quietly forces part of that model back to individual assignments. That is exactly the kind of thing that works on the day it is configured and decays for two years afterwards as people move roles.

Data policies, and the connectors you cannot block

Data policies are the control most organisations actually implement, and they work by classification rather than by rule. Connectors are placed in groups, and a connector in the business data group can only be used alongside other connectors from that group in the same app or flow.

Two details change how you should design them.

You can assign a Blocked classification to stop a connector being used at all, which is the answer to the question every organisation asks about consumer file-sharing and social connectors. But there is a defined set of connectors that cannot be blocked, so a policy built on the assumption that anything can be prohibited will have holes exactly where the platform’s own dependencies sit.

And policies can be scoped to all environments, or to include or exclude specific ones. That is what makes an environment strategy load-bearing rather than administrative: the environment is the unit your data policy applies to, so an estate with one big environment has one policy setting for everybody.

Worth noting alongside this that premium connectors need a licence and custom connectors have to be explicitly shared, which means some of your governance is already enforced by licensing whether you designed it that way or not.

Beyond data policies, two controls sit outside Power Platform and are underused. Customers with Intune can apply mobile application protection policies to the Power Apps and Power Automate apps on Android and iOS. Customers with Entra ID P1 or P2 can apply conditional access based on user, device and location, targeting Common Data Service. Neither requires anything from the Power Platform admin centre, and both are usually already licensed.

What is actually in there

In our engagements the default environment is almost universally being used as unmanaged shadow production, not as the personal sandbox it is described as.

The composition is lopsided, and both halves matter:

That minority is the whole problem. It is typically departmental onboarding forms, executive approval workflows, and core ticketing integrations built on standard SharePoint connectors, which an entire operational division depends on daily. All of it running with no lifecycle management, no dedicated service accounts, and no disaster recovery backup.

Note what that means about the 80% to 90%. It is not the risk. It is the noise you have to sort through to find the risk, which is why “just clean up the default environment” is not a plan. The cleanup is cheap; the identification is the work.

The licence report that shows what the admin centre hides

A short practical section, because this is the fastest way to find out what is actually running.

The Power Platform admin centre gives you active user and app usage, location, connector service performance, error reporting, flows by type and date, application-level auditing and service health, all under Licensing.

More useful for governance is a PowerShell export:

Get-AdminPowerAppLicenses -OutputFilePath ''

That produces every assigned Power Apps and Power Automate licence in the tenant as a table. The reason it matters more than the portal view is a single sentence in the documentation: the export includes self-service sign-up internal trial plans, and those are not visible to admins in the Microsoft 365 admin centre.

So an organisation that has audited licensing through the Microsoft 365 admin centre and concluded its Power Platform footprint is small has audited the half of the picture that is visible. On a large tenant the export takes a while to run. It is still an afternoon, and it routinely changes the conversation.

Audit data itself flows through activity logging integrated with the Office security and compliance centre, with an API that most SIEM vendors already consume, so the reporting path into your existing security tooling exists without anything custom.

Our position: govern the boundary, not the makers

Our position is that most Power Platform governance programmes are aimed at the wrong target. They set out to control what makers can build, when the durable control is where they can build it.

Maker-level restriction is expensive to run and it degrades. Every exception is a ticket, every ticket is a judgement call, and the volume grows with adoption, which means the governance model gets more expensive precisely as the platform succeeds. Environment-level control does not work that way. A well-designed environment boundary with a scoped data policy governs a thousand apps at the same cost as ten.

So the sequence we would argue for is: fix the default environment first, establish environments that correspond to real boundaries, apply data policies to those environments, and only then think about maker enablement. When that point comes, the maker community should not be allowed to run ahead of support. Across our engagements the estates that are genuinely well governed are not the ones with the most policies. They are the ones where the default environment is not where the work happens.

And we would not now build a governance capability on the CoE Starter Kit, whatever the guidance page still says. That is not a criticism of the kit, which did a job the platform should always have done natively. It is that building new automation on something with no maintenance path is a decision you make once and pay for repeatedly.

The reason restriction fails is not that it is unpopular. It is that it does not work. Locking down maker rights outright stalls innovation and drives citizen developers into unmonitored external SaaS tools. The demand does not disappear when you refuse it. It relocates, and it relocates somewhere with no DLP, no audit trail and no tenant boundary at all. You have not reduced the risk, you have exported it.

Routing makers automatically into isolated environments does the opposite. They build freely, and the blast radius is contained by design rather than by permission.

The pushback, and the sequence that dissolves it

Clients push back almost every time we propose locking down the default environment, and the objection is always the same: IT fears breaking undocumented operational flows. Given what is actually in there, that fear is correct rather than obstructive, and arguing with it does not help.

What works is a phased model, because it separates the two problems.

Phase one, stop the bleeding. Turn on environment routing so new makers are directed into their own developer environments immediately. This changes nothing that already exists, which is precisely why it gets approved. The default environment stops growing on the day you enable it.

Two things about that feature are worth knowing before you propose it, because both come up in the approval conversation.

It is a premium governance feature and it requires managed environments: every developer environment it creates is managed by default. Creating or previewing an app there needs no premium licence, but running one does, and managed environments are not included in the Developer Plan entitlement. So phase one has a licensing consequence, and it is better raised by you than discovered later.

And routing changes where a maker lands, not what they can reach. Makers can still switch back to the default environment whenever they choose. It is a very effective default, not a wall, which is another reason the sharing limits in phase two matter.

Phase two, quarantine and move. Apply strict sharing limits in the default environment, blocking “share with everyone”, rather than turning existing flows off. Then catalogue and migrate the business-critical 10% to 15% into dedicated managed production environments with proper ALM pipelines.

The order is what removes the objection. Nobody is being asked to break anything on day one, and by the time you reach the flows that matter, you have a catalogue rather than a guess.

Where to start

Four things, in order, and the first is the one that matters.

Find out what is running in the default environment. Every user in your tenant can create there, so it is where the unmanaged estate accumulates. Until you know what is in it, you cannot safely restrict it.

Run the licence export, including the trial plans the Microsoft 365 admin centre does not show you, so the size of the estate is a measured number rather than an assumption.

Design environments around actual boundaries before writing policies, because the environment is the unit your data policy will apply to.

Then write the data policy, knowing that some connectors cannot be blocked and planning for those specifically rather than discovering them.

This is the third Power Platform change in a quarter that arrives without an announcement in your tenant, alongside the managed environments licence enforcement and the CoE Starter Kit retirement. The pattern is consistent, and so is the exposure: the estates that get caught are the ones running on a governance model designed two years ago and never revisited.

Veratas runs Power Platform governance reviews, and for estates under managed services this is a standing item rather than a project.

If everyone in your tenant can build in the default environment and nobody can tell you what is in there, talk to our team. That is a measurable question with an uncomfortable answer, and it is better to have it now.

Frequently asked questions

Who can create apps in the default Power Platform environment? Every user in the tenant. Microsoft grants all users the Environment Maker role in the default environment by design, which is why the default environment is usually where an ungoverned estate accumulates.

Does Power Apps give users access to data they should not see? No. Microsoft is explicit that Power Apps and Power Automate do not provide access to data assets users do not already have. The governance issue is visibility and how easily existing access can be combined and moved, not privilege escalation.

What changes when Dataverse is added to an environment? Dataverse security roles take over control of security for that environment, and existing environment admins and makers are migrated. The environment role also stops accepting groups and tenant-wide assignment, and accepts individual users only.

Can we block any connector we want? Almost. Connectors can be classified as business, non-business or blocked, but Microsoft maintains a set of connectors that cannot be blocked. Design your policy knowing which those are rather than assuming full coverage.

Why does our licence count look wrong? The Microsoft 365 admin centre does not show self-service sign-up internal trial plans. The PowerShell export Get-AdminPowerAppLicenses does, which is why it usually returns a larger and more accurate picture of the estate.

How much of what is in the default environment actually matters? In the estates we inherit, 80 to 90% is abandoned experiments, personal productivity helpers and one-off test flows. The remaining 10 to 15% is business critical in practice: onboarding forms, executive approval workflows and ticketing integrations that a division depends on daily, running with no lifecycle management, service accounts or backups.

Should we just restrict who can create apps? No. Blanket maker restriction stalls delivery and pushes citizen developers into unmonitored external SaaS tools, which exports the risk rather than reducing it. Route makers into isolated developer environments instead, so they build freely inside a contained blast radius.

How do we lock down the default environment without breaking things? In two phases. First enable environment routing so new makers land elsewhere, which changes nothing existing. Then apply sharing limits rather than disabling flows, while cataloguing and migrating the business-critical minority into managed production environments with ALM pipelines.

Should we still deploy the CoE Starter Kit? Microsoft’s governance guidance still recommends it, but the kit’s own documentation states it is no longer actively maintained and that issues are not reviewed. For a new governance capability, build on the native admin centre experiences instead.

Anuj Kumar Mishra

Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.