“Restrict what my kid can access online” sounds like one problem. It’s actually a question of which layer enforces the restriction, because a browser, a device account, and a network each control a different, narrower slice of what’s possible — and each has a different way of being bypassed. Picking the wrong layer is why a lot of parental-control setups quietly stop working within a week.
Four layers, four different jobs
Roughly in order of how close they sit to the child’s actual click:
- Browser-level — a specific browser (or a browser configured with an extension or policy) decides what loads.
- Device/account-level — the operating system account the child is logged into carries restrictions that apply regardless of which browser is opened.
- Network-level — a router or DNS provider decides what resolves, for any device on that network, regardless of account or browser.
- Enterprise/MDM-level — a managed device profile (common in schools) enforces policy centrally and typically blocks the user from changing it at all.
None of these is a superset of the others. A restriction enforced at one layer often doesn’t apply at all once you move to a different layer.
Browser-level controls
A dedicated approved-site browser, or a mainstream browser locked down with an extension or enterprise policy, controls what loads inside that specific application. This is the tightest, most granular layer — it can distinguish individual URLs, not just domains, and can present a genuinely different experience (a locked, chrome-less window with no address bar) rather than merely blocking pages.
Its limitation is exactly that scope: it only governs that one browser. If the account also has access to a second browser — or can install one — the restriction doesn’t travel with the account. This is why the strongest browser-level tools remove the ability to reach any other browser or navigation surface from that account, rather than just controlling their own window.
Device/account-level controls (Windows)
Windows account-level tools — Microsoft Family Safety being the mainstream example — apply restrictions to a specific Windows account rather than a specific application. Screen-time limits, app restrictions, and category-based web filtering (primarily enforced through Microsoft Edge and SmartScreen) travel with the account across whatever’s installed on that machine.
The trade-off is precision. Account-level filtering is generally category-based — “block adult content,” “block gambling” — which means it inherits the same gap every category filter has: new or miscategorized sites aren’t caught until they’re classified. It also depends on the child using a standard, non-administrator account; a child with administrative rights on the machine can typically change or remove the restriction outright.
Network-level controls (DNS/router)
DNS filtering and router-level controls operate a layer below any single device — they decide what resolves for anything connecting through that network. This makes them the right tool for “every device in the house” or “every device on the school network” rather than “this one child’s account,” since a network-level rule can’t distinguish which family member is asking.
Their bypass surface is different, too: a device that has its own DNS setting overridden, or that leaves the network entirely (cellular data, a neighbor’s Wi-Fi, a VPN), is no longer subject to the rule. Network-level controls are strong for shared-network hygiene and weak as the sole safeguard for a specific child’s device that travels.
Enterprise/MDM-level controls
Mobile device management and school-issued device profiles sit above user-level permissions entirely — policy is pushed centrally, and the logged-in user typically cannot alter it, reinstall a browser, or gain administrative rights, because the device itself is managed by an organization rather than the person using it. This is the layer schools and libraries generally need for CIPA-style compliance, precisely because it doesn’t depend on a single account staying correctly configured.
It’s also the most operationally heavy: someone has to manage the device fleet, push policy updates, and handle exceptions, which is exactly the IT overhead that smaller schools, homeschool co-ops, and libraries often don’t have.
The bypass surface, layer by layer
Every layer has one:
- Browser-level: reachable if another browser is installed or already present on the account.
- Device/account-level: reachable if the child has (or can obtain) administrator rights on that account.
- Network-level: reachable if the device leaves the network or has its own DNS override.
- Enterprise/MDM-level: reachable only through a flaw in the management platform itself — which is the point.
Knowing the bypass surface of the layer you’re relying on is the actual question to ask before trusting it, not the marketing description of what it blocks.
Why admin rights are the boundary that actually matters
Across the first three layers, the practical security boundary usually isn’t the filtering software at all — it’s whether the child’s account has standard (non-administrator) permissions. Nearly every device- or browser-level control can be worked around by a user with admin rights: uninstalling the restriction, installing an unrestricted browser, or changing account settings directly. A meticulously configured filter on an administrator account is a suggestion, not a control.
Layering instead of picking one
These layers are complementary, not competing, which is why a single-layer setup is usually the one that breaks first. A common, practical combination for a younger child on a shared Windows computer: a standard (non-admin) account, a dedicated approved-site browser as the only browsing surface on that account, and network-level filtering as a backstop for any other device that connects. No single layer needs to be perfect if the others cover its specific gap.
Where this applies on Windows specifically
Kidsplorer operates at the browser layer on a standard Windows account — the approved-site list is enforced inside a locked browser environment, and the account boundary (not the filter) is what stops a child from reaching around it. For the full layer-by-layer comparison on Windows, including where Kidsplorer sits relative to Microsoft Family Safety, see How to Restrict Internet Access for Kids on Windows.
Related reading:
- Designing Parental Controls for Younger Children: Access Control vs. Surveillance — the design model behind restricting access in the first place, rather than monitoring it after the fact
- Safe Browser for Kids on Windows: How Kidsplorer Works — the browser-level approach applied on Windows
Devicode Team
Written by the team that builds and uses these products — practitioners who run into these problems in real workflows, not just analysts describing them from the outside.