Birthright Access Design: Default Entitlements

Birthright access is the access a person receives automatically because of who they are in the organisation, and when it is designed loosely it becomes the largest single source of standing over-provisioning in the estate. Every joiner gets it without a request or an approval, every mover keeps or changes it by rule, and it is rarely reviewed because nobody asked for it. This guide covers how to decide what belongs in birthright, how to layer it by population, the attribute rules that drive it, how movers and leavers change it, how to test and roll it out, and how to measure whether it is staying lean. It is for identity governance architects, IAM engineers and access control owners. The lifecycle around it is covered in the Joiner-Mover-Leaver Guide, and wider role design in the Role Mining and Role Design Guide.

Key takeaways

Birthright is a policy decision, not a convenience: include only access that nearly everyone in a defined population needs from day one and that carries low risk if granted to someone who does not use it.
Layer it by population: an enterprise layer for everyone, then layers for worker type, location and department, each driven by an authoritative attribute rather than by copying another user.
Rules must remove as well as add: the same attribute logic that grants access must take it away when the person moves, or birthright turns into accumulation.
Keep privileged and sensitive access out: admin roles, production access and access to regulated data belong behind a request with approval, never in birthright.
Measure usage: birthright entitlements that most of the population never uses are the first candidates to move to request-based access.

What belongs in birthright

A useful test has three parts. An entitlement belongs in birthright only if all three are true:

Breadth: almost everyone in the population needs it, typically from their first day.
Low impact: granting it to someone who does not need it creates little risk (no sensitive data, no ability to change systems others rely on, no privilege).
Deterministic: need can be predicted from authoritative attributes such as worker type, department or location, without human judgement.

Access	Birthright?	Reason
Email, calendar, collaboration and intranet	Yes, enterprise layer	Needed by nearly all staff; low impact
HR and expenses self-service	Yes, employee layer	Needed by all employees; scoped to own record
Department shared drive (read and write)	Yes, department layer	Predictable from department attribute
Site Wi-Fi, building access for the home location	Yes, location layer	Predictable from location attribute
Developer tooling (source control read, issue tracker)	Often, job family layer	Predictable from job family; keep write and admin out
Finance system posting rights	No	Segregation of duties sensitive; needs approval
Production infrastructure, cloud consoles	No	Privileged; use just-in-time or approved roles
Customer personal data, health or payment data	No	Regulated data; requires business justification
Any administrator role	No	Privileged; see the Least Privilege Techniques Guide

The grey area is access that most of a team uses but that touches sensitive data, such as a support team's ticketing tool that shows customer details. Two common answers: grant a read-only or redacted view as birthright and the full view by request, or keep the whole tool request-based with a pre-approved fast path for that department.

Layering birthright by population

Design birthright as a stack of layers, each tied to one attribute. A person's birthright is the union of the layers they match. This keeps each rule small, makes changes predictable and lets a single attribute change (a move to another department) swap one layer without touching the others.

Layer	Driving attribute (example)	Typical contents	Owner
Enterprise	Active worker record	Email, collaboration, intranet, security awareness platform	IT or identity team
Worker type	Employee, contractor, partner	HR self-service for employees; restricted collaboration for contractors	HR and identity team
Location	Office or country	Site network, building access, local printers, country HR portal	Facilities and regional IT
Department or cost centre	Department code	Department drives, team channels, department distribution lists	Department head
Job family	Job code or family	Role-specific tooling at the lowest useful level	Function lead

Keep layers few: five or fewer layers is usually enough. Beyond that, maintenance cost rises and the rules start to encode exceptions.
Avoid job-title rules: titles are free text and change often. Use coded attributes (job code, department code) from the authoritative source.
Contractors get their own layer: not the employee layer minus a few items. See the Contractor Identity Lifecycle Guide.

Attribute rules and data quality

Birthright is only as good as the attributes behind it. A wrong department code in the HR system grants the wrong department's drives on day one.

Use one authoritative source per attribute: usually the HR system for employees and a vendor management or contractor system for non-employees. See the Identity Data Quality and Authoritative Sources Guide.
Handle missing values safely: a rule that matches on an empty department should grant nothing, not everything. Test the empty case explicitly.
Prefer equality over pattern matching: rules such as department equals a code are easier to audit than "contains" or "starts with" patterns, which can match unintended values.
Do not chain rules on group membership: a rule that grants access because a user is in another dynamically managed group creates hidden dependencies. Some platforms are also retiring group-membership operators in attribute rules, so check your platform's current documentation before relying on them.
Exclude service and test accounts: non-human identities should never fall into human birthright rules. Give them owned, purpose-specific access instead.

How identity platforms express birthright rules

Most identity governance and directory platforms let an attribute rule add and remove access automatically. Platforms are listed alphabetically; the table shows each vendor's own feature name and behaviour from its documentation as of November 2026, and is not a comparison.

Platform	Feature	Documented behaviour
Microsoft Entra ID Governance	Automatic assignment policy on an access package	Membership rule on user attributes; assignments are created and removed as attributes change; an optional grace period keeps access for a set time after a user leaves scope; Microsoft suggests one such policy per access package; requires Microsoft Entra ID Governance or Microsoft Entra Suite
Okta	Group rules	Rules on user attributes or group membership populate groups, which can drive app assignment; users are removed when they no longer match; rules cannot assign users to admin groups; up to 2,000 rules per org
SailPoint	Role membership Standard Criteria	Criteria on identity attributes, account attributes or entitlements assign roles; when an identity stops meeting the criteria the role and its access profiles are deprovisioned; source accounts are not deleted when entitlements are removed

The common design point across all three is that removal is automatic only for access the rule granted. Access granted outside the rule (by request, by hand or by an earlier rule) stays until something else removes it, which is why movers need reconciliation as well as rules. Platform-specific hardening is covered in the Entra ID Entitlement Management and Access Packages Guide, the Okta Security Hardening Guide and the SailPoint Hardening Guide.

Movers, leavers and grace periods

Movers: when the department attribute changes, the old department layer should be removed and the new one added. Decide on a short overlap (for example a few days for handover) and make it explicit, rather than letting old access linger because removal was never configured.
Requested access on move: access granted by request is outside birthright logic. Trigger a manager review of requested access on every move, or attach an end date to it at grant time.
Leavers: birthright should disappear when the worker record ends, but the leaver process must still disable the account itself, revoke sessions and handle accounts the rule created. Removing entitlements does not always delete accounts in target systems.
Rehires and conversions: a contractor converting to employee should move layers cleanly. Test this path, because duplicate identities from conversions are a common source of leftover access.
Grace periods: a grace period after a person leaves a rule's scope helps continuity but extends exposure. Keep it short, document it and exclude sensitive layers from it.

How to implement

Baseline current day-one access: pull what a sample of recent joiners in each population received in their first week, by hand or by rule. This shows the real birthright, including what was copied from other users.
Find common access: for each population, list entitlements held by a high share of current members and actually used. Role mining helps; see the Role Mining and Role Design Guide. Apply the three-part test before accepting anything.
Draft the layers and get owners to sign them: each layer needs an accountable owner who approves its contents, because nobody approves the individual grants.
Clean the attributes: fix empty and inconsistent codes in the authoritative source before any rule goes live.
Simulate: evaluate rules against current users without provisioning. Compare the result to current access: entitlements that would be removed show over-provisioning; entitlements that would be added show gaps.
Pilot with joiners only: apply rules to new starters in one population first, while existing users keep their current access. Track help desk tickets for missing access in the first two weeks.
Extend to existing users in waves: add access first, then remove after notice and an owner review of what will be removed.
Rollback: keep the pre-change entitlement export. If a rule removes access wrongly, disable the rule and restore from the export, then fix the rule and attributes before re-enabling.

Decision guidance: small and large organisations

Question	Small organisation	Large organisation
How many layers?	Enterprise and department, sometimes location	All five, with job family layers for large functions
Where do rules live?	Directory dynamic groups driving app assignment	Identity governance platform with simulation and audit
Who owns layers?	IT lead with department heads	Named layer owners with annual attestation
Grey-area access	Request-based with quick approval	Read-only birthright plus request for full access

Where identity governance meets machine identities

Birthright is a human concept, but it affects non-human identities in two ways. First, service accounts and test users created in the HR feed or directory can match human rules and inherit email, drives and collaboration access they never need, so exclude them by account type. Second, AI assistants and agents acting for a user often inherit that user's access, so a broad birthright widens what the agent can read. Keep agent access scoped separately; see the AI data access review guide.

Detection and measurement

Birthright share: percentage of each user's entitlements that come from birthright rules versus requests and manual grants. Very high manual share means rules are not doing the work; very high birthright share may mean layers are too broad.
Unused birthright: percentage of birthright entitlements not used by a holder within 90 days, per layer. A layer item unused by most holders should move to request.
Day-one completeness: percentage of joiners who raise no access ticket in their first two weeks.
Mover clean-up time: median time from department change to removal of the old layer.
Rule exceptions: number of manual overrides to birthright outcomes, with owner and expiry.
Sensitive leakage: count of privileged or regulated-data entitlements granted by birthright rules, target zero.

Log every rule change with who made it and why, and alert on any change that adds a privileged group or application to a birthright layer.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5	CIS Controls v8.1 (control level)
Define access by population in policy	PR.AA-05	AC-2, AC-3	6 Access Control Management
Automate grant and removal from authoritative attributes	PR.AA-01	AC-2(1), AC-2(3)	5 Account Management; 6 Access Control Management
Keep privileged and conflicting access out	PR.AA-05	AC-5, AC-6	6 Access Control Management
Review layer contents and usage	PR.AA-05	AC-6(7)	6 Access Control Management
Link HR events to access changes	GV.RR-04	AC-2	5 Account Management

Common failure patterns

Model-after-a-colleague provisioning: a joiner is given a copy of a peer's access, inheriting years of accumulated grants. Birthright rules exist to replace this practice.
Rules that only add: the department rule grants on join but nothing removes on move, so long-serving staff hold every department's drives.
Sensitive tools creeping in: a team asks for a tool to be added to its layer for convenience, and it includes customer data or admin functions.
Empty-attribute matches: a rule written as "department not equal Finance" grants access to everyone with no department, including service accounts.
No owner per layer: contents grow by ticket and nobody can say why an item is there.
Reviews that skip birthright: access reviews exclude rule-granted access as "pre-approved", so unused entitlements are never challenged. See the Access Reviews Guide.

Practitioner checklist

Write the three-part test (breadth, low impact, deterministic) into the access policy.
Define no more than five birthright layers, each tied to one authoritative attribute.
Name an owner for each layer and have them approve its contents annually.
Exclude privileged roles, production access and regulated data from every layer.
Configure removal as well as grant for every rule, and test the mover path.
Exclude service, test and agent accounts from human birthright rules.
Simulate rules against current users before enforcement and keep a rollback export.
Report unused birthright per layer quarterly and move low-use items to request.

Birthright Access Design Guide: Default Entitlements Without Over-Provisioning