Using AirWatch to Manage Corporate-Owned vs. BYOD Devices Separately
Many Australian organisations support teams that work across Sydney and Melbourne offices, regional depots and home locations. Their fleets can include company-issued tablets, corporate laptops and personal phones carrying business email and approved apps. Treating every endpoint alike creates either unnecessary restrictions for employees or gaps for the business. The practical aim is shared visibility while giving each ownership class its own enrolment and policy depth.
AirWatch, now associated with VMware, provides one enterprise mobility management console for configuration, endpoint security and support. Separate management does not mean two disconnected systems. Corporate-owned devices can receive deeper configuration and restrictions because the organisation owns the hardware. BYOD users need a managed work zone without exposing personal photos, messages or other data. Clear boundaries also give IT, security and business teams a consistent operating model.
Why ownership changes what you can enforce
Ownership determines what an organisation can reasonably enforce, not only who bought the device. Corporate-owned units may support app restrictions, managed Wi-Fi and VPN settings, required software and remote data removal. Applying the same controls to a personal phone can feel invasive. Separate classes let administrators scale management depth to the actual relationship with each user.
BYOD participants should receive clear consent and a boundary around managed work data. Staff can understand which apps are controlled and what happens when they withdraw access, while a personal area stays outside the corporate container. Corporate users can accept a more prescriptive profile without every personal handset being treated as company equipment. Ownership and job risk remain separate decisions.
Australian workforces often mix city-based office staff with technicians in regional WA, Queensland and South Australia. A field technician may need offline maps and barcode scanning, while a clinician may need rapid record access on a personal phone. One broad policy can miss both needs. Ownership groups provide a stable base for adding role-specific controls across mobile, office and field users.
Design enrolment around the device owner
Start with enrolment design because policy decisions depend on what AirWatch knows about an endpoint. Corporate-owned devices normally suit administrator-led enrolment, with ownership assigned through the relevant MDM or device-owner route. The endpoint can then receive company apps, configuration and role-based controls. Staff should not have to guess whether a new handset is personal or business equipment.
For BYOD, user enrolment creates a clearer boundary because the employee chooses to participate and the organisation manages a work profile or container rather than the whole handset. AirWatch can align that mode with identity, access rules and required apps. Deployment labels vary, so confirm the available options in the console and operating documentation before assigning ownership.
Create a clear naming convention before enrolment, such as a company site code, ownership type and sanitised device ID. Imported and manually registered devices should use the same fields. This prevents a tablet bought by a local branch from inheriting BYOD settings merely because it entered through a user portal. For multi-state Australian teams, consistent records also reduce duplicate tickets and simplify audits.
Separate groups before writing policies
Separate groups should reflect ownership and operational responsibility before policies are written. A useful structure might include corporate laptops, corporate mobile devices, BYOD work profiles and shared kiosks with a dedicated policy. Refine each group by role, region or risk rather than creating dozens of nearly identical policy targets. Clear boundaries make exceptions easier to approve and audit.
Policy order and group membership determine which rule reaches a device first. Keep ownership rules broad enough to prevent accidental cross-assignment while allowing BYOD groups lighter defaults than corporate groups. Test precedence outside production, because a small matching change can redirect thousands of endpoints. Document which platform setting controls each behaviour so the next administrator can reproduce the result.
Policy labels should express business intent without replacing technical testing. A BYOD label might promise “work profile only,” while a corporate label promises “managed company device.” Underlying settings still need to show what users can change, which features are enforced and what data can be erased remotely. Clear naming helps staff, support teams and auditors understand those controls.
Match security controls to risk and privacy
Corporate-owned endpoints can usually support stronger management because the business owns the hardware. Depending on role and risk, administrators may apply device restrictions, managed browser settings, app allowlists, VPN profiles and update deadlines. Remote lock and wipe are appropriate when company data remains on the endpoint. Shared or specialist devices can use kiosk mode to reduce unmanaged entry points.
BYOD controls should protect the company portion of the device while respecting personal ownership. Conditional access, published applications, browser protection and a work VPN can secure business traffic without governing the entire handset. Any remote wipe must target a managed container or corporate data rather than everything on the phone. The support policy should also explain what is cached and what employees must do before returning or selling a device.
Privacy design belongs in the same policy conversation, especially under Australia’s Privacy Act 1988, Australian Privacy Principles and Notifiable Data Breaches scheme. Mobility deployments should explain what employee information is collected, why it is needed and how long it is retained. HR, legal and security teams should review notices and consent language for BYOD programmes; enrolment is not a substitute for privacy governance. No technical control removes that responsibility.
Give users a practical support path
Most device problems are solved by making the right action easy to find, rather than by stricter policy. A self-service portal can show compliance status, ownership and the next step, such as approving an update or reinstalling a required app. For BYOD participants, it should distinguish work tasks from personal settings. Australian workplaces often value a straightforward “no worries” route for routine support, backed by clear escalation.
For publishing the portal, the AirWatch self-service setup guide provides a useful setup sequence. Include the enrolment link, approved terms and escalation details in the service catalogue. Corporate-owned devices can have an internal support route, while BYOD users need the difference between troubleshooting a work profile and seeking help with personal hardware made clear.
Support hours should reflect users spread across the country rather than one city roster. A Sydney office starting at 9:00 a.m. may overlap with a field team in Kalgoorlie beginning at 7:00 a.m., and remote workers may log in outside standard hours. A local knowledge desk can follow the sun with a published escalation path while self-service resolves routine cases. Track recurring issues by ownership type so support capacity reflects actual demand.
Pilot with real Australian workflows
A full fleet rollout creates avoidable confusion, so begin with a representative pilot. Include company laptops used by field staff, BYOD phones used by sales representatives and corporate tablets used in a warehouse or clinic. The pilot should cover different network conditions, including regional connections and travelling staff. Test both initial enrolment and the everyday tasks users will perform.
Set baseline measures before changing settings: enrolment time, support contacts per device, compliance failures, app deployment success and recovery time for a lost device. Give pilot participants a simple feedback route and review responses by ownership and role. A policy that looks secure in the console but generates repeated false alerts may still be wrong for that cohort.
Use staged promotion rather than one large switch-over. Move from pilot to department, then region and only then to the wider estate if service levels remain acceptable. Recheck ownership records when employees change roles, receive replacements or leave. Align promotion and review dates with each team’s operating calendar so support and device reconciliation do not collide with major operational periods.
Build the business case for sustainable management
The business case should combine licence fit with operational savings, not present mobility management as a technology purchase alone. Compare packages against expected device counts, user needs, required management depth and the support model for a corporate fleet or BYOD programme. A fully managed option may suit a regulated corporate environment, while a lighter user-enrolled package may work better for occasional remote workers.
Include onboarding time, administrator effort, training, replacement loss, app licensing, help desk cost and the risk of data left on departing employees. Customer stories can show how comparable organisations handled deployment, but check their outcomes against local conditions instead of copying them wholesale. Confirm Australian currency, tax treatment and contracted support terms directly when comparing quotations, because a headline saving can disappear in exchange differences or add-ons.
Define success before the trial ends: perhaps eight of ten new users enrol without assistance, help desk tickets remain stable and every BYOD participant can find the work profile and privacy information. Use the fully functional 30-day free trial to test the hardest workflows, not merely the easiest enrolment path. Package comparisons and a sales discussion can then rest on measured demand and clear policy intent.
Start the 30-day free trial with a representative cohort from both corporate-owned and BYOD populations. Use it to validate enrolment, test group-specific policies and gather evidence for purchasing. Package comparisons and customer stories can help refine the shortlist, while a sales contact can confirm local support, pricing and implementation details.
Begin with the devices already in service, define ownership and role, and assign only the controls each class requires. That focused start creates a usable baseline, cleaner support and a practical path to secure enterprise mobility.