Device provisioning used to mean a technician at a bench. For a distributed company it means getting a machine configured and secured without anybody touching it, which is mostly a sequencing problem rather than a technical one.
TL;DR
- Modern enrolment means a device can configure itself on first boot anywhere in the world, which removes most of the old provisioning work.
- Two things still cannot be done remotely: registering the device for automated enrolment, and anything requiring physical possession.
- Registration has to happen at purchase. A machine bought outside your enrolment arrangement is awkward to bring in afterwards.
- The failure that actually costs you is not configuration. It is a new starter intervening during setup because nothing appeared to be happening.
- Record the serial against the person at despatch, not on arrival, or the device reaches somebody before it reaches your register.
- Test the whole flow on one machine before a cohort. Every assumption breaks in a different market.
What provisioning actually means now
The traditional version was imaging: build a machine to a known state, install everything, hand it over. That assumed the machine passed through your hands, which for a distributed fleet it does not.
The replacement is enrolment. The device is registered against your organisation at the point of purchase, and on first boot it contacts your management service, identifies itself, and applies policy, applications and restrictions without anybody intervening. The box can ship direct from a supplier to somebody’s home.
That shift moves the work earlier. Almost everything that used to happen at a bench now happens in procurement and in policy configuration, which are both done once rather than per device.
The two things you cannot do remotely
Getting the device into automated enrolment. This depends on the machine being purchased through a channel that registers it to your organisation, which generally means buying from the manufacturer or an enrolled reseller. A laptop bought on a card from a retail site is not registered, and bringing it in afterwards ranges from fiddly to impossible depending on the platform.
Anything needing hands. A machine that will not boot, a firmware setting that requires physical presence, a drive swap. These are rare and they are the cases where a remote fleet needs either a spare machine nearby or somebody local.
Everything else, including application installation, security policy, disk encryption, certificates and network configuration, happens over the air on first boot.
Where it goes wrong
| Bought outside the channel | Device never registers for automated enrolment | Buy through the manufacturer or an enrolled reseller. Decide this at procurement |
| User intervenes during setup | Enrolment half applies, machine ends in an odd state | Tell them to leave it for twenty minutes before they open the box |
| Record created on arrival | Device reaches a person before it reaches the register | Record the serial at despatch, from the order |
| Policy assumes an office network | Configuration stalls on a home connection | Test the full flow from outside your network before shipping any |
| Local account created first | Machine is set up as personal, enrolment skipped | Make the first-boot instruction explicit about which account to use |
The second row is the one that generates the most support contacts. Setup frequently shows nothing for several minutes while policy applies, so somebody reasonably concludes it has frozen and restarts or starts clicking.
A worked example
A company shipping direct to new starters in five countries had a reliable process and a persistent problem: roughly one in four machines needed a support session on day one.
Reading the tickets, almost all of them traced to the same thing. The setup screen sat apparently idle while policy applied over a domestic connection, and new starters, keen to get going, restarted the machine or created a local account to get past it. The enrolment then half applied and had to be unpicked by hand over a call.
The fix was two sentences added to the pre-arrival email telling people exactly what they would see, how long it would take and to leave it alone. Day-one sessions dropped to roughly one in twenty, with no change to any configuration.
Getting the sequence right
What to do:
- Buy through a channel that registers devices to your organisation, and confirm this per market before ordering.
- Record the serial against the person at despatch, taken from the order rather than from the box.
- Test the complete first-boot flow from a home connection, not from your office network.
- Write a two-sentence first-boot instruction: connect to wifi, sign in with this address, leave it twenty minutes.
- Send that instruction before the device arrives, in the language the person works in.
- Give a contact route that does not depend on the account being set up, meaning a phone number.
The last item matters more than it looks. Somebody stuck during enrolment cannot email you from an account they are in the middle of activating, and without a phone number day one becomes day two.
Who handles the purchasing side
Since enrolment depends on the purchase channel, provisioning is partly a procurement decision. Buying locally in each market is usually fastest and needs a supplier in that country who can register devices to you, which is the question to ask before the price question.
Global procurement platforms handle this by buying on your behalf through channels that support enrolment, which removes the per-market supplier problem. Workwize, Deel IT, Firstbase, GroWrk and allwhere all do versions of it, and none publishes a price, so expect quotes rather than list figures.
Disclosure: RemoAsset is owned by the same people who publish PeopleOpsHQ. Relevant here because the asset record is created from the order rather than typed on arrival, which fixes the third row of the table above. It publishes no price and requires a demo, it is weaker for hardware it did not supply, and it is not a certified disposal vendor. The alternatives sit in our laptop procurement platform comparison.
Final thoughts
Provisioning a device for somebody you will never meet is largely a solved technical problem and a persistent sequencing one. The configuration applies itself. What breaks is a machine bought outside the enrolment channel, a record created too late, and a new starter who could not tell that anything was happening.
Fix the purchase channel first, since it is the only decision that cannot be corrected afterwards. Then record at despatch, test the flow from a home connection, and write the two sentences that stop people intervening. That is most of the problem, and none of it is configuration work.
Frequently asked questions
What is device provisioning for remote employees?
It is getting a machine configured, secured and ready to work without anybody physically touching it, which modern enrolment makes possible by having the device contact your management service on first boot and apply policy, applications and restrictions itself. The practical consequence is that the work moves earlier in the process, into the purchase channel and the policy configuration, both of which are done once rather than per device.
Can we enrol a laptop bought from a normal retailer?
Not into automated enrolment in most cases, because that depends on the device being registered to your organisation at the point of sale, which generally requires buying from the manufacturer or an enrolled reseller. Bringing a retail machine in afterwards ranges from fiddly to impossible depending on the platform, and it usually means somebody configuring it by hand. This is why the purchase channel is a provisioning decision rather than a procurement detail.
What causes most day-one setup failures?
A new starter intervening during enrolment because the screen appeared to be doing nothing. Policy application over a domestic connection can show no visible progress for several minutes, so people restart the machine or create a local account to get past it, and the enrolment then half applies and has to be unpicked by hand. Two sentences in the pre-arrival message explaining what they will see and how long it takes removes most of these.
When should the asset record be created?
At despatch, from the serial on the order, rather than when the device arrives. Recording on arrival means the machine reaches a person before it reaches your register, and the gap is where records go missing entirely, particularly when the person handling the shipment is focused on getting it there rather than on data entry. Creating the record from the order also means the serial, the recipient and the delivery address all exist from day one, which is what any later recovery depends on.
What still needs somebody physically present?
Very little, and the exceptions matter: a machine that will not boot at all, a firmware setting that requires physical access, or a hardware failure needing a part. These are rare enough that building a capability for them is usually wrong, and common enough that you need an answer. For most distributed fleets the practical response is a small number of spare machines held in the markets where you hire most, so a failure becomes a domestic shipment rather than a visit.
Should we test the process before a cohort starts?
Yes, and specifically from outside your own network, because the most common configuration surprise is a policy that assumes an office connection and stalls on a home one. Run one machine end to end as though you were the new starter, in the destination market if you can, and time how long the first boot takes so the instruction you send is accurate. Every assumption in this process breaks differently in a different market, and one test device costs far less than a cohort of confused starters.