Zero touch IT onboarding: a complete guide for 2026

The fastest I have ever seen anyone break production was with a dropdown menu.

An org was wiring up app provisioning in their identity provider and assigned the Google Workspace connector to the default "Everyone" system group. It sits near the top of the list and looks like precisely what you want. Within moments, 8 to 10 employees were signed out of Google Workspace mid-morning, because the connector on the other end read them as brand-new unlinked users rather than the accounts they had been logging into for years.

No script ran. No change window was involved. Somebody picked a group.

I lead with that because the device is almost never where these projects break. The break is usually three layers up, in identity, and then the MDM gets blamed for a quarter while somebody rebuilds group structure at 11pm.

Identity first, hardware second

Your identity provider sits between the HR system and every downstream app. HR data flows in (by hand at small scale, through an HRIS integration once you have real headcount), and from that point Okta or Entra owns the authoritative version of name, title, and department. Those attributes get pushed downstream by API, which is how you stop "Jay Smith" in the HR record from becoming "John Smith" in the CRM and "jsmith2" in the ticketing system.

Build this before you touch a laptop. Every later decision reads from these attributes: what auto-installs, who can elevate, what gets revoked on someone's last Friday.

The user-facing payoff is much smaller than the architecture and people notice it far more: a dashboard of tiles showing exactly the apps that person has access to, which retires a whole weekly category of ticket beginning "what do I have access to."

The SSO tax, and the honest workaround. Plenty of SaaS vendors charge extra to enable SSO or SCIM at all, sometimes bumping you a whole pricing tier for one checkbox. When paying is off the table, the practical dodge is routing logins through an identity you have already federated: let the app use "sign in with Google," where Google itself sits behind Okta. The real cost is visibility. That app's access no longer appears in your IDP admin console, so it goes missing from next quarter's access review unless you track it by hand.

Break-glass, documented before you need it. Most SaaS platforms let an account owner or super-admin bypass SSO entirely, which is your way back in when the identity provider has a bad day. Okta runs on infrastructure that has bad days like everything else. Write down which accounts can bypass and where those credentials live, while the topic is still boring.

Choose your MFA methods on day one. One org let people enroll with whatever second factor they liked, then tried to narrow that to an approved list and found native reporting would not show per-method enrollment. They could not answer "who is on TOTP versus a hardware key" without buying third-party tooling.

Groups, and the checkbox that ruined a Tuesday

Three kinds of groups, doing three different jobs.

Application groups. One per app, named so they sort together (app_Slack, app_Jira). They exist purely to drive provisioning.

Organizational groups. Department and team structure, which is what your rules evaluate against.

Push groups. These carry permission level downstream, so the app on the far end knows this set gets admin and that set gets read-only. Skip them and you hand-fix roles forever.

Direct user-to-app assignment is the habit to break. It works fine at 30 people, damages your audit trail immediately, and becomes unreviewable somewhere north of 200. I ran it that way for years and defended it as pragmatic. What changed my mind was not a security review. It was trying to answer "why does this contractor have Figma" and finding no group, no rule, and no ticket, just an assignment somebody made in 2022.

So, restated as a flat rule: never point a provisioning connector at a system-generated group like "Everyone." Those groups contain accounts you were not thinking about.

What the receiving end does varies alarmingly by vendor. Slack will deactivate on a bad SCIM assignment, immediately, no grace period. Figma can silently strip users out of projects on a bad pull. Vendors document what provisioning turns on and go conspicuously silent about what it turns off, so your reliable answers come from a support case or a test account.

Test against an account nobody will miss.

Group rules and their four sharp edges

Rules are the low-code conditionals that assign membership from attributes: engineering gets Atlassian, exclude sales. Useful, and full of specific traps.

1. What a rule provisions cannot be changed after creation. You deactivate it and build a new one. Name your rules with that in mind.
2. A licensing shortfall fails silently and never retries. The rule fires, the push fails for want of a seat, nothing tries again, and the user sits in the group with no account on the other side.
3. Manually removing a user from a rule-managed group creates a hidden exclusion entry on the rule. It persists. Six months later somebody wonders why exactly one engineer has no Jira, and the answer is a cleanup task nobody knew existed.
4. There is no preemptive downstream capacity check. Your IDP will push a new hire into Google Workspace without asking whether you own a spare license. You find out afterward, manually.

Enrollment order: portal, then MDM

Zero touch deployment has a required build order, and people reverse it constantly.

First, get devices into the vendor's business portal. For Apple that is Apple Business Manager, and when you buy through a channel that reports serials, new purchases typically appear within seconds, though the official commitment is within 24 hours. This is the prerequisite for automated device enrollment, which is what lets a sealed box configure itself on somebody's kitchen table.

Second, link a real MDM. Apple Business Manager alone enforces nothing. It is a list of serial numbers with an assignment field.

The lightweight native MDM folded into Apple Business is fine for about a five-person business. It has blueprints, and it cannot push policies, scripts, or packages, which is where the interesting work lives. Past that scale you are choosing among Jamf, Kandji, Intune, Mosyle, or Fleet, and which one matters less than committing to one and configuring it properly.

Ten apps in three minutes

First run is where IT onboarding automation either earns its budget or hands you a support queue.

Ten apps, several of them large: a purpose-built onboarding tool averaged 3 minutes 9 seconds. The same ten through a hand-rolled Installomator loop averaged about 15 minutes 29 seconds. The gap comes from four design choices worth demanding from whatever you buy or build: concurrent rather than serial downloads, exponential-backoff retries for the network blips that are normal during enrollment, checksum verification against a maintained catalog, and idempotent runs that skip whatever is already present.

Push both a configuration profile and an installer package during Setup Assistant itself, so installs begin in the background before the user account exists. By first login, most of the software is already sitting there.

Then fix your update notifications. One notification per app is the default in most patch tooling, and it trains people to dismiss everything. Coalesce them into a single summary on a cadence, set a deferral limit so nobody defers forever, and when the limit is hit, fire the update behind a visible countdown so the app closing under them is expected rather than alarming.

And while all that runs, FileVault. On Apple silicon the disk is already encrypted. FileVault's real job is gating the encryption key behind the user's password or a recovery key, a meaningfully different claim than "we turn on encryption," and worth getting straight before you write it into a compliance answer.

The trap underneath is specific. The bootstrap token must be escrowed to your MDM automatically, and there is a real window where FileVault reports as on while the token has not landed yet. A forced software update restarting inside that window stops at a pre-boot password screen, waiting for a user who is not sitting there, and the rollout stalls for that device without telling you anything. Check escrow as its own verification. Do not infer it from FileVault status.

Nobody is admin all day

Standard users get no persistent local admin. The reason is unglamorous: malware inherits whatever privileges the account it landed in already has.

Elevation becomes self-service and time-boxed instead. One hour by default. The request requires a written justification that lands in front of a human, and the vague ones get followed up on, which is most of the value here: people write better justifications once they know somebody reads them. When the timer expires, the account reverts to standard automatically.

New software requests need their own written path:

1. Employee submits the request to procurement.
2. Procurement pings IT and security.
3. Review covers risk, business need, and the question that saves the most money: does a tool we already own do this job?
4. Optional pilot, scoped in the MDM by username, role-based group, device serial number, or an explicit "pilot" tag.
5. Packaging and deployment.

A simple app that drops straight into the Applications folder can clear that whole pipeline in under 15 minutes. Anything needing a translation layer, permission entitlements like screen recording or full disk access, or bundled drivers takes considerably longer, and saying so up front costs you nothing.

Offboarding is a day-one design decision

Design the exit on the day you design the entrance. It is the same machinery pointed the other direction.

The HR termination event notifies the identity provider. The IDP kills sessions and app access, then triggers a remote lock or wipe through the MDM. The device lands on a screen saying it has been locked and asking for a PIN.

Keep that PIN. It comes from the lock command itself, and if anyone ever needs data off that machine, it is the difference between a recovery and a full DFU wipe. Put it in the ticket and in the asset record, anywhere other than a chat message you will not be able to find in eleven months.

Retention deserves its own line item. One major identity platform keeps user action history for only 90 days and access requests for one year before purging both automatically. If your auditor wants two years of "who approved this elevation and why," your IDP will not have it. Log those events out to your ticketing system as they happen.

If you are starting from nothing

The employee onboarding IT checklist I would actually build, in order, starting from zero on a Monday.

1. Identity provider, with the HR feed as source of truth. Nothing else until this part is correct.
2. Group architecture and naming conventions, written down, before you connect a single app.
3. One app end to end. Provision it to a test group, then deliberately deprovision a test user and watch what the vendor actually does. Repeat per app. Tedious, and it is what prevents your own version of the Google Workspace story.
4. Apple Business Manager, then an MDM linked to it.
5. FileVault with bootstrap token escrow verified. Verified, not assumed.
6. A first-run app set, kept small. Five apps that always work beat fifteen that mostly do.
7. The elevation workflow, so you are never tempted to hand out standing admin as a stopgap.
8. The offboarding runbook, PIN retention and external audit logging included.

The sequence is not arbitrary. Each step's failure mode gets more expensive the later you discover it, and identity mistakes are the ones that reach into every other system you own.

What I would resist is treating any of it as a finished build. A vendor changes SCIM behavior in a release note nobody read, HR renames a department and four rules stop matching, somebody buys a laptop at retail on a Friday. The list above works better as a set of things with named owners than as a project plan with an end date.

When zero touch onboarding works, nobody notices. A new hire signs in, sees their apps, gets to work, and forms no opinion about IT whatsoever. Strange thing to build a career around, being invisible on the good days.

Day one is the first real evidence a new employee gets about how this company works. That is a lot of weight to rest on a group membership, and it is where the weight sits.