Birthright access

Birthright access is what someone gets because of who they are, not because they asked. A role maps to a bundle of applications and permissions, and a new hire in that role has them on the first morning without a ticket. The name is old and slightly grand; the mechanism is a rule attached to a field in the HR system.

The thing it replaces is a week of asking. A new person opens tickets for the applications they discover they need, each ticket is answered by someone guessing at the right permission level, and the answers accumulate into an access profile nobody designed.

role in the HR system  -->  bundle  -->  accounts, on day one
                                  |
        +-------------------------+-------------------------+
        |                                                   |
   IN THE BUNDLE                                     BEHIND A REQUEST
   everyone in the role needs it, every day          some of them, sometimes
   - email, chat, the wiki                           - production data
   - the team's project tool                         - the billing console
   - the CRM, read-only, for a sales role            - admin on anything
   - the code host, for an engineer                  - the finance system

   granted automatically                             asked for, approved,
   removed when the role changes                     time-bounded, logged

   mover: recalculate the bundle for the new role, add and remove both ways

Why does day one matter?

Because the first day is the one everybody remembers, and because the alternative costs more than it looks.

The courtesy argument

A thread on onboarding antipatterns put it in the plainest terms available:

"Your chair is still on order": Have things ready on day 1. Nothing is worse than waiting on necessary accounts, hardware or people for the onboarding. If you cannot have things ready, at least have the decency to not have your new hire sit around twiddling thumbs, find something interesting and productive to do for them

The cost is real even when nobody complains about it. A new hire waiting on four accounts is a salaried person doing nothing for two days, and the manager chasing those tickets is a second salaried person doing work that should not exist.

The governance argument

There is a governance argument as well as a courtesy one. Access granted in a hurry, one ticket at a time, is granted at whatever level makes the request go away. Access granted from a bundle is granted at the level someone chose once, in advance, when they were not under pressure. The auditable difference is that a bundle is a rule. An access profile assembled from tickets can only be compared against itself, so no part of it is ever demonstrably wrong. A profile derived from a rule can be compared against the rule. Every difference between the two is then either a finding or an approval.

What belongs in the bundle, and what does not?

The daily-use test

The test is not how sensitive the access is. It is whether everyone in the role uses it, every day. Sensitivity decides the permission level and who approves it, and frequency decides whether the access is automatic. That is how a bundle comes to include read access to the system of record while excluding the export button on the same screen.

The two ways a bundle goes wrong

A generous bundle is the common failure and the more expensive one. Access that most of the role does not need becomes standing access for all of it, so every access review carries rows nobody can justify and nobody can safely remove either. A starved bundle fails in the other direction and looks like success on the dashboard. The bundle provisions cleanly while the new hire spends the first week filing the tickets it was meant to replace. The correction for the first is to move the item behind a request with an owner. The correction for the second is to read what the last ten hires were actually given.

How are the bundles derived?

Not by modelling the organisation, but by reading what already happened.

1Read what the last ten hires were granted

Take the last ten hires per function and list what each of them was actually granted, from the applications themselves rather than from the tickets. The tickets record what was asked for, which is a smaller and tidier set than what exists. A good share of any real access profile arrives through a colleague adding someone directly inside a product.

2Keep what appears every time

What appears in all ten is the bundle, and the threshold is strict on purpose. An item present in eight of ten is not a default with two exceptions. It is a request that two people never needed. Promoting it to a default hands standing access to everyone hired into the role from that day on.

3Move what appears sometimes into a request

Anything intermittent becomes a request with a named owner who can approve it. The owner matters more than the form does. A request routed to IT is a ticket with extra steps. A request routed to the person accountable for the data is a decision with a record attached.

4Name each bundle after the role in the HR system

Each bundle takes its name from the role in the HR system, so the mapping needs no translation later. RFC 7643 defines the enterprise user extension that carries department, division, cost center and manager, and those are the fields a bundle rule reads. Matching their names exactly is what keeps the rule from depending on a lookup table somebody maintains by hand.

5Start with two or three bundles per function

Precision can come after the thing works, which makes two or three bundles per function the right first pass. Most companies settle at eight to fifteen bundles for a few hundred people, and the exceptions land in the request flow rather than in a spreadsheet of special cases.

Delegating the exceptions

The second half of the work is delegating those exceptions, which is what stops IT being the bottleneck the bundle was meant to remove:

Delegating some rights to some managers in Active Directory. For example allow them to add or remove access to specific groups in a way that is intuitive to them. It would allow us to focus on other stuff, and they would be able to quickly grant access without waiting after us at all.

What is the mover rule?

A bundle is recalculated on a role change, not added to. That single sentence is the difference between birthright access working and birthright access becoming the reason access reviews run long.

Recalculate, do not add

• The new role's bundle is granted.
• The old role's bundle is removed, minus anything the new bundle also contains.
• Requests approved for the old role are re-justified or expire, because the reason they were approved has changed.

The order matters in practice, because granting before removing keeps the person working through the transition while removing first strands them for a morning. Running only the first half is what leaves a person holding two bundles.

Why the removal half gets skipped

Nothing in a role change asks for it. The new manager requests the access the new role needs, so that grant has a requester, a reason and somebody waiting on it. The removal has none of the three: no ticket, no deadline and nobody inconvenienced by its absence. The HR field changes quietly, and the only system that can notice is one reading that field on a schedule. This is why the mover stage produces most of the privilege that a review later has to unpick.

What does it take to grant a bundle on day one?

Two things, and the second is where most stacks stop.

An authoritative source with a start date

The HR system knows the role, the start date and the manager before IT does. Reading it, rather than waiting for a ticket, is what makes the access exist before the person arrives. The start date is the field that makes early provisioning possible at all. A bundle applied on the morning of day one is a race against the new hire's first sign-in. A bundle applied the evening before is finished before anyone is watching.

A path into every application in the bundle

For applications with SCIM on the plan the company already pays for, the directory creates the account. For everything else, the bundle needs another path: the application's own API, or automation that drives its admin console. A bundle that only covers the SCIM applications delivers half a first day, and the missing half is the applications the role actually works in.

A role in the HR system maps to a bundle in Iden, and the onboarding workflow provisions it before the start date across every connected application, over SCIM where the application has it and over its API or admin console where it does not. The workflow run shows each account being created for one new hire, so day-one access is a thing with a status rather than a promise. The feature behind it is Day one access, without a ticket.

Derselbe Workflow als Definition und als Durchlauf. Darunter drei Accounts für eine Einstellung, jeder mit eigener Ticket-ID.

What does good look like?

The Monday test

The test is a Monday morning. A new hire signs in and finds exactly the applications their role requires, at the permission it requires, with nothing they have to ask for and nothing they should not have. Nobody worked a ticket, and the record of what was granted and why exists without anyone assembling it. That record is the part most easily lost, because a bundle provisioned by a script that logs nothing produces a good first day and no evidence of one.

The Tuesday test

The second test is a Tuesday six months later, when that person moves teams and the bundle changes in both directions on the day the HR field changes. Most programs pass the Monday test within a month of setting the bundles up and never pass the Tuesday one, because onboarding has an obvious owner and a role change has none.

The four numbers that show it is working

Four measures separate a working bundle from a documented one, and each of them can be read from systems rather than asked for.

1. The share of joiners whose full bundle exists before the start date, which should be nearly all of them rather than most of them.
2. The number of access tickets a joiner files in the first week, which is the direct measure of what the bundle is missing.
3. The number of people holding two bundles, which counts the role changes where only the granting half ever ran.
4. The size of each bundle tracked over time, because a bundle that only ever grows is one nobody is prepared to argue about.