All writing
Birthright Access

Birthright Access vs. Least Privilege: Resolving the Onboarding Tension

Generous birthright access makes day-one productive and least privilege impossible. Stingy birthright protects you and floods the help desk. Here is how I square the circle.

19 May 2026·3 min read·Aditi Shah

There is a genuine tension at the heart of identity design that no framework resolves for you. On day one, a new starter needs enough access to be productive — and every hour they spend unable to do their job is a cost the business notices immediately. But every entitlement you grant by default, to everyone, is standing privilege that erodes least privilege and inflates your attack surface in ways the business doesn't notice until there's an incident. Birthright generosity and least privilege pull in opposite directions.

Separate "productive" from "complete"

The reframe that resolves this: birthright access should make someone productive, not complete. Productive means the handful of things every person in that role uses on day one — email, the core line-of-business app, collaboration tools, the basics. Complete means everything they might eventually need, which is a much larger and far more person-specific set. Conflating the two is what drives bloated birthright. Grant productive automatically; make complete an explicit, governed request as the need arises.

Derive birthright from role, and keep it small

Birthright should be role-derived and ruthlessly minimal. The discipline is to ask, for every candidate entitlement: does literally everyone in this role need this on day one? If the answer is "most people, eventually," it is not birthright — it is requestable access. Keeping birthright small is the single highest-leverage thing you can do for your long-term least-privilege posture, because birthright multiplies across every member of the role and is the hardest access to ever claw back.

The clawback problem

Birthright access is uniquely sticky. Nobody ever files a request to remove the access everyone gets by default, and reviewers approve it precisely because everyone has it. Over-granting birthright is a decision you live with for years. Under-granting it costs a few help-desk tickets in week one. The asymmetry should make you stingy.

Make requesting the missing access frictionless

Stingy birthright only works if getting the rest is fast and easy. If requesting access means a five-day ticket and three approvals, people will hoard, share credentials, and route around your controls — and you will have created the exact behaviour you were trying to prevent. Invest in a self-service access request experience with sensible auto-approvals for low-risk entitlements and quick human approval for the rest. The goal is that requesting access is barely slower than already having it.

Use access intelligence to tune the line

Over time, usage data tells you where the birthright line should sit. If 95% of a role requests the same entitlement within their first week, that is a candidate to promote into birthright. If a birthright entitlement goes unused by most of the role, demote it to requestable. Birthright should not be set once and frozen; it should be tuned continuously against what people in each role actually do. That feedback loop is how you converge on the smallest birthright that still feels generous to the user.

The tension between day-one productivity and least privilege is real, but it is not a stalemate. Productive-not-complete birthright, derived from role and kept minimal, paired with frictionless governed requests for everything else — that is how you give people a great first day without mortgaging your security posture to do it.

Birthright AccessLeast PrivilegeOnboardingIAM
Aditi Shah
Aditi Shah
Cybersecurity & IAM Specialist, Melbourne — 12+ years across regulated finance, government & telecom. About →

Looking for an IAM lead who thinks this way?

I help regulated enterprises govern identity at scale — from SailPoint to PAM to audit.

Get in touch