Birthright access is the baseline set of tools and permissions someone gets simply by joining an organization, or a specific department within it, without individually requesting any of it. It's meant to remove friction on day one. The risk is treating it as a permanent, unreviewable default just because it's automatic, when it deserves exactly the same ongoing scrutiny as anything else.
Quick Summary
Birthright access describes the access every employee, or every employee within a defined segment, receives automatically based on simply being who they are: a new hire, a member of the Sales department, someone based in a specific region. Not access they individually requested.
It's one of the most valuable applications of provisioning automation, since it removes the friction of a new hire waiting on basic tools. It's also easy to under-govern, precisely because "automatic" can start to feel like "settled" when it shouldn't.
This piece covers how birthright access actually gets delivered in Zluri, how it's scoped to the right segment rather than applied universally by default, and why it still needs the same periodic scrutiny as any other access grant. (For the broader concept, what qualifies as birthright, why it covers only part of an employee's eventual access, and how the market approach evolved, see the full guide to birthright access.)
The Staged Delivery Model
Birthright access is one stage within a broader, staged onboarding sequence, not a single, isolated action.
A representative pattern chains multiple playbook actions within a single Automation Rule, each with independent timing:
The staging matters because birthright access typically isn't the very first thing that should happen. Foundational identity setup and communication access often need to exist first, with the baseline application and license bundle following once those earlier steps are confirmed.
Universal vs. Segment-Level Birthright
Not all birthright access should apply company-wide, and the distinction between universal and segment-level birthright is a real design decision, not a detail to overlook.
Genuinely universal birthright, something every employee gets regardless of role, department, or location, runs through an unconditioned playbook action, applying identically to anyone the rule matches.
Segment-level birthright, the baseline bundle specific to Sales, or Engineering, or a particular office location, requires an Add Condition scoping the relevant application block to that specific segment: department equals Sales, for instance. That's what makes the "baseline" bundle actually reflect what's baseline for that specific group, rather than a generic, company-wide default that doesn't fit most roles particularly well.
Recommended Apps as the Practical Starting Point
Building out a segment's birthright bundle doesn't have to start from a blank canvas.
The workflow builder's Recommended applications, surfaced based on the selected users' role, department, and location, give a practical starting point for what a specific segment's baseline should look like: which apps a typical Sales hire, or a typical Engineering hire, tends to need from day one. Nobody has to independently reconstruct that list from scratch for every new segment being defined.
Group Membership as an Alternative Delivery Mechanism
Birthright access doesn't only have to be delivered through an onboarding playbook directly.
Assigning a new hire to the appropriate Group, itself a relationship synced from a connected identity provider, delivers the equivalent outcome through a different mechanism: license assignment and access changes tied to group membership apply automatically the moment that membership is established. That functions as a form of birthright delivery keyed off group assignment rather than a workflow action explicitly built for it.
Both paths lead to the same practical result. Which one an organization uses often comes down to whether its existing identity provider structure is already organized around the groups that would need to exist anyway.
Turning a Birthright Bundle Into a Reusable Standard
Once a segment's birthright bundle is defined correctly, saving it as a Playbook is what actually makes it a standard rather than a one-time build.
A playbook run consistently for every matching new hire in that segment is what ensures two people joining the same department on different days receive identical baseline access, rather than a slightly different bundle depending on which admin happened to configure their onboarding that particular week.
Why Birthright Access Still Needs Governance
This is the point worth taking seriously rather than treating birthright access as a solved, set-and-forget category. Access granted automatically is still access, and it still needs periodic verification that it remains appropriate.
A segment's baseline bundle from two years ago might include a tool the team has since moved away from, or a license tier nobody in that segment actually uses to its full extent. Two mechanisms keep that in check:
Access Reviews can be scoped to a specific segment's birthright bundle just as they can to any other access category, so the baseline itself gets certified periodically, not just the individually requested access on top of it.
Optimization's usage-based detection applies to birthright-granted licenses exactly as it does to individually requested ones. An unused license is an unused license, regardless of whether a person requested it or received it automatically as part of their baseline bundle.
Treating birthright access as permanently exempt from review simply because it was never individually requested is exactly the gap that lets a stale, oversized baseline bundle persist far longer than it would if someone had actually asked for each piece of it individually.
Frequently Asked Questions
Is birthright access the same for every employee, or can it differ by department?
It can, and often should, differ by segment. Universal birthright access applies to everyone regardless of role, while segment-level birthright, scoped through a condition on department, location, or a similar attribute, reflects the baseline bundle appropriate to a specific group rather than a single, one-size-fits-all default applied company-wide.
Does birthright access provision immediately on someone's first day, or can it be staged?
It can be staged as part of a broader onboarding sequence, with birthright provisioning as one specific step, commonly timed to fire exactly on the onboarding date itself, following earlier steps like identity creation and communication channel setup that are often sequenced to happen first.
Should birthright access ever be reviewed, given that it's granted automatically rather than individually requested?
Yes. Automatic delivery doesn't exempt a grant from needing periodic verification that it's still appropriate. Access Reviews and usage-based optimization apply to birthright-granted access exactly as they do to individually requested access, since an unused or outdated baseline bundle represents the same waste and risk regardless of how it was originally delivered.
Can group membership deliver the same outcome as an onboarding playbook's birthright provisioning step?
Yes, through a different mechanism. Assigning someone to the appropriate group can trigger the same license and access outcomes automatically, keyed off the membership change itself rather than a workflow action explicitly built for onboarding, which is a viable alternative depending on how an organization's identity provider is already structured.
.svg)
