Gatekeeper and SIP: a macOS Compliance Baseline

On macOS, two native mechanisms form the first line of defense of any managed Mac: Gatekeeper, which controls the origin of launched applications, and System Integrity Protection (SIP), which protects system files and processes even from the administrator account. Too often teams pile on expensive third-party tools, forgetting that this foundation is already present, enabled by default and free. Including it explicitly in your compliance baseline prevents many incidents and gives auditors tangible proof of control for ISO 27001 or NIS2.

What Gatekeeper and SIP do

These two mechanisms act at different moments in a piece of software's life, and their complementarity is their strength. Understanding each role helps you clearly explain why both must stay enabled.

Gatekeeper: control at execution

Gatekeeper checks an app's signature and notarization before its first run. An app downloaded outside the App Store must be signed by an identified developer and notarized by Apple, otherwise macOS blocks its launch by default. It is an effective barrier against malware distributed as booby-trapped applications.

SIP: protecting the system itself

SIP, enabled by default since OS X El Capitan, prevents modification of protected system directories (/System, /usr, /bin) and critical processes, even by the root account. As a result, malware that gained administrator rights still cannot alter the core of the system or install a persistent rootkit.

• Gatekeeper blocks apps not signed or notarized by Apple.
• SIP protects /System, /usr and critical processes from the root account.
• Together they strongly limit the installation of persistent malicious software.
• They are natural requirements for ISO 27001 (control A.8) and NIS2.

Checking status with a compliance policy

Intune lets you define a macOS compliance policy that requires, among other things, Gatekeeper and the system firewall to be active. The principle is simple: the device evaluates itself, reports its state, and a non-compliant Mac can be flagged and then denied access to resources through Conditional Access.

1. 1Create a dedicated macOS compliance policy in Intune.
2. 2Require Gatekeeper to be enabled (App Store and identified developers).
3. 3Check system firewall status and FileVault encryption.
4. 4Set an action and a grace period for non-compliance.
5. 5Pair the policy with Conditional Access to block non-compliant machines.

Common mistakes to avoid

The main risk comes not from initial configuration but from poorly managed exceptions. A developer who disables SIP to debug and then forgets to re-enable it leaves a machine lastingly weakened.

• Disabling SIP for a one-off need and never re-enabling it.
• Globally allowing apps from unidentified developers instead of targeted exceptions.
• Neglecting macOS updates, which withholds the latest notarization rules.
• Treating a SIP-disabled Mac as compliant just because it runs normally.
• Forgetting to pair compliance with Conditional Access, making it purely informational.

Best practices

Never disable SIP in production, even temporarily, without a controlled procedure: a machine with SIP disabled should be treated as non-compliant. Document the rare exceptions, time-box them and monitor them. Keep macOS up to date to benefit from the latest notarization rules, and include FileVault verification in the same profile to cover encryption, execution and integrity in one coherent check.

A Mac with SIP disabled is no longer a trusted Mac: treat it that way.

A concrete example

Take the case of a developer machine that, to install an uncommon tool, temporarily disables SIP and then allows an unsigned application. The technical need was real, but the machine stays in this weakened state for weeks afterward: nothing prevents malware that gains root rights from installing itself permanently in system directories. Without a compliance baseline, no one notices. With a policy that requires SIP active and Gatekeeper set to identified developers, that Mac would be flagged non-compliant immediately, the user would be notified, and access to sensitive resources would be withheld until it is restored.

This scenario illustrates why continuous verification matters more than the initial setup. A machine correctly configured at deployment can drift at any moment; only permanent evaluation, paired with Conditional Access, guarantees the security state stays compliant over time and provides an audit-ready trail. It also spares your team the tedious, error-prone work of checking each Mac by hand.

Combining the native foundation with EDR

Gatekeeper and SIP form the foundation, but they do not replace a detection and response solution. The first filters app origin, the second protects the system; neither continuously analyzes behavior nor responds to incidents. For full coverage, pair this baseline with Microsoft Defender for Endpoint, whose risk level can also feed compliance. You then get a coherent defense in depth, where each layer plays a distinct and verifiable role.

• Gatekeeper: control of app origin at execution.
• SIP: protection of system integrity, even against the root account.
• FileVault: disk encryption to protect data at rest.
• System firewall: filtering of incoming connections.
• Defender for Endpoint: advanced detection, investigation and response.

Bringing these elements together in one baseline avoids blind spots and eases the production of evidence during an ISO 27001 or NIS2 audit, since each control is documented and verified continuously rather than checked once and forgotten.

How AuPoint helps

AuPoint turns these requirements into a ready-to-use macOS compliance baseline, in plain language and without scripting. You verify Gatekeeper, SIP, the firewall and FileVault encryption continuously, with an impact preview before activation and guided remediation for machines that drift. Each check maps to your compliance objectives, letting you feed your Conditional Access rules and produce ISO 27001 and NIS2 evidence with confidence.

Frequently asked questions

Can you tell remotely whether SIP is disabled?

SIP status is a device property that compliance and security mechanisms can evaluate. A machine whose system integrity is compromised should be flagged non-compliant, then remediated before regaining access to resources.

Is Gatekeeper enough to replace antivirus?

No. Gatekeeper filters app origin at execution, but it does not detect threats already present or malicious behavior in progress. It complements an EDR solution such as Microsoft Defender for Endpoint for full coverage.

Should you enforce App Store only?

Not necessarily. The recommended setting allows the App Store and identified developers, which covers most legitimate business applications while blocking unsigned software.

Want to make Gatekeeper and SIP a continuously verified baseline, without PowerShell? With AuPoint, deploy your macOS compliance baseline in a few clicks and feed your Conditional Access with confidence.