Devices

Work phone: Android, iPhone, or nothing

An honest comparison of the two platforms for professional use in a constrained environment, with the real trade-offs.

Published April 24, 2025 16 min read Exposed

Last reviewed: March 1, 2026

A CFO calls me three days after an M&A deal collapsed. His phone: a personal iPhone on BYOD, all his family apps on it, the work mail managed by the company MDM. Except the MDM separated nothing from his personal iCloud. The due-diligence files had landed in iCloud Photos — automatic backup — then in the shared album with his spouse via Family Sharing. Five separate Apple accounts had seen the documents go by. Nobody had “hacked” anything. The phone had simply done what it’s built to do: sync everything, everywhere, all the time.

Angle de lecture

Particulier RSSI / DSI

The usual trap

“We have an MDM, we’re protected.” That’s the sentence I hear most often when I raise the question of the work phone. It’s false in the majority of the deployments I audit, and it’s false precisely where it counts. An MDM controls enrolment, can enforce a PIN, can wipe the device remotely, can see the list of installed apps and their versions. What it cannot do: stop iCloud from syncing a work document into the family photo album, prevent a screenshot saved to the personal camera roll, or control what the user does with a file once they’ve opened it and forwarded it on WhatsApp. The problem isn’t the MDM. The problem is believing that an MDM laid over a personal device solves data separation. It doesn’t solve it. It papers over it.

The second trap is the religious war of Android versus iPhone. You’ll be told that iOS is “closed therefore safe” or that Android is “open therefore dangerous,” and the reverse with just as much confidence from the opposing camp. Both claims are slogans. The platform matters less than the configuration, the account it’s attached to, and the actual use made of it. A brand-new iPhone connected to a family iCloud shared with three teenagers and stuffed with free apps is less secure than an old Pixel running a hardened system used for two carefully chosen apps. The platform-versus-platform debate is an intellectual comfort that dodges the real question: what passes through this phone, and who wants it?

The third trap is more insidious. We treat the phone as a footnote next to the laptop, when it’s become the other way around. The phone is the device that never leaves your pocket, that receives the MFA codes, that hosts your messaging, that geolocates you constantly, that crosses borders in your pocket and not in your suitcase. It’s the densest single point of failure in your digital life, and it’s treated with a casualness we’d never grant a workstation. The right question isn’t “which phone is the safest,” it’s “what must this phone protect me from, and what am I willing to pay in convenience for it.”

The real threat model: who wants it, and how

Before choosing a platform, you have to name the adversary. The phone of a salesperson with no access to sensitive data and the phone of an executive in the middle of an M&A operation don’t face the same threats, and applying the same configuration to both is a mistake in both directions: over-protecting the first creates needless friction, under-protecting the second creates an incident.

The first vector, the most mundane and the most frequent, is passive exfiltration by the apps themselves. The majority of mobile data leaks don’t come from a sophisticated exploit but from perfectly legal apps that hoover up what they’ve been granted: geolocation resold to data brokers, the contact book uploaded “to improve the service,” access to the clipboard where pasted passwords sit. A free weather app that knows your position to the metre, 24 hours a day, produces a movement profile that, once cross-referenced, reveals your home, your office, your recurring appointments, and your unusual trips. These are metadata, and they often speak louder than the content.

The second vector is the account rather than the device. An attacker doesn’t need to physically touch your iPhone if they can take control of your Apple ID or your Google account. A successful SIM swap, followed by an SMS password reset, and the adversary reaches your cloud backups, your photos, sometimes your messages — without ever going near the handset. That’s why the security of the work phone starts with the security of the account that feeds it, not with the armoured case.

The third vector, reserved for genuinely targeted profiles, is active exploitation: IMSI catchers that intercept nearby mobile traffic, forensic-extraction tools of the Cellebrite or GrayKey type used at borders and during detention, and mercenary spyware of the Pegasus class capable of a zero-click compromise. These threats are rare but real for exposed executives, journalists, corporate lawyers, and anyone travelling to a high-risk region. It’s that last third that justifies the hardest configurations — Lockdown Mode, a hardened system, a disposable mission phone. Applying them to the average person is theatre; failing to apply them to a confirmed target is negligence.

iPhone versus Android: the comparison without the folklore

Let’s lay out the technical facts, no slogans. On hardware security, the two platforms are now on a par at the high end: Apple’s Secure Enclave and the Pixel’s Titan M2 are dedicated coprocessors that isolate the encryption keys and the biometrics from the main system. Fingerprint or face unlock doesn’t release the key outside that chip, and the number of attempts is capped in hardware. On this ground, a recent iPhone and a recent Pixel offer comparable protection against brute-forcing the passcode.

The real difference plays out on three concrete axes. The first is the pace and universality of updates. Apple pushes an iOS release the same day to the entire compatible fleet, and a critical fix reaches hundreds of millions of devices within days. On the Android side, fragmentation remains a problem: only Pixels and a handful of manufacturers guarantee fast and durable patches; across the rest of the fleet, a mid-range phone bought two years ago may receive no security patch at all. For professional use, that disqualifies most consumer Android phones outright and narrows the serious Android choice to the Pixel range — or to a hardened system on top of it.

The second axis is the app model. App Store control eliminates most consumer malware, at the cost of a locked-down ecosystem. Android allows installation outside the store (sideloading), which is at once a precious freedom for an informed profile and an open door for a user who taps an APK received in a message. Permission granularity works the other way: Android, and especially hardened systems on top of it, allow far finer control over what an app can do — notably cutting an app’s network access while leaving its other permissions intact, something iOS can’t do natively.

The third axis is forensic extraction and borders. Tools of the Cellebrite or GrayKey type constantly exploit flaws to extract the contents of a seized phone. No platform is durably immune, but the state the device is in at the moment of seizure changes everything: a phone that hasn’t been unlocked since reboot (the BFU state, Before First Unlock) has its data encrypted at rest and resists far better than a device already unlocked once (the AFU state). Operational discipline — fully powering off the phone before a sensitive border crossing rather than locking it — counts more than the brand. On this point, a border search isn’t handled with a case but with a procedure: full shutdown, a long passcode, no active biometrics in a high-risk zone.

The right approach: a spectrum, not a camp

There’s no “best phone.” There’s a spectrum of isolation, from the most convenient to the hardest, and you place the cursor according to the threat model and the convenience you’re willing to sacrifice. Here are the four notches I actually use.

Notch 1 — standard iPhone, dedicated account. For the majority of professional uses in a non-critical company, this is the honest baseline. iOS brings good base security: app isolation (sandboxing), Secure Enclave for biometric and encryption keys, fast updates pushed simultaneously to the whole fleet, strict App Store control that eliminates most malware. The lever that changes everything isn’t the device but the account: an Apple ID dedicated to work, with no Family Sharing, with iCloud Photos and the backup of sensitive documents disabled. It’s free, it’s invisible to the user, and it removes nearly all of the accidental leaks I see in audits.

Notch 2 — iPhone + Lockdown Mode. For profiles at risk of advanced targeting — executives, corporate lawyers, journalists, publicly exposed people. Lockdown Mode disables or restricts the functions that have served as the entry point for documented attacks: JIT compilation in WebKit (eliminates an entire class of browser exploits at the cost of slower browsing), link previews in Messages, wired connections to an unknown device when the phone is locked (which complicates cable extraction), unsigned configuration profiles. The ergonomic cost is real but bearable: some web apps lag, a few features disappear. Test it over a normal week before imposing it on an executive, otherwise he’ll switch it off the first Friday evening.

Notch 3 — Pixel running GrapheneOS. When the threat model justifies leaving the consumer ecosystem. GrapheneOS is a hardened Android, developed independently of Google, that runs only on Pixels. It brings things that exist nowhere else: per-app network permission (you let an app use the mic but cut all its internet access — it captures but can’t exfiltrate anything), an optional Play Store run in a sandbox with no system privilege, no Google services active by default, serious kernel hardening. The downside is honest: some banking or enterprise apps refuse to run for lack of Play Integrity, and adoption requires accepting a more austere ecosystem. For sensitive operational use with a handful of chosen apps, it’s the most solid solution available on a smartphone.

Notch 4 — dedicated mission phone. For high-risk, time-boxed situations: an M&A operation, a sensitive negotiation, a trip to China or Russia. A burner phone with a temporary eSIM, minimal configuration, no personal apps and no personal accounts, no access to corporate systems except through a strictly controlled VPN. The principle is the same as the travel laptop: the device is designed to be lost, seized, or compromised without it being an incident. The main phone stays home, or goes into airplane mode and never leaves the safe.

Across that whole spectrum, three cross-cutting measures are worth more than the choice of platform. One, secure the account that feeds the phone: hardware MFA, no SMS recovery, monitoring for SIM swap with the carrier. Two, move sensitive conversations to Signal, the only messenger that combines end-to-end encryption (E2EE) with minimal metadata collection — WhatsApp encrypts the content but hands Meta who talks to whom, when, and how often, which is enough to reconstruct a deal. Three, inventory the apps and cut abusive permissions. These three moves cost nothing and close more doors than any change of phone.

BYOD or dedicated phone: the honest trade-off

The question comes up at every deployment: should you let people use their own phone (BYOD, Bring Your Own Device) or provide a dedicated work device? The theatrical answer — “everyone on a dedicated device” — is financially and humanly untenable. The honest answer depends, once again, on the data that passes through.

BYOD has two real advantages you can’t wave away. It costs less, and above all it’s better adopted: people take care of their own phone, always have it on them, don’t leave it “at the office over the weekend.” Deployment studies consistently show a higher security-policy adoption rate on devices users own. But BYOD has a structural limit: you’re imposing compartmentalization on a machine that belongs to someone else and whose uses spill far beyond the work context. Family iCloud, personal messaging, hobby apps, private photos — all cohabit with company data. An MDM can apply policies, but it can’t decide what the user does with a file once they’ve opened it in a personal app.

The dedicated phone offers real isolation: a cloud account created for work, with no link to private life, no Family Sharing, no personal camera roll hoovering up the documents. In return, you pay for the second device, you accept a sometimes mediocre adoption rate, and you assume the user will eventually install three personal apps on the work phone after a few months — which reintroduces some of the mixing you wanted to avoid. Discipline isn’t decreed, it’s designed: a dedicated phone with no control procedure drifts into a BYOD in disguise.

My arbitration is simple. Below a certain sensitivity threshold — a salesperson, a project manager with no access to strategic data — a properly configured BYOD, with a compartmentalized cloud account and a work container, is acceptable. Above it — the executive committee, finance during an operation, legal in litigation — it’s a dedicated device, full stop. And for the extreme notch, travel to a high-risk region, it’s a mission phone that doesn’t survive the trip.

What the MDM can do, and what it can’t

Since the MDM is the tool everyone leans on, let’s be precise about its real perimeter. An MDM can enforce a PIN or biometrics, encrypt the work container, wipe the device or the work profile alone remotely, block certain apps or categories, enforce a permanent VPN, automatically distribute Wi-Fi and mail configurations, see the list of installed apps and their versions, and verify the OS is up to date before authorizing access to company resources (integrity attestation, a building block of a zero-trust approach).

An MDM cannot read the content of encrypted conversations — Signal, iMessage, WhatsApp remain opaque to it, which is deliberate and healthy. It can’t prevent a screenshot of a displayed document, nor a photo of a screen taken with another device. It controls nothing of what happens in personal apps installed outside its perimeter. And on a BYOD, it can’t technically guarantee that a copy-paste from a work app to a personal app won’t leak the data, short of deploying an aggressive application DLP policy that users quickly route around if it’s too painful.

The operational lesson fits in one sentence: an MDM gives an illusion of control over personal devices. If your security policy rests on the conviction that the MDM prevents data leakage from a BYOD, you’re managing a risk you believe contained when it isn’t. The MDM is necessary, it’s never sufficient, and it never replaces compartmentalization by account and by device.

What it means in practice

For you, as an individual

Three things this week, under £200, that genuinely reduce your exposure without changing phone.

Separate the account, not necessarily the device — on your iPhone, create a clean work use: turn off Family Sharing for your sensitive documents, switch off iCloud Photos for work folders, check that no shared album syncs your screenshots. Free, ten minutes, and it removes the most frequent leak.
Clean up the permissions — review, app by app, who accesses your location, your mic, your contacts. Cut “always on” geolocation for everything that isn’t a map you use live. Uninstall the free weather, torch, free VPN, and utility apps: their business model is you. Free.
Move the sensitive stuff to Signal — for any conversation you wouldn’t want read by a third party, use Signal and enable disappearing messages. And protect the account that holds your phone: hardware MFA or an authenticator app, never SMS, and call your carrier to enable protection against SIM swap. Free.

For you, the CISO / IT director / executive

1. An MDM with no work/personal segmentation isn’t acceptable for executives. Imposing an intrusive MDM on an executive’s personal device — one that sees their apps, can wipe everything, reads their location — creates a legitimate and entirely predictable resistance: they’ll refuse the kit, or worse, route around it. Modern MDMs (Jamf, Intune) allow data separation via work containers or application DLP profiles. Direct consequence: if your BYOD deployment doesn’t technically separate work from personal, you have a GDPR legal risk over the personal data you administer, on top of an uncontrolled work-data leak.

2. Define the phone by the risk level of the data, not by user convenience. Map which roles access what: a salesperson with no access to strategic data can stay on a well-configured BYOD; an executive-committee member during an operation must have a dedicated device with a compartmentalized account. Direct consequence: without that mapping, you apply the same policy to the whole fleet, so too much friction for some and not enough protection for others — and it’s exactly the exposed executive who gets the most dangerous exemption.

3. Write and test the exit procedure. What happens to a BYOD phone when the employee resigns? Does the partial wipe really erase only the work container? Verify it under real conditions, not on the vendor’s product sheet. Direct consequence: a misconfigured wipe erases a former employee’s family photos (litigation guaranteed) or leaves work data on a device gone into the wild (leak guaranteed).

Mistakes we see all the time

BYOD with Family Sharing iCloud active: files received or downloaded on the “work” phone surface in albums shared with the family. Accidental, systematic, and invisible until the incident.
Believing Lockdown Mode protects against everything: it hardens the attack surface against specific exploits. It does nothing against a user who voluntarily forwards a sensitive document on WhatsApp.
WhatsApp for deal discussions: the content is encrypted, fine. But the metadata — who, when, how often — has value in itself and goes to Meta.
GrapheneOS imposed on someone who needs their banking app: the finest config in the world is useless if the user keeps a second, un-hardened phone in parallel to do what the first no longer does.
Securing the handset and forgetting the account: a device locked to the TPM is worth nothing if the Apple ID resets via an SMS interceptable through SIM swap.
Counting the work phone and forgetting the other one: the uninventoried device — the old personal Android, the kids’ tablet connected to the same account — is the leak by default.

Actionable checklist

N1 Create an account (Apple ID / Google) dedicated to work, separate from the personal and family account
N1 Disable Family Sharing and iCloud Photos for sensitive work data
N1 Audit permissions app by app and cut superfluous 'always on' geolocation
N1 Uninstall ad-supported free apps (weather, free VPNs, utilities)
N1 Move sensitive conversations to Signal with disappearing messages
N2 Protect the account with hardware MFA or an app, never SMS, and enable anti-SIM-swap protection with the carrier
N2 Enable Lockdown Mode for profiles at risk of advanced targeting, after a week of testing
N2 Deploy an MDM with documented work/personal separation and a tested exit procedure
N2 Map roles by the risk level of the data accessible from mobile
N3 Evaluate a Pixel running GrapheneOS for the most sensitive operational profiles
N3 Plan a disposable mission phone with a temporary eSIM for travel to high-risk countries
N3 Inventory all devices attached to work accounts and neutralize orphan devices

Going further

The GrapheneOS documentation concretely details the network-permission model and how the sandboxed Play Store works — read it before any real deployment. Apple’s Lockdown Mode guide lists exactly which functions are disabled, indispensable for calibrating an executive’s ergonomic expectations. The Apple Platform Security Guide documents the Secure Enclave and the encryption chain, and the NCSC’s Mobile Device Guidance frames the subject from the standpoint of an enterprise policy. On the adjacent vectors, see the SIM swap, the travel laptop, and preparing for a trip to a high-risk region, covered in the related articles.

Sources and further reading

GrapheneOS — Documentation [official]
Apple — Lockdown Mode [official]
NCSC — Mobile Device Guidance [official]
Apple Platform Security Guide [official]