Everyone on the engineering team can reach production. Not because anyone decided that, but because at eight people it was obviously right, and nothing has forced a decision since.
At some point the number of people who can read every customer's data stops being something you would say out loud to a customer. That point arrives before anyone notices, because nothing breaks.
This post is how to narrow production access without making the team unable to work. For whoever would have to answer the question.
Separate the three things people actually need
"Production access" is one phrase covering several needs with very different risk, and conflating them is why it is granted broadly.
Seeing what happened. Logs, traces, metrics, error reports. This is the overwhelming majority of what engineers need, and it does not require access to production systems at all. If your observability platform is good enough, most requests for production access disappear.
Reading data. Looking at a specific record to understand a bug. Needed occasionally, satisfiable with a read-only path scoped to what the question requires, and this is where support tooling belongs rather than a database prompt.
Changing things. Running a command, editing data, restarting a service. Genuinely needed in emergencies, rarely otherwise, and the only one that deserves the heavy controls.
Splitting these turns "does everyone need production access" into three questions with different answers, and two of them become easy.
Make the safe path better than the unsafe one
The reason people hold standing access is that requesting it is slow. If getting temporary access takes twenty minutes and a colleague's approval at 03:00, engineers will keep a credential rather than depend on it, and they will be right to.
So the elevation path has to be fast: self-service for read, a second person for write, measured in a minute rather than an hour. Then standing access can be removed without anyone losing the ability to do their job, which is the only version of this that survives.
Invest in the request path before removing the access. In that order.
What good looks like
Time-bounded by default. Access expires in hours, not indefinitely. This alone removes most of the accumulated permission in a typical estate.
A reason recorded at request time, because it is trivial to give then and impossible to reconstruct later. It also makes the monthly review readable.
Attributable to a person, never a shared account. If five engineers use one credential, your audit log has one name in it and it is not anyone's.
Scoped to the task. Read-only for reading. One service rather than everything. One tenant where the question concerns one customer.
Visible. An elevation posts to a channel the team sees. Not to catch wrongdoing, but because visibility is what keeps a control honest at small scale, where formal review is disproportionate.
Logged with what was done, not merely that access was granted. Session recording for interactive access is heavy and it is the difference between knowing someone had access and knowing what they did with it.
Break-glass is a separate thing
There must be a path that works when the elevation system does not, because the elevation system depends on identity, and identity is exactly what fails in the incidents where you need it most.
Keep it separate, pre-provisioned, loudly alerting on use, and reviewed after every use. The mistake is letting the emergency path become the ordinary path because it is quicker, which happens quietly whenever the ordinary path is slow.
The measurement
How many people have standing production write access? One number, and most teams are surprised by it because it includes service accounts, a former contractor, and two people who changed roles.
How often is elevation used, and by whom? If it is never used, either nobody needs it or everybody still has standing access.
What proportion of elevations recorded a reason that means something? "Debugging" repeated forty times is a process that has become a formality.
What a customer or auditor will ask
Expect: who can access customer data, how is that access granted and removed, is it logged, is it reviewed, and can you show a sample.
The answer that lands is specific: how many people, under what conditions, for how long, and with what record. "Only engineers who need it" invites the follow-up and does not survive it.
The concession
Tight production access has a real cost on the worst day. An outage where the person who can fix it is waiting for an approval is a worse outcome than the risk you removed, and every engineer who has lived through one will tell you so.
That is what the break-glass path is for, and why it must be genuinely fast and genuinely separate. The trade only works if the emergency route is reliable. If you tighten access without building that first, you will be overruled the first time it costs you an hour of downtime, and you will deserve to be.
The implication
Nobody decided that everyone should have production access. It is the residue of a smaller company, and it persists because removing it requires building something and nothing forces the issue.
Count the people with standing write access today. Whether that number is one you would be comfortable stating to your largest customer is the whole of the question.
