Filter shared office devices according to their fixed job, not the permissions of the last person who used them. Give tablets and kiosks a distinct device or network scope, allow only required destinations where practical, and test the complete task on the device. Reset user sessions separately, because DNS cannot identify the person at the screen.
Start with the shared job
A reception check-in tablet, warehouse scanner, meeting-room controller, point-of-sale display, and public information kiosk are all shared, but they do not need the same internet access. Write one sentence describing the device's approved job. Then list the vendor services, update endpoints, identity provider, time service, and support destinations required to perform it. That purpose becomes the testable boundary; “office device” is too vague.
Name a custodian even when no person owns daily use. The custodian approves changes, knows how the device is reset, and receives failure reports. Record its location, management status, resolver method, network, expected device label, and retirement process. Do not assign activity to the last employee who signed in: background services continue making lookups, and another person may already be using the screen.
Choose a stable enforcement point
A managed tablet may support an operating-system DNS configuration. A locked kiosk may be easier to govern through a dedicated network segment. Devices without native encrypted DNS may inherit resolver settings from DHCP. Select the point the device consistently uses, then check whether a browser, VPN, privacy relay, or application chooses another resolver. Apple documents managed DNS settings for Shared iPad and other enrolled devices, while Windows documents native DNS-over-HTTPS behavior.23
| Situation | Useful scope | Main check |
|---|---|---|
| Managed roaming tablet | Endpoint DNS configuration | Works off-network and after restart |
| Fixed kiosk bank | Dedicated network or device scope | No unrelated devices share the rule |
| Meeting-room controller | Segmented device policy | Calling, updates, and calendar work |
| Temporary event tablet | Time-bounded configuration | Removal and reset are owned |
Separate shared equipment from guest and employee traffic wherever practical. This avoids giving a public kiosk the access expected by a managed laptop and avoids breaking infrastructure with a human browsing policy. CISA recommends segmenting guest traffic from operational traffic; the same boundary helps keep a public device out of trusted employee scope.4 Network scope alone may not distinguish devices sharing a segment, so verify what identity the resolver actually receives.
Build a shared-device policy
- Define the device job and name its custodian.
- Capture required domains from vendor documentation and a short observation period.
- Apply normal threat protection to the shared-device scope.
- Add narrow destination rules only when the job requires them.
- Record every exception with its reason, owner, test, and review date.
- Create a rollback path that restores the last known working resolver configuration.
- Document session reset, software update, replacement, and retirement separately from DNS.
An allow-only approach can suit a truly single-purpose kiosk, but it demands careful testing because cloud services often depend on several changing hostnames. Start with documented domains and observe failures narrowly. Do not allow a broad wildcard or disable a threat category merely to silence one error. If the device is general-purpose, ordinary threat protection plus specific blocks may be more maintainable than an incomplete allow list.
Test, reset, and recover
Test cold start, sign-in, the complete user task, sign-out or session reset, updates, and recovery after a network interruption. Repeat after changing the rule and from every network the device is meant to use. Confirm the intended resolver, test a harmless blocked domain supplied by the provider, and verify that required services still work. A DNS success does not prove that authentication, certificates, or application APIs work.
Keep a local recovery instruction for the custodian. It should say how to identify a DNS-related failure, how to switch to the approved rollback state, whom to contact, and how to preserve only the evidence needed for diagnosis. A captive portal or third-party VPN can interfere with encrypted DNS, so distinguish those conflicts from a block decision before adding an exception.
Avoid shared-device mistakes
- Do not use DNS policy as a substitute for kiosk mode, patching, strong authentication, or physical controls.
- Do not retain individual-looking labels when the device rotates among users.
- Do not place a kiosk on the trusted employee network merely because setup is quicker.
- Do not forget vendor update and certificate-validation destinations during testing.
- Do not leave temporary event devices enrolled after they are returned or repurposed.
DNS filtering acts on domain lookups and policy outcomes. It cannot read page contents, URLs beyond the hostname, search terms, in-app chats, voice audio, or full browser history. It also cannot erase downloads, cookies, saved passwords, or app sessions. Shared-device safety therefore combines DNS with device management, session isolation, updates, network segmentation, and a visible way to report problems.
Shared-device questions
Should a kiosk use the normal employee DNS policy?
Usually not by default. A kiosk has a narrow shared purpose and often needs fewer destinations than a staff laptop. Give it a purpose-specific scope, then test every required service instead of inheriting broad employee access.
Can DNS filtering sign users out of a shared tablet?
No. DNS policy does not clear browser sessions, app tokens, downloaded files, autofill, or local history. Use kiosk mode, managed guest sessions, application controls, and a documented reset process for user-state hygiene.
Should shared-device DNS activity name individual users?
Not unless a separate authorized sign-in system provides that attribution. DNS normally identifies a device, resolver, or network context, not the person at the screen. Keep retained activity limited to a stated operational or security purpose.
Apply shared scope in Veilty
In Veilty, keep shared office devices in the relevant Tenant and give their stable operational group reusable, Tenant-scoped baseline policy. Use Tenant-scoped enforced policy only for requirements members must not override, and keep kiosk exceptions narrow and owned. Test the real workflow plus a harmless blocked domain before rollout. Invitations happen at account scope and do not grant Tenant access by themselves; assign a Tenant role afterward. Retained activity belongs to the Tenant and is available only through permitted Tenant roles. When enabled, it is end-to-end encrypted, while the resolver still processes live requests.1