day one, already too much

The new hire arrives at 9:02 a.m., a few minutes late, because the Uber took a wrong turn. Welcome email is waiting. Laptop is on the desk. Credentials are in a password manager. The IT onboarding guide has a list of sixteen steps, and the first four have already been done for them.

By 9:45, they are logged in. By 10:30, they have browsed through Slack, set up their Notion workspace, glanced at the engineering wiki, and tried out the internal CRM. Their manager has sent a welcome note. HR has pinged them about paperwork. It’s a good first morning.

What they don’t see, what almost nobody at the company sees, including the IT team that provisioned them, is the shape of what their user identity now has permission to touch. Sixteen SaaS systems are federated to SSO. The default group membership has put them in seven Google Groups and twelve Slack channels they haven’t opened yet. The “all staff” distribution in SharePoint has granted them read access to a document library that has been accumulating material since 2018. The automatic GitHub provisioning has added them to three engineering organizations. The default Notion workspace has them in the “team” role, which includes, depending on how your Notion permissions decayed over the last three years, somewhere between “most things” and “basically everything.”

They have not yet been promoted. They have not yet completed a single project. They have not yet been handed a laptop sticker. And they already have more access than the thesis of access creep implies, because the thesis has been wrong about where the creep begins.

Access creep starts with the first login, long before the first promotion shows up on anyone’s list of risks.

the birthright bundle

Every mid-sized company, somewhere between the first fifty hires and the first two hundred, builds a concept that eventually acquires a name like “the new hire kit” or “the birthright” or “day-one provisioning.” It is a bundle of default accesses that get granted automatically the moment a person becomes an employee.

The bundle exists for good reasons. The cost of provisioning something case-by-case for every new hire is high. Multiplied by 150 hires a year across twelve different SaaS tools, it becomes untenable. So the company codifies a default. Every new hire gets email, chat, identity in the ticketing system, a seat in the wiki, a Slack account, a GitHub org membership if they’re technical, a CRM seat if they’re in sales. It’s a shortcut, and like most shortcuts in a company, it gets optimized for speed and not for minimization.

The default bundle gets built once, by someone who reads the title of the new role and guesses what that role will need. “Junior product manager”, probably needs Jira, Linear, Figma view access, Notion, Slack, GitHub read on the main monorepo, Looker, and HubSpot. The bundle gets encoded in an automation. Every new junior product manager gets all of it, from day one, without anyone revisiting the question of whether each item is actually required.

Two things happen after the bundle is built. The first is that new items get added to it over time. A new tool joins the stack, let’s say Amplitude for product analytics. Somebody observes that many product managers use Amplitude. Amplitude gets added to the default provisioning bundle. It stays there forever. Five years later, the bundle includes Amplitude even for PMs working on products that don’t use Amplitude, because the bundle was never unassembled when use cases diverged.

The second thing that happens is that the scope of each item creeps upward. The original Figma access was “view access on the specific project they’re joining.” In practice, the automation grants “view access on the brand workspace,” because granting workspace-level access is one step simpler than granting project-level access, and the edge cases where a new hire didn’t need something would be a ticket to resolve later. The later never comes. Workspace-level access becomes the default. New hires get it. They keep it. Workspace-level access accretes across every new hire until it is indistinguishable from “view everything Figma.”

The bundle is supposed to be minimum necessary. It becomes maximum conveniently grantable. The direction of drift is always in one direction, because the cost of over-granting is invisible and the cost of under-granting is a ticket from an annoyed new hire on day two.

the day-one bundle: what it was meant to be, and what it becomes

meant to be

minimum necessary

• Access to the project the hire is joining
• Seats in the tools the role uses daily
• Revisited when the role changes

becomes

maximum conveniently grantable

• Workspace-wide access, because it's one step simpler
• Every tool someone once thought the role might need
• Never revisited, so it only grows

nobody audits day zero

Access reviews, when they happen at all, treat day-zero access as out of scope. The review looks at accumulated access over time, what has a person gained since their start date?, and compares it to what their current role requires. The implicit baseline is “whatever they had on day one.” That baseline is never questioned.

This is backwards. Day-one access, precisely because it is automated and not case-specific, is the highest-leverage audit target in the entire identity program. A default bundle affects every hire. If the bundle grants one unnecessary permission, that permission multiplies across hundreds of identities without any person ever deciding, for any individual, that they needed it.

The conventional access review looks at a single person and asks whether their accumulated grants are justified. The useful audit is the opposite shape: look at a single grant in the default bundle and ask, for every hire in the last three years who received it, whether they actually needed it. The answer, almost always, is that a meaningful minority did and the rest inherited the grant for no operational reason.

Picture what this audit finds for a design tool in the engineering bundle: a large share of seats that were never used after week one. The hires signed in once during onboarding because the bundle gave them a seat. The seat sits dormant. It could be removed tomorrow without affecting anyone. It won’t be, because no process in the company is designed to notice dormant seats granted by default, the seat was given for a reason, even if nobody can remember what it was.

role templates drift into role collections

The bundle is usually organized by role. There’s a Junior PM bundle, a Senior Engineer bundle, a Sales Rep bundle, a Customer Support bundle. On paper, this is RBAC at the onboarding layer, and it should work cleanly.

In practice, after three to five years of company evolution, the role templates drift into something else. New hires get categorized into the nearest existing template, and each template carries the concatenation of everything every past occupant of that role was given. The Senior Engineer bundle of 2026 includes access the 2022 version didn’t, because in 2023 one Senior Engineer needed production access for an incident, and the cleanest way to avoid the same ticket next time was to add it to the default. In 2024 somebody added access to the observability tool for similar reasons. In 2025 somebody added the data warehouse. Each addition was reasonable. Nobody ever subtracts.

This pattern has a name in software: feature creep. Every feature that got added once, to solve one use case, stays forever. The bundle gains features in the same way a product gains features, through individual reasonable decisions that compound into something nobody planned.

The second-order effect: any new hire whose needs slightly deviate from the template gets the full template plus the deviations, because nobody removes template items when they don’t apply. A senior engineer who will work only on the mobile app still gets full monorepo access, full observability across backend services, full data warehouse access, because those are in the template. The template was never refactored when the company’s work split into clean domains.

Cleanly-structured RBAC at the template layer is a thing companies have at year two and lose by year five. The loss is gradual. No single change breaks it. The cumulative effect, by year five, is that every template is a collection of grants whose origin nobody can fully explain.

how a role template drifts into a role collection

1. 1a template is builtSomeone reads the job title and guesses what the role needs.
2. 2new tools get addedA tool many people in the role use joins the bundle, and stays.
3. 3scopes widenProject-level access becomes workspace-level, to save a step.
4. 4every hire inherits all of itFrom day one, for years, without anyone deciding it for them.

what actually needs to be in the bundle

A well-designed day-one bundle has a specific property. The scope of access granted on day one should cover only what the person will need in the first 48 hours, onboarding work, orientation, basic communication, initial exposure to the tools they’ll eventually use.

Everything else should be provisioned on demand, triggered by the first moment the person actually needs it.

The first moment is easy to detect. The new hire asks their manager for access to the specific Jira project their first assignment is in. The manager approves a request, access is granted, the grant is logged with a clear reason (“needed for assignment on project X”). Three days later the new hire needs access to a specific Confluence space. Same flow. Over the first two weeks, the person’s actual access graph assembles itself from real requests tied to real work, rather than appearing all at once from a template that guessed what they’d need.

This approach has an obvious objection: it’s slower. Managers have to approve individual requests. New hires have to wait. The friction of on-demand provisioning is higher than the friction of default bundles.

The counterobjection: the friction of wrong default bundles is invisible but larger. Every permission granted by default that the person never uses is a permanent expansion of the company’s access surface, multiplied across every hire who ever received it. The bundle’s friction is amortized across five years of dormant permissions contributing to every access creep problem downstream.

The case for minimal day-one provisioning, usually framed as “just-in-time access”, rests on two expectations you can test yourself. Ramp speed should barely change, because most of what a new hire receives on day one isn’t needed in the first 48 hours. And total permissions a year later should be lower, because on-demand grants follow actual use.

the audit to run on monday

Here is the test.

Pull your company’s default onboarding automation, whatever system actually executes when a new hire joins. List every permission, group membership, tool seat, distribution list, and default grant that gets applied to a new hire in the largest role category (engineering or sales is usually the biggest).

For each item on the list, ask: what percentage of hires in this role over the last twelve months actually used this permission within their first thirty days?

You can answer this from audit logs in most SaaS tools. Login events, file access, ticket creation, any activity attributable to a user. The answer will be a number between 0% and 100% for each item.

Everything under roughly 30%, meaning most hires never touched the thing, is a candidate for removal from the default bundle. Moving it to on-demand provisioning costs a small amount of manager time for the minority who actually need it. The savings, across every future hire and across the cumulative permission surface of the company, are structural.

On a bundle that hasn’t been touched in three years, expect a sizeable part of it to fall under that threshold: grants going to people who never use them. The bundle is carrying three years of accumulated “just in case” without anyone having decided to keep them.

Shrink the bundle. Let the access graph assemble from real work instead of assembled guesses.

Day one is the cheapest day to get this right. Every day after day one, the compounding has already started.