MDM lockdown at provisioning

• Factory-floor handhelds (about tens of devices across the line) shipped in near-default state, so operators could open any app.
• Used an MDM tool to remotely enroll the fleet and push a configuration profile.
• The profile hid everything except the approved apps and pulled the rest off the home screen, leaving only the work app and sanctioned tools.
• Root cause was process, not tech: there was no provisioning step that applied the lockdown before a device reached the floor.
• Fix was small in effort: a few config screens and one profile push, which worked the first time and didn't really break.
• The remaining lesson is to move that lockdown earlier, into provisioning, instead of reacting after noticing someone on the wrong app.

# MDM lockdown blocked the app/scanner — work WITH the policy, not around it
- allowlist the app package + its server host:port in the device profile
- whitelist required permissions (scanner/camera, network)
- ship it as an MDM policy exception, not a per-device hack

• ·We had tens of handhelds on the factory floor that shipped almost default, so operators could open any app.
• ·I used an MDM tool to enroll the fleet and push a profile that hid everything except the approved apps and cleared the rest off the home screen.
• ·Technically it was easy: a few config screens, one profile push, worked the first time.
• ·The real takeaway was about timing. We were locking devices down reactively, after catching someone on the wrong app.
• ·That lockdown should be a provisioning step before a device ever reaches the floor, and at the time there was no such step.

• Make the lockdown profile part of standard provisioning so a device can't reach the floor without it.
• Add an enrollment gate or check that flags any device on the floor that isn't carrying the approved profile.
• Treat the approved-app list as configuration owned by the team, reviewed when apps change, not a one-off manual push.