A guide to the new employee IT onboarding process

Most onboarding failures never show up as failures in the ticket queue. The problem only surfaces on the first morning, when the new hire can’t get past MFA or a group membership never applied. A February 2026 audit by the Treasury Inspector General for Tax Administration found that 40% of sampled IRS new hires received their laptop more than five workdays after their start date.

An onboarding ticket should close only when the employee has signed in, completed MFA, and confirmed access to every system they need, on a device you can prove is in the right hands. Their access should go no further than the role requires. Below, we explain why day-one onboarding typically fails and how to build a framework that works.

Why day-one onboarding usually breaks down

Day-one onboarding usually fails because steps get marked complete without anyone confirming they worked. An account gets created, a laptop gets assigned, a ticket gets closed, and each handoff assumes the previous one landed without really validating it.

These two main failure patterns below come from opposite ends of the process, but they share that root cause:

1. An account isn’t the same as access

Provisioning and authentication are separate outcomes, and treating the first as proof of the second is a common mistake. An account can exist in the directory while access stays blocked by a missing group membership, which doesn’t show up as an error at creation time. The employee only finds out when they try to sign in, then loses time logging a ticket while someone tracks down the cause.

Misdiagnosing the problem compounds the damage. A missing group membership or a corrupted identity or profile might look like a login failure from the outside, and first-line support often treats it that way. That means password resets and retries that can’t fix the underlying problem, and sometimes actions that even make it worse.

Removing an authenticator profile isn’t a neutral troubleshooting step. NIST SP 800-63B-4 treats authenticator binding, replacement, and account recovery as controlled processes, because each one is a point where the link between a person and their credentials can break or be hijacked. When a profile is deleted mid-onboarding, the employee drops out of the normal flow and into recovery. That usually means new verification and more days without working access.

» Improve technician training with an IT troubleshooting framework

2. Manual records drift from reality

The second failure is slower and less visible. Onboarding depends on knowing which devices exist, who has them, and what state they’re in. When that information lives in a manually maintained spreadsheet, every new device, reassignment, configuration change, and retirement depends on someone remembering to update a row.

For onboarding, that drift has direct consequences. A laptop listed as available may still be assigned to someone else, or still be waiting on a reimage, while a device issued to a new hire may never be recorded against their name. When that employee eventually leaves, nobody can say with confidence which equipment they have. The spreadsheet looks complete, which is exactly why nobody questions it until a handoff fails.

» Don’t miss our guide to preventing configuration drift

3. A compliant device doesn’t prove who’s using it

The third failure happens even when every check passes. In June 2025, the US Department of Justice announced coordinated action against a scheme in which North Korean IT workers used stolen and fake identities to get remote jobs at more than 100 US companies. In one case alone, the defendants compromised the identities of more than 80 US persons. US-based facilitators received the company-issued laptops at their homes and connected them to keyboard-video-mouse (KVM) switches, hardware that let the overseas workers control the machines remotely.

From the employer’s side, onboarding looked successful. The new hire cleared identity checks, the laptop was a managed corporate device, and it connected from a domestic address. None of that showed who was actually operating it. A KVM switch sits outside the operating system, so the endpoint can look compliant while someone else controls its keyboard, screen, and mouse.

What secure, repeatable onboarding looks like

All three failures have the same fix, applied at different points: nothing counts as done until it has been verified. A secure, repeatable onboarding process builds that rule into how it’s staged, how it defines completion, how it grants privilege, and where it keeps its records.

Follow these pillars:

Build around readiness gates, not calendar dates

It’s standard to split the onboarding work into preboarding, day one, and the first few weeks. That’s a useful way to organize tasks, but it assumes identity provisioning, access approvals, and equipment preparation all run on a predictable schedule.

In actuality, remote hires add:

• Shipping
• Device enrollment
• Endpoint compliance
• VPN access

Each of these has to be in place before corporate access works. Contractors and external users often start at short notice. They also need narrower access than employees, and that access should end well before a standard review cycle comes around. The fix is to treat each phase as a gate rather than a date. A hire moves forward when that stage’s conditions are confirmed, not when the calendar says they should have been.

Here’s an example of what must be true at each gate before moving on:

• Preboarding: Identity is confirmed, required access is approved, and the device is built, enrolled, and recorded against the employee.
• Day one: The employee has signed in, completed MFA, and opened every essential application on their own account.
• First weeks: Outstanding access requests are closed, temporary access has an expiry date, and the asset record matches what the employee actually has.

Verified, not provisioned

This checklist runs in the order the work should happen. It starts with the access-scoping steps that apply to every user, including contractors and external testers, then adds the device, email, and licensing steps a full-time hire needs:

Verification also has to cover more than one thing. Identity, device custody, and authenticated access are separate controls, and each answers a different question:

• Is this the person we hired?
• Is the device in their hands and under our IT management?
• Is the person signing in the one we verified?

Least privilege by default

Local admin rights usually get handed out on day one because something needs installing and that’s the quickest fix. In a well-run process, the need never comes up. The role’s software is identified during preboarding and installed before the employee starts, so a developer who needs Visual Studio, Git, Docker, and a set of SDKs finds them already on the machine. Everyday accounts run as standard users, privileged roles are activated only when needed, and exceptions are approved and time-limited.

Removing admin rights doesn’t eliminate shadow IT, though. Employees can still run portable applications or install software into their user profile without elevation. Least privilege only holds when someone can see what’s actually installed.

» Learn how much shadow IT is really costing your business

A single source of truth for assets

That visibility depends on records that match reality. Asset and software data should be collected automatically from the devices themselves and stored centrally, with reports generated from that data. Nobody should be keeping a spreadsheet in sync by hand. Atera’s asset and inventory scanning collects hardware and software details from each managed device at regular intervals, so you get centralized, up-to-date visibility into what’s installed instead of relying on what someone remembered to record.

An accurate assignment history also shows which equipment was issued to whom, which makes recovering it during offboarding straightforward. ISO/IEC 19770-1 frames IT asset management around exactly this kind of reliable, lifecycle-wide asset information.

How to build a repeatable onboarding process

A repeatable onboarding process doesn’t have to rely on someone remembering every step for every hire if it moves each new employee through the same sequence of checks automatically, where each stage is complete only once its outcome has been verified.

Here’s a structure you can start with that covers how to organize those stages, what the checklist looks like in practice, how to build the device, and where the records should live:

Use a practical IT onboarding checklist

This checklist below runs in the order the work should happen, starting with the access-scoping steps that apply to every user, including contractors and external testers, and adds the device, email, and licensing steps a full-time hire needs:

1. Confirm the new hire’s identity, roles and responsibilities, sponsoring manager, start date, and (for contractors) the date their access should end
2. List the applications, resources, and permissions the role needs to do its work
3. Create the user in your identity provider, such as Microsoft Entra ID, and set up their mailbox
4. Assign the licenses the role needs for email, collaboration, and line-of-business applications
5. Add the user to role-based groups that grant only the access listed in step 2
6. Set up Privileged Identity Management for any privileged roles, so elevated access is activated when needed rather than assigned permanently
7. Build, enroll, and record the device against the employee before it ships or is collected
8. Require MFA registration and confirm the employee can authenticate successfully
9. Validate access by signing in to each required system with the employee’s own account
10. Confirm the user can complete their intended tasks without reaching resources outside their role
11. Document the access granted, who approved it, the device assigned, and any expiry dates
12. Schedule an access review or revocation date for contractors and temporary access

Step 7 is where most of the manual effort goes, and it’s the step Atera takes off a technician’s plate. Software bundles group a role’s applications from WinGet or a private repository for Windows, or Homebrew for Mac. A technician selects the new hire’s device, chooses the bundle, and installs every application in one action, instead of working through a list by hand. Assigning the device to an automation profile then keeps those applications and the operating system patched on a schedule after handover.

Additionally, Atera’s Recent Processes report shows whether each installation ran, and Software Inventory shows what’s actually on the machine, at which version. Check both, because a completed install command doesn’t prove the application is there. Preinstalled software the role doesn’t need can be uninstalled from the same inventory view.

Run the final handover test on the employee’s account

A clean software inventory doesn’t necessarily mean the employee can work. Licensing, application permissions, and authentication all depend on the user’s identity, not the device, and they only fail when that identity is used. Before the device is handed over, sit with the employee or use their account (or remote support software) to confirm these points:

• They can sign in to the device and complete MFA
• They can reach the corporate resources their role needs, including VPN where it applies
• Each essential application launches and opens with their license
• Endpoint protection and disk encryption are active
• Their account runs with standard-user permissions, not local admin

The device is ready only when both its technical configuration and the employee’s access have been verified.

Pro tip: The last two checks don’t need the employee in the room. With Atera’s RMM, a technician can run a PowerShell script remotely to confirm the device’s encryption status and check that the new user isn’t in the local Administrators group, before the laptop ships. If no script exists yet, AI Copilot can generate one from a plain-language description.

» Outdated licenses? Don’t miss our guide to preparing for a software license audit

Harden identity and device checks for remote hires

For remote hires, most of the risk comes from establishing identity and device custody. Strengthen them with these checks:

• Identity verification: HR or an approved verification provider should check government-issued ID against the person presenting it, using live verification where appropriate, and confirm that employment records and contract details match.
• Shipping verification: Equipment goes only to an independently verified address linked to the employee, and any address change, third-party collection, or forwarding request triggers extra checks before dispatch.
• Device enrollment: The laptop is enrolled in endpoint management, with disk encryption, endpoint protection, and compliance policies active before it gets any corporate access.
• Phishing-resistant authentication: MFA uses FIDO2 security keys or passkeys bound to the verified employee, and enrollment and recovery procedures are protected against impersonation.
• Ongoing infrastructure monitoring: Unusual sign-in locations, unfamiliar devices, concurrent sessions, and unexpected remote-control software are investigated, along with mismatches between the employee’s declared location and their activity.

Apply the same checks to contractors, with closer scrutiny wherever privileged access or sensitive systems are involved.

Onboard mobile and BYOD devices

Mobile devices need a different approach, especially when they belong to the employee. Take a new hire who uses their personal phone for corporate email, Microsoft Teams, and MFA approvals. Your organization needs to protect corporate credentials and data on that phone. It has no business reaching the employee’s photos, messages, or personal apps.

For personally owned devices, mobile application management (MAM) is often the better fit than full mobile device management (MDM) enrollment when the business only needs to secure a handful of corporate apps. Company-owned phones can justify full management. Either way, a BYOD onboarding process should:

• Publish a BYOD policy covering acceptable use, supported operating systems, minimum security requirements, and what the organization can and can’t see on the device
• Enroll the device through your approved MDM process, or apply MAM protection to corporate apps without enrolling the whole device
• Require device encryption, a screen lock, a supported OS version, and current security updates
• Enforce MFA and Conditional Access before the device can reach corporate resources
• Separate corporate apps and data from personal ones, using an Android Enterprise work profile, Apple User Enrollment, or an equivalent
• Block corporate data from moving to unmanaged apps, personal cloud storage, or unapproved backup services
• Confirm that email, collaboration tools, and required business apps work on the device before you mark onboarding complete

That separation also makes offboarding cleaner. On Android, the work profile can be removed without a factory reset, and Apple’s User Enrollment keeps organizational data separate from personal data. Corporate apps, credentials, and data can be wiped selectively when someone leaves or a device falls out of compliance, and nothing personal is touched. The exact behavior depends on the enrollment type and how it’s configured.

» Learn more about IT onboarding and offboarding procedures

Ready means tested, not provisioned

Onboarding that holds up past day one isn’t built from more steps. It’s built from verification. That means identity confirmed before the laptop ships, access tested on the employee’s own account, and privileges granted for the task rather than for convenience. Every gap the process doesn’t verify becomes a ticket on someone’s first morning.

Atera gives IT teams and MSPs a way to take manual app installs off the technician’s plate. Role-based software bundles deploy approved applications to each new device, and software inventory confirms what actually landed rather than what the installer reported. New hires get the tools they need without anyone reaching for a local admin password. Each gate then closes on evidence, not on an assumption.

» Sound good? Try Atera for free