TL;DR
A developer who needs to deploy to Production is not necessarily a developer who needs to administer Production, yet many teams still bundle the two by granting System Administrator access. Power Platform Pipelines supports delegated deployments, allowing a maker to request a deployment that runs under a separate identity. This keeps developers moving while reducing standing administrative access and improving governance.
This is Part 1 of 2 in a series on production access and least privilege in Power Platform.
Table of Contents
The hidden assumption behind Power Platform production access
For years, one request has quietly shaped how organisations grant Power Platform production access: “The developer needs to deploy, so give them System Administrator.”
It sounds reasonable. It is also the wrong default, and the platform has evolved enough that we should stop reaching for it.
Here is the sleight of hand. A developer needs the ability to initiate or request a deployment. That is not the same as the ability to directly administer, customise or modify Production. Two different requirements became welded into one role because, historically, that was the easiest way to make deployment work.
This is Part 1 of a two-part series. In this post, I make the case that deployment and administration are separate jobs and show how to separate the identity that requests a change from the identity that executes it.
Part 2 covers the harder half: giving developers enough visibility in Production to support their workloads without handing back the keys.
Deployment and administration are two different jobs
Picture the environment model almost everyone runs: Development, then Test, then Production.
Developers legitimately need real power in Development. They build applications, modify Dataverse components, create flows, configure connection references and troubleshoot their own work. Test may also require elevated access, depending on the operating model.
Production is a different animal. It holds live data, active integrations and the business processes your users depend on every day. So “who can change this” carries nothing like the stakes it carries in Development.
Now hold those two facts next to each other. The access a developer needs to build lives in Development. The access needed to change Production is a separate question with a much higher bar. Bundling them because it is convenient is how convenience quietly becomes your security model.
How “just give them System Administrator” happens
The pattern usually is not reckless. It is practical people solving a real problem under time pressure.
The release-pressure shortcut
A release is due. The maker cannot move their solution into Production without rights they do not have. Someone with the authority to grant access wants to unblock the release.
System Administrator is the biggest hammer in the drawer, and it definitely solves the deployment problem. Job done.
It also grants far more access than the deployment requires. Depending on the environment and assigned roles, System Administrator access can include the ability to:
- modify production configuration
- change security roles and assignments
- alter Dataverse components
- create unmanaged customisations directly in Production
- change environment behaviour
- read and modify production data
- change automation and flows
- troubleshoot by editing the live system in place
Why the shortcut feels reasonable
Let me steelman the decision for a moment, because the people making it are not careless.
In a small team, giving one trusted developer broad access is faster than establishing a governed deployment pipeline. The release ships, nothing breaks that week and the habit sticks.
The problem is not that developers are untrustworthy. Least privilege has nothing to do with distrust. It is about designing systems so that an identity receives only the authority required for the task in front of it.
Deployment and administration are different tasks. We should design them that way. A standing System Administrator grant is the design smell that tells you we have not.
Separate who requests the change from the identity that deploys it
A stronger model separates the request from the execution.
A developer creates and validates a change in Development. A deployment is then requested. Automated validation or an approval process runs. A controlled deployment identity carries the change into Production.
At no point does the developer’s own account need standing elevated access in the target environment.
This is not theory on a whiteboard. Power Platform Pipelines supports delegated deployments that run as either a service principal or a pipeline stage owner. When delegated deployment is configured, the pipeline stage deploys using the delegate identity rather than the requesting maker’s identity, per Microsoft’s guidance on delegated deployments.
The consequence is the important part. A maker can request a deployment without holding elevated access, or, in some configurations, any access, in the target environment.
The privilege moves to the deployment process. The developer keeps the ability to ship without carrying a permanent administrator badge around Production.
That reframes an assumption many teams never question: a developer does not need to become a Production administrator simply because their solution needs to reach Production.
Treat deployment as a privileged operation, not a privileged person
Deploying to Production is genuinely powerful. The insight is that this power can belong to the operation rather than permanently belonging to every person who triggers it.
Once you accept that, the roles almost design themselves.
Developer identity: Builds in Development, tests components, packages changes, runs quality validation and requests deployments. It does not routinely customise Production, bypass the approved pathway or make undocumented emergency fixes.
Deployment identity: Performs the controlled deployment operations required by the release process, and nothing more. Its permissions are explicitly scoped and governed rather than inherited by every maker.
Approver or release authority: Assesses release readiness, approves sensitive deployments and enforces separation of duties where the risk warrants it.
Platform administrator: Administers environments, troubleshoots platform-level issues and manages security and governance controls.
In a smaller organisation, these responsibilities may overlap, and that is fine. The principle is that they should not overlap automatically simply because separating them requires more setup.
Design the overlap deliberately, based on risk, rather than defaulting to one identity that can do everything.
The question to ask before granting production access
The next time someone requests System Administrator access in Production because they “need to deploy”, pause and split the request in two.
Do they need to administer Production?
Or do they need a safe, repeatable mechanism for moving an approved change into Production?
Those are not the same requirement, and modern Power Platform application lifecycle management gives you a clean way to separate them.
The business impact is concrete. Every standing System Administrator account in Production creates permanent audit exposure, increases the blast radius of a mistake or compromised account, and makes security reviews harder.
Replacing standing administrator access with a governed deployment identity reduces all three. Once the pipeline is in place, you also lose nothing in release speed.
That is a rare trade-off where the safer option is also the more scalable one.
Give developers the access they need to engineer effectively. Give the deployment process the permissions it needs to deploy safely. Stop assuming those permissions have to live in the same identity.
Coming in part 2
Removing Production administrator access only works if developers can still see what is happening in Production.
Next up: observability without authority, fixing forward instead of hot-patching, break-glass access, and creating a golden path that makes the governed route the easy route.
Talk to Arinco
Want a second opinion on how your Power Platform environments manage production access?
Arinco’s Power Platform and Azure teams help organisations design governed application lifecycle management practices that keep developers moving while protecting Production.
Get in touch with us at https://arinco.com.au/contact/ to talk it through.
