Mac

FileVault prevents access to your Mac at startup without the password for an account with permission to boot the computer. Instead of loading macOS, enabling FileVault has your Mac pass control after startup to a very simple program that resembles the standard macOS login window. Entering a valid account password on this screen allows that program to access the encryption key to unlock the startup disk and proceed seamlessly (and invisibly) into your regular Mac session. Because FileVault is integrated into macOS at such a deep level, there’s only an on/off button. You don’t need to manage any of the parts.

On Macs without a T2 chip or Apple silicon processor, FileVault also performs full-disk encryption (often called FDE). But that’s automatic and cannot be turned off on T2/Apple silicon Macs.

Starting in macOS 26 Tahoe, FileVault is automatically enabled for all users in new installations and via upgrades. It can be disabled; read on to find out if you have a reason to do so. If you didn’t previously have FileVault enabled, the first time you start up in Tahoe, you will see a message that “Your Mac is [sic] Protected by FileVault.” The dialog further explains that the Passwords app has the critical Recovery Key (see where to find your FileVault Recovery Key).

Apple also got rid of a lingering potential path for crackers and government intrusion by switching from relatively insecure storage in iCloud to fully secure storage. This is welcome!

Should you ever disable FileVault?

FileVault is an additional protection for all users that prevents unwanted access to their data. However, despite my strong recommendation to enable it, it is overkill for some people that could result in them losing access to their data in specific circumstances.

What are those circumstances?

First, they would have to either be unable to remember or find their macOS account password, or the FileVault login data for accounts would have to become corrupt and reject a legitimate password.

Second, they then couldn’t find or gain access to their FileVault Recovery Key, discussed in where to find your FileVault Recovery Key.

Most people enter their macOS account password routinely and are unlikely to forget it. But it is the case that you can experience a problem that scrambles the normal startup FileVault login. If so, your FileVault Recovery Key is your only hope. If that becomes irretrievable, you’re sunk.

So before you proceed, consider if protection for your data when the computer is turned off is worth the risk of disabling FileVault.

How startup encryption works

Full-disk encryption puts a layer between the operating system and a storage drive that automatically decrypts all information coming off the drive and encrypts it as it’s written. This means all information on the drive “at rest” is fully encrypted.

Only while a Mac is active is stored information vulnerable to interception: macOS holds the encryption key in memory to allow it to encrypt and decrypt data on the fly. This allows a Mac to treat an encrypted volume as if it were effectively not encrypted at all while the volume is in use, including letting you share the volume over a network and back it up to an external drive, a networked volume, or an internet service, and use sync services like Dropbox, iCloud Drive, and OneDrive.

Whenever a Mac is shut down, a drive is an inaccessible vault, with no more information accessible than a lump of solid metal. The key material necessary to decrypt its data can’t be accessed.

The introduction of the T2 chip, and, later, Apple silicon, removed all overhead, and Apple made the decision for security reasons that FDE is always enabled on T2/Apple silicon Macs, even if FileVault is not. This also means T2/Apple silicon Macs can enable or disable FileVault in seconds, if desired.

However, without FileVault enabled, the drive is automatically decrypted on startup even before an account password is entered! That’s the piece that FileVault fills in.

With an Apple silicon Mac, the startup process without FileVault begins with operations that retrieve the security key, which is mediated by the Secure Enclave. If the SSD drive is removed from the Mac, which in modern Macs is difficult enough to be infeasible, the decryption information remains in the Secure Enclave left behind. It seems unlikely a thief or corporate or government spy would take the drive and not the whole computer, however.

Additional protections available in Apple silicon, combined with changes in macOS (starting back in Big Sur), allow that Mac to unlock the system files to boot directly into macOS without exposing any user data files.

Your data and Mac remain protected until a valid account password is entered, at which point the key protecting the data is made available for use, and startup proceeds. This may feel like enough for you. However, Apple seems to think it isn’t, and thus enables FileVault by default in Tahoe.

Encrypt external drives

You can also encrypt any mountable SSD, HDD, or disk image that is not configured as a macOS startup drive.

There are two primary ways to encrypt non-startup volumes:

• Control-click or right-click in the Finder: This is the easiest method, and will take place in the background. Control-click or right-click the volume and choose Encrypt. Enter and verify a strong password, preferably one you generated in a password-management app. Add a hint if you think it will help. Click Encrypt Disk. This converts the drives in the Finder without losing any data. (Disk Utility, by contrast, can change a volume’s format type to the encrypted flavor, but it always erases the volume—and warns you before you proceed.)
• Disk Utility for disk images: Disk Utility can also create encrypted disk images, though it uses a different method. Choose New Image > Blank Image, then choose 256-bit AES from the Encryption menu. You’re prompted to enter and verify a password, but not store a reminder tip. Set other parameters as needed and click Save to create the image.

In the future, you have to enter the password for a volume to mount an encrypted volume or disk image in the Finder or to access it via Disk Utility. When mounted, the drive appears as fully decrypted to the Finder, just like a startup volume with FileVault, and can be shared, synced, and backed up.

Apple notes carefully that passwords created for any encrypted drive other than the startup volume aren’t managed in the Secure Enclave. You have to manage them yourself, and they don’t come with the same high level of protection.

Apple will no longer support Encrypted HFS+ after Golden Gate. If you have an HFS+ volume you encrypted in a previous macOS release, this is the time to remove encryption or upgrade the volume to APFS. You can perform both operations in Disk Utility.

If you’re the only person who ever uses your Mac, none of this applies. Otherwise, you should know a few things about what sorts of access other people may have to your data.

First, if everyone uses the Mac via a single account—without having to log in and enter a separate username and password—all bets are off. Whatever’s available to you is available to everyone else. I’m not a fan of that arrangement. Ideally, every human who uses your Mac should have a unique username and password. (I might make exceptions for kids too young to type their own passwords. See how to set up safe user accounts on a shared Mac.)

But let’s say each person does have a separate account and password, and each one diligently logs out (or shuts down the Mac) after every session before the next person logs in. Then what?

How ownership and permissions work

macOS, as a variety of Unix, relies on the properties of ownership and permissions for each file. To oversimplify a bit, each file and folder has a designated owner—usually one of the individual account holders or the system itself—and a set of attributes assigned to it that specify who can access it, modify it, delete it, or execute it, in the case of files. (Apple adds a number of Mac-specific attributes on top of that.)

But there are owners and there are owners. macOS Standard account owners can access files, apps, and folders in all public places, like the system-wide Applications folder, but they can modify and add items only in specific locations: their own home folder (/Users/username) and the Shared folder in the main /Users folder. No other standard user can view files in any other users’ home folders, except the default Public folder, which is read-only and has a Drop Box item (not Dropbox, the service) that other users can drag items into, but then not see afterwards (write-only). For day-to-day segregation of one person’s data from another, this system provides a reasonable barrier.

An administrator can assign additional access to all non-system files and folders by changing ownership to a user, creating a group and providing group read/write access to a folder, or changing permissions to make things readable and modifiable by anyone with an account.

Where the barrier breaks down

But that reveals the weakness, no? An administrator has “root” access, which is the top-level permission holder in Unix. Anyone with an administrator account and working knowledge of the Unix command line can access everyone else’s files by opening the Terminal app in /Applications/Utilities, entering sudo -s, and supplying the administrator account’s password.

They can also restart in recovery mode, and use Terminal there to avoid any safeguards or monitoring tools that might be installed in macOS. With an Apple silicon Mac, an administrator can share the entire Mac as a volume on another Mac via macOS Recovery, too.

Standard users also have some options to get around the protections that should prevent them from seeing other files:

• Filching your password: Anyone who knows or can guess your login password can log in as you and access all your files. Of course, you have a terrific password that you’ve kept completely safe from everyone else, right? Fine, but there are still other problems.
• Attach your Mac’s startup drive to another Mac as an external drive: If you start up your Mac from an external drive someone could attach that drive to another Mac to which they have administrator permissions and access all the files on it. If it’s protected with FileVault, they only have to have an account enabled for FileVault on the original Mac and know the password. While other users’ files appear locked when the Mac’s drive is mounted, they can be copied over and unlocked by entering an administrator account password on the destination Mac.
• Can’t attach volumes and other stuff while locked: Apple lets you require approval to attach new peripherals, SD cards, and other accessories to your Mac. See the Mac settings worth changing. If your Mac is locked, nothing can be approved.
• Connect your Apple silicon Mac to another Mac: Mac Sharing Mode is a feature introduced with Apple silicon Macs to let you mount one Mac as a volume on another Mac. Mac Sharing Mode turns a Mac into a file-sharing volume, instead of appearing as an externally connected drive. (This is functionally equivalent to, but less risky than, the Target Disk Mode available on Intel Macs.)

To use Mac Sharing Mode, connect an Apple silicon Mac to another Mac of any vintage with a USB or Thunderbolt cable. Restart your Mac in recovery mode, choose Utilities > Share Disk, and then select the volume to share. On the other Mac, the sharing Mac appears as a network volume.

In addition, someone who has access to backups of your files on mounted or unencrypted volumes or drives can likely access all of them without file ownership and permission getting in the way.

For all these reasons, the only safe assumption is that anyone else who has an account on your Mac or physical access to it could conceivably access your files. Although your data is fairly safe from casual access by nontechnical users, you should not think of ownership and permissions as a significant roadblock.

Moral of the story: Don’t give other people’s accounts administrator access if you don’t trust them and you can prevent giving them such privileges.

If you can’t, another option is to use encrypted disk images or volumes in which you keep the password to yourself. You can use the Finder to encrypt volumes and Disk Utility to create encrypted disk images; see how to turn on FileVault and encrypt your Mac. Unmount these disks when they’re not in use.

Many apps have startup activities you can manage. This includes launching an app when you log in and components of apps launching to run in the background continuously. From a security perspective, you should know what’s launching and occasionally check to see whether anything new has appeared that you’re unaware of.

Login items

Apps can add themselves to a list of items that open when you log in to your account. You can also add items manually. This Login Items list is unique to the current user logged in. It’s located in System Settings > General > Login Items & Extensions.

Your Mac uses a notification to let you know whenever an app adds itself or a component to the Login Items list.

You can take several actions on the items in this list:

• Control-click/right-click: This reveals the Show in Finder option. Choose it, and the enclosing folder appears with the item selected.
• Remove: Select one or more apps and click the minus button to remove them. There’s no prompt—it just happens.
• Add: Click the plus button and then select one or more apps, documents, or network servers to open or mount at launch.

With Siri AI active in Golden Gate, the top item is Ask Siri, as with some other contextual menus, where you can ask or type in something like “What is Pastebot?” to know what a particular login item does or is. Unfortunately, you can’t just ask “What is this?” even though it’s on a contextual menu—Siri just replies with details about Login Items.

If you want to prevent all login items from launching, you can do so temporarily in one of two ways:

• With a required user login: On the login screen, hold down the Shift key when clicking the login button. Keep holding down Shift until you see the Dock appear.
• With an automatically logged-in user: Restart your Mac. Hold down the Shift key when the progress bar starts and release after you see the desktop appear.

Background activity

macOS also gives you insight into and control over components of apps that are set to run in the background. First, you’re alerted when an app installs them.

Then, you can find a list of these items in System Settings > General > Login Items & Extensions under the Background App Activity heading (or App Background Activity in Tahoe and earlier). The list provides additional information under each item that can be useful. In Golden Gate, the labels explain the item’s status, noting whether it is currently running in the background. If it ran in the background within the last week, the label notes how long ago that was.

In Tahoe, the label provided one of three pieces of information: how many components the background item represented (typically “1 item”), how many accounts it affected on multi-account Macs with an item breakdown (“5 items: 2 items affect all users” as one example), or whether it was from an unknown developer, typically the case when the app that installed it was no longer installed and the background item was orphaned.

Items that are installed without the full information required by Apple are shown with a magnifying glass button. Click it, and it opens the component in the system or user Library folder where it lives.

While you can’t remove background items via this interface, you can enable and disable them. When you disable background items, you’re prompted to authenticate with Touch ID or your password.

Launch components are divided into daemons, which run at system startup before an account login, and agents, which launch after login. They’re found in folders named LaunchAgents and LaunchDaemons in /System/Library/ and ~/Library/.

If you want more insight into and control over what’s automatically running on any release of macOS, do yourself a favor and get Lingon X. The app shows everything that launches automatically—apps, scripts, daemons, agents, and the like. A free version lets you view all that; paying $23.99 unlocks editing and saving.

Automatic login

When you set up a new Mac, one of the first things you are prompted to do is create a user account for yourself by picking a username and a password. (Your Mac can have many such accounts, but it must have at least one.) By default, macOS logs in that initial user account automatically when you turn on or restart your Mac. That means you can get right to work without entering a password, and it’s the most convenient arrangement for Macs with a single user—especially if the Mac is kept in a secure place.

However, if anyone else (including a thief!) can get to your Mac, that automatic login becomes a problem, because your keychain unlocks automatically (see how the Mac keychain works) and all the files on your Mac are readily available.

If there’s a risk of someone gaining access to your Mac, you should disable this option by selecting Off. It’s found in System Settings > Users & Groups as a pop-up menu next to “Automatically log in as.”

Automatic login is incompatible with the FileVault security model and can’t be enabled when FileVault is turned on, which is by default starting in macOS 26. See how to turn on FileVault.

Which apps are allowed to launch

Apple hides their powerful Gatekeeper technology behind a menu selection. Gatekeeper prevents malicious software from easily taking root on a Mac, even on a naïve user’s computer (not you, to be sure). You can find the setting “Allow applications downloaded from” in System Settings > Privacy & Security. The options are App Store & Known Developers (the default) and App Store, which is “App Store Only” but not labeled that way explicitly.

I recommend leaving App Store & Known Developers selected unless you’re setting up a computer for someone who needs more handholding and protection. For a full explanation of how Gatekeeper works, see how Gatekeeper decides which Mac apps can run.

Limiting your apps to the App Store may also be the right choice at a very high level of risk, where people or organizations may expend substantial resources to subvert someone’s computer. Few people fall into that category.

You can select a different option whenever you like, but it only affects apps launching after that point. Switch from App Store & Known Developers to App Store, and you can still launch any third-party apps you had previously run, but no new non-App Store apps will validate.

If you have the launch option set to App Store and attempt to mount a disk image with a third-party app, or open a downloaded third-party app or one copied from a disk image you’ve approved, a Mac first tells you why it can’t mount or launch it.

However, if you then return to the “Allow applications from” location in your version of macOS, you see a helpful Open Anyway button along with an explanation of why the app didn’t launch in the Finder. That’s a little informal, but it makes sense: you made this choice, so why not?

An administrative macOS user can lock settings to App Store here, and a regular macOS user won’t be able to override it. See how to set up safe user accounts on a shared Mac.

Manage system extensions

Apple lets developers extend the system with, er, the appropriately named system extensions, which run with relatively few privileges, but give developers controlled capabilities. Apple mediates access to system extensions through System Settings > Privacy & Security.

Up until a few years ago, Apple allowed a deeper way to modify core functions, but removed that method seemingly because of security concerns.

If you have no extensions installed and never install software that requires them, you will never see extra information there, and you don’t have to interact with those parts of the pane.

If you have an Apple silicon Mac, you’re blocked from using system extensions without first enabling Reduced Security for your system as described in how macOS protects its own system files. Read that first: the mode changes your Mac’s risk profile.

After you run the installer, a note appears with a button in System Settings > Privacy & Security. Click Details and you see a list of all system extensions.

Note that all the switches are disabled—you can’t take action here. Click OK, and, despite not seeming to have done anything, a system extensions cache rebuilding dialog appears. Finally, you’re typically prompted to restart in a non-modal dialog: you can’t opt out of restarting.

Because Apple requires no standard for removing a system extension, you could wind up with old ones littering your Mac and no sure way of what to do next. Sequoia added a distinct improvement in System Settings > General > Login Items & Extensions. You can view the list using By App or By Category. In both cases, the list mixes simpler macOS extenders (like additions to the contextual menu in the Finder or Quick Look) with system extensions. To disable an extension, click the info button for an app or a category, like Fantastical or Network Extensions, and then disable it.

However, if you want to uninstall a system extension, first choose By Category. Then, for a category with system extensions, like Camera Extensions, a More button appears for each item. Click that to reveal a menu from which you can choose Delete Extension. You’re warned when you disable or delete an extension that the extension may continue to operate until after a restart.

If you can’t find the item you’re looking for in that list, open Terminal and enter systemextensionsctl list and press Return.

The resulting output shows all system extensions and where you need to go to find them in the Extensions list. This list tells you exactly which Extensions category contains each component.

to find extensions’ configuration location.

Start by trying to find an app’s uninstaller or instruction on its website. Failing that, turn to Lingon X to dig out old agents, daemons, and extensions. It may not be able to help with all system extensions.

When you delete a file by putting it in the Trash and then emptying the Trash, you might think it’s somehow gone forever. But file deletion ironically doesn’t erase the file from your drive. It simply makes a change to the disk’s catalog indicating that the space occupied by that file is available and can be overwritten with something else if and when necessary.

As a result, even if you’ve deleted a file, someone using file-recovery software could potentially undelete it later, as long as no other file has been stored in exactly the same spot since then. (That someone may be you if you accidentally deleted the file and don’t have a backup.)

Hard drives may eventually overwrite the deleted file’s freed-up storage with new data, but that isn’t a guarantee that the previous file can’t be recovered. With specialized equipment, it’s sometimes possible to retrieve old versions of files that have been overwritten one or more times with new data. It’s painstaking, technically challenging, and expensive work—which means it would happen only when the stakes are quite high—but it can be done.

With an SSD, it’s even harder to ensure data is gone for good: SSDs use wear leveling, which spreads your data out all over an SSD, as opposed to the specific physical locations that are mapped on an HDD. Each memory cell in an SSD has a maximum number of times in its usable life that it can be erased and rewritten before it fails. Wear leveling ensures that the last previously written-to location is the least likely to be overwritten soon relative to any other location that’s available on the drive. SSDs also employ trim, which tells the controller that a given location is no longer able to be erased. With even more expensive gear than required for HDDs, data can be retrieved to an alarming extent from SSDs.

The good news is that with an Apple silicon Mac, all data on the startup volume is also encrypted by default. You only need to consider external SSDs that you use for storage.

If you’re still using external hard drives, you could conceivably securely delete removed file portions, but Apple dropped a feature for that years ago. However, you can encrypt external HDDs and you can securely erase them before getting rid of them using Disk Utility:

1. Open Disk Utility, select the drive or volume, and click Erase.
2. Click Security Options.
3. Move the slider to the desired level of security and click OK, then click Erase. The slider has four notches:
   • Fastest: Regular erase, which doesn’t overwrite the data.
   • One-pass: Overwrite the data once with zeroes.
   • Three-pass: Overwrite the data three times, twice with random data and once with non-random data.
   • Most Secure: Overwrite the data seven times, meeting a U.S. Department of Defense standard.

The three-pass and Most Secure options can take a long time, and are necessary only in extreme cases, but if you want to make it all but impossible for someone to recover a file, you can.

Have the drive destroyed instead

Removable and external SSDs and HDDs can be sent out for secure destruction to outfits that receive licenses or certifications from various organizations. This includes some electronics recyclers who will use a drive crusher right in front of you. Some will give you a certificate that confirms the drive was destroyed. This is bad for the environment, but may be a valid choice if you have any concern about non-FileVault-encrypted drives’ data.

Apple Pay on a second volume

Apple allows Macs with a Secure Enclave and Touch ID enabled to store Apple Pay card information, so you can make purchases in apps and via Safari directly with your fingerprint. There’s no need to use a separate device. Setting up Apple Pay is straightforward, and handled via System Settings > Wallet & Apple Pay.

The security situation you may encounter, however, is when you set up Apple Pay either with another account on the same Mac or on an external startup drive! In the former case, Apple warns you in a notification. In the latter case, when you restart from your primary startup volume, your Mac also alerts you.

I saw both the above errors after restarting from an external bootable clone, because macOS interpreted both conditions as true.

Whether you set it up with a separate macOS user or an external volume, you can reset Apple Pay to work with your current main account with your current volume. However, it involves several steps:

1. Open System Settings > Wallet & Apple Pay.
2. Click the Add Card button.
3. The Mac prompts you about changing back. When prompted, enter your password or use Touch ID to proceed.
4. Select the cards you want to use and click Next.
5. For each card, you will have to confirm details, such as entering your Apple Account password or the security code on the card. You will also have to accept terms and conditions for many cards, and receive two-factor authentication for some.

Even if Apple Pay is disabled, you can still use it in Safari by approving purchases on your iPhone or Apple Watch. Enable this option in Safari > Settings > Advanced, where you can select “Allow websites to check for Apple Pay and Apple Card.”

Apple hides a powerful feature behind a menu in System Settings > Privacy & Security. That menu is the visible part. Behind it, Apple manages a good deal more to protect you against malicious software.

The point of knowing more is twofold: First, to recognize when something’s gone wrong. Second, to bypass protections in the limited cases in which you need to.

Manage app sources

The Gatekeeper feature was introduced years ago, and affects how you install and use software. Gatekeeper examines downloaded apps when they are first launched, including custom installers from a developer. (Apple has a generic installer that most apps rely on.) If you have set your app launch preference to App Store only, macOS tells you that you can’t open a given app. Click Show in Finder to reveal the app.

However, there’s a workaround if you want to be able to open just some of these apps. With Gatekeeper set to App Store only, go to System Settings > Privacy & Security. You will see this message: “‘App Name’ was blocked from use because it is not from an identified developer.” That much we know. But there’s also an Open Anyway button to the right of this message.

Click the button. Once that’s clicked, your Mac launches the app with a dialog that asks you to confirm you really, really want to open it. Click Open to proceed.

This App Store bypass seems clunky, but it’s consistent. If you have locked a Mac account down (for a kid, say, or a client or parent) without administrative permissions to make changes, this workflow for launching a non–App Store app still won’t let them. However, if you’re the captain of your own ship, this is a simpler set of steps than switching your Gatekeeper App Store preference to allow identified developers and then switching it back again.

Gatekeeper can also reject launching an app in these circumstances:

• The app wasn’t notarized, an extra security check (explained below) that Apple made mandatory years ago.
• You allow non–App Store apps to launch, but this app is unsigned, which means it hasn’t gone through the extra pass of validation described below, including notarization.
• The app is or contains known malware or other harmful software, and Apple blocks it from running altogether.
• Something is wrong with the app, such as it having been tampered with, so it won’t launch, and you will be warned.

Gatekeeper’s point is to prevent apps from running that, more or less, don’t digitally smell right according to multiple characteristics. It is worth understanding app signing and notarization to see what that buys you. If everything’s OK, your Mac launches the software.

Apple software and components always launch unless macOS detects they were tampered with. There’s no step to approve them.

For apps outside the App Store with Gatekeeper set to allow apps from identified developers, you still have one more step: you’re informed the app was downloaded from the internet and told that it was cleared for takeoff, but you must click Open to proceed. This may seem like overkill, but it’s one additional way that Apple ensures you haven’t been tricked into running software you didn’t intend to.

Apple also lets you know when an app is on a disk image instead of copied to your Applications folder, in case the disk image window tries to mislead you about its contents.

But wait! There’s more! If you do not check “Don’t warn me when opening applications on this disk image,” macOS…warns you when you open the application, requiring yet another click of Open.

If the app you try to run contains malware, Apple provides a unique warning, one I’ve never seen, and had to source from an Apple support note. This dialog also lets you report the item to Apple.

App signing and notarization

Each developer who has joined Apple’s $99-per-year Apple Developer Program receives a unique digital certificate that binds their identity with cryptography to prevent tampering and impersonation. When building an app in Apple’s Xcode development environment, the creator can use that certificate to sign the app.

This signature results from feeding the compiled binary version of the app—the actual code package you install and that runs—through a hashing routine, an iterative cryptographic process that produces a modest-length number (the hash) that appears innocuous. However, hashing is designed so that if even a single byte is changed in the entire source material (here, the app)—even if the number 8 becomes the number 9—the resulting hash is dramatically different. With modern hashing algorithms, there’s no way for a malicious party to modify an app, sign it, and get the same signature as the valid app.

Neat, huh? Hashing underpins a shockingly vast part of internet and real-world encryption, including all HTTPS web connections, secure email, and vastly more.

That hash is then countersigned by secret keys tied to certificates only Apple possesses, which lets macOS validate the signature and makes it impossible to forge the hash—otherwise, that would be a gaping loophole.

Notarization is a separate and distinct step that applies both to an app and any third-party components and libraries it makes use of. Notarized apps, non-Apple installers, kernel extensions, and other bits of code have been scanned by Apple for known malware and none was found. But it also includes other security scanning, such as ensuring apps and components are hardened, which means there’s no way for parts of the app to be swapped out by malicious software while they’re running.

The text that appears in the launch dialog for non-App Store apps confirms notarization: “Apple checked it for malicious software and none was detected.”

Apple requires signing and notarization for apps in the App Store and those distributed directly by developers. App Store apps also go through review by human beings for content and purpose, which is separate from these automated scanning and signing operations.

A signed and notarized app doesn’t look any different to us, as users, from an unsigned app (whether notarized in part or whole), but it contains extra data that lets macOS determine:

• Integrity: Whether the app has been changed since it was built
• Identity: Which developer created (and signed) an app
• Access: Which system resources the app may access

Each of these attributes helps to protect your security.

Let’s start with integrity. If an attacker were to modify an app after it was signed—for example, inserting malicious code while it sat on the developer’s web server or even after you started using it—Gatekeeper would notice the change, as the hash wouldn’t match, and it would prevent the app from running.

Gatekeeper always prevents signed apps that have been altered from running, even if they ran fine before.

Next, suppose someone signed up for the Apple Developer Program and started delivering malicious software, signed with their certificate. The identity feature kicks in—once Apple discovers that the developer is distributing dangerous software, Apple can revoke that certificate, telling Gatekeeper not to let any software signed with that certificate launch. Gatekeeper checks Apple’s revocation list every time an app launches to make sure it’s still valid.

A malicious party using a legitimate certificate isn’t a hypothetical situation, though it’s rare in practice. In 2017, a phishing message convinced people to download and open a ZIP file, then launch an app inside it, and further conned them into entering an administrative password. The ne’er-do-wells had signed up for a developer account, and the app was signed. Apple revoked the certificate, defusing its potential.

The third aspect, access, involves system resources such as the keychain. If you grant an app permission to store information in the keychain or access it afterward, you don’t want to have to keep doing so every time you update the app.

But if you install a new version of an app that was signed with the same certificate, Gatekeeper treats it as the “same” app for the purpose of granting access to system resources, and you won’t be prompted for keychain access again.

Conversely, if someone altered the app or gave you an unsigned and therefore unauthorized version, it wouldn’t be able to access your keychain without your permission—in fact, Gatekeeper should prevent it from launching at all, because it won’t pass the signing test.

All of this reduces your risk of inadvertently running malicious software. If an app is not in the App Store and has not been signed and notarized, there is one way to bypass Gatekeeper.

Beware bundled adware

A slimy practice that peaked a few years ago was for download sites to take otherwise safe and trustworthy software from someone else and wrap it in their own custom installer with a type of malware known as adware—which, among other things, displays intrusive ads, even if you block pop-up windows and use ad-blocking browser extensions in your web browser. Here’s how to protect yourself:

• Avoid free software download sites. If the app isn’t in the Mac App Store, download it directly from the developer. (The sole exception is Setapp, a multi-developer subscription service that has a single app that can install multiple apps for you.)
• Don’t override Gatekeeper unless you’re sure it’s from an absolutely trustworthy source.
• If an installer asks if you want to install any extra software (especially if it’s “sponsored”) or browser extensions, or make changes to your browser settings, say no.

While the problem seems to have waned for many years, I still receive scattered emails messages from readers who have installed adware without intending to. Be vigilant about the source of your software.

Avoiding malware is a result of both preparation and ongoing vigilance and consistent behavior.

Apple’s built-in protections

Early in macOS’s history, Apple took a hands-off approach to malware, working to keep the system as free of exploits as possible, but leaving viral issues to third parties. That changed in Mac OS X 10.6 Snow Leopard, when Apple added the first vestiges of XProtect, its file quarantine and anti-malware checker. It now has several often interlocking measures.

Like Gatekeeper, you won’t find the name XProtect in macOS at all; Apple describes it only on their website.

Apple continues to add invisible and overt protections, too, such as the anti-paste warning and script blocker described in the kinds of Mac malware.

XProtect and XProtect Remediator

XProtect offers just a single aspect of anti-malware software, which is that it protects against known exploits. Using a method that relies on a signature that identifies specific malware, XProtect from macOS 10.15 Catalina onward checks apps when first launched or after they’ve been modified, and whenever the list of signatures updates. Apple collects these signatures into a database; a scheduled process automatically checks every 24 hours for updates to it. Apple will make emergency pushes to your Mac sooner if necessary. If a compromised app is found, you’re alerted to take action.

The moment an exploit is found in the wild, these XProtect updates ensure no Mac user connected to the internet after that point will be subject to the attack, even as Apple releases operating system security software fixes that take longer typically to ship that prevent future variant attacks that rely on the same weakness.

Apple used to also schedule regular passes by the hidden Malware Removal Tool (MRT), which could both find and remove malware, including in documents. Because Apple provides only limited documentation about XProtect and didn’t even mention MRT, it’s hard to know how they interact. Fortunately, Mac users have the previously mentioned Howard Oakley, one of the key independent people who finds and documents hidden system-level features.

Howard discovered Apple had added a new tool called XProtect Remediator that runs frequently and can both discover and remediate (take action on) any malware it finds. Howard reported in 2022 that Apple sunsetted MRT and now relies entirely on Remediator—including in macOS back to Catalina—which scans about once a day generally, although individual modules may run more frequently. In a post in June 2023, Howard explained the replacement and listed current modules that Remediator uses to check for known malware.

Check Howard’s site for updates about XProtect and Remediator if that piques your interest. Or get his free tool, SilentKnight, to get detailed information about scans and fixes installed on your Mac.

Gatekeeper

Gatekeeper is a great way to prevent potentially dangerous software from launching, even when you’ve been fooled into downloading a file you think is legitimate. Likewise, configuring Gatekeeper to App Store only for accounts you manage for other people—kids and others who want you to help them stay out of trouble—limits their potential exposure even more.

System extensions

The macOS system can be modified by extensions, as covered in what launches on your Mac, which includes modifications to and monitoring of network traffic. Even third-party software that’s notarized and signed has to declare to Apple what kind of networking it’s engaged in. Thus, a virus that somehow managed to insert itself into legitimate, signed software would still be unable to tap into your networked data without alerting you or causing errors.

Security responses

Starting in macOS 13 Ventura (and iOS 16/iPadOS 16), Apple added Rapid Security Response, a new method for delivering critical security updates without requiring a full system update. Starting in Golden Gate, macOS seemed to encompass those responses in the “Install system data files and security updates” setting in Automatic Updates; see how to set up automatic security updates. All the items in this category are installed automatically and don’t require a reboot.

Apple’s array of protections, described in how macOS protects its own system files, prevents malware from changing them.

Keep good backups

The easiest way to fight malware of all kinds, and particularly ransomware, is to have a continuously streaming backup of your documents, along with an archive or version history.

Ransomware attacks occur at some specific point in time, and most of them aren’t subtle: they try to encrypt all potential files as fast as possible to avoid detection. While some malware can try to erase backups or you might discover it was installed months ago, ransomware requires a much shallower archive.

If you have any or all of the following, you can use anti-malware software to remove the ransomware; tune up your system to avoid future attacks; and then restore files:

• Time Machine: Time Machine backups retain file versions as they’re modified, and updates are typically written every hour. Older files are typically deleted only after a few weeks and only when there’s pressure on available storage. You may be able to roll back your corrupted files to a snapshot just before the attack began.
• Cloud backups: Backblaze and other incremental archiving services typically run continuously or frequently, and retain overwritten and deleted files for a period of time, usually no less than 30 days. Some services let you pay extra to retain files for up to one year or as long as forever—as long as you keep paying. Using the service’s tools, you can find the point before the attack and download an archive of pristine files.
• Sync services: Services like Dropbox and others sync files as you modify them while retaining previous versions and deleted files, just like cloud backups. It can be a little trickier to grab all files from a point in time, but it’s doable.
• Occasional offline clones: Obviously, if you clone your drive after a ransomware attack, the cloned version has the same problem as your live system. However, making regular clones that you store offline (not connected or powered up), or even offsite, can give you a revert position if you have a problem with other backups, even if you might lose some more recent file changes or email messages.

Backblaze stopped archiving cloud-based files available through the macOS filesystem, such as Dropbox, Google Drive, and Microsoft OneDrive, in April 2026. Some people were upset about this, because Backblaze provided this detail in an update log for its apps rather than in an announcement. It’s not in a support note, either.

The reason, however, is straightforward: Apple shifted how cloud sync services appear in macOS to the Finder, apps, and parts of the system. The files appear locally stored, while sync service components ensure they load a file on demand if there’s no cached copy.

For backup services, that’s problematic, because it either means every synced file is loaded, which causes delays and huge bandwidth usage, or a stub is stored, which isn’t useful for restoring. Backblaze opted out, since it can’t reliably ensure it’s copying your cloud files.

So what are you to do as a user? The reason to use the cloud is to not store files locally. I don’t want to—and don’t want you to—rely on the potential that just a single copy of your files exists in the cloud. I haven’t figured out the answer yet. Carbon Copy Cloner and other tools have a way you can temporarily download files from the cloud to back them up, but there are complications involved in this, too, as Bombich Software explains in a detailed note for CCC.

Common sense

As with everything in the world of security, all you can do is improve your odds. So, when it comes to malware, here are my recommendations. First, everyone (regardless of risk level) should do the following:

• Install security updates rapidly: Apple pushes XProtect Remediator updates to your Mac and Rapid Security Responses, but you need to choose to install or set automatic installation for most security updates. Apple will often put out the word if there’s a really severe problem. See how to set up automatic security updates.
• Trust your gut when it says “no”: If you receive an email that wants you to carry out an action, give it a few looks before proceeding. Don’t click unknown URLs. If you reach a site with a weird or dubious URL, close the tab immediately. Don’t enter your administrator password when you don’t know why it’s being asked.

I’m not waggling my finger at you—I’ve missed my gut talking, too. Recently, a spate of “unpaid toll camera fee” and “unpaid traffic ticket penalty” texts spewed in my and many people’s text messages. Since we have a toll bridge near us, I thought, “Oh, something must have gone wrong with the account.” But I checked the account first instead of clicking the link. That saved me.

Apple and third-party password managers keep you from falling into a phishing abyss. If you saved a password or passkey at americanexpress.com and go to amer1canexpr3ss.com, the manager won’t cough up the credentials. Keep a close eye on this, as sometimes companies have multiple sites for different services or tasks, and you may occasionally have to use your credentials at a different domain.

• Filter your mail: Email is one of the most common ways for malware to spread, and a good spam filter will zap it before it hits your inbox—or before you’re as naïve as I am sometimes!

Even if your email provider offers effective, configurable server-side filtering, I recommend adding SpamSieve.

• Avoid software whose origins you don’t know: Malware often spreads through sketchy or pirated software. If you don’t know who made an app or where it came from, or you know it should be paid for, but you’re nevertheless downloading a cracked or otherwise non-legitimate version, you are asking for trouble.

Firewalls and network monitoring

At one point we both avidly recommended using firewall software. Apple’s built-in solution is fairly weak, so we’d suggest one of several third-party options, often bundled with anti-malware software. Up until a few years ago, it seemed like the biggest risk to a Mac user would be from a remote invader.

Turns out, not! Phishing, Trojan horses, stolen or misused developer certificates, and simple “hey, install this by typing in your administrator password” were the big vectors—and not very big at that.

As covered in which Mac sharing services are safe to turn on, the best advice is to not enable network services you don’t need.

It is rare to find an app that hasn’t gone through notarization. But you may still encounter software you can download from an open source project’s site—typically free and often developed by a group of volunteers—that isn’t signed and notarized.

While most developers consider Apple’s annual developer program fee and company oversight affordable and reasonable, some folks do not. They may be creating a small piece of utility software that’s maintained, but nobody in the group that produces it wants to either ask for donations or cough up the dough. Or they may find Apple’s oversight irksome and invasive, despite the advantage to users. Or they may have interpreted copyright in a way that doesn’t match Apple’s policies.

If it’s not the above case, there are a few other reasons that you might encounter an app Gatekeeper balks at:

• You run a preliminary version of a new app that the developer simply hasn’t gotten around to signing yet.
• You create your own app or standalone script (perhaps using Script Editor) and don’t want to (or don’t know how to) sign it.
• You’ve downloaded malware. It isn’t signed because the developer doesn’t want to risk exposing their identity—and enabling Apple to revoke the certificate, thus preventing the app from being installed in the future.

Whatever the reason, if you launch an app that isn’t signed or is signed but not notarized, macOS explains the problem. The dialog may say that it’s by an unidentified developer, or by a developer whose identity can’t be verified. Click OK—the only choice—and the app never completes launching.

Apple does let you install Mac software like this, but they don’t make it easy. There used to be an option in the Gatekeeper settings to disable Gatekeeper altogether; now, you have to use a manual bypass for any such app you want to launch on its first use, which Apple made more complicated in Sequoia to deter people even further.

Before you override Gatekeeper, give a lot of thought to what you’re trying to run and where you got it. As battle-scarred and cynical as I am, I always take additional effort and make additional scrutiny before bypassing Gatekeeper for an app I know I need and know its source.

Check it before you run it

The most excellent developers who forswear Apple’s process always offer out-of-band methods you can use to check the integrity of their downloads. So if you trust the project and want to make sure an app hasn’t been fiddled with, the site might post hashes it makes of its disk image files at the time of creation, or use its own signing process that can be validated with publicly available encryption keys. The best of these apps will then also provide pointers on how to perform validation and authentication without you having to take a two-hour cryptography course.

With all that in mind, here’s how to bypass Gatekeeper.

1. Open the application. You see a dialog saying the app can’t be opened, with no suggestion of what to do next. Click Done.
2. Go to System Settings > Privacy & Security. As with a signed app when you have Gatekeeper set to App Store, you have identical text and an Open Anyway button.
3. Click Open Anyway.

I’m not sure Apple made the right call here, equating signed apps from developers and unsigned apps as the same kind of problematic item based on the Gatekeeper setting. But I suppose both are now considered suspect in the context of each setting choice.