MDM and Privacy???

For some fucking reason I now have to manage MDM for many companies. So figured I’ll have to learn more in depth how they work…

Some companies give employees a “work phone” or ask to download software to use work applications in their personal phones. The thing is that is not just giving access to company resource, but also allows admins/IT to view much more details of your phone and its usage. Kinda like a spyware.

MDM (Mobile Device Management) is like an invisible layer between the hardware (phone) and the company/org IT team. There are many reasons why a company would want to implement MDM, such as security compliance, remote data wipe when devices get lost, enforce encryption, monitor correct, etc. However it allow allows employers to view the employee behavior up to a surprising level of detail.

Many people has iOS devices but I’ll focus on Android, because fuck Apple.

What is MDM Software?

MDM (Mobile Device Management) is not spyware. It doesn’t record your microphone or screenshot your screen on demand. It’s a framework: a combination of device-level agents, cloud policy servers, and OS-level APIs that let IT administrators configure, monitor, and control enrolled devices at scale.

The major platforms are Microsoft Intune, VMware Workspace ONE, and IBM MaaS360. All of them connect to the same underlying OS APIs, they pretty much differ in features, not in fundamental capability.

The most important thing to understand is that what MDM can see depends on how the device was enrolled. A company-issued phone enrolled in full device management mode is more of a privacy nightmare than a personal phone enrolled in a BYOD work profile.

What Your Employer Can Actually See

On a company-owned, fully managed device, the employer’s MDM platform has device-owner-level access to the Android OS. That includes:

Every app installed on the device
Real-time and historical GPS location
Battery level
Wi-Fi networks the device has joined
Mobile data and Wi-Fi traffic volume per app
Device compliance status (rooted? screen lock set? OS patched?)
Browsing history, when a managed browser profile is deployed

On a personal phone enrolled via Android Work Profile (the standard BYOD setup), the profile is isolated container running under a separate user ID. The MDM is scoped to profile owner permissions and cannot reach into the personal side of the device. Personal apps, photos, messages, and browsing history are invisible to IT.

How Android MDM Works

The Three Management Modes

Google’s Android Enterprise framework has 3 management modes, each granting different levels of OS access to the deployed DPC (Device Policy Controller) app.

flowchart TB
    subgraph DO["FULLY MANAGED: Device Owner"]
        D1["DPC = Device Owner<br>Full OS control, work-only device"]
        D2["Sees: all installed apps<br>GPS location<br>Per-app network usage<br>Device-wide policy enforcement"]
        D1 --> D2
    end

    subgraph COPE["WORK PROFILE ON COMPANY-OWNED DEVICE, Android 11+"]
        C1["DPC = Profile Owner<br>with elevated company-owned policies"]
        C2["Work Profile<br>IT manages fully: apps, data, policies"]
        C3["Personal Side<br>App content invisible to IT<br>Device-wide security policies enforced"]
        C1 --> C2
        C1 --> C3
    end

    subgraph BYOD["WORK PROFILE: Personally Owned Device"]
        B1["DPC = Profile Owner only"]
        B2["Work Profile<br>IT manages fully"]
        B3["Personal Side<br>OS-enforced kernel barrier<br>IT has zero access"]
        B1 --> B2
        B2 -. "blocked, separate Linux UID" .-> B3
    end

    style DO fill:#1a2e1a,stroke:#4caf50,color:#e8f5e9
    style COPE fill:#1a1a2e,stroke:#5c7cfa,color:#e8eaf6
    style BYOD fill:#2e1a1a,stroke:#ef5350,color:#fce4ec

Fully Managed (Device Owner): The company owns and controls the entire device.

Work Profile on Company-Owned Device The DPC acts as a Profile Owner with access to extended company-owned device policies via getParentProfileInstance(). IT fully manages the work profile and can enforce device-wide security policies like screen lock and encryption, but personal app data remains inaccessible.

Work Profile on Personally-Owned Device (BYOD): This is the strictest privacy separation. IT cannot see the personal profile. Yay!

How Device Owner Status Is Granted

Device Owner mode can only be set on a factory-reset or a brand new phone. The provisioning process is orchestrated by the Android setup wizard, which grants Device Owner status to the specified DPC package through an internal system call. The enrollment methods are:

flowchart LR
    subgraph ZT["Zero-Touch"]
        ZT1["Device purchased<br>from authorized reseller"] --> ZT2["IT pre-registers<br>IMEI in ZT portal"]
        ZT2 --> ZT3["First boot contacts<br>Google ZT servers"]
        ZT3 --> ZT4["DPC APK downloaded<br>and installed silently"]
    end
 
    subgraph QR["QR Code"]
        QR1["Factory-reset device"] --> QR2["Tap setup screen<br>6 times in same spot"]
        QR2 --> QR3["Scan QR code from<br>IT console"]
        QR3 --> QR4["JSON payload decodes:<br>DPC package, APK URL,<br>enroll token, WiFi creds"]
        QR4 --> QR5["Android downloads<br>and installs DPC APK"]
    end
 
    subgraph AFW["DPC Identifier"]
        AFW1["Factory-reset device"] --> AFW2["Enter afw#setup<br>instead of Google account<br>at setup wizard"]
        AFW2 --> AFW3["Wizard downloads DPC<br>from Play Store"]
    end
 
    subgraph KME["Knox Mobile Enrollment<br>Samsung only"]
        KME1["Register device IMEI<br>or serial in Knox portal<br>(no reseller required)"] --> KME2["Device pulls config<br>and DPC on first boot"]
    end
 
    subgraph FINAL["Provisioning completes"]
        F1["DPC installed"] --> F2["Setup wizard grants<br>Device Owner status<br>to DPC package"]
        F2 --> F3["Device enrolls with<br>MDM cloud server"]
        F3 --> F4["Policy pushed:<br>CA certs, VPN config,<br>app restrictions,<br>location reporting..."]
    end
 
    ZT --> FINAL
    QR --> FINAL
    AFW --> FINAL
    KME --> FINAL
 
    style ZT fill:#1a2e1a,stroke:#4caf50,color:#e8f5e9
    style QR fill:#1a1a2e,stroke:#5c7cfa,color:#e8eaf6
    style AFW fill:#2e1f1a,stroke:#ffa726,color:#fff3e0
    style KME fill:#2e2e1a,stroke:#cddc39,color:#f9fbe7
    style FINAL fill:#1a1a1a,stroke:#ef5350,color:#fce4ec

The SSL Inspection Problem

When an MDM pushes a corporate root CA certificate, the OS adds it to the system trust store. Every TLS connection that validates against the system trust store (which is most of them) now trusts certificates signed by that CA. Combined with setAlwaysOnVpnPackage(lockdownEnabled = true), the company routes all device traffic through a corporate proxy that performs full TLS break-and-inspect:

flowchart TB
    subgraph PREREQ["MDM Pre-conditions Active"]
        S1["installCaCert<br>Corp root CA pushed to system trust store"]
        S2["setAlwaysOnVpnPackage lockdown=true<br>All traffic routed through org proxy"]
    end

    subgraph INTERCEPT["Standard HTTPS Request: Intercepted"]
        N1["App sends TLS ClientHello to example.com"]
        N2["Corporate proxy intercepts the connection"]
        N3["Proxy opens separate TLS session to example.com<br>Receives real DigiCert certificate"]
        N4["Proxy presents forged cert to app<br>Corp CA signed example.com<br>App trusts Corp CA, no warning shown"]
        N5["App request decrypted by proxy<br>Logged in IT console<br>Re-encrypted and forwarded to server"]
        N6["Server response decrypted by proxy<br>Logged in IT console<br>Re-encrypted back to app"]
        N1 --> N2 --> N3 --> N4 --> N5 --> N6
    end

    subgraph PINNED["Certificate-Pinned Apps: Not Interceptable"]
        P1["App sends TLS ClientHello to Signal servers"]
        P2["Proxy presents Corp CA signed certificate"]
        P3["App checks cert fingerprint against hardcoded value<br>Fingerprint mismatch, connection refused<br>No silent interception possible"]
        P1 --> P2 --> P3
    end

    PREREQ --> INTERCEPT
    PREREQ --> PINNED

    style PREREQ fill:#1a1a2e,stroke:#5c7cfa,color:#e8eaf6
    style INTERCEPT fill:#2e1a1a,stroke:#ef5350,color:#fce4ec
    style PINNED fill:#1a2e1a,stroke:#4caf50,color:#e8f5e9

The proxy decrypts traffic, inspects it for DLP policy violations, logs it, re-encrypts it with a Corp CA-signed certificate, and forwards it. From the app’s perspective, TLS succeeded. From IT’s perspective, they saw plaintext.

What Can I Do? Certificate pinning. Apps that hardcode expected certificate fingerprints (like Signal) validate the certificate chain independently of the OS trust store. If the fingerprint doesn’t match what the app expects, the connection fails rather than silently accepting the proxy’s certificate. Signal’s traffic appears to the corporate proxy as an opaque TLS stream to Signal’s servers; the proxy can’t decrypt it and can’t provide a plausible forged certificate that Signal would accept.

Check Your Android Device’s Enrollment State

Steps vary depending on brand/OEM, but these are for Samsung.

Check if MDM is Active:

Any app listed here holds elevated device administration permissions

Settings → Security and privacy → More security settings → Device admin apps

Check the Management Mode:

A Work Profile appears as a separate section with a briefcase badge on work-side app icons. If there’s no work profile listed but device admin apps are present, you’re on a fully managed device with no personal/work separation

Settings → Accounts and backup → Manage accounts

Check for Pushed CA Certificates:

Any certificate in the User tab that you didn’t install yourself was pushed by an MDM
On a fully managed device also check the System tab, since Device Owner DPCs can install CAs at system level where they’re less visible

Settings → Security and privacy → More security settings → View security cetificated → User tab

Check for Always-on VPN:

A VPN profile with a lock icon and no option to disconnect is an MDM-enforced always-on VPN. Every packet you send goes through corporate infrastructure regardless of which network you’re on, including cellular

Settings → Connections → More connection settings → VPN

What You Can Do

I don’t like MDM-controlled devices. The most effective protection is to have a separate device for work and another for personal use (never mix them, technology improves and becomes more anti-privacy). Using a company phone for personal activity is effectively consenting to the monitoring, whether or not you’re aware of the full extent.

If you want to communicate with another person, use a private personal device and use Signal. Certificate pinning prevents the corporate SSL inspection proxy from intercepting Signal traffic. End-to-end encryption means the content is protected regardless. The MDM can see Signal is installed and that traffic is flowing to Signal’s servers, it cannot see what you’re saying.

Don’t log into personal accounts on a managed device using the corporate browser or any app without certificate pinning. On an always-on VPN deployment, assume the proxy sees plaintext for those sessions.

Finally, read your company’s BYOD agreement. You will always be fucked, but no one cares i guess…

What is MDM Software?#

What Your Employer Can Actually See#

How Android MDM Works#

The Three Management Modes#

How Device Owner Status Is Granted#

The SSL Inspection Problem#

Check Your Android Device’s Enrollment State#

What You Can Do#