Web Protection for macOS
- Last UpdatedJul 17, 2025
- 12 minute read
Web protection detects and blocks inbound and outbound threats that occur during network activity with computers. Web protection is configured via policies in the Jamf Security Cloud portal.
Web protection blocks the following macOS threats:
Phishing attempts
Malware
Command and Control (C2) servers
Unauthorized app stores
Web protection provides category-based content filtering, which allows you to prevent access to risky content. When access to content is blocked, you can configure clear messages about the blocked content to end users.
Web protection can be deployed through a Jamf Protect agent deployment or independently through a configuration profile in Jamf Pro (or another UEM).
Setting up web protection with Jamf Protect involves the following steps:
Activating your Jamf Security Cloud account
Deploying an activation profile to enable web protection to macOS computers
Configuring a threat prevention policy
Configuring a content filtering policy
Testing and validating the previously configured policies
Configuring UEM Connect to sync computer information between Jamf Security Cloud and your UEM or MDM solution, such as Jamf Pro
Jamf Security Cloud Data Processing
Enabling integrations via the Jamf Security Cloud portal results in all customer data (including personal data) processed by this feature being transferred, processed, and stored within Jamf infrastructure located in Ireland.
Administrator access to Jamf Pro
Administrator access to Jamf Security Cloud.
For more information, see Setting Up Your Jamf Security Cloud Portal Account.
macOS computers enrolled with Jamf Pro
Familiarity with deploying computer configuration profiles using Jamf Pro
A Jamf Protect for Business subscription
For equivalent functionality for Education using Jamf Safe Internet, contact Jamf.
For assistance, log in to Jamf Account with your Jamf ID and click Get Help
in the top-right corner of the page to contact your Account team.
Due to limitations with macOS 14.x and earlier, Jamf Protect web protection is not compatible with EPP/EDR software that deploys a firewall network extension on the endpoint (for example, Microsoft Defender or CrowdStrike Falcon). To avoid this compatibility issue, Jamf recommends updating your devices to macOS 15.x or later.
Web protection is deployed through your MDM solution using an activation profile in Jamf Security Cloud.
If you have already followed the instructions in the Distribute the Jamf Trust App with Jamf Pro documentation, you may have already deployed an activation profile to devices. If so, disregard this step and advance to the next step in the workflow.
Administrator access to your Jamf Pro account
Access to the administrative portal of Jamf Protect
Access to Jamf Security Cloud to use a pre-configured activation profile
Configure your threat prevention policy in the Jamf Security Cloud to prevent web-based threats such as phishing, cryptojacking, and malicious network activity.
- In Jamf Security Cloud, navigate to .
- On the screen that appears, click Apply smart policy to apply suggested security default settings.
- Click Laptop under Filter by platform.
- Review the pre-configured policies and modify to fit your organization's security requirements.
- Click Save in the top-right corner of the page.
Configure your content filtering policy in the Jamf Security Cloud to enforce category-based internet content filtering or custom block rules. You can do this by selecting a default set of rules, and then configuring them as required.
Use the following instructions to make sure web protection is deployed and working properly on your target devices.
There are two areas to check: on the target computer and in the Jamf Security Cloud portal.
Validating Your Web Protection Deployment on a Computer
Use a test computer to confirm that your threat prevention and content filtering policies are correctly deployed.
If you are unable to verify your policies are deployed, check your UEM or MDM solution to confirm your deployment was successful.
Validating UEM Connect Syncing and Policy Reporting in Jamf Security Cloud
When macOS computers are enrolled with a UEM or MDM instance that is connected to Jamf Security Cloud via UEM Connect, the computer information is automatically added to Jamf Security Cloud when it connects to the internet.
You must configure UEM Connect to display the correct platform, otherwise the device type appears as Unknown in Jamf Security Cloud.
When deployed, the web protection service handles all DNS requests generated on a macOS computer.
In more complex networking environments,"split-DNS" handling, where DNS request routing is prescribed based on your specific networking requirements, may be required.
The DNS Settings profile used by the web protection service enables two levels of control that you may adopt based upon your networking requirements:
Disabling web protection completely under specific network conditions.
Configuring specific domains to always bypass the web protection service.
Both of these configurations rely on the DNS Settings profile's On Demand rules parameter. These rules are constructed using XML and must be crafted manually either in your UEM/MDM solution's UI or by editing the profile downloaded from Jamf Security Cloud before being uploaded to your UEM or MDM solution. In either case, it is important that you test the profile changes on test devices to ensure proper behavior before deploying to production.
Modifying On Demand DNS Settings
Depending on your UEM or MDM solution, the On Demand rules payload of the DNS Settings profile may or may not be directly editable via the solution's management console.
For Jamf Pro, the On Demand XML settings can be edited in the web app.
Disabling Web Protection on Devices
There are certain situations where your network security policies require you to disable web protection completely on the device. These situations include:
When devices are using an enterprise network that has a local security stack or proxy that the device must use.
When the device connects using a corporate VPN, all DNS requests must be handled by the enterprise's DNS name servers.
You can configure a rule to disable web protection by defining certain network criteria. The criteria may include:
Wi-Fi SSID
DNS name server IP address
DNS search domain match is assigned to the device
As part of the network criteria, specify the connection that will disconnect when that criteria is met.
The following example shows a sample On Demand rules payload that does the following to the web protection service on the device, evaluated in this order:
Disable web protection if the DNS search domain issued to a device matches
*.customer.com.Disable web protection if the DNS name server addresses issued to the device is
10.102.46.20or10.102.46.30.Otherwise, enable web protection.
<array> <dict> <key>DNSDomainMatch</key> <array> <string>*.customer.com</string> </array> <key>Action</key> <string>Disconnect</string> </dict> <dict> <key>DNSServerAddressMatch</key> <array> <string>10.102.46.20</string> <string>10.102.46.30</string> </array> <key>Action</key> <string>Disconnect</string> </dict> <dict> <key>Action</key> <string>Connect</string> </dict> </array>You can use the following steps to discover the DNS search domains and DNS name service addresses that are configured by the network you are connecting:
In Terminal, enter the command scutil --dns when your macOS device is connected to the network in the manner in which you would like web protection disabled.
The resulting response should include a list of search domains and DNS name server IPs, like this:
DNS configuration resolver #1 search domain[0] : cof.ds.customer.com search domain[1] : ds.customer.com search domain[2] : kdc.customer.com search domain[3] : osd.dev.customer.com search domain[4] : dev.customer.com search domain[5] : uk.customer.com search domain[6] : customer.com nameserver[0] : 10.102.46.20 nameserver[1] : 10.102.46.30Then, issue the same command when the device is "off net", and ensure the returned values sufficiently differ from the "on net" values that were returned. You can then use those "on net" values to define the conditions in which web protection should be disabled.
Bypassing Specific Domains
In network environments where a "split-brain" DNS is present—that is, where hostnames belonging to a specific domain can only be resolved by (internal) private DNS name servers—it is often necessary to bypass those domains from the web protection configuration. Otherwise, those private/internal hostname lookups will be sent to Jamf, where a public resolution will be attempted and will fail in most cases.
This is very common where VPNs are used or for situations where a device should only be able to resolve and connect to specific services when directly connected to the organization's local network (for example via Wi-Fi or Ethernet).
Unlike the solution to disable web protection on endpoints in this scenario, it may be desirable to keep web protection active to protect the device from network threat, but to bypass (that is, ignore) specific organization-owned domains.
To do this, define EvaluateConnection rules in the On Demand rules section of the DNS Settings profile. The DNS Settings ship from Jamf Security Cloud with some of these rules already configured, so you can add your own entries to the existing EvaluateConnection dictionary.
Assuming you want all DNS lookups destined to .company.com and .company.lcl to always bypass the web protection service—thereby using whatever DNS resolver has been set on the device given its current network connection—you would modify the On Demand rules as follows:
<array> <dict> <key>Action</key> <string>EvaluateConnection</string> <key>ActionParameters</key> <array> <dict> <key>DomainAction</key> <string>NeverConnect</string> <key>Domains</key> <array> <string>*.customer.com</string> <string>*.customer.lcl</string> <string>*.jamf.com</string> <string>*.jamfcloud.com</string> <string>*.push.apple.com</string> <string>identity.apple.com</string> <string>iprofiles.apple.com</string> <string>setup.icloud.com</string> <string>vpp.itunes.apple.com</string> <string>deviceservices-external.apple.com</string> </array> </dict> </array> </dict> <dict> <key>Action</key> <string>Connect</string> </dict> </array> The service bypasses *.jamf.com and *.jamfcloud.com along with specific Apple services to enable service continuity in the event of a major web protection outage. This would allow the web protection service to be temporarily removed from endpoints in the event of a service outage.
If you are not using Jamf Cloud, Jamf recommends adding the hostname (for example, mdm.company.com) used by your macOS devices to communicate with your MDM server to the list of EvaluateConnection hosts.
Bypassing Specific SSIDs
The most common reason for bypassing specific SSIDs is when dealing with networks that have a captive portal not following WISPr standards. Such networks are frequently encountered in the airline industry.
When a network does not adhere to WISPr, it often leads to Apple devices being unable to display the captive portal page, which is essential for establishing an internet connection through that network. The root cause of this issue lies in the use of Jamf DNS servers instead of the DNS provided by the local network. Typically, only the local DNS server can provide the IP address of the captive portal.
To prevent the use of the Jamf DNS server on a specific WiFi network, you can configure an SSID bypass. With SSID bypass enabled, the device uses the local DNS server for hostname resolution instead of Jamf servers. However, it is important to note that this effectively disables all web protection functionality while the device is connected to this SSID.
<array> <dict> <key>Action</key> <string>Disconnect</string> <key>SSIDMatch</key> <array> <string>AlaskaWiFi.com</string> <string>BA Wi-Fi</string> <string>BAWi-Fi</string> <string>deltawifi.com</string> <string>DeltaWiFi.com</string> <string>EurostarTrainsWiFi</string> </array> </dict> <dict> <key>Action</key> <string>Connect</string> </dict> </array>Using Multiple Bypass Rules
On Demand rules are processed from top to bottom; once a match occurs, all further rules are ignored.
This means that because the EvaluateConnection section always counts as a match, with the domains/hostnames contained within being bypassed or not, any further Connect or Disconnect actions that are added lower in the list of On Demand rules will always be ignored.
To exclude entire networks from using web protection, these rules must be added above the EvaluateConnection rule that is added by default to the payload.
- App status column in Jamf Security Cloud
The app column is not applicable for web protection devices. Currently, red X icons display in this column indicating there is no app activity. This is a known issue and will be changed to a "not applicable" icon soon.
- Content Filtering Policy
Web protection macOS computers are affected by the "Traffic Interface: Domestic" content filtering policy type at all times.
- Reporting
Web protection macOS devices are shown under the "Traffic Interface: Domestic" filter in the Reports section.
- Captive Portal Networks
- For devices on macOS 12.5 or earlier, certain Wi-Fi networks that require authentication to reach the Internet—such as coffee shops, airplane networks, and hotels—may not work while the service is enabled. To avoid this limitation, upgrade devices to macOS version 12.5 or later. If it is not possible to upgrade the devices to macOS 12.5 or later, you can configure web protection in Jamf Pro to exclude unsupported versions of macOS. For more information on configuring scope in Jamf Pro see Scope.