Lite-to-zero touch device onboarding is a way of setting up a new starter’s laptop so that the operating system, every application, security setting and compliance policy installs itself automatically the moment the user logs in, with no engineer needed to build the device by hand. We built it by combining device management and automation tools with our own in-house scripts, tailored to each customer’s own setup, rather than relying on any single platform. Here is how it works, and what changed as a result.
What problem were we trying to solve?
Before this existed, building a new starter’s laptop was a manual job: an engineer opened the device, logged in, then installed every application that role needed, one at a time, against a checklist built for that customer. It worked, but it depended entirely on an engineer’s time and on getting that checklist right every time.
The push to change it came from the move to remote or flexible working. Once teams stopped sharing one office, there was no central desk where a device could be built before a new starter arrived, it had to be shipped straight to them. Premium, single vendor tools can solve this, but only if a business’s devices and identity platform all match one ecosystem. Most of our customers run a mix of Mac, Windows and other devices, some on Microsoft 365, others on Google Workspace, so rather than lean on any single platform, we designed different combinations of tools and our own customisations, tailored to each customer’s environment, to get the same result.
How much pain was the old way causing?
Manually building devices was not just slow, it created problems that compounded the more customers we supported.
- It ate engineer time. Installing sometimes twenty or more applications, each at a specific version, is repetitive work that does not get faster or less error prone the thirtieth time round.
- Mistakes were invisible until someone noticed. When a person misses a step building a device by hand, there is rarely a record of it, so the gap only surfaces once the new starter cannot access something they need.
- It did not scale with department complexity. A large customer could have thirty to forty applications split across departments, and keeping every checklist current by hand became its own job.
- It showed up as a customer complaint. “Our IT provider takes days to build a new device” is a line we have heard about other providers more than once, usually a sign the process is still manual.
How does Lite (often Zero) onboarding actually work?
The build runs slightly differently for Mac and Windows devices, but the shape is the same in both cases:
- The device checks in the moment it is switched on. A new, or freshly wiped, device recognises which organisation it belongs to as soon as it connects to the internet, through Apple Business Manager for a Mac or the equivalent Windows enrolment flow.
- The new starter logs in with their own credentials. The user enters the credentials for their identity platform, whether that’s Microsoft 365, Google Workspace or a 3rd party platform like Jumpcloud, already set up and sent to them ahead of day one.
- The device enrols itself automatically. Once authenticated, the device enrols in the mobile device management (MDM) platform we have set up for that environment, which locks it to the organisation. A lost or stolen device can be wiped and stays locked, so it is no use to anyone outside the business.
- Automation workflows take it from there. Combining third-party deployment tools with scripts we have written and tailored in-house, the right applications, settings and desktop layout for that starter’s department are pulled down and installed automatically, matched to whichever platforms that customer runs.
- The new starter can see it happening. A simple on-screen message tells them the device is being set up and roughly how long it will take, usually around 30 minutes.
- A short, mostly cosmetic step finishes it off. The last small piece, an e-mail signature or syncing a shared drive, takes 10 to 30 minutes with a little help, rather than the 3 to 4 hours a full manual build used to take.
The same process works on an existing device too. If a leaver’s machine is being reassigned, wiping it and running it through the same flow builds it back up exactly as if it were new.
Why isn’t this built around one or two platforms?
Premium, all in one platforms exist and are genuinely good at what they do, but they are built around a single operating system and a single way of working. Our customers are not that uniform: some are Mac-first, some Windows-first, some run Google Workspace, most run Microsoft 365, and quite a few mix two or more.
Rather than force every customer into one tool’s assumptions, we combine whichever device management and deployment tools fit that customer’s own platforms, then layer our own in-house scripts and tooling on top to tie it all together. The result is the same zero or lite touch experience for the user, whichever combination of operating system and identity platform their business actually runs, and it is part of the value we build into our managed IT support as standard: once we have automated a piece of a build for one environment, every future new starter on a similar setup benefits from it too.
What challenges did we run into?
- Keeping a “golden image” up to date does not scale for an MSP. The traditional alternative to scripting is imaging: build one perfect device, then clone it onto every new one. Every image is a snapshot in time, and across hundreds of customers with different patching needs, keeping every image current becomes a job of its own. Scripts avoid that, because they always install the latest version at deployment.
- No single platform covers every combination we need. Mac, Windows, Microsoft 365 and Google Workspace each have their own enrolment mechanics, so a consistent experience across all of them meant building our own glue between platforms.
- Department differences have to be documented before they can be automated. Getting this right depends on knowing exactly which applications and permissions belong to which team, captured during getting started with every new customer. Get it wrong and the gap can be significant: we have seen one person placed in the wrong group be the difference between thirty and sixty pieces of deployed software.
- Automation can still fail, but it fails usefully. A failed script logs exactly what did not install, so we can redeploy just that piece rather than the whole build.
What’s the end result for a new starter?
A new starter logs in with their own credentials on day one, on a device that is either brand new or wiped and redeployed, and within around 30 minutes it has every application, setting and security permission their role requires, without an engineer touching the keyboard.
What impact has this had?
| Before | After |
| A full manual build took 3 to 4 hours of engineer time per device | The bulk of the build completes automatically in around 30 minutes |
| Missed installation steps often went unnoticed until a new starter flagged them | Failures are logged automatically, so a specific application can be redeployed without rebuilding the whole device |
| Only our most experienced engineers could reliably handle complex, department specific builds | Any team member can run a build, because the logic lives in the automation rather than in one person’s memory |
| A lost or stolen device relied on someone remembering to deprovision it manually | Every device is locked to the organisation from the moment it enrols, and can be wiped remotely regardless of whether it is ever returned |
What security and compliance considerations are built in?
Because every device enrols in the mobile device management platform set up for its environment the moment it is switched on, it is immediately covered by whatever compliance policies a customer has set, conditional access rules in Microsoft 365, or context aware access in Google Workspace, without anyone configuring that separately afterwards. If you are already thinking about IT compliance for UK businesses, getting device enrolment right from day one is one of the simplest wins available.
The same enrolment also protects the business if a device goes missing: locked to the organisation rather than the person carrying it, a lost or stolen laptop can be wiped remotely and never unlocked again, which also supports obligations like Cyber Essentials without extra effort at audit time. We configure the identity side, who can see what, as part of the same onboarding process, so permissions are correct from the first login too.
What did we learn building this?
- Automation compounds across customers, not just within one. Each piece of scripting or glue we build for one customer’s environment makes the next similar build faster too, which is why we treat it as an ongoing investment inside our managed IT support rather than a one-off project.
- The real upfront cost is documentation, not scripting. Knowing exactly which applications and permissions belong to which department, captured during getting started with a new customer, is what makes the automation accurate later.
- There is no single tool for every customer. Because our customers run different operating systems and identity platforms, the solution had to be a combination stitched together by our own developer, not an off the shelf product.
- Good automation should not depend on one or two people. The logic lives in scripts rather than an engineer’s head, so any team member can run a build, the same philosophy behind our daily back-up check workflow: automate the verifiable work, and keep a person in the loop for anything that needs judgement.