Every rollout I’ve been near started with the same assumption: people will push back because they don’t want the company near their phone. In practice I’ve found the objection is narrower than that. People push back when the process lands badly, takes long, or breaks something they use at six in the morning.
I’ve watched enrolment go smoothly in one department and badly in another, with the same tooling and the same instructions. The difference was almost entirely timing and how much notice anyone got.
The phrase that tends to cause trouble is not encryption or policy. It is wipe. Somebody hears it, tells two colleagues, and by lunch the rollout has a reputation it did not earn.
What the Rollout Actually Feels Like on the Ground
Most people have one work account on a personal device. Mail, calendar, a chat app, maybe a document viewer. Their worry is usually specific: will this let someone see my photos, my messages, my browsing. I’ve found that question is worth answering plainly before anything else.
Then there is the practical side. Enrolment takes ten minutes when it works and forty when it does not, and the forty-minute version usually involves a password reset loop or a certificate prompt that looks alarming. If the first person in a team has the bad version, the rest of the team hears about it.
Batteries and notifications come up more than you would expect. Someone notices a slight change in behaviour after enrolment and attributes it to the tool, correctly or not. Those small complaints spread faster than any policy document.
And there is usually a group of people whose device is unusual. An older handset, a regional app store, a phone bought on a trip. The standard instructions do not apply, and those are the cases that quietly stall a rollout.
Why Rollouts Tend to Stall
I think the main reason is that enrolment is announced as a policy change rather than as a task with steps. A policy announcement invites a debate. A task with a time estimate invites a shrug and a slot in the calendar.
The language in the notice matters a lot. Words like monitor, inventory, and remote wipe are accurate and genuinely unsettling when read cold. I’ve seen well-meaning announcements that were technically correct and completely counterproductive.
Timing is the other half. A rollout during a busy period gets deferred individually by dozens of people, which adds up to a stalled programme. Nobody says no. They just don’t get around to it.
There is also the support question. If the only help channel is a ticket queue with a two-day response time, then a fifteen-minute problem becomes a two-day problem, and word gets around quickly.
What I’ve Seen Teams Try
Some teams try consolidated platforms like Ping64 to reduce the daily busywork of multi-tool security stacks.
For enrolment specifically, the approach I’ve seen work well is a walk-in session. A room, a couple of hours, someone who has done it before, and no appointment needed. Most people finish in one sitting and leave with a working phone.
Phased rollouts by team also seem to help. Ten people at a time means the odd case gets real attention, and the people next in line hear that it went fine.
I’ve seen a few places publish a short plain-language note about what the company can and cannot see on a personal device. It takes an hour to write and it answers the question everyone actually has.
Small Practical Suggestions
Say what you can and cannot see, in plain words, before asking anyone to enrol.
Use the word wipe carefully and explain the condition attached to it. Lost device is not the same as curiosity.
Run a pilot with the most patient team first, and fix what they hit.
Offer a walk-in slot rather than only a ticket queue. Most problems are quick.
Give a realistic time estimate. Understating it costs more trust than the extra minutes.
Have a spare loaner phone ready for the person whose device is genuinely incompatible.
Enrol new starters on day one, when it is part of setup rather than a change.
Keep a note of the odd cases and their fixes. The next rollout will need them.
Thank people afterwards. It is a small thing and it lands well.
Closing
I don’t think device enrolment is unpopular so much as badly timed. Most of the resistance I’ve seen melted once someone explained what was actually visible and sat with people while they did it. My own rule of thumb is to make the first ten enrolments easy and public, because those set the tone for the next hundred. Phones are personal, and a little patience up front saves a lot of it later.
References
- NIST SP 800-53 Rev. 5, Security and Privacy Controls: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST SP 800-124 Rev. 2, Guidelines for Managing Mobile Devices: https://csrc.nist.gov/pubs/sp/800/124/r2/final
- MITRE ATT&CK, Enterprise framework: https://attack.mitre.org/
- CISA, Cybersecurity guidance and resources: https://www.cisa.gov/
Top comments (0)