Inventory devices before applying DNS policy so every rule has a known owner, resolver path, network context, and support plan. Separate managed, shared, personal, fixed, and roaming endpoints before enforcement. This exposes coverage gaps and overly broad scope early, while giving operations a repeatable record for testing, troubleshooting, changing, and retiring each configuration.
Inventory the path, not just the hardware
A serial-number list answers what the company owns, but DNS enforcement depends on how a lookup travels. A managed laptop may use an endpoint configuration in the office and on a hotspot. A printer may inherit DNS from an infrastructure network. A personal phone may use guest Wi-Fi, cellular data, a browser-specific encrypted resolver, or a VPN. List the expected path and the path observed during a test before choosing policy scope. Otherwise, a rule that looks correct in a console may never receive the device's requests.
Start with populations rather than one undifferentiated fleet: company laptops, personal devices authorized for work, shared tablets, meeting-room systems, printers and IoT, developer machines, guests, and roaming endpoints. Name an operational owner for each population and an accountable user or custodian where appropriate. NIST treats BYOD as a distinct security and privacy problem because personally owned devices create different risks and authority boundaries.4 Veilty managed BYOD support is planned for Enterprise use, so personal-device inventory here is general planning guidance, not a current Veilty setup path.
Record the fields that change enforcement
| Field | Decision it supports | Example |
|---|---|---|
| Population and owner | Who approves scope and exceptions | Managed sales laptop; operations |
| Management and consent | What the team may configure | Company managed; personal opt-in |
| Resolver method | Where policy is applied | Endpoint DoH; network DHCP |
| Network contexts | Where tests must run | Office, guest Wi-Fi, hotspot |
| Expected identity | How results are attributed | Stable device label; site only |
| Test and retirement | Whether control is current | Pass date; remove on return |
Also record the expected policy, any justified narrower rule, known VPN or browser-DNS interaction, and a rollback contact. Keep personal-device data minimal: a work-purpose label and configuration state are usually more useful than hardware details unrelated to enforcement. Tell staff what is configured, what activity may be retained, who can access retained data, and how a configuration is removed when participation ends. An inventory should reduce uncertainty, not become a second source of unnecessary personal data.
Turn inventory into policy scope
- Group devices by ownership, management status, resolver path, and network context.
- Assign normal protection through reusable, Tenant-scoped baseline policy.
- Reserve Tenant-scoped enforced policy for requirements members must not override.
- Segment guests, infrastructure, shared equipment, and developer devices when their needs differ.
- Document narrow exceptions with an owner, exact domain, reason, test, and review date.
- Choose representative devices from every population for a reversible pilot.
Inventory is not a reason to force endpoint software onto every object. A fixed printer may fit a segmented network policy; a roaming laptop may need an endpoint path; a visitor belongs on guest Wi-Fi rather than in the employee register. Use the least intrusive method that delivers the intended domain-level outcome. Keep endpoint, identity, browser, email, and network controls for risks DNS cannot address.
Verify before and after enforcement
Before enforcing, capture the resolver used and whether one harmless provider-supplied test domain receives the expected result. After applying policy, repeat the test from the actual device in each relevant context: office Wi-Fi, guest Wi-Fi where authorized, hotspot or cellular, VPN on and off, and a travel network if roaming matters. Apple and Windows both expose managed or native encrypted-DNS behavior, so check the endpoint and browser rather than assuming one network setting owns every request.23
Use aggregate success and failure counts first. Inspect a narrow slice of retained activity only for a named troubleshooting or security purpose. DNS can show requested domains and policy outcomes; it cannot read page contents, search terms, in-app chats, voice audio, or full browser history. A successful lookup also does not prove that a page loaded or that a person deliberately opened it.
Keep the register operational
Assign updates to existing lifecycle events. Onboarding adds the endpoint and its first verification. Replacement transfers the intended scope but requires a fresh test. Offboarding removes the configuration, revokes access through the owning systems, and marks the endpoint retired. Network, VPN, browser, and major operating-system changes trigger retesting. A monthly or quarterly stale-entry check catches devices missed by those events.
Reconcile the register against two independent operational sources, such as device-management enrollment and network assignment records. Investigate mismatches rather than automatically deleting them: a missing entry may be an unmanaged endpoint, while a silent device may simply be powered off. Record the resolution and next review date so the same uncertainty does not return each cycle.
- Do not treat a console label as proof that traffic arrives through the intended path.
- Do not put guests, personal phones, printers, and managed laptops under one convenient rule.
- Do not retain detailed activity indefinitely merely because storage is available.
- Do not leave replaced or returned devices active in the operational register.
- Do not enforce until the pilot has a named rollback path and owner.
Device inventory questions
Does a small team need a full asset-management platform first?
No. A maintained worksheet can be enough for a small fleet. It should name an owner, management status, resolver method, expected policy, network contexts, latest test, and retirement action. The process matters more than buying a large inventory system.
Can DNS logs replace a device inventory?
No. Logs may show an identifier or source context, but they do not reliably establish ownership, authorization, management status, off-network behavior, or retirement state. Applications also make background lookups, so a DNS request does not prove a person visited a site.
How often should the inventory be reviewed?
Review it when people join or leave, devices are replaced, networks or VPNs change, and operating systems receive major updates. Add a lightweight scheduled review to find stale entries that event-driven updates missed.
Map the inventory to Veilty
In Veilty, keep currently supported work devices within the relevant Tenant. Apply reusable, Tenant-scoped baseline policy for ordinary protection and Tenant-scoped enforced policy only where members must not override a requirement. Test one representative endpoint from every supported population before widening scope. Invitations happen at account scope and do not grant Tenant access by themselves; assign the appropriate Tenant role afterward. Retained activity belongs to that Tenant and is available only through permitted Tenant roles. When enabled, it is end-to-end encrypted, while the resolver still processes live requests to answer them.1