macOS Security Features: A Guide for Apple IT

Apple uses a layered approach system to protect Mac users against malware. The three layers are:

Prevent the launch or execution of malware;

Block malware from running on customer systems; and

Remediate malware that has executed.

Those three layers, in turn, rely on three distinct security systems that are built into the Mac ecosystem generally and macOS specifically:

Here’s what you as an Apple admin need to understand about those three core anti-malware strategies and how they—along with other features built into macOS—work together to make the Mac more secure.

The App Store

Apple recently reported that in 2022 alone it had rejected nearly 1.7 million app submissions to its App Store, for failing to meet the company’s standards. That number underscores the fact that every app (and every proposed app update) in the Store has been reviewed for functionality, performance, adherence to the company’s design guidelines, and—most important to this discussion—for security. That review is the first line of defense in Mac security.

While Apple understandably keeps many details about its review process under wraps, we know that it starts early: Even before an app is ready for submission, Xcode checks to be sure it relies only on what Apple calls “authorized technologies.” Once the app has been submitted, automated checks are run to check for known malware and calls to private APIs; they also confirm that the code—which must be signed by the developer—hasn’t been tampered with. (More on that in a minute.)

According to Apple, more than 400,000 of those rejected submissions violated user privacy in some way—requesting unnecessary access to system functionality or user data, for example.

All apps in the Store must respect sandboxing, which prevents an app from accessing data not associated with it, protecting user data from unauthorized access. This layers on top of the Mac architecture, which sets up firm boundaries between a user’s app space and critical system files, resources, and the kernel. If an app from the App Store wants access to data outside of its own sandbox, the OS must provide the necessary APIs and services.

The App Store and Device Management

For admins, then, how you acquire and distribute apps has a huge impact on the security of your organization’s Mac computers. The first choice for doing so, from a security perspective, is the App Store. Licenses to Store apps can be obtained through Apple Business Manager and, from there, distributed through your MDM solution. That’s the safest route, but not the only one. That’s why there are two more layers in Apple’s security model.

macOS Gatekeeper

Gatekeeper ensures that only trusted software can run on a Mac. It verifies the app’s trustworthiness the first time it’s opened based on two factors: code signing and notarization.

Code Signing

If the app comes from the App Store, Gatekeeper checks that the code is properly signed, to confirm that it came from the Store and hasn’t been tampered with. Given the App Store’s review processes, that’s considered an adequate basis for trust moving forward.

The files making up the app must be digitally signed with a Developer ID certificate issued by Apple. All developers submitting apps in the App Store must have a signing identity and use it to sign their code.

Code signing ensures the app is from a known developer. Once an app’s files have been signed, macOS can tell if those files have been altered since signing; if such a change is detected, Gatekeeper will prevent the code from running. In addition, mandatory access controls (MACs) built into macOS use code signing to allocate access to protected system resources.

Code signing guarantees that the files making up an app are what they say they are and that they come from a trusted source. It does not guarantee that the code itself is safe. That’s what the App Store review ensures.

Notarization

What about apps that don’t come from the App Store? The first time a user tries to run an app, plug-in, or installer package that has been downloaded from somewhere other than the App Store, Gatekeeper will check to see if it’s been notarized. Since macOS 10.15, all such software has needed to be notarized by Apple in order to launch.

Developers submit their apps to Apple for notarization. Apple notarizes apps only after checking that they are:

from a recognized developer (meaning it’s signed with a Developer ID certificate);
free of malicious content; and
free of code-signing issues.

On successful completion of that review, Apple issues a notarization ticket, which can be stored on Apple servers or attached to the app (in case the app is launched on a device that’s offline).

If an app is later found to be malicious, Apple can also revoke such tickets. macOS checks for such tickets regularly; if such an app is found, Gatekeeper will thereafter block that app from launching.

Gatekeeper and Device Management

Users have the choice (in System Settings > Privacy & Security) of allowing:

only software from the App Store, or
from the App Store and known developers.

This is the equivalent of saying that only signed or notarized apps can run. In older versions of macOS, a third option was available that let users allow apps from anywhere—i.e. bypassing Gatekeeper; in Ventura, this is a command line option (that we don’t recommend using).

All of these options are manageable via MDM, so admins can make those choices for their users, using the Gatekeeper infrastructure. In addition, MDM allows admins to bar users from overriding their Gatekeeper settings.

Apple XProtect

Regardless of the software's provenance, macOS still checks it for malicious content when it’s opened for the first time. XProtect is the specific tool that does the checking. To do so, it uses a signature-based approach, which is to say it looks for sequences in code or network traffic that have been found in identified malware.

In particular, XProtect uses YARA signatures, an open-sourced system for classifying malware based on text and binary patterns. XProtect checks app files and file hashes against those signatures when the app is first launched or whenever it changes. When XProtect detects such a signature, it blocks the execution of that code and notifies the user, who then has the option to delete the app in question.

Apple regularly updates the signatures it looks for; macOS checks for such updates every day, not waiting for system updates. In addition, when Apple does discover a new piece of malware, it may revoke the Developer ID certificate associated with that code and issue a notarization revocation ticket (see above).

XProtect and Device Management

XProtect operates independently. Admins can’t turn it on or off with an MDM solution. What an admin can do is control the security updates, by opting to enable automatic software updates. (In Kandji, for example, this is done in the Software Update Library Item.)

Other macOS Security Measures

The App Store, Gatekeeper, and XProtect are the main security tools built into macOS for app security and protection against malware. But Mac offers IT admins several additional security measures and components.

Securing a Mac with Passwords

Those additional layers start with user passwords. You can’t create a user account on a Mac without one. As an admin, you can use MDM—optionally in conjunction with an identity provider (IdP)—to make sure users are using good ones.

With MDM, you can specify password settings such as the minimum length or need for complex characters. You can define the maximum acceptable age of a password or whether a user can recycle old ones. You can also define things like the number of failed attempts before a user account is locked. You can even define a user’s password ahead of time and prevent them from changing it.

If you use a solution (such as Kandji Passport) to sync local Mac account passwords with those stored with your identity provider (IdP), it’s recommended to configure your IdP to be the source of the password policy, rather than your MDM solution; that way you avoid having two different password policies that might conflict over time.

Beyond passwords, you can use MDM to manage biometric authentication, too, preventing users from modifying Touch ID or Face ID and even preventing users from using biometric authentication altogether to unlock devices.

FileVault and Mac Security

You can also manage FileVault settings, enabling you to control whether or not full-disk encryption will be used to protect against unauthorized access to data.

Using MDM, you can require FileVault to be enforced (or to allow the user to decide). Depending on your solution, you may also be able to generate and then escrow the FileVault recovery key or automatically rotate it on a regular schedule.

System Integrity Protection

System Integrity Protection (SIP) protects against unauthorized changes to macOS itself, by restricting access to system files and directories, which malicious software might otherwise target.

SIP is built into macOS but is unmanageable by MDM or other means. The one thing you can do as an admin: Prevent users from restarting their computers in recovery mode (Kandji admins can use the Recovery Password Library Item to do so). That’s because the one way to turn SIP off is to boot into recovery mode, open Terminal, and issue a command there. So a user could in theory turn SIP off if they can boot into recovery. There are some possibly legitimate reasons a user might want to do so, but in general, they shouldn't.

Firewall

Like any firewall, the one built into macOS monitors and controls incoming and outgoing network connections, acting as a barrier between the Mac and outside threats, blocking unauthorized access to the system while allowing legitimate network traffic to pass through. It provides granular control over network traffic, allowing specific rules to permit or deny incoming and outgoing connections.

The macOS firewall is manageable via MDM. Specifically, the MDM framework allows compatible solutions to turn the firewall on or off, to block incoming connections (all or just some), and to enter ‘stealth mode,’ barring access to the Mac via the Internet Control Message Protocol (ICMP). You can also use an MDM solution to turn firewall logging on and off.

Signed System Volume

Introduced in macOS Big Sur, the Signed System Volume protects the integrity of the system software, ensuring that macOS itself—including its core components, kernel extensions, and system files—remains unaltered and free from unauthorized modifications.

Signed System Volume works with Apple's Secure Boot process, which verifies the integrity of every component involved in the startup process. During boot-up, firmware checks the signatures of those components, to be sure they’re unmodified. Any attempts to tamper with system files, inject malicious code, or modify critical components will be detected during the boot process, and the Mac won’t start up.

Signed System Volume also ensures that only trusted and properly signed software updates and upgrades can be installed; it performs a function similar to Gatekeeper for the incoming software packages.

As with SIP, there’s little you as an admin can do about Signed System Volume, beyond being thankful that it’s there. As we’ve explained before, it’s had an impact on how OS updates are managed via MDM.

Final Thoughts

There are other built-in features in macOS that can make users' computers safer, but those are the main ones that Apple admins should keep in mind. The point is that users can be responsible for Mac security—by using good passwords, enabling FileVault, and so on. But as an admin, you can use MDM to enforce those good habits.

About Kandji

Kandji is the Apple device management and security platform that empowers secure and productive global work. With Kandji, Apple devices transform themselves into enterprise-ready endpoints, with all the right apps, settings, and security systems in place. Through advanced automation and thoughtful experiences, we’re bringing much-needed harmony to the way IT, InfoSec, and Apple device users work today and tomorrow.