Least Privilege Starts at Onboarding: My Access Checklist

When I onboarded new users at a manufacturing plant with more than 1,200 people, each setup came with the same quiet pressure: get this person working today. Create the account, set up the machine, map the drives, add them to the right groups, show them the systems and move on to the next ticket.

Under that pressure, the easiest decision is often the riskiest one: give the new person the same access as someone else in their team. "Copy Sam's account." It's fast, it usually works and it nearly always grants more than the new person needs.

That's how access sprawl begins. Over months and years, permissions pile up. People change roles and keep their old access. Temporary access becomes permanent. Eventually nobody can say with confidence who can reach what.

The principle that prevents this is called least privilege. This article explains what it means in practice and shares the checklist I'd use for every new starter, role change and departure.

What least privilege means

Least privilege means every person, device and service should have only the access it needs to do its job, and nothing more, for only as long as it needs it.

It sounds obvious. In practice, it takes discipline, because extra access rarely causes immediate problems. Missing access, on the other hand, produces an angry phone call within minutes. So systems drift toward too much access over time unless someone deliberately pushes back.

Why it matters so much

Excess access turns small problems into big ones.

• Compromised accounts do more damage. If an attacker steals a password through phishing, they inherit everything that account can reach. An account with access only to its owner's work limits the damage. An account with broad access to file shares, admin tools and financial systems hands over the keys.
• Malware spreads further. Ransomware encrypts whatever the infected user can write to. Broad write access to shared drives means broader damage.
• Mistakes have bigger consequences. People delete or change things accidentally. Least privilege limits what an honest mistake can affect.
• Insider risk is reduced. Most employees are trustworthy, but limiting access protects both the organization and the employee if questions ever arise.
• Audits and investigations become possible. When access is deliberate and documented, you can answer "Who could have done this?" quickly.

The onboarding checklist

Here's the checklist I'd use when setting up a new user. It's written for IT teams, but managers play a big part in it too.

1. Start from the role, not from a person.

Define standard access by role: what does a production supervisor, an accounts clerk or a warehouse operator need? Then build new accounts from that role definition rather than copying a colleague. Copying an existing account copies years of accumulated exceptions.

2. Get written approval from the manager.

Access should be requested by the person's manager and recorded in the ticket. The manager knows what the job requires. IT knows how to grant it. Both are needed.

3. Use groups, not individual permissions.

Grant access by adding the user to role-based groups, not by giving permissions to the individual account directly. Groups make access easier to review, change and remove consistently.

4. Separate everyday and admin accounts.

If someone needs administrative rights, such as an IT staff member, they should have a separate admin account used only for admin tasks. Their everyday account, used for email and browsing, should have standard rights. This keeps a phishing email from landing in an account that can change the whole system.

5. No local admin by default.

Standard users shouldn't be administrators on their own computers. Approved software can be installed by IT or through a managed software portal. This one change blocks a large share of malware.

6. Enable multi-factor authentication from day one.

Set up MFA as part of onboarding, not as a follow-up project. It's far easier to establish the habit on the first day.

7. Set temporary access to expire.

If someone needs access for a project or a short period, set an end date when you grant it. Access without an end date tends to become permanent.

8. Document what was granted and why.

Record the groups, systems and exceptions in the ticket. Future reviewers, and future you, will need to know.

9. Explain the basics to the user.

A two-minute conversation on day one covers a lot: how to reach IT, what IT will never ask for (like passwords and MFA codes), how to report something suspicious and why access requests go through their manager.

Movers: the forgotten middle

Onboarding gets attention. Offboarding gets attention. The middle, when people change roles, is where access quietly accumulates.

When someone moves from one department to another, they often get the new access they need while keeping everything from the old role. After a few moves, a long-serving employee can have access to far more than any single role requires.

My mover checklist:

• Treat a role change as a fresh access request for the new role.
• Remove access tied to the old role, with a short overlap only if the manager approves a handover period.
• Review admin rights and shared mailbox or folder access specifically, since these are easy to overlook.

Leavers: close every door

When someone leaves, their access should end promptly and completely. An account that stays active after its owner has gone is an open door that nobody is watching.

My leaver checklist:

• Disable the account on or before the last day, coordinated with HR so IT knows in advance.
• Revoke remote access, including VPN and any cloud applications that don't use the main login.
• Collect devices, keys, badges and tokens, and record their return.
• Transfer ownership of files and mailboxes to the manager or a successor so work isn't lost.
• Change shared passwords the person knew, and check for any accounts they created.
• Remove them from groups and distribution lists, then delete the account according to the retention policy.

How access creep happens: a typical story

Here's a pattern that plays out in organizations everywhere.

An employee joins the warehouse team, and their account is copied from a long-serving colleague. That colleague once helped finance during a busy quarter, so the new hire quietly inherits access to a finance share. A year later, the new hire moves into a supervisor role and gets supervisor access, but nobody removes the warehouse permissions. Then they join a short project and get access to an engineering system "for a few weeks." The project ends. The access doesn't.

Three years in, this person can reach finance, warehouse, supervisor and engineering systems. They've done nothing wrong, and they probably don't know about most of it. But if their account is ever phished, the attacker gets all of it.

Now replay the same story with the checklist. The new account is built from the warehouse role, so the finance access never appears. The promotion is treated as a fresh request, so warehouse access is removed. The project access is granted with an end date and disappears automatically. Same person, same career, a fraction of the risk.

Review access regularly

Even with good processes, access drifts. A periodic access review catches what slipped through.

Every few months, give managers a simple list of who in their team has access to which key systems and groups, and ask them to confirm or remove each item. Focus first on sensitive systems: finance, HR data, admin rights and remote access. Reviews are tedious, but they're one of the most effective security controls an organization can run.

Service accounts need least privilege too

Applications and automated tasks often run under service accounts. These are frequently over-privileged, rarely reviewed and sometimes have passwords that never change. Give each service account only the permissions its application needs, document who owns it, and rotate its credentials. Attackers love forgotten service accounts precisely because nobody is watching them.

Making it work in real life

Least privilege fails when it makes people's jobs impossible. If access requests take a week, people share passwords instead. So the process has to be fast, clear and predictable.

What helps:

• Standard role packages that can be granted in minutes.
• A simple request form with manager approval built in.
• Clear service levels for access requests.
• Explaining the "why" to users and managers, so it feels like protection rather than bureaucracy.

The takeaway

Least privilege isn't a product you buy. It's a habit built into everyday IT work: onboarding from roles, separating admin accounts, expiring temporary access, cleaning up after role changes and reviewing regularly. Get it right on day one, and every other security control has less to protect against.

How does your organization handle access when people change roles?