drduh/macOS-Security-and-Privacy-Guide: a hardening checklist for Apple silicon Macs

The problem: macOS defaults are not a hardening baseline

macOS ships with sensible defaults for a consumer, not a baseline for someone who wants the practices large organisations apply. The gap is not one setting. It is a set of decisions spread across disk encryption, the application layer firewall, DNS resolution, browser configuration, account separation, backup, and monitoring, each with its own trade-off in convenience.

The README frames this directly: the guide is a collection of techniques for improving the security and privacy of macOS on Apple silicon Macs, and it targets experienced users who want security practices commonly used by organizations, while still being suitable for novice users with an interest in privacy and security. That second half matters. Nothing here requires a security team, but the guide assumes you are willing to read and to make choices rather than accept a preset.

It is also not aimed at managed fleets. The README explicitly redirects organisation-managed Macs to the macOS Security Compliance Project maintained by NIST. If your Macs are enrolled in MDM and you need auditable configuration, that project is the correct starting point, not this one.

Threat model first, then controls

The most distinctive design choice is that the guide does not begin with settings. It begins with a threat model, and the README calls that the most important step to meaningfully improve security and privacy. The structure is assets, then adversaries, then capabilities, then mitigations, then an example model.

That ordering is deliberate. You list what you want to protect in order of importance, define who might want it and why, and rank those adversaries from least to most capable. Only then do you pick controls, because the guide's own framing is that controls are worth usability trade-offs, and a trade-off only makes sense against a stated adversary. A casual thief is defeated by screen lock and encrypted storage with strong passwords. A determined, well-funded adversary is not, and applying controls aimed at that adversary costs you time and convenience every day.

This is a real constraint on how you use the document. Skimming to the command sections and applying everything produces a hardened machine you may resent, and resentment is how controls get switched off. The example model in the README exists so you can see what a filled-in threat model looks like before writing your own.

What the guide covers, section by section

The table of contents is long, and it is worth reading as a map of the attack surface rather than as a list of tasks. Hardware and installing macOS come first, including system activation, the Apple Account, the App Store, and virtualization with a subsection on Apple containers. Then first boot, admin and user accounts with a caveats subsection, firmware, FileVault, and Lockdown Mode.

Network controls get the most space. The firewall section splits into the application layer firewall (with stealth mode, signed apps, reload, get state, and AirDrop), third-party firewalls, and the packet filter, which includes an example pf config, firewall commands, and blocking networks. DNS follows with DNS profiles, the hosts file, DNSCrypt, and Dnsmasq. Then certificate authorities, Privoxy, browsers (Firefox, Chrome, Safari, and a web browser privacy section), Tor, and VPN.

Beyond that: PGP/GPG, email with Thunderbird, messengers covering XMPP, Signal and iMessage, malware handling with downloading software, App Sandbox, Hardened Runtime, antivirus and Gatekeeper, System Integrity Protection, metadata and artifacts, authentication, backup, Wi-Fi, SSH, physical access, and monitoring (logs, DTrace, processes, Endpoint Security, install history, network with Wireshark). Miscellaneous closes with screensaver, diagnostic data, media player, file handlers, Finder options, custom umask, keyboard entry, network hardening, and sudoers.

The breadth is the point and also the cost. There is no single switch that turns this on.

Installing and a first real use

There is nothing to install. The repository has no package and no release artifacts; the top level holds .gitignore, LICENSE, README.md, and config/ and scripts/ directories. The README is the guide, and the homepage at drduh.github.io/macOS-Security-and-Privacy-Guide/ serves the same content in rendered form.

A first real use is to clone the repository so the config and scripts directories are on disk while you read, then work through the sections in order rather than jumping to commands.

git clone https://github.com/drduh/macOS-Security-and-Privacy-Guide.git
cd macOS-Security-and-Privacy-Guide
ls

The listing should show .gitignore, LICENSE, README.md, config, and scripts. Read the threat model section before touching anything else, and write your own assets, adversaries, and capabilities list. The README's example model is there to compare against.

The first concrete control the guide reaches for is disk encryption. FileVault has its own section, and the Basics section states plainly that you should enable FileVault to encrypt internal storage. The Basics section also names `softwareupdate` as the command-line utility for installing operating system updates, and notes that neither System Settings nor `softwareupdate` requires an Apple Account.

The guide does not print a `softwareupdate` invocation of its own, so the command you run is the one from the linked utility documentation. Installing available updates is the step the Basics section asks for: keep the system and software up to date, and subscribe to the Apple security-announce mailing list or check Apple security releases for notice of what changed.

After that, pick one area and finish it. The firewall section is a reasonable second stop because it has an explicit example pf config and a set of firewall commands, so you can see the intended shape of a change before applying it. Do not run the whole document as a batch on a machine you depend on.

Where the guide stops and you start

The README is upfront that the guide is provided as is, without warranties of any kind, and that you are solely responsible for any consequences of following it. That is not boilerplate. It describes the actual support model: there is no rollback procedure documented, no verification step that your machine still boots and connects, and no undo for a firewall or DNS change that breaks something you needed.

The practical failure mode is a machine that is more private and less usable, and the owner does not know which change caused it. Packet filter rules, DNS configuration, and hosts file entries all sit in the path of ordinary network traffic. If you apply them without recording what you changed, you will be debugging from memory.

The guide is also the wrong tool in two specific cases. If your Macs are organisation-managed, the README points to the NIST macOS Security Compliance Project, which is built for that. And if you want a single audited profile applied and reported on, this is a reading and decision-making document, not a compliance scanner. The monitoring section describes how to inspect logs, processes, and network activity, but it does not tell you what your baseline should be.

How this differs from Apple's own documentation

The obvious alternative is Apple's own material, and the README links to it repeatedly: the Apple platform security guide, the FileVault support page, the Lockdown Mode and Gatekeeper documentation, and Apple security releases. Apple's documents describe what the platform does and what each setting means. They are authoritative on mechanism, and they do not carry the as-is disclaimer because they are not asking you to change anything.

The difference in approach is direction. Apple explains the control; this guide starts from an adversary and asks whether the control is worth its cost to you. That is why the threat model comes first here and why the guide is willing to say a casual thief is defeated by screen lock and encrypted storage, while a more capable adversary needs more. Apple's platform security guide will not tell you to skip a control because your threat model does not justify it.

The two are complementary rather than competing. Use Apple's documentation to understand what a setting actually does, and use this guide to decide whether you need it. Where the guide gives an example pf config or a set of firewall commands, the platform documentation is the place to confirm the underlying behaviour before you apply it.

Maintenance, licence, and what upkeep looks like

The repository is not archived, and the last push was on 2026-09-19. That is recent, which matters for a document tied to an operating system that ships updates on its own schedule, because a hardening guide goes stale when the settings it describes move.

The licence is MIT, which is permissive: you can reuse, adapt, and redistribute the text, including inside an organisation, provided the licence terms are met. That is a statement about the licence text, not legal advice, and if you plan to fold the guide into internal policy you should read the LICENSE file at the repository root rather than take a summary.

Upgrade cost is the part the guide cannot absorb for you. macOS updates can change where a setting lives, add or remove a control, or alter default behaviour, and the Basics section's instruction to keep the system up to date means you will be applying those changes. Each one is a chance for a control you configured to move or stop applying. The guide has no versioned per-release changelog, so re-checking the sections you rely on after a major update is work you own. Budget for that rather than treating the guide as a one-time read.

Editorial conclusion

Adopt it if you administer your own Apple silicon Mac and want an organisation-style baseline you can work through section by section: threat model, FileVault, firewall, DNS, browser, backup. Do not adopt it if you expect a one-shot script or a managed compliance report; the repository ships config/ and scripts/ directories, but the guide is written as prose and commands you apply yourself, and for organisation-managed fleets the README points at the NIST macOS Security Compliance Project instead. Before you start, read the threat model and mitigations sections and decide which controls you will actually keep, because the guide states that it is provided as is and that you are solely responsible for any consequences of following it.

Frequently asked questions

Official sources

1. drduh/macOS-Security-and-Privacy-Guide on GitHub
2. Issues
3. License: MIT
4. Project website
5. README