Web Content Filter Data for MDM Products
Device management buyers increasingly expect web content filtering in the same console where they push apps and passcode rules. Typing domains into a block list does not scale to a fleet, or to the web.
This guide is for MDM and UEM product teams adding category-based web filtering: where it is enforced, which categories each device group needs, and how to deliver and refresh the data.
What MDM buyers ask for, and what it needs from the data
Requests from MDM customers tend to arrive in the same words. Each one translates into a specific requirement on the category data behind the feature.
Broad, dependable coverage
120 million categorized domains, with the 20 million most visited covering 99.99% of web traffic, so a short policy covers the real web.
Strong allow-side categories
Education/Reference, Webinars/E-learning and Science need to be accurate, because they become the allow-list on strict tablets.
AI tool detail
The AI / LLM Tools category plus a set of 16,000+ AI tool domains in 18 categories, updated daily, for reports and approved-tool rules.
Clean infrastructure labels
Allow-list kiosks still need CDN / Hosting / Infrastructure domains to load. Clear labels stop broken pages.
Daily freshness
About 300,000 newly registered domains are categorized daily and delivered as delta files to keep security categories current.
Data that runs locally
Files that run inside your own systems let you filter work traffic without sending personal browsing anywhere.
Where an MDM product can enforce web filtering
Managed devices offer several enforcement points. Each holds category data differently, and most MDM products combine two or more to cover every device type.
| Enforcement point | How it works | Where category data lives | Strengths | Limits |
|---|---|---|---|---|
| Configuration profile URL lists | The OS or browser enforces allow and block lists pushed in a profile | Inside the profile, as plain lists | No extra software | Profile size limits; no categories, only domains |
| Managed DNS settings | Devices use a filtering resolver, often over encrypted DNS | On the resolver you run | Covers every app, simple to deploy | Domain level only; no path or page detail |
| OS content filter component | A filtering component inspects connections on supervised or fully managed devices | Compact index on the device, plus lookups | Works on and off network | Platform rules differ; supervision often needed |
| VPN tunnel to a gateway | Traffic goes through an always-on or per-app tunnel to your filtering gateway | Full database on the gateway | URL-level policy and logging | Adds latency and gateway cost |
| Managed browser | A managed browser or browser policy applies web rules | Browser policy or extension with a local index | Fine control in the browser | Does not cover apps |
| Desktop agent | An agent on laptops filters at the network layer | Local index plus lookups | Roaming laptops stay covered | One more agent to maintain |
Which categories matter for each device group
MDM policies are built per device group, so category presets should be too. These presets are a starting point admins can adjust. Full definitions are on the category list.
Corporate devices
Security first, then productivity. Most companies block risk categories and leave content categories open.
Student devices
Strict by default, with learning categories always open. Schedules often relax rules after school hours.
Kiosks and shared devices
Allow-list mode. Only the categories the kiosk needs, plus the infrastructure that makes pages load.
Frontline and rugged devices
Narrow job use on mobile data plans. Block bandwidth-heavy and distracting categories to protect data costs.
BYOD work profile
Filter only managed apps and the managed browser. Focus on protecting company data, not policing content.
Regulated environments
Healthcare, finance and government fleets often add data-loss categories and strict remote access rules.
Offline database, lookup API, or both
Managed devices roam between office Wi-Fi, home networks and mobile data. The data design must keep filtering working wherever the device is.
Offline database
The full file on your gateway or resolver, a compact index on devices.
- Fast decisions on device
- Works with poor connectivity
- No browsing data leaves your systems
- Long tail needs a fallback
Lookup API
Devices or your cloud ask the included API for each new domain.
- Small on-device footprint
- Full coverage from day one
- Good for early releases
- Each miss is a network call
Both, layered
Device index first, then your cloud database, then the API.
- Most decisions stay on device
- Full coverage for rare domains
- One update job feeds every layer
- The usual choice for production
Sizing the on-device index
Device storage, battery and data plans all limit how much category data a managed device should hold. Size the index per device group, not once for the whole fleet.
Update cadence: regular refreshes across the fleet
Pushing a new configuration profile for every data change would flood devices with installs. Category data should travel on its own channel, while profiles carry only the policy.
Delta files
About 300,000 newly registered domains categorized each day. Apply to gateways at once; send small patches to device indexes.
First recheck
New domains are checked again after a week, since many add content after launch. Changes arrive in the deltas.
Second recheck
A further check after a month catches sites that changed purpose or left parked status.
Full refresh
All other domains are refreshed. Rebuild device indexes and roll them out by group, starting with a pilot group.
Integration steps for MDM teams
These steps take category data from a licensed file to a web filtering feature in the MDM console. Lock the policy model first, because it shapes every later step.
Design the policy model
Decide how categories map to console switches, presets per device group, and per-group exceptions.
Pick enforcement points
Choose which points you support per platform: managed DNS, content filter component, tunnel, browser, agent.
Load the database
Import the CSV, Parquet or JSON file into your cloud store and your filtering resolver or gateway.
Build device indexes
Cut, compress and sign an index per device group, and serve it from your update channel.
Wire the miss path
Device misses go to your cloud store, then the lookup API. Domain only, never full URLs.
Schedule the delta job
Apply daily deltas, generate patches, and track which devices have taken them.
Add reporting
Report blocked and allowed visits by category per group. Admins buy on reports as much as on blocking.
Pilot, then roll out
Release to a pilot group, compare block rates against expectations, then widen the rollout.
BYOD and privacy boundaries
Employees accept device management more readily when the line between work and personal use is clear. Category-based filtering makes that line easier to draw and to explain.
Inside the filter
- Managed apps and the managed browser
- Work profile traffic
- Security categories on all managed traffic
- Category-level reports for admins
- Approved and blocked AI tools for work data
Outside the filter
- Personal apps and personal browser
- Personal profile traffic
- Full URLs, paths and search terms
- Per-person browsing histories
- Content categories on personal use
Testing before each rollout
Device fleets are slow to roll back, so test data and policy changes before they leave the pilot group. Automate the tests so they run on every index build.
| Test | What it proves | When |
|---|---|---|
| Known sites per category resolve as expected | The index and policy mapping are correct | Every index build |
| Kiosk allow-list loads its pages fully | Infrastructure domains are allowed | Every kiosk policy change |
| Student tablets reach learning sites on strict mode | The allow side works | Before each school term |
| A domain from the latest delta is handled | Daily updates reach devices | Daily, automated |
| Device offline: index still filters | Roaming devices stay protected | Every release |
| BYOD personal apps are untouched | Privacy boundary holds | Every release |
Reports admins expect from category filtering
Blocking is only half of what MDM buyers pay for. They also want to see what is happening on their fleet, in terms they can share with management. Categories make those reports readable.
Top blocked categories
Per device group and per week. A sudden rise in VPN / Proxy blocks on student tablets is often the first sign of a new bypass trick.
AI tool usage
Which AI tools are reached from managed devices, by category, so security teams can approve some and restrict others.
Security events
Visits to Malware / Phishing / Suspicious domains, with device and time, to feed incident response and user training.
Data plan use
Streaming and gaming traffic on frontline devices, used to justify stricter rules or larger plans.
Policy coverage
Share of devices with a current index and policy. Auditors ask for it, and it shows where rollouts stalled.
Exception requests
Which blocked domains users ask for most. It helps admins refine presets instead of granting one-off exceptions forever.
Common pitfalls when adding filtering to an MDM
These issues come up repeatedly in MDM integrations. Each is easier to avoid at design time than to fix across a deployed fleet.
Data in the profile
Shipping domain lists inside configuration profiles hits size limits and forces a profile reinstall on every update. Keep the data on its own channel.
Broken kiosk pages
Allow-lists that forget content delivery and infrastructure domains leave kiosks with half-loaded pages. Allow the infrastructure category the site needs.
Encrypted DNS bypass
If devices can set their own encrypted DNS, a DNS-based filter is easy to skip. Manage DNS settings by policy where the platform allows it.
One policy for all groups
A single preset frustrates someone. Ship presets per device group from the first release and let admins clone and adjust them.
Licensing category data for an MDM product
An MDM or UEM product that filters customer devices embeds the data, so it needs an OEM licence. See the OEM licensing page for the model.
OEM / embedded
The data runs inside your MDM, gateways and device components. Customers see categories, presets and reports, not the raw file.
Group-wide
For vendors with several products, such as MDM plus endpoint security or a DNS service, under one licence.
Pricing
Starter database tiers from $999; enterprise and OEM licences are quoted per deployment. See pricing. Resale or publication of the raw data is not allowed.
MDM web content filtering FAQ
Why does an MDM product need URL category data?
Admins want to set web rules by type of site, not by typing domains into a list. Category data lets an MDM offer switches such as block adult content or allow only approved AI tools, and keep them current as new sites appear.
Can category data be pushed inside a configuration profile?
Small allow and block lists can be, but profile size limits make a full category list impractical. Most MDM products push a filtering component or agent that downloads a compact category index, or route traffic to a filtering resolver or gateway that holds the full database.
How do we filter BYOD devices without invading privacy?
Apply web filtering only to the work profile, the managed browser or managed apps, and log categories rather than full URLs. Personal apps and personal browsing should stay outside the filter.
How fresh is the category data?
About 300,000 newly registered domains are categorized every day and delivered as daily delta files, rechecked after a week and after a month, while all other domains get regular monthly refreshes.
Which licence does an MDM vendor need?
An OEM licence, because the data runs inside a product you sell to customers. Group-wide licences suit vendors with several products. Resale or publication of the raw data is not allowed.
Is a lookup API included?
Yes, with every licence. MDM products use it for domains their on-device index or gateway database does not hold.
Do supervised and unsupervised devices need different data?
No, the data is the same. What changes is the enforcement point: supervised or fully managed devices can usually run an OS content filter component, while lighter management may rely on managed DNS, a managed browser or a tunnel.
Can admins add their own allow and block entries?
Yes, and they should be able to. Per-group allow and block entries sit on top of the category presets and always win over them. Store them in your policy layer, not in the category data.
How do we keep kiosks working when sites change their hosting?
Allow the infrastructure categories a kiosk's sites depend on, rather than single content delivery hosts. Daily updates then pick up new hosting domains without an admin having to edit the allow-list.
Can the same data cover laptops and mobile devices?
Yes. One licensed file feeds every enforcement point. Laptop agents usually hold a larger local index, phones a smaller one, and both fall back to your cloud store and the lookup API for anything they miss.
Does category filtering work for apps as well as browsers?
At the DNS, tunnel or OS filter level it does, because those points see the domains apps connect to. A managed browser or extension only covers browsing, so most MDM products pair it with one of the network-level points.
Add category filtering to your device management console
Tell us your platforms, device groups and fleet size. We will suggest a data layout and the licence that fits.