The IT Onboarding Checklist for New Employees

Why ad hoc onboarding leaks security and time

Onboarding is where your identity, endpoint, and access controls either start clean or start compromised. When a new hire's setup runs on a manager's email, a half-remembered list, and whatever the last admin happened to do, two things go wrong at once. The employee sits idle waiting for accounts and hardware, which is expensive on day one and demoralizing on day two. And the security posture drifts: accounts get over-provisioned "to be safe," MFA gets skipped "just for now," and the device ships without management because setup was rushed.

Neither failure is dramatic on its own. The damage is cumulative. Verizon's DBIR has for years put stolen credentials and the human element at the center of most breaches, and every account created without least privilege or without MFA is a standing invitation. A repeatable onboarding process is not paperwork — it is a security control that runs dozens or hundreds of times a year, and its consistency is exactly what makes it defensible to an auditor and hard for an attacker to exploit.

The goal of this post is a concrete, ordered checklist you can adopt: what fires the process, what gets provisioned, how access is scoped, how the device is enrolled, and how you confirm it all worked 30 days later.

Start from an HR trigger, not a ticket

The single most important design decision is what starts the process. If onboarding begins when a manager emails IT, you have already lost — the trigger is inconsistent, the data is incomplete, and nothing is auditable. Make the HR system the system of record. A new hire entered once in Workday, BambooHR, UKG, or ADP should fire the entire downstream sequence automatically.

A well-run trigger carries the attributes that drive everything else:

• Start date — so provisioning completes before day one, not on it.
• Department and job code — the inputs to role-based access.
• Manager — for approvals, mailbox delegation, and the day-30 check-in.
• Location and employment type — full-time, contractor, or intern, which changes access scope and device policy.

When HR owns the trigger, the routine case needs no human to remember anything. Wiring that pipeline is the core of a managed identity and access management program: one authoritative source, feeding one identity provider, feeding every downstream system.

Figure: onboarding is a sequence, not a pile of tasks — each step gates the next so nothing ships half-configured.

The core account: identity, SSO, and MFA

The identity account is the root of everything the employee will touch, so build it correctly before anything connects to it.

1. Create the directory identity from HR attributes. Name, username convention, email, department, and manager populate automatically. No free typing means no typos that break downstream provisioning.
2. Place the user in role-based groups by attribute, not by copying a "similar" existing user. Cloning entitlements is how over-privilege spreads silently across a company.
3. Enforce single sign-on so the identity provider is the one front door. Every application that supports SAML or OIDC should authenticate against the central IdP, which means cutting off one account cuts off access everywhere it is integrated.
4. Require phishing-resistant MFA at enrollment. Register the second factor during a guided first-login on day one — ideally a passkey or authenticator app rather than SMS. An account that reaches a productive state without MFA is a gap you will have to chase down later.

Do not let the pressure to make someone productive fast become a reason to skip enrollment. First-login MFA registration takes a few minutes and closes the most common attack path against a brand-new account.

Least privilege: birthright versus requested access

Not all access is equal, and treating it as one bucket is why role models collapse over time. Split it in two.

• Birthright access is what everyone in a role gets automatically on day one: email, the intranet, the standard productivity suite, chat, and the tools a department universally uses. Provision it by attribute the moment the joiner record lands, so the new hire is working on their first morning without a single ticket.
• Requested access is everything sensitive, expensive, or role-specific: production systems, financial applications, admin consoles, and customer data. This should require an explicit request, approval from a defined owner, and ideally a time bound.

Keep birthright bundles small and specific. The moment "birthright" quietly grows to include high-value systems because it is convenient, you have recreated standing access under a friendlier name. A useful test: if you would be uncomfortable seeing an entitlement on an access review with no justification attached, it does not belong in a birthright bundle. Privileged rights — admin consoles, infrastructure, anything that can change other people's access — should never be part of onboarding by default; grant them just-in-time when the role actually requires them.

Device enrollment through MDM

A new laptop that ships without management is an unmanaged endpoint on day one, and it usually stays that way. Enroll every device before it reaches the user.

• Zero-touch enrollment. With Apple Business Manager or Windows Autopilot, a device bought for the employee enrolls into management automatically on first boot, tied to your tenant. The user signs in with their SSO identity and the device configures itself.
• Baseline configuration. Full-disk encryption on, screen lock enforced, automatic OS and patch policy applied, and the standard application set pushed down. These are policy, not a checklist someone runs by hand.
• Endpoint protection agent. The EDR or endpoint agent installs as part of the baseline so the device is monitored from the first session, not from whenever someone notices it is missing.
• Compliance as a login condition. Tie access to device posture: an endpoint that is not enrolled, encrypted, and healthy should not reach sensitive applications.

Running this consistently across a mixed fleet is exactly what an endpoint and device management program delivers — every machine enrolled, encrypted, patched, and monitored to the same standard regardless of who set it up.

Role-based app access and security training on day one

With identity and device in place, provision the applications the role needs — not the applications the last hire happened to have. Map each role to a defined application set and provision through SCIM where the app supports it, so accounts are created (and later disabled) automatically rather than clicked into a dozen admin consoles. For anything sensitive that falls outside the birthright bundle, route it through the request-and-approve path.

Day one is also the right time for baseline security awareness. A new employee is a prime target for business email compromise precisely because they do not yet know who normally asks them for what. Cover the essentials before they get their first suspicious message: how to recognize phishing, how to report it, password and MFA hygiene, and acceptable use. A managed security awareness training program makes this a scheduled, tracked part of onboarding with completion recorded as evidence — which matters both for culture and for frameworks like SOC 2 that sample onboarding records.

Verify at day 30

Provisioning that is never checked is provisioning you cannot trust. Close the loop with a scheduled 30-day review — one that is triggered automatically, not dependent on anyone remembering.

• Confirm access matches the role. Reconcile what was granted against what the role should have. Remove anything that crept in, and capture any legitimate additions through the proper request path so they are documented.
• Verify device compliance. The endpoint should be enrolled, encrypted, patched to policy, and reporting healthy to your endpoint tooling.
• Confirm MFA and training are complete. No account should still be running on a temporary factor, and awareness training should be logged as done.
• Gather friction feedback. What was the new hire missing in week one? Feed it back into the birthright bundle so the next person's onboarding is smoother.

This check-in doubles as your first micro access review, catching drift while it is one person instead of a fleet.

Make it repeatable, then let it run

Ad hoc onboarding fails quietly and expensively — idle new hires on one side, over-privileged unmanaged accounts on the other. The fix is not heroics; it is a sequence that always runs the same way: HR fires the trigger, the IdP provisions identity with SSO and MFA, access is scoped by role under least privilege, the device enrolls through MDM before it ships, apps and training land on day one, and a day-30 review proves it all held.

intSignal builds and runs this process end to end, integrated with your HR system and backed by a managed IT helpdesk that handles the exceptions the automation cannot. If your onboarding still depends on someone remembering the steps, talk to our team and we will turn it into a control you can rely on.