Network Access Control for Unmanaged Devices
You set up network access control for unmanaged devices by checking user identity and device state before granting network entry. When a laptop lacks company software, the network places it in a restricted zone with limited reach. Teams often set up guest networks or virtual private networks for contractors and personal laptops. Still, broad network rules let anyone inside that zone reach whole servers and databases. How to set up network access control for unmanaged devices First, the networ
Network Access Control (NAC): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up network access control for unmanaged devices by checking user identity and device state before granting network entry. When a laptop lacks company software, the network places it in a restricted zone with limited reach. Teams often set up guest networks or virtual private networks for contractors and personal laptops. Still, broad network rules let anyone inside that zone reach whole servers and databases.
How to set up network access control for unmanaged devices
First, the network checks every machine that tries to join a local port or wireless signal. Managed laptops show a valid machine key and go straight to the main work network. Unmanaged laptops lack this key, so the switch moves them into a holding zone.
Next, the user must log in through a web page using their company identity. The network checks who the person is and what team role they hold. Some setups also run a quick browser check to see if the operating system is old. After login, the firewall applies a specific set of network rules to that device.
These rules list the exact server addresses and ports the contractor or personal laptop can reach. Everything else on the main network stays blocked by default. Teams also use virtual desktop setups so unmanaged machines only view a remote screen. This keeps raw files off the personal hard drive while the user works.
What native network controls solve and what they miss
Native network controls stop strangers from plugging into an office wall jack and scanning local servers. They also keep personal phones and home laptops away from core production subnets. By splitting the network into small zones, teams reduce the blast radius of a compromised laptop.
Still, network controls only care about IP addresses and ports at the start of a connection. Once a rule opens the configured port to a database, the network stops watching. It cannot tell a safe read query from a command that drops a table. The user still holds raw database passwords or long-lived keys on their personal machine.
Network Access Control (NAC): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
If malware steals those local keys, the attacker can run any query the database role allows. Network logs only show that bytes moved between two IP addresses during that time. They do not record the actual SQL statements or shell commands the user ran. Also, network rules cannot rewrite sensitive fields like emails or card numbers in query results.
Why teams move checks closer to the target
Relying only on network zones forces admins to manage hundreds of complex firewall rules. Every time a contractor needs a new database or server, someone must update IP lists. When projects end, old firewall rules often keeps the session active by mistake.
Shifting control to the command and query level removes the need for broad network trust. Instead of trusting a whole network segment, teams check every single request in flight. Users log in with their single sign-on identity, and each action faces strict rules. Sensitive data like phone numbers or national IDs gets masked in results before reaching the laptop.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is an unmanaged device on a company network?
An unmanaged device is any phone, tablet, or computer that the IT team does not control. This includes personal laptops, contractor machines, and local hardware that cannot run company management software.
Can unmanaged devices reach internal databases safely?
Network rules alone cannot make direct database connections safe from an unmanaged machine. You must remove local database passwords from the laptop and inspect every query in flight.
How does identity control differ from network control?
Network control checks the machine and opens a path between two IP addresses. Identity control checks the user on every single request and logs the exact commands they run.