Work laptops and personal phones should not receive the same DNS policy. A company-owned laptop may carry mandatory, roaming threat protection because the organization controls its purpose and configuration. A personal phone needs a narrower boundary tied to a work context or company network. Give each class its own resolver path, disclosure, retained evidence, exception rule, and removal process.
Separate authority from risk
Ownership tells you what the organization may manage; risk tells you what protection the work requires. Record who owns the endpoint, what company data it handles, where it connects, whether it roams, and who can change its resolver. A finance laptop and a personal phone used for calendar notifications differ on both axes. Keeping authority and risk separate prevents a convenient shared rule from becoming an unjustified device-wide policy.
For the laptop, define mandatory protection against known malicious and phishing domains, required business services, roaming behavior, administrative ownership, and support. For the phone, begin with the smallest work boundary: company Wi-Fi or an isolated work profile or browser where the platform supports it. NCSC guidance emphasizes that BYOD leaves device ownership with the user.4 If a sensitive task requires full-device control, provide a company device instead of erasing that distinction in policy.
| Decision | Company laptop | Personal phone |
|---|---|---|
| Primary scope | Managed endpoint on required networks | Work context or company network |
| Enforcement | Threat baseline may be mandatory | Narrow and proportionate |
| Administration | Company operations team | Owner retains personal control |
| Offboarding | Reimage or reassign device | Remove work configuration and access |
| Evidence | Purpose-limited operational detail | Minimum necessary, clearly disclosed |
Write two operating contracts
Write down what each policy promises. The laptop contract should name mandatory protection, permitted administration, update expectations, exception ownership, and off-network behavior. The phone contract should say whether protection ends with company Wi-Fi or follows an isolated work context, which activity may be retained, and how the employee removes access and configuration. Do not hide broader personal-phone reach in a generic acceptable-use paragraph.
Operating systems can support different managed DNS arrangements. Apple documents DNS settings payloads for managed devices, and Windows documents policy-driven DNS over HTTPS behavior.23 Browsers, VPNs, and applications may still choose another resolver. Treat the written policy as a hypothesis until the actual device path confirms it.
- Use separate endpoint inventory labels for company laptops and personal phones.
- Keep the shared security baseline narrow enough to explain domain by domain or category by category.
- Put stricter rules only on the class with the ownership and risk justification.
- Document who may request, approve, and remove an exception for each class.
- Review detailed retained activity only for a named support or security purpose.
Test the paths, not the labels
- Choose one representative laptop and one personal phone with informed pilot users.
- Capture each current resolver on office Wi-Fi, home Wi-Fi, mobile data, and through required VPNs.
- Apply the correct device-class policy without changing both devices at once.
- Test a harmless blocked test domain and essential work applications from every required path.
- Confirm the laptop remains protected while roaming and that the phone stops or continues exactly as disclosed.
- Reproduce one exception, narrow it to the necessary domain and class, and retest protection.
- Remove the phone configuration and verify offboarding without disturbing personal settings.
Measure policy outcomes, not employee behavior. Aggregate allow, block, and error counts can reveal a broken rollout or noisy rule. If diagnosis requires detailed retained activity, name the affected endpoint and purpose, limit the time window, and close the review when the fault is resolved. DNS can show a domain lookup and policy outcome; it cannot read page contents, search terms, in-app chats, voice audio, or complete browser history.
Stop one exception from crossing classes
One endpoint may encounter a network rule, endpoint resolver, browser setting, and VPN on the same day. Record which path should own each context and what happens when it is unavailable. An exception for one personal phone must not weaken every managed laptop, and a laptop allow rule should not spread to personal endpoints merely to make the lists look consistent. Scope the exception to the smallest device class and work need, then give it an owner and review date.
Common failures are grouping by operating system instead of ownership and risk, assuming office router policy follows roaming laptops, applying a whole-device phone configuration without notice, and using lookup records as proof of human intent. Retest after OS, browser, VPN, and network changes because resolver behavior can change even when the central policy did not.
Do not confuse this organizational split with a personal routine that switches one person between work and leisure settings. Here, ownership determines authority, support responsibility, retention choices, and removal rights. The two classes may happen to block the same phishing domain, yet still need different deployment and evidence rules. Record the reason for every difference in the device matrix clearly and consistently. If no ownership or risk reason supports a stricter phone rule, narrow it instead of copying the laptop baseline. If a personal phone cannot meet a necessary security requirement without broad device control, provide a managed work device and keep the personal endpoint outside that requirement.
Device separation questions
Can both device classes use the same threat list?
They may share a narrow threat baseline, but scope, enforcement, retained detail, exception handling, and off-network behavior should still reflect ownership and work risk.
What happens when a personal phone leaves the office?
Network DNS policy normally stops applying. A managed endpoint or work-profile resolver may continue, but that wider scope must be disclosed and tested.
Can DNS tell whether a lookup came from a work app?
Not reliably by itself. A domain may serve both work and personal activity, and background processes make lookups. Use a genuinely isolated work context where app-level attribution matters.
Prepare a Tenant model for device classes
Veilty support for managed BYOD is planned as an enterprise capability, so do not treat this as a current personal-phone setup guide. Teams can prepare the model now: keep company-owned device classes within the relevant Tenant, reuse baseline and enforced policies across Tenants, and allow a resource in one Tenant to override only that Tenant’s baseline. Enforced policy remains non-overridable. Invitations happen at account scope; Tenant roles then govern Tenant work and access to that Tenant’s end-to-end encrypted retained activity. The resolver still processes live requests.1