← Back to Work

Multi-Layer Mobile Device Management

Defense-in-Depth Content Filtering and Policy Enforcement

October 2024 :: #mdm #emm #android #defense-in-depth

Overview

I built a four-layer mobile device management setup to enforce content and policy in a way that a determined user can't simply switch off. Most single-layer approaches have an obvious bypass: DNS filtering dies the moment someone turns on a VPN, MDM settings fall to a factory reset, and network filtering stops mattering once the phone leaves the office. So I stacked independent controls at different levels of the system, where each one covers the others' weak spots.

The Four Layers

1 · EMM

Locks down developer options, DNS settings, and profile creation at the user level.

2 · DNS

Filters content at resolution, with the config protected by the EMM lock above it.

3 · Firewall

Kernel-level iptables rules that block beneath the application layer.

4 · Enforcement

A watcher that detects rule tampering and restores policy automatically.

How It Holds Together

The whole design rests on redundancy — if one layer is bypassed, the rest keep enforcing:

LayerMechanismWhy it resists bypass
EMM (Wizy)Prevents user-level config changesBlocks developer options and settings edits
DNS (ControlD)Blocks at resolutionProtected by the EMM DNS lock
iptablesDrops packets in-kernelOperates below the app layer
Enforcement (Termux)Restores tampered rulesSelf-healing, no manual intervention

Change DNS with a VPN and iptables still drops the packets. Edit the iptables rules and the enforcement script puts them back. Take the phone off the corporate network and local filtering keeps running.

Getting kernel-level rules in place meant rooting the device, which I treated as a security decision in its own right: I downgraded OxygenOS to a version with a compatible boot image, hash-verified that image before flashing, and used Magisk for managed root rather than a free-for-all.

The honest caveat

Rooting breaks Android's security model and would be the wrong call in most real deployments — a production fleet should use a non-root MDM. I built it this way to understand the mechanisms commercial platforms hide, and the more useful skill it demonstrates is knowing when a control creates more risk than it removes.

What I Took From It

Single-layer security is a single point of failure, and manual enforcement doesn't survive contact with real users — the layer that mattered most was the automated one that quietly repairs itself. Building this from the ground up also made the trade-offs in off-the-shelf MDM concrete, which is exactly what makes vendor selection and troubleshooting easier on the job.

Evidence & availability

Built and run on my own hardware, so there's nothing client-confidential here — which means I can show the working parts. Configuration, scripts, and a full walkthrough are available on request.