A new engineer's first week sets their access for the next three years. Whatever they are granted on day two, they keep, because nothing removes it and asking for less is not a thing people do.
Most onboarding is designed to get someone productive quickly, which is the right goal, and the access decisions get made by whoever is unblocking them at the time. This post is how to do both. For whoever runs onboarding, which at most companies is the new person's manager plus an improvised checklist.
Grant by role, not by request
The pattern that produces sprawl: the new engineer is blocked, asks in a channel, someone with admin rights grants what unblocks them, and that grant is never reviewed. Repeat for six systems in the first fortnight.
The fix is a defined bundle per role, granted at once on day one. A backend engineer gets this set. A data engineer gets that set. The bundle is reviewed occasionally by someone thinking about it, rather than assembled ad hoc by people thinking about a blocker.
Anything outside the bundle goes through a request that records who approved it and why. That is not bureaucracy, it is the only way to distinguish deliberate grants from accumulated ones later.
Start narrow, widen on evidence
Day-one access should cover what someone does in their first month. Production write, customer data, billing and administrative consoles are not in that set for most roles, and adding them later is a conversation that takes a minute.
This is easier to do at the start than to undo afterwards, because widening access feels like progress and narrowing it feels like an accusation.
The device is part of the grant
Access is meaningless if the machine holding it is not managed. Disk encryption verified rather than assumed, screen lock enforced, the ability to wipe remotely, an inventory record tying the device to the person.
Two things worth getting right on day one specifically:
The password manager, before anything else. If someone's first week involves receiving credentials over chat because the manager is not set up yet, those credentials are in a chat history permanently.
Hardware second factor, issued before the accounts it protects. Retrofitting multi-factor is a project; doing it at account creation is a step.
Teach the paths, not the principles
A security induction that explains why security matters is forgettable. One that tells people exactly what to do when something happens is not.
Four things, on one page:
- How to report something odd, with the specific channel and the promise that reporting a false alarm is welcome.
- Where secrets live, and the fact that they never go in code, tickets or chat.
- How to get production access when they need it, so they do not acquire standing access instead.
- Who to ask, by name.
Everything else can wait. Those four are what determine behaviour in the first month, and the first one determines whether you hear about the phishing email they clicked.
Make the first week produce something reviewable
A record of what was granted, by whom, and why, created at the time. This is nearly free on day one and impossible to reconstruct in a year, and it is what makes the quarterly review possible at all.
The same record is what offboarding works from. An onboarding that leaves no trace produces an offboarding that misses things, which is the pattern behind most of the dormant accounts in any organisation.
The mirror test
The honest check on your onboarding is to run it backwards. Take someone who left recently and ask whether everything granted in their first week was removed.
If you cannot answer, the gap is in onboarding rather than in offboarding: there was never a list. Fixing the record at the start is what makes the end possible, and it is one of the few places where a small amount of discipline at a quiet moment removes a whole category of problem at a busy one.
The concession
Every control here slows down someone's first week, and a new engineer who cannot contribute for three days because access is pending is a real cost, in productivity and in how the company feels to them.
Which is why the bundle matters more than the restrictions. Granting a well-designed set instantly on day one is both faster and narrower than the ad hoc alternative, and it is the version that does not trade speed for control. The restrictions that remain, production write and customer data, are the ones where a day's delay is genuinely proportionate.
The implication
Access granted during onboarding is the largest single source of standing permission in most organisations, and it is handed out by people optimising for something else entirely.
Define the bundles once. It takes an afternoon, it makes the first week faster, and it is the only intervention here that costs nothing in the thing everybody actually cares about.
