Mobile Guardian uses two systems to enforce web filtering and content policy on managed devices: on-device synchronisation and cloud categorisation. These systems work together to ensure that filtering rules are applied consistently, whether a device is on the school network, at home, or offline.
This article explains what each system does, how they interact, which platforms use which approach, and how the data flows between the device and the Mobile Guardian Dashboard.
What You Will Learn
- What on-device synchronisation is and how it applies filtering rules locally
- What cloud categorisation is and how it classifies web content in real time
- How the two systems work together to enforce web filtering
- Which platforms use on-device filtering, cloud filtering, or both
- How sync intervals affect policy updates and reporting
On-Device Synchronisation
On-device synchronisation is the process by which a managed device downloads its assigned filtering policy from the Mobile Guardian platform and enforces it locally. The device holds a local copy of its profile configuration, including allow lists, block lists, keyword rules, and category settings. When a user attempts to access a URL, the on-device agent or extension checks the request against this local policy before the connection is made.
How it works:
- The Mobile Guardian agent (or browser extension) on the device connects to the Mobile Guardian platform at regular intervals
- It downloads the latest version of the device’s assigned profile, including any changes made by an administrator since the last sync
- The profile is stored locally on the device
- All web requests are evaluated against the local profile in real time
- Blocked requests are denied immediately on the device, without needing to route through an external server
What gets synchronised:
- Web filter allow lists and block lists (URLs, wildcard domains, and categories)
- Keyword block lists
- Safe content settings (safe browsing, safe search enforcement)
- Profile assignment (Baseline or Conditional)
- Schedule and zone-based rules (if configured)
Note
On-device filtering decisions happen locally, which means filtering continues to work even if the device temporarily loses internet connectivity. The device enforces the last-synced policy until a new sync completes.
Cloud Categorisation
Cloud categorisation is the process by which Mobile Guardian classifies a URL in real time using a cloud-based categorisation engine. When a device encounters a URL that is not explicitly listed in its local allow list or block list, the request is sent to the Mobile Guardian cloud service, which returns a category classification. The device then applies the profile’s category rules to determine whether the URL should be allowed or blocked.
How it works:
- A user on a managed device navigates to a URL
- The on-device agent checks the URL against the local allow list and block list
- If the URL is not explicitly listed, the agent sends the URL to the Mobile Guardian cloud categorisation service
- The cloud service returns a category (e.g., Social Media, Gaming, Education, Adult Content)
- The agent checks the returned category against the profile’s category rules
- The request is allowed or blocked based on the category configuration
Why cloud categorisation is needed:
- The internet contains billions of URLs. Maintaining a complete local database of every URL and its category on each device is not practical
- Cloud categorisation provides real-time classification of new, uncategorised, or recently changed websites
- It ensures that filtering remains effective against newly created domains that have not yet appeared in any static list
Note
Cloud categorisation requires an active internet connection. If a device is offline and encounters an uncategorised URL, the filtering behaviour depends on the profile’s default action setting: either allow uncategorised traffic or block it until connectivity is restored and the URL can be classified.
How the Two Systems Work Together
On-device synchronisation and cloud categorisation are not alternatives. They operate as two layers of the same filtering pipeline:
| Layer | What It Does | When It Applies |
| Local allow/block list | Permits or denies URLs that the administrator has explicitly listed | First check, applied immediately on the device |
| Local keyword rules | Blocks pages containing specific keywords | Applied to page content after the URL check |
| Cloud categorisation | Classifies URLs not found in the local lists and applies category rules | Only when the URL is not explicitly allowed or blocked locally |
Processing order:
- The device checks the URL against the local block list. If matched, the request is blocked immediately
- The device checks the URL against the local allow list. If matched, the request is allowed immediately
- If the URL is not in either list, the device sends it to cloud categorisation
- The returned category is checked against the profile’s category rules
- If the category is blocked, the request is denied. If allowed (or uncategorised and the default action permits it), the request proceeds
This layered approach means that administrators have direct control over specific URLs via lists, while cloud categorisation handles the broader internet without requiring manual classification of every site.
Platform Differences
The filtering mechanism varies by platform due to differences in how each operating system allows Mobile Guardian to intercept web traffic.
| Platform | On-Device Agent | Filtering Mechanism | Cloud Categorisation |
| Android | Mobile Guardian app (MDM agent) | Intercepts web traffic via the on-device app. Supports the Mobile Guardian Browser for enhanced filtering | Yes |
| iOS / iPadOS | Mobile Guardian app (MDM agent) | Uses the iOS content filter framework to intercept web requests system-wide on supervised devices | Yes |
| ChromeOS | Mobile Guardian Chrome extension | Monitors and blocks web requests via Chrome extension APIs (webRequest, webRequestBlocking) | Yes |
| Windows | Mobile Guardian Edge extension | Monitors and blocks web requests via the Edge browser extension, deployed through Microsoft Intune | Yes |
| macOS | Mobile Guardian app (MDM agent) | Uses the macOS content filter framework on supervised devices | Yes |
Note
On ChromeOS and Windows, filtering is applied at the browser level through the extension. Traffic from other applications outside the managed browser is not filtered by the extension. On Android and iOS/iPadOS, the on-device agent can filter traffic system-wide, including traffic from apps outside the browser.
Sync Intervals and How They Affect Policy Updates
When an administrator makes a change in the Mobile Guardian Dashboard, such as adding a URL to a block list or changing a category rule, the change is not applied to devices instantly. Devices pick up changes on their next sync cycle.
Default sync behaviour:
- The Mobile Guardian agent on each device checks in with the platform at a regular interval to download updated policy
- The default interval varies by platform and can be adjusted in the dashboard under Settings > Global Preferences (see Device Update Frequency)
- The sync interval can also be affected by battery state: devices with low battery may sync less frequently to conserve power
What triggers a sync:
- The regular timed interval (configured in Global Preferences)
- A manual sync initiated from the dashboard (available for some platforms via device actions)
- The device reconnecting to the internet after being offline
- A user signing in on a ChromeOS device (the extension fetches the latest policy on sign-in)
What does NOT trigger an immediate sync:
- Saving a profile change in the dashboard does not push the change to devices in real time. Devices must check in to receive the update
- Changing a device’s profile assignment takes effect at the next sync, not immediately
Note
If you need a policy change to take effect urgently, you can trigger a manual sync from the dashboard. Navigate to Devices in the left-hand menu, select the device, and use the Sync action (where available for the platform). On ChromeOS, having the student sign out and back in will also force the extension to re-sync.
How Filtering Data Flows Back to the Dashboard
Filtering is not only about blocking content. The on-device agent also reports browsing activity and filter events back to the Mobile Guardian platform, where they appear in the Web Filter Reports section of the dashboard.
What is reported:
- URLs accessed by the device (allowed and blocked)
- The category assigned to each URL (from cloud categorisation)
- The action taken (allowed, blocked, or flagged)
- Timestamps and the profile that was active at the time
Reporting flow:
- The on-device agent logs each web request and the filtering decision
- At the next sync interval, the agent uploads the log data to the Mobile Guardian platform
- The data appears in Reports > Web Filter Reports in the dashboard
- Administrators can review, filter, and take action on reported URLs directly from the report (see Actions on Web Filter Report)
Note
Web filter report data is uploaded during the regular sync cycle, not in real time. There may be a delay between a browsing event on the device and its appearance in the dashboard report, depending on the configured sync interval.
Summary
| Concept | Description |
| On-device synchronisation | The device downloads its filtering policy from the platform and enforces it locally. Filtering works even when the device is temporarily offline |
| Cloud categorisation | URLs not found in local lists are classified in real time by a cloud service. Requires an active internet connection |
| Processing order | Local block list, then local allow list, then cloud categorisation. Explicit lists always take priority |
| Sync interval | Devices check in at a regular interval to download policy updates. Configurable under Settings > Global Preferences |
| Reporting | Browsing activity and filter events are uploaded to the dashboard during the sync cycle and appear in Web Filter Reports |
Please let us know if you found this helpful.
Thanks for reading! 🙂