TL;DR
Least privilege for Power Platform developers fails when “remove Production admin” turns into “developers cannot see anything in Production”. The fix is observability without authority, fixing forward through the pipeline instead of hot-patching, break-glass access for real emergencies, and a golden path that makes the governed route the easy one.
Table of Contents
In Part 1, “Stop giving developers system administrator access just so they can deploy”, I argued that deploying to production and administering production are two different jobs, and that Power Platform pipelines lets you separate them. There is a failure mode that gives least privilege a bad name, though, and it deserves its own post: teams that strip production access and accidentally blind the very developers who keep the system running.
This is Part 2 of the series. Here I cover how to make least privilege for Power Platform developers genuinely workable: what developers need to see in production, how to handle emergencies without configuration drift, and how to design a path people follow because it is easier, not because policy forces them.
Least privilege fails when it blinds developers
When access removal becomes operational friction
Here is how good intentions can go wrong. An organisation removes production access and announces, “developers are no longer allowed into production.” The policy looks clean on paper. Then something breaks.
The developer who owns the application cannot see enough telemetry to work out why. Every investigation now needs a platform administrator to pull logs or check a flow run. Support slows to a crawl. The developer gets frustrated, the business feels the outage drag on, and eventually someone requests permanent System Administrator again, because the restricted model is operationally unusable.
That is not successful least privilege. That is poor operational design wearing a security badge. Locking people out is easy. Designing the right, narrow access is the actual work.
The better question to ask
The better question is not whether developers should be “in” or “out” of production. It is this: what does a developer genuinely need in production to support a workload, without receiving unrestricted rights to change it?
Observability without authority
Separate visibility from control
Most of what a developer needs in production is the ability to see, not the ability to change. Those two can, and should, be separated. Depending on the architecture, appropriately scoped read access might cover:
- application monitoring;
- flow run history;
- telemetry and logs;
- integration diagnostics;
- deployment history;
- error information;
- support dashboards;
- relevant Dataverse data where there is a clear business justification.
The goal is observability without unnecessary authority. A developer should be able to diagnose most problems without also holding the ability to casually rewrite the live system. Get this right and you remove the biggest reason people ask for System Administrator access back: not because they wanted to change production, but because they could not see enough to support it.
Design effort is part of the control
To steelman the other side: yes, defining these read scopes takes design effort, and Dataverse data access in particular needs care where records are sensitive. That effort is the point. It is far cheaper than the standing admin grant you are trying to avoid, and far easier to defend in a security review.
Fix forward, do not hot-patch production
Why quick fixes create long-term risk
The other big driver of elevated access is emergency remediation. Something breaks, a developer opens production, makes a quick change, and everything works again. Problem solved. Except it is not.
Development still holds the old version. Development and production have diverged. The next deployment may quietly overwrite the emergency fix, or nobody remembers exactly what changed at 2am. That gap has a name: configuration drift. It compounds every time someone hot-patches the live system.
Fix at the source, then redeploy
The stronger principle is to fix the issue at the source and redeploy it through the controlled path wherever reasonably possible: diagnose using telemetry, reproduce or correct in Development, validate the change, deploy through the pipeline, then confirm production has recovered.
There will be genuine emergencies where that loop is too slow. Pretending otherwise is how you end up back at standing admin. The answer is not to abandon the principle, it is to design a proper exception for the moments that need one.
Design break-glass access instead of permanent privilege
Make exceptions deliberate and temporary
There is a big difference between two sentences. The first: “developers have System Administrator forever, because they might need it one day.” The second: “developers can receive controlled elevated access when an incident genuinely requires it.”
What a practical break-glass model includes
The first is a standing risk. The second is a managed exception. A break-glass model for Power Platform production access can include:
- documented justification;
- an approval step;
- time-limited elevation that expires automatically;
- auditable activity for the duration;
- association with a specific incident;
- removal once the issue is resolved;
- review of any direct changes made;
- reconciliation of those changes back into the managed source.
That gives you a controlled exception without letting the exception quietly become the everyday operating model. The privilege exists when an incident calls for it, only for as long as it is needed, and with a clear trail of what happened.
Protect the golden path
Make the governed route the easiest route
Removing unnecessary production access gets dramatically easier when the supported route is also the easiest route. If developers have to fight governance to ship, they will route around it, and who could blame them.
A strong golden path guides people from build to operate: build in the correct Development environment and solution structure; validate with automated quality and security checks early; test by promoting into Test or UAT with repeatable ALM; approve with release controls sized to the risk; deploy through a controlled pipeline and delegated deployment identity; operate through accessible telemetry; and elevate only when an exceptional scenario demands it.
Use tooling to reinforce the path
The platform should guide developers toward good behaviour, rather than relying on everyone to remember every governance rule on a bad day. Power Platform Pipelines are built to give makers and developers a more accessible application lifecycle management (ALM) path, and pipeline extensions can add approvals and pre-deployment checks, per Microsoft’s Power Platform pipelines documentation. When the governed path is the path of least resistance, least privilege mostly enforces itself.
Match separation of duties to the risk
Separate duties where the risk justifies it
The architectural principle underneath all of this is simple: the person creating a change does not necessarily need unrestricted authority over the environment where that change runs.
The right amount of separation depends on the workload. For a low-risk departmental app, strict separation of duties may be overkill. For sensitive, regulated, or business-critical systems, it matters a great deal. Let the level of separation follow the risk, rather than applying one blanket rule everywhere.
Map access to tasks, not job titles
That is the whole point. Avoid swapping one oversimplified rule, “everyone needs production admin”, for the opposite oversimplified rule, “no developer can ever touch production”. Both miss the nuance. Instead, ask a sharper set of questions for each workload:
- What does this developer need to build?
- What do they need to diagnose?
- What does the deployment process need to deploy?
- What access requires human approval?
- What should only ever exist temporarily?
- What can be automated away entirely?
Those questions produce a far stronger access model than any single rule, because they map access to tasks instead of to job titles.
The payoff
What least privilege should achieve
Least privilege for Power Platform developers is not about locking people out. It is about giving each identity, human or not, exactly the authority its task requires: build access in Development, read access to diagnose in production, a governed process to deploy, and a controlled break-glass door for the rare genuine emergency.
The business impact is worth stating plainly. You get a smaller attack surface, cleaner audit trails, fewer unexplained 2am changes, and developers who stay fast because the safe path is also the convenient one. That is a delivery model you can scale and defend at the same time.
The future of enterprise low-code should not depend on giving every developer broad production privileges just because our deployment processes were once designed around human access. We can do better, and the tooling is finally there to let us.
Talk to Arinco
Ready to design a Power Platform access model that keeps developers fast and production safe? Arinco’s Power Platform and Azure teams build governed ALM, observability, and break-glass patterns for exactly this. Get in touch at arinco.com.au/contact
Frequently asked questions
Should Power Platform developers have production access?
Developers generally need production visibility, but not unrestricted production administration. Read access, monitoring and deployment controls usually provide a safer operating model.
What is break-glass access in Power Platform?
Break-glass access is temporary elevated access granted during incidents, with approval, auditability and automatic removal.
How do Power Platform pipelines support least privilege?
Power Platform pipelines separate deployment permissions from environment administration, helping organisations implement separation of duties.
