Review this. A zero-trust programme has shipped a device agent on every laptop, mutual TLS between all services, a policy decision point in the request path and a 94-page policy catalogue. Meanwhile 340 engineers hold standing administrator roles in production, break-glass is a shared account whose password is in a vault, and the policy engine fails closed with one replica. What would you remove, what would you change, and what would you leave alone?

What is actually required

Zero trust is a claim that access decisions are made per request, from identity and context, rather than from network position. Judged against that claim, the programme has built the plumbing and skipped the decision. 340 standing administrators means the most consequential access in the estate is granted permanently, in advance, to a population nobody can justify individually.

What I would remove, and why it is safe to

• The single-replica fail-closed policy decision point. As built, one component's availability bounds the entire estate's, and it fails closed - so a policy-engine restart is a total outage. Either it gets at least three replicas across zones with a sub-second timeout and a documented fail-open path for read traffic, or it comes out of the request path. A control whose own failure is the biggest risk it introduces is not a control.
• Most of the 94-page catalogue. A policy document that nobody can hold in their head is not enforced by anything; the enforcement is in the engine's rules. Keep the rules, keep a page of principles, and delete the rest - because its real function is to make an auditor's question answerable with a document rather than with evidence.
• The shared break-glass account. A shared credential removes attribution at the exact moment attribution matters most. Replace it with per-person emergency elevation that is auto-approved, time-boxed, loudly alerted and reviewed afterwards.

The one change that matters

Eliminate standing production administrator access. Just-in-time elevation: a request, an approval (or auto-approval with notification for defined scenarios), a one-hour expiry, a reason recorded, a loud alert, and a weekly review of what was used. Nothing else on the list reduces risk comparably, because every other control is bypassed by someone who already has administrator rights.

Sequence it to avoid breaking the organisation: measure who actually used administrator rights in the last 90 days - typically a small fraction of the 340 - remove standing access from everyone who did not, ship the elevation path for those who did, then remove theirs.

What I would leave, even though it looks odd

• Mutual TLS everywhere, despite its latency and certificate-rotation burden. It is the precondition for service identity, and retrofitting it later is far more expensive than carrying it now.
• The device agent, which is the only source of the device posture signal that makes per-request decisions meaningful rather than identity-only.

How I would argue this in the review

With one measurement, not an opinion: what fraction of the actions the programme claims to control could be performed by one of the 340 standing administrators without triggering any policy? If the answer is "most", the programme's own definition of success has not been met, and that is an argument its sponsors can act on. Then offer the trade - I will support the next phase of investment if standing privilege goes first - so the conversation is about sequencing rather than about whether the work was worthwhile.

Common weak answers

• "Remove all 340 roles on Friday." Correct destination, wrong method: it breaks the organisation and the roles will be restored by Monday with the lesson that the programme is unworkable.
• "Add approval workflow to the existing standing roles." An approval on a permission somebody already holds is theatre, since the permission is what grants the access.
• "Rewrite the 94-page catalogue properly." Months of document work that changes no access.
• "Make the policy engine fail open everywhere." Removes the outage risk and also the enforcement; the distinction worth drawing is fail-closed for privileged writes and fail-open for reads.