20MAY2026 MDM endpoint android infrastructure family

When Parental Controls Aren't Enough, You Build Your Own

My son is eighteen. He's neurodivergent -- on the autism spectrum -- and for the better part of three years, electronics weren't a meaningful part of his life. It didn't start that way by design. It started with school expectations he didn't think were fair, a decision to let things tank rather than fight through them, and then avoidance of the conversations that could have fixed it. When access was given back, trust got broken -- workarounds, sneaking time, finding gaps in whatever controls were in place. His sister was making some genuinely scary judgment calls around parental controls at the same time. Electronics came off the table entirely.

Three years is a long time. Avoidance works until it doesn't, and graduation day was the moment it ran out of road. A lot came down at once. He's been doing the work since then -- the real work, the kind that doesn't have a clean metric -- and lately it's starting to show. This year, the phone became part of the plan. Not a reward handed back. A tool, deliberately scoped, one piece of a larger effort to help him build a life that actually works for him.

Because I'm an infrastructure engineer, I built it like one.

Why consumer parental controls fail this specific problem

Consumer MDM and parental control tools are built for the average case. They assume a kid who isn't actively looking for gaps, running on a device that wasn't already set up with three years of app history. They work by hiding things rather than preventing access. Hide the browser icon -- but if Settings is open and the app is still installed, you can launch it from there. Block the search engine -- but leave Google Maps installed and you can type a URL into the search bar. Every pre-installed carrier app, every Samsung service with a launch button, is a potential escape route the control layer never mapped.

My son's brain is wired to find every edge. That's not a criticism -- it's a description. Neurodivergent people, especially those on the spectrum, often have an almost compulsive pattern-recognition quality that makes systematic loophole-finding practically inevitable. Consumer tools weren't built to handle that. They were built for a kid who glances at the phone, sees the obvious things are gone, and moves on.

What I needed wasn't a layer on top of the existing device. I needed to own the device from the first boot.

Device Owner -- what it actually means

Android has a management posture called Device Owner. It's the strongest available on the platform -- stronger than what most consumer parental tools use, which operate as Device Administrator. The difference is enforcement. A Device Administrator can suggest policies. A Device Owner enforces them at the platform level. A Device Administrator can be removed by a persistent user. A Device Owner cannot be removed without a full factory reset -- and when that happens, the device loses trusted access to the management platform entirely and I know immediately.

Device Owner enrollment

Achieved via QR code at the very first screen during Android provisioning, before any account is signed in. The MDM platform takes control before the OS completes setup. This is the same enrollment method used in enterprise Android deployments. The key is enrolling before anything else runs -- retrofit enrollment is always weaker.

I ran through the enrollment process six times on a test device before touching the production phone. Each iteration caught something. By the time I enrolled the real device, the process was documented and repeatable. It took under ten minutes.

The stack

This runs entirely on TekForge infrastructure. No third-party MDM cloud. No subscription. No vendor handling telemetry from my son's device.

Device Samsung S20 FE · Android 13 · Device Owner enrollment

↑↓ MQTT / HTTPS

Cloudflare Proxied ingress · MDM and MQTT endpoints

↑↓

HAProxy Smart edge layer · routes by hostname

↑↓

Headwind MDM Self-hosted · Docker · Tomcat + PostgreSQL · open source

The MDM platform is Headwind MDM, open source and self-hosted. It communicates with the device over MQTT. The device checks in roughly every 60 seconds with location, battery state, and connectivity. If it goes offline, I know. The platform handles configuration pushes -- app policy, launcher appearance, restrictions -- and can send commands remotely. The TekForge wallpaper is served from tekforge.dev infrastructure. Nothing about this touches a vendor cloud.

What's on the phone -- and what isn't

The launcher shows exactly what I configured. Phone, messaging, contacts, camera, maps, calendar, email, Discord, Spotify, clock, gallery. Communication, navigation, music. Nothing that opens a browser. Nothing that opens a store. Nothing that lets him install anything without my involvement.

Apps that aren't on the launcher aren't just hidden -- they're disabled at the OS level via pm disable-user. Hiding an app in the launcher still leaves it reachable through Settings if you know where to look. Disabling it at the OS level means it doesn't launch from anywhere.

Google Search is a browser

It renders web pages. So does the Samsung Galaxy Store given enough navigation. Every app that can load arbitrary web content is a browser until proven otherwise. Found this out during testing. They're all disabled at the OS level now.

The Android Device Policy API's UserManager restrictions handle the rest. no_control_apps means Settings is accessible but nothing actionable can happen inside it -- no force-stopping, no disabling, no clearing data. no_install_apps means the Play Store UI opens but nothing installs. no_uninstall_apps means nothing leaves. These aren't cosmetic. They're enforced by the Device Owner at the platform level and survive reboots cleanly.

The family found the gaps

My son told me he'd find a way around it and if he felt like telling me how he did it, he would tell me when he was older. Before he finished the sentence, I told him the automation layer would probably respond faster than he could test the exploit. He started testing immediately. So did my wife.

Between the two of them they found Game Launcher via the Samsung app search function -- a system feature that indexes all installed packages and lets you search by name, bypassing the custom launcher entirely. They found the Samsung Galaxy Store. They found Netflix, outdated and non-functional but technically launchable. Every gap went on the list. Every gap got closed.

Settings is accessible -- disabling it at the OS level caused boot loops on Samsung Android 13, a lesson learned the hard way -- but the Device Owner policy restriction on app control means navigating Settings freely without being able to do anything that matters.

The bigger picture

The phone is one piece. This spring I started nightly check-ins with him -- structured, brief, forward-looking. We work through what he's thinking about, what's in the way, what the next step is. He's also started using a lightweight handwritten planning system I've used for years, adapted for how his brain works. He said it's helping. That it's creating momentum where things used to just stall. The phone fits into that same framework -- a tool with clear scope, clear purpose, and guardrails that make it usable rather than overwhelming.

A lot of parents are navigating versions of this right now. Kids who got lost in digital environments before they had the foundation to handle them. Neurodivergent young adults for whom the structure of the internet -- infinite scroll, infinite novelty, no natural stopping points -- is particularly difficult to regulate against. The diagnosis often comes late, after the patterns are already established. The work of untangling it is slow and not linear.

The phone isn't a cage. It's a controlled ramp -- the right amount of access at the right time, built to expand as the foundation gets stronger.

He felt improvement today. That's the metric. Not the enrollment process, not the policy configuration, not the MQTT telemetry. Him feeling like things are moving in the right direction.

The engineering is in service of that. It always is.

Lessons learned -- for the IT audience

01 Enroll at first boot or don't bother. Retrofit MDM inherits the existing mess. Factory reset, QR at the first screen, nothing else first.
02 The MDM config and ADB must agree. If the MDM policy says Allow for a package you've disabled via ADB, the MDM re-enables it on next sync. They have to say the same thing.
03 Test every ADB disable with an immediate reboot. com.android.settings is a boot dependency on Samsung Android 13. Disable it and you get a boot loop. Use Device Owner policy restrictions instead.
04 QR enrollment bypasses carrier provisioning. Verizon's bloatware installs during the normal setup flow. Enroll via QR before that flow runs and the bloatware never arrives.
05 The UserManager restriction API is the right tool. no_control_apps, no_install_apps, no_uninstall_apps, no_safe_boot -- enforced by the Device Owner at the platform level, survive reboots cleanly.
06 Google Search is a browser. Anything that renders web content is a browser. Disable at the OS level, not the launcher.
07 Have a runbook before touching the production device. Test enrollment on a throwaway device until the process is documented and boring. Then run it once on the real one.