Vendor devices should not inherit employee DNS rules. Put temporary equipment on a separate network and DNS resource, permit only the domains its documented task requires, and preserve enforced threat protection. Confirm network isolation separately, test the real workflow, assign an owner and end date, then remove the resource or exception when the visit ends.
Separate the machine from the person
A maintenance laptop, diagnostic tablet, payment-terminal installer, or temporary camera controller has a different job from an employee endpoint. It may need a vendor cloud, software updates, remote support, and one local appliance. It does not need the employee network merely because a person carrying it has been approved to enter the office. Start with the equipment, task, sponsor, arrival window, and required dependencies. That creates a boundary the team can test and retire.
The distinction protects both sides. An employee policy may contain productivity restrictions or internal allowances irrelevant to a service device. A vendor exception copied into that policy can affect every employee. Conversely, employee access may expose internal names or services a temporary endpoint should never reach. CISA guidance treats separation of guest traffic and organizational traffic as an architecture concern; a DNS rule is not a substitute for segmentation.3 Use a dedicated vendor SSID, VLAN, or equivalent access class, then enforce routing and firewall boundaries with the network owner.
Avoid turning the vendor name into a user identity. Label the resource by function and visit, such as “HVAC commissioning, west office, Tuesday,” rather than attaching ordinary DNS activity to a technician. A device may make background requests, share an address, or change operators. The useful evidence is whether the approved service path worked and whether a security outcome occurred, not a story about what a named person intended.
Draw a vendor access envelope
| Decision | Record | Do not assume |
|---|---|---|
| Business task | Exact equipment and service outcome | Vendor employment proves technical need |
| Network | Temporary isolated access class | DNS filtering creates isolation |
| DNS policy | Threat baseline plus verified dependencies | Employee allowances belong here |
| Exception | Exact hostname, owner, and expiry | A vendor wildcard is harmless |
| Evidence | Test result and aggregate outcome | A lookup proves a person acted |
Start with a security-focused baseline that blocks well-supported malicious infrastructure. CISA describes protective DNS as analyzing queries and preventing connections to known or suspected malicious infrastructure.2 Add only dependencies necessary for the approved task. Ask the vendor for hostnames, update endpoints, remote-support services, time synchronization, and certificate-validation dependencies before arrival, but treat the list as input rather than an automatic allowlist. Confirm domain ownership and observe what the device actually needs during a supervised test.
DNS filtering can allow, block, or otherwise answer a domain lookup according to policy. It cannot inspect a URL path, webpage contents, search terms, files, in-app chats, voice audio, or full browser history. It also cannot prove that an allowed connection completed. When two functions share one hostname, DNS cannot permit one page or API path while denying another. Use application, proxy, firewall, authentication, or endpoint controls when the decision requires those details.
Prove the service path before arrival
- Name the internal sponsor, technical owner, equipment, purpose, arrival window, and removal time.
- Place a representative device on the isolated vendor access class and confirm it cannot reach internal networks.
- Assign the intended resolver and security policy without copying employee-specific rules.
- Test a provider-owned harmless block domain and an ordinary allowed hostname; never test with live malicious infrastructure.
- Run the actual maintenance, update, authentication, and support workflow while the sponsor is available.
- If DNS blocks a dependency, verify the hostname and add the narrowest temporary allowance that does not weaken enforced protection.
- Retest IPv4 and IPv6 where offered, record rollback, and schedule removal with the work order.
Diagnose failures in order. Confirm the correct access class, captive-portal state, address assignment, route, firewall result, resolver, and policy outcome before editing DNS. A VPN, secure-DNS setting, or vendor tunnel may select another path. Record that behavior rather than claiming the DNS policy covers traffic it never receives. If the vendor needs inbound access or direct contact with a local controller, the network and application owners must approve and test that path separately.
Expire access with the work order
Temporary access often becomes permanent through neglect rather than design. Tie the network credential, DNS resource, hostname allowances, retained evidence, and sponsor review to the same end condition. At departure, confirm the device is disconnected, disable the access class when no other job uses it, and remove exceptions that have no continuing owner. Keep a short decision record: task completed, tests passed, exception removed or renewed, and who approved any renewal.
Review aggregate resolver health before opening detailed activity. If a named troubleshooting question requires retained activity, limit the resource, time window, and permitted role, then close the review when the question is answered. Common mistakes include reusing employee Wi-Fi, allowing broad vendor domains indefinitely, weakening threat rules during a rushed visit, confusing a DNS block with network isolation, and retaining device activity without a stated purpose. The completion test is simple: the vendor task works, employee policy did not change, internal routes remain closed, and temporary access has an ending.
Vendor-device questions
Can a vendor device use the employee Wi-Fi for only one day?
It should use a separate temporary access class even for a short visit. Duration does not remove the risk of inherited employee access, stale credentials, or an exception that affects unrelated devices.
Does a separate DNS policy isolate vendor equipment from internal systems?
No. DNS policy controls domain lookups and outcomes. Network segmentation, firewall rules, client isolation, and access controls must independently prevent the device from reaching employee and internal-service networks.
Should the team allow every domain named by the vendor?
No. Verify ownership and purpose, observe the failed task, and allow the narrowest required hostname. Preserve enforced threat protection and give each temporary allowance an owner and review point.
Model the vendor boundary in Veilty
In Veilty, represent the vendor access class as a distinct resource in the appropriate Tenant, separate from employee resources. Reuse baseline and enforced policies across Tenants: the vendor resource may override its Tenant baseline for a verified temporary dependency, but it cannot weaken enforced Tenant policy. Invitations add operators at account scope and grant no Tenant access by themselves. After acceptance, Tenant roles govern the Tenant, its controls, and its retained activity. Saved history belongs to that Tenant, is end-to-end encrypted with user-held keys, and is visible only through permitted Tenant roles; the resolver still processes live DNS requests. Verify one vendor device, record the expiry, and remove stale access.1