BYOD: what you can actually enforce on a phone you don't own

BYOD is not a decision you get to make

Most organisations think they are deciding whether to allow personal devices. They are not. The moment someone can reach webmail in a browser, or install the Outlook app and sign in, BYOD has already happened. The decision in front of you is narrower and more useful: whether work data on a personal phone sits somewhere you can see and revoke, or somewhere you cannot.

Answering it well requires being honest about a tension that most BYOD policies paper over. Every control you add to a device you do not own is a control you are asking an employee to accept on their own property, and the ones that protect you most are the ones they will resist hardest. Pretending that tension does not exist is how you end up with a signed policy nobody follows.

The two models, and what each one costs you

Underneath every vendor's branding there are two fundamentally different approaches.

Full device enrolment — MDM in the traditional sense. The device is registered with your management platform and you manage the device: passcode policy, encryption, OS version, which apps may be installed, and a wipe capability. Strong control, maximum visibility, maximum friction.

Application-level protection — app protection policies, sometimes sold as MAM. The device is not enrolled and you never manage it. Instead you manage the work apps on it: work data must stay inside approved apps, copy and paste out is restricted, a PIN is required to open the work container, and you can wipe the work data without touching anything else. Less control, far less friction, and no claim over the personal half of the phone.

The instinct is to treat the second as the weaker option. For personally owned phones it is usually the correct one, because a control people accept beats a stronger control they route around.

What full enrolment actually lets you see

This is the conversation that goes badly when it happens after rollout instead of before. Enrol a personal phone and, depending on platform and configuration, the organisation can typically see the device model, serial, OS version, phone number, and an inventory of installed applications — including the personal ones. On a supervised or fully managed device it can go considerably further.

What it generally cannot see, on a normally configured deployment, is the content of personal messages, personal photos, browsing history or call contents. That distinction is real and worth stating plainly to staff, because in the absence of a clear answer people assume the worst.

The one that causes actual disputes is wipe. A full device wipe on an enrolled personal phone removes everything, including the photos of somebody's children. Most platforms support a selective wipe that removes only work data, but only if the deployment was configured for it and the administrator picks the right option under pressure at 6pm on a Friday. Decide which wipe you are entitled to perform, write it down, and make the default the selective one.

What app protection does instead

App protection puts the boundary around the data rather than the hardware. Work email, files and chat live inside managed apps; the policy stops data being copied into unmanaged apps, saved to personal cloud storage, or backed up outside your control. The employee's phone remains theirs and unenrolled.

The trade-offs are genuine and you should know them going in. You cannot enforce device encryption or a device passcode directly — you enforce a PIN on the work container instead. You have limited visibility of the device's health, so a jailbroken or badly out-of-date phone is harder to detect, which is exactly the gap mobile threat defence exists to close. And you are relying on the app boundary holding, which means the list of approved apps is a security control and should be maintained like one.

In exchange, offboarding becomes trivial. Revoke access and the work data is removed from the container without a conversation about someone's personal photos.

The Australian overlay everyone forgets

Two things make this more than an IT decision in Australia, and both are commonly missed.

The first is workplace surveillance. Several states and territories — New South Wales, the ACT and Victoria among them — have specific legislation governing surveillance of workers, with notice requirements that differ between them. Device management that collects location or application inventory can engage those obligations depending on how it is configured and where your people work. If you operate across more than one state, the strictest applicable requirement is the practical planning assumption.

The second is that personal devices holding work data are still your responsibility under the Privacy Act if that data includes personal information. A phone lost with unprotected client data on it is capable of being an eligible data breach, and "it was their own phone" is not a defence. The mirror image is also true: a selective-wipe-capable container is often the difference between a lost phone being an incident and being a notification.

This is general information rather than legal advice, and surveillance law in particular is state-specific. Have your employment adviser read the policy before it goes out.

Choosing between them, role by role

The mistake is picking one model for the whole organisation. Segment by what the role can reach:

• Corporate-owned devices — full enrolment, every time. You own it, so manage it properly. This is also the right answer for any role with standing access to bulk client data or payment authority.
• Personal phones, standard roles — app protection. Email, Teams and files in a managed container, no enrolment, no argument.
• Personal phones, privileged roles — do not. Administrators and anyone who can approve payments should use a corporate device for those functions. If that is not affordable, the fallback is a managed container plus phishing-resistant authentication, not a stronger BYOD policy.
• Contractors and temporary staff — app protection with a defined expiry. The access should lapse by default rather than requiring someone to remember.

Whichever model applies, conditional access is what makes it real. A policy that says "personal phones must use the managed app" and a rule that only permits the managed app to connect are very different things, and only one of them survives a determined workaround.

What the policy has to say

A BYOD policy that only says "you must comply with IT requirements" is not a policy. The questions people will actually ask, and which you should answer in writing before anyone enrols:

• What can the organisation see on my device, specifically?
• What can the organisation delete, and under what circumstances?
• What happens on the day I leave, and who initiates it?
• Who pays for the data, and is any allowance provided?
• If IT breaks my personal phone while supporting it, what then?
• Am I expected to respond to work messages outside hours because the phone is with me?

That last one is not an IT question, and it is the one most likely to cause a problem later. Answer it anyway.

Questions

General information about how BYOD controls and Australian workplace surveillance obligations commonly operate, not legal advice. Surveillance requirements differ by state and territory — have your employment adviser review any policy before you issue it.