The Apple System Policy Control Policy in Swif lets you centrally manage how Gatekeeper behaves on company-owned macOS devices. Gatekeeper is Apple’s built‑in protection that controls which apps are allowed to run based on their source and code signing status.
With this policy, you can:
Enforce whether Gatekeeper is enabled
Control whether apps from identified developers are allowed, in addition to Mac App Store apps
This is one of the controls Swif uses to help you meet SSC‑1 | Security Services requirements, specifically around “Gatekeeper end-user override disable” (preventing users from bypassing Gatekeeper warnings).
Policy overview
Policy name in Swif: Apple System Policy Control Policy
Purpose: Manage macOS System Policy Control, primarily Gatekeeper behavior.
Minimum OS: macOS 10.8+
Supported platforms:
macOS
Ownership types:
Company-owned devices
This policy is designed for managed corporate Macs, not BYOD.
Key settings
The policy exposes two boolean fields:
Allow Identified Developers (
allowIdentifiedDevelopers)Enable Gatekeeper (
enableAssessment)
Both default to false in the raw payload, and you explicitly choose how strict you want Gatekeeper to be.
1. Allow Identified Developers
Field name (internal): allowIdentifiedDevelopers
Display name: Allow Identified Developers
Default: false
Minimum OS: macOS 10.8+
What it controls
This setting controls whether macOS Gatekeeper allows apps from “identified developers” (apps signed with an Apple Developer ID, but not from the Mac App Store).
Conceptually, it maps to the Gatekeeper options:
App Store only
App Store and identified developers
Behavior
If set to
true:
Gatekeeper allows apps from:The Mac App Store, and
Identified developers (Developer ID signed apps)
If set to
false:
Gatekeeper is effectively limited to Mac App Store apps only, assuming Gatekeeper itself is enabled.
When to set true
You have trusted, line-of-business apps signed with Developer ID but not distributed via the Mac App Store.
You want a balance between security and practicality:
Still block completely unsigned / unknown apps
Allow vetted vendor software from identified developers
When to set false
High-security environments where you want:
App Store–only software on corporate Macs, or
Very strict control over what can be installed (e.g., all apps deployed via MDM or a curated internal catalog).
2. Enable Gatekeeper
Field name (internal): enableAssessment
Display name: Enable Gatekeeper
Default: false
Minimum OS: macOS 10.8+
What it controls
This is the main Gatekeeper switch. It determines whether Gatekeeper is enabled on the device, which directly addresses:
Gatekeeper end-user override disable – preventing users from bypassing Gatekeeper warnings and running untrusted software.
Behavior
If set to
true(Gatekeeper enabled):Gatekeeper is turned on.
App execution is checked against Gatekeeper rules (Mac App Store and/or identified developers, depending on your other settings).
Users are prevented from easily bypassing Gatekeeper prompts to run unknown or untrusted software.
If set to
false(Gatekeeper disabled):Gatekeeper checks are effectively off.
Users can run apps from any source with far fewer restrictions.
This weakens your security posture and is not recommended for managed corporate Macs.
Relation to SSC‑1 (Security Services)
In the SSC‑1 control described in your Jira issue ST‑6445, the requirement is:
“Gatekeeper end-user override disable” → Prevent users from bypassing Gatekeeper.
In practice, this means:
Gatekeeper must be enabled, and
Users should not be able to switch it off or ignore its warnings for untrusted apps.
Swif helps you enforce this by configuring Enable Gatekeeper via this policy so that the OS itself maintains Gatekeeper protection.
Note: In your compliance logic, you might check that enableAssessment is set to the secure state you’ve defined (for example, true to ensure Gatekeeper is enforced).
Example configurations
A. Strict security (recommended for most corporate Macs)
Goal: Align with SSC‑1 Security Services and prevent user overrides.
Enable Gatekeeper (
enableAssessment):trueAllow Identified Developers (
allowIdentifiedDevelopers):falsefor Mac App Store–only environments, ortrueif you use trusted Developer ID apps
Outcome:
Gatekeeper is enforced across the device.
Users cannot easily bypass warnings and run arbitrary untrusted apps.
You maintain a controlled set of allowed sources:
Optionally Mac App Store only
Or Mac App Store + identified developers
B. More flexible, but still controlled
Goal: Allow a wider range of vendor software while keeping protection enabled.
Enable Gatekeeper (
enableAssessment):trueAllow Identified Developers (
allowIdentifiedDevelopers):true
Outcome:
Gatekeeper remains on, blocking completely unsigned / unknown apps.
Users can install apps from:
Mac App Store
Reputable vendors using Apple Developer ID
You still prevent the most risky software from running, while keeping usability high.
C. Not recommended: Gatekeeper disabled
Enable Gatekeeper (
enableAssessment):false
This configuration:
Effectively disables Gatekeeper protection.
Allows users to run apps from any source with little friction.
Conflicts with the intent of “Gatekeeper end-user override disable” in SSC‑1.
Should only be used for very specific, controlled exceptions (e.g., lab machines, short-term troubleshooting).
How this works with Swif MDM
When you assign the Apple System Policy Control Policy to a device or group:
Swif sends the System Policy Control configuration payload to macOS.
macOS applies Gatekeeper settings according to:
Enable Gatekeeper (
enableAssessment)Allow Identified Developers (
allowIdentifiedDevelopers)
Users on the device will see Gatekeeper behavior aligned with your policy, and cannot simply turn it off or bypass it if your configuration enforces it.
Together with the Apple Security Logging Policy (for audit and firewall logging), this policy forms the Security Services foundation you outlined in ST‑6445 for secure, compliant macOS environments.