For the first 15 years of Classic Mac OS, right up to Mac OS 9 in 1999, Macs remained fundamentally single-user, and privacy wasn’t an issue of much concern. In those halcyon years of desktop publishing and HyperCard, users were more excited by opening information up than keeping it private, and the internet was in its infancy. It was Mac OS 9 that first integrated multiple user accounts and started to secure information using keychains.

Mac OS X brought the first full multi-user operating system to the Mac, but as internet connections became increasingly common and lasting, little attention was paid to privacy. By 2011, the Privacy tab in Security & Privacy, then in System Preferences, contained just three items: Location Services, Contacts, and Diagnostics & Usage. While privacy features developed elsewhere, for the sake of simplicity I’ll here focus on that pane in System Preferences, and its successor in System Settings.

Four years later, in OS X 10.10 Yosemite (2015) and still in 10.12 Sierra (2017), those three items had grown to eight, with the addition of Calendars, Reminders, Accessibility, and two social media platforms, Twitter and Facebook.

Then at WWDC in 2018, Apple revealed its new privacy architecture, putting it at the forefront in macOS 10.14 Mojave, and eventually reversing the order to Privacy & Security.

Mojave protected information in the following 15 categories:

• Location Services,
• Contacts (address books),
• Calendars,
• Reminders,
• Photos (Photos libraries),
• Mail,
• Messages,
• Safari browsing history,
• HTTP cookies,
• Call history (iOS),
• Time Machine backups,
• iTunes backups,
• camera input,
• audio input through the built-in microphone,
• automation (AppleScript and others).

Its new protection system was dubbed TCC, for Transparency Consent and Control, and has since become prominent in the nightmares of developers, those who support Macs and many who use them. At its worst, it crashes apps that don’t comply with its rules, as shown in the diagram below for macOS 10.14.

Various classes of protected data are shown at the left, those in red being covered explicitly in Privacy controls. The first step was to determine whether the app trying to access protected data was signed by Apple: if it was, access was determined by private controls, and sometimes regular controls as well.

Apps developed by third parties were checked to see whether they already had access to that particular class of protected data according to Privacy settings. If they had, access was then granted without further dialogs. Note that the effect of adding an app to the Full Disk Access list was to give it access to all protected data, but not services or hardware, without any further consent being sought.

If they hadn’t already been given access, the next check was to see which version of the SDK they were built against. If they were built against 10.13 or earlier, then Mojave didn’t expect them to have support such as usage information, so it should have displayed a dialog inviting consent to the requested access. That would normally only contain the standard text information.

If consent was given, then that app was added to the appropriate class in Privacy settings; if it was declined, then it was denied access, but wasn’t put on any blacklist, so consent could still be given on another occasion.

If the app was built against the 10.14 SDK, then stricter rules were applied. It was then required to have a usage statement for the class of data it was trying to access, where that was in the class-specific list at the top, or a protected device or service. If the app didn’t provide the appropriate usage statement, TCC considered the request to access protected data was unintended, and crashed the app as an ‘unexpected quit’.

If the app did contain a usage statement appropriate for that class of protected data, then Mojave displayed the consent dialog, this time containing the text from that usage statement as well. If consent was then given, the app would be added to the list in Privacy.

Since Mojave, TCC has been a fertile source of vulnerabilities for third-party researchers to discover, and the malicious to exploit. Three were reported shortly after the initial release of 10.14. Two, discovered by Patrick Wardle and Jeff Johnson, weren’t disclosed, to allow Apple to address them, and the third, in ssh, wasn’t so much a vulnerability as a feature that could be exploited.

Each successive major version of macOS has added further to that list from Mojave. Catalina (10.15, 2019) added new locations that required user intent or consent to access, including:

• ~/Desktop, widely used for active documents
• ~/Documents, main document storage
• ~/Downloads, the default location for downloaded files
• iCloud Drive, now widely used for shared working documents
• third-party cloud storage, if used
• removable volumes
• network volumes.

This is one of the late Security & Privacy panes from macOS Catalina in 2019.

By the time that macOS 13 Ventura was released in 2022, its shiny new Privacy & Security section in System Settings listed 20 categories. Some, like Full Disk Access and Files and Folders, overlapped, while others like Accessibility appeared to have been misnamed. Controls provided varied between different categories, and many users dreaded having to tinker with them.

At this rate of growth, Privacy will soon have its own app alongside System Settings.

Modern Macs and macOS feature multiple layers of protection, most of which I have recently described. This article tries to assemble them into an overview to see how they all fit together, and protect your Mac from startup to shutdown. There are also many additional options in macOS and third-party products that can augment security, but I’ll here concentrate on making best use of those that come with a modern Mac and macOS. My recommendations are for the ‘standard’ user, as a starting point. If your needs differ, then you may of course choose to be different, but should always do so in the full knowledge of what you are doing and what its penalties are.

Startup

Whether your Mac has a T2 or Apple silicon chip, it’s designed to boot securely, which means that every stage of the boot process, from its Boot ROM to running the kernel and its extensions, is verified as being as Apple intends. To ensure that, your Mac should run at Full Security. For a T2 model, that means disabling its ability to boot from external disks; for an Apple silicon Mac, that means no third-party kernel extensions. If you need to run your Mac at reduced security, that should be an informed decision when there’s no good alternative.

A vital part of the Secure Boot process is the firmware loaded by the Boot ROM. That needs to be kept up to date by updating to the latest minor release of the major version of macOS. That doesn’t prevent your Mac from staying with an older supported version of macOS, as Apple supplies the same firmware updates for all three supported versions of macOS.

The System volume should be signed and sealed, as the SSV created by a macOS installer or updater. System Integrity Protection (SIP) should also be fully enabled, as without it many macOS security features work differently or not at all. Some need to disable specific SIP features, but again that should only be set when you’re fully aware of their effects and consequences, and should be the minimum needed for the purpose.

User Data

Having got the system up and running, the boot process moves to what is in mutable storage on the Mac’s Data volume. In the internal SSD of a modern Mac, that’s always encrypted, thanks to the Secure Enclave. Although that might appear sufficient, you should always turn FileVault on if your Mac starts up from its internal SSD. That ensures the encryption is protected by your password: an intruder then has to know your password before they can unlock the contents of its Data volume. They have limited attempts to guess that password before the Mac locks them out from making any further attempts. As FileVault comes free from any performance penalty, there’s no good reason for not using it.

Good security is even more important for Data volumes on external boot disks, where FileVault is just as important, but needs additional physical measures to ensure the external disk isn’t mislaid or stolen. That’s a more complex issue, for which the simplest solution is to start your Mac up from its internal SSD with the benefit from FileVault there.

Run Apps

With the user logged in successfully, and the Data volume fully accessible, the next stage to consider is running apps and other software. For this there’s another series of security layers.

When an app is launched or other code run, Gatekeeper will first check it, and in many circumstances run a check for malware using XProtect. Those shouldn’t be disabled, or macOS will still make those checks, but will simply ignore the results. XProtect looks for evidence that the code about to be run matches that of known malware. Although on its own this won’t detect unknown malware, it’s an effective screen against what’s most common. You also need to keep your Mac up to date with the latest security data updates, as those can change every week or two as new malware is identified and included.

Currently, no well-known malware has been notarized by Apple, and most isn’t even signed using a trusted developer certificate. Most therefore attempt to trick you into bypassing checks made by macOS. In Sonoma and earlier, the most common is to show you how to use the Finder’s Open command to bypass the requirement for notarization. As that has changed in Sequoia, those who develop malware have had to adapt, and some now try to trick you into dropping a malicious script into Terminal. Expect these to become more sophisticated and persuasive as more upgrade to Sequoia.

There are simple rules you can apply to avoid getting caught by these. The first time you run any new app supplied outside macOS or the App Store, drag the app to your Applications folder and double-click it in the Finder to open it. If it can’t be launched that way, don’t be tempted to use the Finder’s Open bypass, or (in Sequoia) to enable the app in Privacy & Security settings. Instead, ask its developer why it isn’t correctly notarized. Never use an unconventional method to launch an app: that’s a giveaway that it’s malicious and you shouldn’t go anywhere near it.

macOS now checks the hashes (CDHashes) of apps and code it doesn’t already recognise, for notarization and known malware. Those checks are run over a connection to iCloud that doesn’t need the user to be signed in. Don’t intentionally or inadvertently block those connections, for instance using a software firewall, as they’re in your interest.

Private Data

Traditional Unix permissions weren’t intended to protect your privacy. Now so many of us keep important or valuable secrets in our Home folders, privacy protection is essential. While you might trust an app to check through some files, you may not expect or want that app to be looking up details of your bank cards and accounts.

Privacy protection is centred on a system known as TCC (Transparency, Consent and Control), and its labyrinthine Privacy & Security settings. One of the most tedious but important routine tasks is to check through these every so often to ensure that nothing is getting access to what it shouldn’t.

No matter how conscientious we might be, there’s always the request for access that you don’t have time to read properly, or items that end up getting peculiar consents, like a text editor that has access to your Photos library or your Mac’s camera. Take the time to check through each category and disable those you don’t think are in your best interests. If you get through a lot of new apps, you might need to do this every week or two, but it needn’t be as frequent in normal use, and shouldn’t become an obsession.

There’s some dispute over whether it’s better to leave an app turned off in a category that you control, like Full Disk Access, or to remove it. I tend to disable rather than remove, with the intention of removal later, but seldom get round to that.

Downloaded Apps

While macOS continues checking apps in Gatekeeper and XProtect, there are a couple of other important protections you need to know about. Since macOS Catalina, every 24 hours or so macOS runs a paired set of scans by XProtect Remediator, looking for signs of known malware. If it finds any, it then attempts to remove, or remediate, that. The snag is that it does this in complete silence, so you don’t know whether it has run any scans, and you don’t know if it came across anything nasty, or removed it. I like to know about such things, and have written my own software that lets me find out, in SilentKnight, Skint and XProCheck. One day Apple might follow suit.

Some browsers like Safari have a potentially dangerous setting, in which they will automatically open files they consider to be safe, once they have been downloaded. This can include Zip archives that might not be as innocent as you expect. If you leave that behaviour set, you could discover your Downloads folder with all sorts of items in it. I much prefer to turn that off and handle those downloads myself. You’ll find this control in Safari’s General settings, where it’s called Open “safe” files after downloading.

Bad Links

Most of the protection so far relies more on features in your Mac and macOS, and less on your habits and behaviour. But it’s the user who is the kingpin in both security and privacy protection. Nowhere is this more important than dealing with links in web pages, emails, messages, and elsewhere. If you’re happy to click on a link without checking it carefully, you can so easily end up in the company of your attackers, inviting them into your Mac and all your personal data.

Unless it’s a trusted web page or contact, I always inspect each link before even considering whether to open it. For emails, my general rule is never, and I inspect the text source of each message to see what that really links to. It’s harder on the web, where even ads placed by Google can whisk your browser into an ambush. One invaluable aid here is Link Unshortener, from the App Store, which is a ridiculously cheap and simple way to understand just where those cryptic shortened links will take you. If you can’t convince yourself that a link is safe and wholesome, then don’t whatever you do click on it, just pass on in safety.

Summary

That has been a whirlwind tour through getting the best from macOS security, summarised in the following diagram. Fuller details about each of those topics are easy to find using the Search tool at the top right of this page. There’s plenty more to read, and for deeper technical information, try Apple’s Platform Security Guide.

Work and play safely!