Deploying with MDM

Outbound supports managed deployment at three levels. Configuration profiles install the network filter without prompting the person using the Mac. Managed preferences force policy choices the user cannot change. A managed rule feed, audit export and SIEM delivery (also forced through preferences) supply the rules and collect the decisions. The preference keys are covered in Managed preferences, the feed in Managed rule feed, and the log in Audit log export.

Teams licences are one seat per Mac, billed yearly. Email support@outboundfirewall.com with the number of Macs and we reply with a quote within 2 business days. Deploy the key to every Mac by forcing the LicenseKey managed preference.

Before you deploy

• Install the sample profiles on a pilot Mac first, as with any system extension, before rolling them out.
• System-extension and content-filter policies require user-approved MDM enrollment on the device channel. User Enrollment is not enough.
• Check Outbound alongside your endpoint security stack during the pilot.
• Keep a way to remove the filter policy through MDM as part of your recovery plan.

Identifiers

The samples on the IT page identify the app com.outboundfirewall.outbound, the filter extension com.outboundfirewall.outbound.filter and signing team 5GS535L4GD. Recheck these identifiers against the release you deploy: the bundle IDs and the team are fixed in the app, and macOS matches them exactly.

The content-filter payload carries a designated requirement for the data provider, anchor apple generic and identifier "com.outboundfirewall.outbound.filter" and certificate leaf[subject.OU] = "5GS535L4GD". macOS refuses to run the extension if its signature does not satisfy it.

The sample profiles

Five sample files are published for download:

1. System-extension policy (outbound-system-extension-policy.mobileconfig): install first. It must be on the Mac before the app asks to install the extension, otherwise the user sees the approval prompt.
2. Content-filter configuration (outbound-content-filter.mobileconfig): install second. It pre-approves the filter configuration so macOS does not ask the user to add it.
3. Managed preferences (outbound-managed-preferences.mobileconfig): install any time. The app reads it at launch and picks up changes while it runs.
4. Managed login items (outbound-login-items.mobileconfig): optional, macOS 13 or later. It locks the background agent’s switch on in System Settings › General › Login Items, matched by com.outboundfirewall.outbound.agent and team 5GS535L4GD.
5. Sample rule feed (sample-rule-feed.json): a schema-versioned example with 3 rules, for your own feed server. See Managed rule feed.

Sign profiles with your MDM’s profile-signing certificate. The samples are system scope and pass plutil -lint.

The system-extension policy

Payload type com.apple.system-extension-policy. It pre-approves the network filter, which is a Network Extension system extension, so the person using the Mac never sees an approval dialog.

Key	Value in the sample	Effect
AllowedSystemExtensions	5GS535L4GD and com.outboundfirewall.outbound.filter	That extension loads without a user prompt.
AllowedSystemExtensionTypes	5GS535L4GD and NetworkExtension	Team 5GS535L4GD may only ship network extensions.
NonRemovableSystemExtensions	5GS535L4GD and com.outboundfirewall.outbound.filter	The extension cannot be disabled or uninstalled while SIP is on.

AllowedSystemExtensions and AllowedSystemExtensionTypes work on macOS 10.15 and later. NonRemovableSystemExtensions is a macOS 15-or-later control; earlier versions ignore it. Check that the restriction fits your recovery policy before you install it.

The sample does not set AllowUserOverrides, so it does not restrict which other vendors’ extensions a user may approve. Keep a way to remove this policy through MDM as part of your recovery plan.

The content-filter payload

Payload type com.apple.webcontent-filter. It registers Outbound as a socket-level content filter so macOS does not ask the user to approve the filter configuration.

Key	Value in the sample
FilterType	Plugin
PluginBundleID	com.outboundfirewall.outbound
UserDefinedName	Outbound
FilterSockets	true
FilterBrowsers	false
FilterGrade	firewall
FilterDataProviderBundleIdentifier	com.outboundfirewall.outbound.filter
FilterDataProviderDesignatedRequirement	the requirement quoted above

FilterSockets true is what a firewall needs: it filters socket flows rather than only browser traffic, which is why FilterBrowsers is false. The sample sets FilterGrade to firewall.

Deployment order

1. Install the system-extension policy.
2. Install the content-filter configuration.
3. Install the managed-preferences payload (any time before or after the app).
4. Optionally, install the managed login items profile (macOS 13 or later).
5. Install Outbound.app into /Applications and open it once, or run a launch script that does, so the app submits the system-extension activation request. With steps 1 and 2 in place the extension activates without a prompt.

Tip

To check what the app and the agent report on a deployed Mac, use outboundctl status on the Mac itself, or sudo outboundctl audit export --to <dir> to collect decisions without opening the app.

Inventory and diagnostics

outboundctl status --ea <field> prints one status value as plain text, so an MDM inventory script, such as a Jamf extension attribute, can collect it from every Mac:

#!/bin/sh
echo "<result>$(/Applications/Outbound.app/Contents/MacOS/outboundctl status --ea filter_enabled)</result>"

The fields include app_version, filter_enabled, extension_state, mode, active_profile, rules, unapproved_rules, managed_feed and cli_changes; the full list is in outboundctl status. A value that can’t be read prints unknown.

For a support case, outboundctl diagnose --out <file.zip> writes a redacted archive with the status, managed preferences, rule and blocklist counts, the system extension list and Outbound’s recent log. Host names, addresses and user folder names are redacted unless you add --include-hosts.

After deployment

• Managed preferences, the rule feed and the audit export have their own pages. All of them count only when the key is forced by a profile; the same keys written as ordinary user defaults do nothing.
• A user on a managed Mac can still read everything: the Network Monitor, rules and settings stay visible, and editing is locked only where your profile locks it. See Locking settings for what that looks like.
• If the mode is forced, the mode controls in the app and the menu bar panel are disabled and the app says so: “Your organization sets the mode”.