Problem
Should developers have access to production?
Also asked as: should engineers have production access, and how do we remove standing access to production without slowing everyone down.
Yes — for a window, on request, with the window's end chosen before it starts. The other two answers both fail, in opposite directions.
Developers should have access to production when they are doing production work, and not otherwise. In practice that means no standing production access, a request path fast enough that nobody routes around it, approval only where the access warrants a second person, and automatic removal when the window ends.
The three answers teams give
| Answer | What it looks like | How it fails |
|---|---|---|
| Never | Only an operations team touches production; developers file tickets | Incidents wait on a handoff between the person who understands the code and the person allowed to look at it. The rule survives until the first bad outage, then quietly gets an exception list that never shrinks. |
| Always | Every engineer holds production roles permanently, because it is simpler | Every laptop, every token and every coding agent running as an engineer can change production at any hour. It works until one of them is compromised or wrong, and then the blast radius is everyone. |
| For a window | Access is requested for a task, granted for hours, and removed automatically | Only if the request path is slow. Then people keep standing access anyway, and you have built the second answer with extra steps. |
The third answer is the only one that holds up, and it has exactly one failure mode. Almost everything below is about avoiding it.
The request path has a latency budget
Engineers keep standing access for one reason: getting it on demand is slower than the work. If a request takes a day, a developer who needs production twice a week will lobby for a permanent role, and they will be right to. So before removing anyone's standing access, decide how fast the request path has to be, and measure it:
- Read access — logs, dashboards, read replicas — should take under a minute. Self-service, no approver, recorded.
- Write access during working hours should take minutes: one other person's approval, and approvers who are notified the moment a request arrives rather than when they next check a queue.
- Write access during an incident should take no longer than the on-call engineer spends reading the alert. That usually means the on-call rotation's package is pre-approved for whoever is on call, or an emergency path exists for an approver who is not answering.
A request path that misses these numbers is not a control. It is a queue people learn to avoid.
Who should approve what
Approval is worth something only when the approver can judge the request and is likely to say no sometimes. An approval that is always yes is a delay with a signature on it, and it trains everyone to click approve without reading.
| Access | Approval | Why |
|---|---|---|
| Read-only production | None — auto-approved and recorded | The risk is data exposure, which the window and the record bound. A human approver adds latency and no judgment. |
| Deploy or operate a service the requester owns | A teammate or team lead | They know whether the task is real and the window is sensible. |
| Direct access to customer data | Someone outside the requester's team | The risk is misuse, and a peer who shares the deadline is the wrong check on it. |
| Identity-provider or cloud-tenant admin | A named, short list of approvers | Whoever holds this can grant themselves everything else. |
Nobody approves their own request in the ordinary path. An emergency path where they can is a separate, deliberate decision, with loud notification and a short expiry — the break-glass guide covers what it has to get right.
Moving a team off standing production access
- Build the request path first. Name the access people actually use as a handful of packages, and have them working before anything is taken away.
- Measure it against the budget above for a couple of weeks while standing access still exists. If people are not using the path when they do not have to, find out why before you make them.
- Remove standing access one group at a time, starting with the one whose members use production least. Keep an escape hatch back to today's access for the first few weeks; it will be used less than you expect.
- Leave the exceptions on a short list: break-glass accounts and the rare role that genuinely is full-time. Review that list, and only that list, every quarter.
The migration guide walks through the same sequence with the product, including the escape hatch.
What changes for the developer
Less than people fear. A developer who needs production for an afternoon asks for it, gets it in a minute or two, and does not think about it again — the removal happens without them. What they lose is the ability to change production at a moment they did not choose to: while on holiday with a stolen laptop, or when a tool running under their name does something they did not ask for. That is also the loss a security lead is trying to buy.
How TemprBac fits
TemprBac is the request path. Access is defined as packages — groups across Entra ID, Okta, Google Workspace, GitHub, AWS IAM and Active Directory — each with its own window of one to eight hours and its own approval rule: auto-approved, or approved by a list of named approvers who are emailed when a request arrives. An org can enable break-glass for the approver who is not answering. Every grant is recorded and removed automatically when its window closes, and no plan limit or billing state can stop that removal.