Granting is not the hard part
Everyone can grant narrowly on day one. Least privilege fails over time, because the forces acting on an entitlement are asymmetric: adding permission unblocks someone who is currently blocked and is therefore urgent and popular.
Removing permission has no visible benefit and a non-zero chance of breaking something at an inconvenient moment. Run that asymmetry for three years across joiners, movers and leavers and you get privilege creep, where the most senior engineers hold the union of every role they have ever occupied and nobody dares touch it.
So the practical form of least privilege is mostly about the unglamorous half. Entitlements have owners and expiry. Access granted for a project ends when the project does, which works far better if it was granted with an end date than if someone has to decide to remove it. Movers are treated as leavers-and-joiners rather than as additions, which is the single change that stops accumulation.
And access reviews exist and have teeth. The reviewer is the person accountable for the resource rather than the requester's manager, the review presents effective access rather than role names, and the default action for no response is removal.
A review that shows a manager forty rows of role names they cannot interpret produces approval of all forty. That is worse than no review because it manufactures evidence of a control that is not operating.
The design tension worth naming is between role explosion and role vagueness. Model roles too finely and you get thousands of them, nobody can reason about the set, and requests get approved by pattern-matching on names. Model too coarsely and every role is a superset of what its holders need.
The workable middle is a small number of coarse roles for routine work, plus fine-grained, time-bound elevation for the rare operations. Express permissions against attributes - this team, this environment, this tenant - rather than enumerating every resource. What you are optimising for is not minimal permission on paper but a permission set a human reviewer can hold in their head, because a control nobody understands is not being applied.
Privileged access is a different problem
Ordinary access control asks who may use the application. Privileged access asks who may act outside it: production database sessions, cloud administrator roles, key management, CI/CD credentials, identity provider administration. These are different because the blast radius is unbounded and because the privileged operator can usually alter the record of what they did, which is precisely what makes the audit trail's ownership a separate question.
The target state is that nobody holds administrative rights while sitting idle. Elevation is requested, tied to a ticket or an incident, approved by someone else, granted for a bounded window, scoped to the environment in question, and expires by itself.
That last property does most of the work: an entitlement that expires cannot be forgotten. Shared privileged accounts should not exist, because they destroy attribution. Where a system genuinely only has one root credential, it belongs in a vault that brokers a session per person and records it. High-risk sessions are recorded, not to watch people but so that "what happened during that window" is answerable later.
The population people forget is the non-human one. In most estates, service accounts, CI runners, automation identities and integration tokens outnumber employees several times over. They were provisioned by whoever needed them, granted broadly to make the pipeline pass, belong to nobody in particular, and their credentials do not expire.
A convincing answer names them: every workload identity has an owner, uses short-lived federated credentials rather than a static secret where the platform allows it, and appears in the same review as human access. An interviewer asking about least privilege and hearing only about employees will conclude you have not run this in a real environment.
What separation of duties is for
Separation of duties comes from accounting, and its purpose is narrower and more useful than "limit access". It exists to ensure that no single person can both carry out a sensitive act and suppress the evidence or the check on it. The unit of concern is therefore not a permission but a combination: a pair or set of entitlements that is individually defensible and jointly dangerous.
| Toxic combination | What it enables | Usual split |
|---|
| Create a supplier record and approve payments | Invent a supplier and pay yourself | Vendor master data sits with a different function from payment release |
| Raise a purchase order, receive the goods and approve the invoice | Pay for goods that never arrived | Three-way match across three owners |
| Write code and deploy to production unreviewed | Ship a change nobody saw, including a deliberate one | Pipeline enforces a second approver; no manual path around it |
| Grant entitlements and hold them | Give yourself whatever you need, retroactively legitimate | Identity administration cannot approve its own requests |
| Administer the data and administer its audit trail | Act, then edit the history of acting | Audit store owned outside the team it audits |
| Create a user account and activate or approve it | Manufacture an identity | Provisioning separated from approval |
| Issue refunds and edit customer bank details | Redirect refunds to yourself | Financial data changes require independent verification |
Two points make this more than a list. First, the risk lives in the intersection of a person's total entitlements, across every system, accumulated over their whole tenure. Nobody ever requests a toxic pair; they request one half of it in March and the other half in October, and both requests are approved correctly by different approvers looking at different systems.
Detecting that requires a single view of effective access and an explicit ruleset of forbidden combinations evaluated against it, which is one of the few places where buying an identity governance product beats building one. Second, the combination can be reconstituted temporarily by mechanisms designed for good reasons: an on-call escalation, a delegation while someone is on leave, a break-glass role, or the group membership left behind by a team move. Preventive controls that only evaluate steady state miss all four.
The part where you are honest about size
Full separation of duties assumes enough people to separate. On a team of four, insisting that the person who wrote the migration cannot run it means the migration does not run.
The mature answer is not to pretend, it is to name the compensating control and its weakness: the act still requires a second pair of eyes even if that person is from another team, the action is executed through an automated path that produces its own record rather than by hand, the record lands somewhere the actor cannot modify, and the review is detective rather than preventive — someone competent looks afterwards, on a schedule, and would notice. Auditors accept compensating controls that are specific, evidenced and reviewed.
What they reject is the claim that a preventive control exists when in practice one person can do everything and the mitigation is that they are trusted.
That is also the sharpest way to test your own design. For each sensitive act, ask who could perform it and then make the record of it disappear, including everyone with administrative access to the underlying platform. If the answer is not "nobody", you have found the real gap, and it is usually not in the application's permission model at all — it is in the cloud account, the database superuser, or the CI system that can deploy anything anywhere.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).