Inside every Intel Mac with a T2 chip, and every Apple silicon Mac, is a secure enclave, originally referred to as its security enclave. The subject of a flurry of Apple’s patents from 2012 onwards, this was introduced in the A7 chip inside the iPhone 5s and iPad mini 3, 12 years ago in September 2013, where it brought biometric authentication in Touch ID.

iPhone 5s

Protecting the most important secrets in a computer is a great challenge. No matter how secure you try to make the main processor and memory, as they’re exposed to direct attack, isolation can only be relative and temporary. An alternative approach is to move the most secure data and its processing into a secure enclave and its processor, and that’s the architectural solution chosen by Apple in what it patented as a security enclave, filed in September 2012, a year before its release in the iPhone 5s. Engineers credited for that patent are Manu Gulati, Michael J Smith and Shu-Yi Yu.

Successive iPhone chips steadily improved their secure enclaves, and by the time the iPhone 7 was introduced in September 2016, with its A10 Fusion chip, its secure enclave was handling encryption and authentication but not replay prevention. It also had EEPROM secure storage, and an AES engine with DPA protection and lockable seed bits. When the first Intel Mac with a T1 chip was released a couple of months later, that was based not on the A10 but the S2 used in the Apple Watch Series 2. The T1 thus doesn’t really have a secure enclave as such, although it supports Touch ID.

An early and thorough account of these secure enclaves was presented by Tarjei Mandt, Mathew Soling and David Wang at Black Hat USA in 2016. This appears to be the only such account apart from the section in Apple’s Platform Security Guide, most recently updated in December 2024. Apple’s engineers continued to gain new patents, covering trust zone support (filed in 2012), key management (filed in 2014), and most relevant to Macs, Pierre Olivier Martel, Arthur Mesh and Wade Benson’s patent for multi-user storage volume encryption, filed in 2020.

T2 chip

The first Macs with a true secure enclave are those with a T2 chip, starting with the iMac Pro in December 2017. Those are based on the same A10 Fusion chip from the previous year, and were already lagging the iPhone 8 in this respect.

The T2 secure enclave is another co-processor system, run by a Secure Enclave Processor (SEP), a 32-bit ARM CPU running its own operating system, sepOS, based on a specialised L4 microkernel completely different from those used by Macs and Apple’s devices. It has its own secure storage (EEPROM), and a Public Key Accelerator for signing and encryption/decryption using RSA and ECC methods. Outside the enclave is a dedicated AES256 encryption/decryption engine built into the data transfer path between the internal SSD and main system memory.

M-series chips

The big leap forward for Macs was the release of the first models featuring M1 chips, which caught up with the features of late versions (after autumn 2020) of the A12 and A13, with Apple’s second generation Secure Storage Component.

Perhaps the most significant of its improvements are measures to prevent replay attacks. Those are best illustrated with FileVault. Let’s say that you didn’t enable FileVault at first, but left your Apple silicon Mac to handle the encryption of its internal Data volume without the added protection of your password. That would mean that its volume encryption key (VEK) was generated internally by the Secure Enclave, and stored there. If you then turned FileVault on, the VEK would be encrypted using your password and the hardware key. In the T2 chip, it might be possible to use the old VEK to decrypt the volume. In the secure enclave of an M-series chip, that type of replay attack is prevented by the revocation of all previous events and records.

Other improvements include the use of second generation secure storage incorporating counter lockboxes to enforce limits on the number of passcode attempts allowed, instead of an EEPROM, and a better Public Key Accelerator.

Currently, the secure enclave is known to protect the following:

• encryption keys for Touch ID, FileVault, and the Data Protection (iCloud) keychain (but not file-based keychains);
• that Mac’s Unique ID (UID) and Group ID (GID);
• Touch ID control, and (on older devices not Macs) Face ID using a secure neural engine; in recent devices and M-series chips, that’s implemented as a secure mode in the main neural engine (ANE);
• Apple Pay handling;
• Activation Lock, through the Owner and User Identity Keys;
• signing and verification of LocalPolicy for boot environments (Apple silicon).

Communication between the CPU and SEP is performed using a dedicated mailbox whose function is detailed in Apple’s patents. Further information is also provided in the Platform Security Guide.

FileVault encryption

It has been stated widely (even here) that the secure enclave in T2 and Apple silicon chips contains a hardware encryption/decryption unit and acts as the internal SSD’s storage controller. In fact, as shown in the original patent of Martel and others, and now in the Platform Security Guide, the AES engine responsible is located outside the secure enclave, together with the Flash controller, and has a secure link to the enclave.

During SEP boot, it generates an ephemeral key to wrap keys to be used by the AES engine for encryption and decryption. That key is sent from the secure enclave to the AES engine over the dedicated connection between them, then used to protect keys transferred from the enclave to the AES engine. That ensures an unprotected key is never exposed outside the enclave and AES engine.

The Apple silicon secure enclave is by no means unique. ARM TrustZone, other Trusted Execution Environments, and Trusted Platform Modules offer similar features and facilities. However, the secure enclave is unusual because it has been integrated into all Macs with T2 or Apple silicon chips, and all Apple’s recent devices, and can’t be disabled or bypassed.

References

Manu Gulati, Michael J Smith and Shu-Yi Yu, US Patent 8,832,465 B2, Security enclave processor for a system on a chip, filed 25 September 2012, granted 9 September 2014.
R Stephen Polzin, James B Keller, Gerard R Williams, US Patent 8,775,757 B2, Trust zone support in system on a chip having security enclave processor, filed 25 September 2012, granted 8 July 2014.
R Stephen Polzin, Fabrice L Gautier, Mitchell D Adler, Conrad Sauerwald and Michael LH Brouwer, US Patent 9,419,794 B2, Key management using security enclave processor, filed 23 September 2014, granted 16 August 2016.
Pierre Olivier Martel, Arthur Mesh and Wade Benson, US Patent 11,455,432 B1, Multi-user storage volume encryption via secure processor, filed 8 June 2020, granted 27 September 2022.
Tarjei Mandt, Mathew Soling and David Wang (2016), Demystifying the Secure Enclave Processor, Black Hat USA 16 (PDF)
Apple, Platform Security Guide
Wikipedia’s overview of Apple silicon chips.

Apple has just released its weekly update to XProtect for all supported versions of macOS, bringing it to version 5312. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds three new detection rules: MACOS.SOMA.AUENB augmenting rules for the Soma/Amos family, MACOS.DUBROBBER.CHBI for another Dubrobber variant, and MACOS.ODYSSEY.LELI for an additional Odyssey variant.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5312

Sequoia and Tahoe systems only

This update has now been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5312 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

When Mac OS X 10.0 was released in March 2001, privileges, permissions and security adopted a conventional model based on BSD and Unix. Those sufficed for 15 years until the release of OS X 10.11 El Capitan in September 2015, when System Integrity Protection, SIP, was introduced. This article outlines its history over the last decade.

2015 Introduction

The first public account of SIP was presented by Pierre-Olivier Martel at WWDC 2015 in June, and documented in Apple’s System Integrity Protection Guide that September, which hasn’t been revised since. These changes were justified as adding a further layer of security protection to prevent attackers from gaining full control by escalating privileges to root.

Three types of protection were promised:

• file system protections, so that system files could only be modified by processes signed by Apple;
• prevention of runtime attachment, code injection, or modification of system binaries, with modifications only permitted by Apple’s installers and updaters;
• kernel extensions (kexts) had to be signed using special certificates granted by Apple.

Each Mac’s SIP configuration was stored in NVRAM, and controlled by the csrutil command used in Recovery mode.

When released, the csrutil command provided some degree of separate control over six groups of features: file system protections, debugging protection, DTrace protection, kext signing requirement, NVRAM and ‘Apple internal’ protection. One immediate beneficial side-effect was that SIP prevented permissions being changed for system files, and that made the practice of repairing permissions on them unnecessary, allowing removal of support for that procedure from Disk Utility.

2015 Conflicts

Press reviews of the SIP feature were divided, with some claiming it was a sign that OS X was being closed down and moved to the iOS security model, while others considered that few users would notice much difference.

Problems resulting from SIP were reported soon after El Capitan’s release. For example, some older Mac models intentionally prevented their use with Apple USB SuperDrives. One workaround to address that had been to modify one of the files now protected by SIP, which consequently required the user to disable SIP to make that change.

As kernel extensions hadn’t previously been required to be signed at all, other early casualties were all older unsigned kexts, making some apps unusable unless a new version was provided with a correctly signed kext.

2016 Error

Late in 2016, it became clear that Apple had shipped a substantial batch of new MacBook Pro systems with SIP disabled. At that time, System Information was unable to report SIP status, and the only way to enable protection was to start that Mac up in Recovery mode and use the csrutil command in the Terminal app there. That applied to macOS Sierra 10.12 to 10.12.1.

To make this easier, Apple changed csrutil so that it could enable SIP when invoked in normal running mode, provided it was run with elevated privileges obtained using sudo. Despite that, some of those affected MacBook Pro models didn’t have SIP enabled correctly for several months.

2017-18 Problems

Over the following years, SIP continued to cause irritations that infuriated some users.

Bundled apps in the main Applications folder were protected by SIP, and that prevented the user from modifying them. As the handling of kexts changed, it was discovered that SIP made it awkward to remove old kexts the user had installed. That was because the folder /Library/StagedExtensions was put under the protection of SIP by attaching a com.apple.rootless extended attribute to it.

One reading of that extended attribute is that only Apple’s KernelExtensionManagement service can give permission for changes to be made within that folder, and the folders within it.

2020 Extended attributes

Apple later used SIP to lock down individual extended attributes (xattrs) attached to regular unprotected files. The first example of this was the undocumented com.apple.macl xattr that macOS started to attach widely to all user documents. Presence of that xattr was implicated in some problems in which those documents became locked down and unable to save changes, despite permissions and other visible attributes showing that the user had full ownership of the file. The only workaround for this has been to copy the file to another volume, where the xattr no longer has the protection of SIP, and can be stripped.

When Apple later introduced another undocumented xattr com.apple.provenance, that too was sometimes but not always protected by SIP, although that hasn’t been implicated in problems visible to the user.

2022 Launch constraints

Launch constraints were introduced in macOS 13 Ventura and iOS 16 in 2022. Every executable binary in the system now has a set of rules determining the requirements for that binary to be launched. These include self constraints that the binary itself must meet, parent constraints that must be met by its parent process, and responsible constraints that must be met by the process requesting the launch. Together these form that code’s launch constraints. To make those constraints simpler, they come in different categories, ranging from 0, in which there are no constraints at all, to combinations that prevent launch by processes that aren’t themselves part of the system and require the code itself to be on the System volume.

Although Apple has documented these for developers, they can cause unexpected behaviour for users, who haven’t been given any explanation. Testing has demonstrated that launch constraints are dependent on SIP, so must be assumed to have been added to its list of protections.

2024 Malware scans

Many users have reported slowing app launch times in recent versions of macOS. In February 2024, Jeff Johnson investigated these, and concluded that the cause was the macOS security system repeatedly performed malware scans against a growing set of Yara rules. These stopped when SIP was disabled, implying that this is yet another protection that has been added to those controlled by SIP.

2024 Current protections

Current user documentation for SIP explains only its file system protection, csrutil‘s man page refers to its usage information, but from that and XNU it’s possible to separate out its controls to include the following, at least:

• Filesystem Protections, disabled by CSR_ALLOW_UNRESTRICTED_FS, abbreviated to fs
• Debugging Restrictions, disabled by CSR_ALLOW_KERNEL_DEBUGGER and CSR_ALLOW_TASK_FOR_PID, abbreviated to debug
• DTrace Restrictions, disabled by CSR_ALLOW_UNRESTRICTED_DTRACE, abbreviated to dtrace
• Kext Signing, disabled by CSR_ALLOW_UNAPPROVED_KEXTS, abbreviated in csrutil to kext
• NVRAM Protections, disabled by CSR_ALLOW_UNRESTRICTED_NVRAM, abbreviated to nvram
• Apple Internal, disabled in XNU by CSR_ALLOW_APPLE_INTERNAL, and only disabled when SIP is fully disabled
• BaseSystem Verification, abbreviated to basesystem
• Boot-arg Restrictions, disabled with nvram
• Kernel Integrity Protections, disabled with kext
• Authenticated Root Requirement, disabled by CSR_ALLOW_UNAUTHENTICATED_ROOT, managed separately using csrutil authenticated-root disable and enable
• Additional configuration flags available in XNU that don’t appear to be directly supported by csrutil include: CSR_ALLOW_TASK_FOR_PID, CSR_ALLOW_DEVICE_CONFIGURATION, CSR_ALLOW_ANY_RECOVERY_OS and CSR_ALLOW_EXECUTABLE_POLICY_OVERRIDE. Those should be disabled when SIP is fully disabled.

2015-2025 Vulnerabilities

Over the last decade, many vulnerabilities have been discovered in SIP that have allowed parts of its protections to be bypassed. Among the most recent is CVE-2024-44243 discovered by Jonathan Bar Or (@yo_yo_yo_jbo) of Microsoft Threat Intelligence and Mickey Jin (@patch1t), and fixed in the update to macOS 15.2 Sequoia. However, this wasn’t fixed in Sonoma until the following round of updates (14.7.3), and appears to remain unpatched in Ventura 13.7.8.

Microsoft’s report explains how bypassing just one of SIP’s many protections can give access to bypasses of more or all of SIP’s other protections. Note also how Apple’s description of the vulnerability in its security release notes refers to StorageKit but doesn’t reveal that this affected SIP.

Over the last decade, SIP has grown like Topsy from three protections that seemed worthwhile and simple, into a protean collection of many parts that remain largely undocumented and pervade much of modern macOS security.

References

Wikipedia’s account, still largely based on SIP in 2015
This blog on csrutil controls

There are so many controls in macOS that sometimes you can’t see the wood for the trees. This can leave uncertainty over essentials, such as whether your Apple silicon Mac really is properly secure, or maybe there’s something sinister going on with it? This is a question I’m asked not infrequently, usually when someone has been spreading disinformation or FUD (fear, uncertainty, doubt). So how can you check that your Mac is properly locked down and boots securely?

Quick checks

There are two quick checks that cover the essentials. First, open System Information and select the Controller section in Hardware.

This provides a brief summary of your Mac’s boot security, which should read as shown above. If you still need to use a kernel extension or similar, your Mac might show Reduced Security with Allow All Kernel Extensions enabled, but you should do everything you can to avoid that.

Secure Boot is controlled using Startup Security Utility in Recovery mode, and if you care to start up in that mode, you can confirm or correct its settings there.

Back in normal user mode, open Privacy & Security settings and ensure you have FileVault enabled there.

SilentKnight also checks that XProtect/Gatekeeper checks are enabled, and that security data are up to date, giving you complete confidence.

Details

Although those should be sufficient for most, some want to go further and verify that their Mac’s boot process and security systems are also working correctly. To do that, shut your Mac down, wait ten seconds or so, and start up normally with the startup chime sounding at a known time. Enter your password, wait a few seconds for the Finder to get set up and running, and open LogUI. Set its time to that of the startup chime, and get the first 10 seconds or 10,000 log entries. You may need to adjust the seconds to capture the full boot sequence. When you have, look through the log and identify the following waypoints.

In each of these log entries, I have emboldened a word or two that you can copy from here and paste into LogUI’s Search box, then press Return. That will display the log entry, and sometimes others you might find relevant. Times are given here in seconds, with the startup chime occurring at about 37 seconds. Version numbers shown are those for macOS 15.6.

The start of boot is recorded as
37.562774 === system boot: [UUID]
and a little while after that, the kernel declares its version details
42.759300 Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:40 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6041
for macOS 15.6.

Further down you’ll come across more information about key security components, including the Trusted Execution Monitor
43.060422 [Log]: Code Signing Monitor Image4 Module Version 7.0.0: Fri Jul 11 16:51:29 PDT 2025; root:AppleImage4_txm-320.100.22~1090
43.060447 [Log]: build variant: txm.macosx.release.TrustedExecutionMonitor_Guarded-135.100.37

Then the iBoot firmware version
43.061758 iBoot version: iBoot-11881.140.96
43.061760 iBoot Stage 2 version: iBoot-11881.140.96

CoreCrypto support is vital, and another Image4 extension
43.137635 FIPSPOST_KEXT [133796636] fipspost_post:154: [FIPSPOST][Module-ID] Apple corecrypto Module v18.3 [Apple silicon, Kernel, Software, SL1]
43.242334 Darwin Image4 Extension Version 7.0.0: Mon Jul 14 11:23:46 PDT 2025; root:AppleImage4-320.100.22~2585/AppleImage4/RELEASE_ARM64E

You should see entries reporting the loading of security policy components
43.242343 Security policy loaded: AppleImage4 hooks (AppleImage4)
43.242961 Security policy loaded: Apple Mobile File Integrity (AMFI)
43.243092 Security policy loaded: Seatbelt sandbox policy (Sandbox)

The Secure Enclave Processor or SEP is another key component that has to be started up
43.264594 "AppleSEPKeyStore":326:0: starting (BUILT: Jul 14 2025 23:34:10) ("normal" variant 🌽 , 1827.120.2)
43.264639 "AppleSEPKeyStore":471:0: _sep_enabled = 1

Apple System Policy should follow a bit later
43.760156 Security policy loaded: Apple System Policy (ASP)
43.760188 AppleSystemPolicy has been successfully started

The root of the file system is then identified in two entries whose origins go right back to the start of Mac OS X
43.940643 BSD root: disk3s1
43.940644 , major 1, minor 13

And APFS mounts the root file system, using the SSV snapshot
43.941048 apfs_vfsop_mountroot:2984: apfs: mountroot called!
44.034685 apfs_vfsop_mount:2763: disk3s1 Rooting from snapshot with xid 1724240.

One of the most important entries comes shortly after that, where successful validation of the SSV’s root hash is reported
44.038830 authenticate_root_hash:642: disk3s1 successfully validated on-disk root hash

It’s now time to start user space processes, and for that launchd must be loaded so it can launch everything else
44.103761 load_init_program: attempting to load /sbin/launchd

How Secure Boot works

Apple silicon Macs have a small ROM to support DFU mode in case a full Restore is required, and to check and load the first stage of the ‘firmware’, the Low-Level Bootloader or LLB. Only if that matches its signature will the ROM firmware hand over to it and proceed with the boot process. The LLB in turn performs the same checks on the second stage ‘firmware’, iBoot proper. That goes on to check the kernel, before loading that and handing over for kernel boot to take over.

iBoot ‘firmware’ doesn’t write anything in the log, but once the kernel takes over its log entries provide a detailed account of its progress. The great majority of its log entries are unintelligible to anyone outside Apple, but the waypoints I have given above identify some of the most important steps it takes. When it’s ready, the kernel validates the root hash for the SSV snapshot, as noted above, enabling the boot process to proceed to load and run other parts of macOS. The remaining hash checking of the SSV, to confirm that it’s exactly as Apple intends, proceeds in a ‘lazy’ fashion, as access is needed to its contents.

This chain of validation before loading the next stage ensures that nothing in the boot process can be tampered with or changed, and the boot is secure throughout. Apple provides further details in its Platform Security Guide.

Apple has just released urgent security updates to bring macOS Sequoia to 15.6.1, Sonoma to 14.7.8, and Ventura to 13.7.8.

Security release notes for these are already available, for 15.6.1, 14.7.8 and 13.7.8 Each refers to the same single vulnerability in ImageIO, which is apparently being exploited “in an extremely sophisticated attack against specific targeted individuals” using a crafted image file.

The download for 15.6.1 is about 1.56 GB for an Apple silicon Mac, and should be well under 1 GB for Intel. Time to update!

Security utilities that detect known malicious software do so using sets of detection rules. Since their introduction by Victor Alvarez of VirusTotal 12 years ago, the most common method of expressing these rules is in a text file with the extension .yara. Apparently YARA stands for either YARA: Another Recursive Acronym, or Yet Another Ridiculous Acronym.

Yara rules are used extensively in macOS by both the original XProtect and its sibling XProtect Remediator. Those of XProtect are found in the XProtect.yara file in XProtect.bundle, in /Library/Apple/System/Library/CoreServices and its additional location in /private/var/protected/xprotect in Sequoia and later. Further Yara rules are also encrypted and embedded in XProtect Remediator’s scanning modules, as detailed by Koh M. Nakagawa in the FFRI Security GitHub.

As used by Apple, each rule can consist of up to three sections:

• meta, containing the rule’s metadata including a description and in more recent cases a UUID for the rule.
• strings, specifying some of the content of the file, typically in the form of hexadecimal strings such as { A0 6B }.
• condition, a logical expression that, when satisfied, meets the requirements of that rule, so identifying it as malicious.

I’ll exemplify these using Yara rules used in XProtect version 5310.

Private rules

At the start of the Yara file are any private rules. These are a bit like macros, in that they define properties that are then used in multiple rules later. Laid out in compact form, an example reads:

private rule Shebang
{ meta:
description = "private rule to match shell scripts by shebang (!#)"
condition:
uint16(0) == 0x2123
}

This starts with description metadata for this private rule, then states the condition for satisfying this rule, that the first 16-bit unsigned integer in the file contains the hex 0x2123, the UTF-8 characters 0x21 or ! and 0x23 or #. In the reverse order of #! they’re known as the shebang, and the opening characters of many shell scripts, but in this rule they are given the other way around because of the byte order used in the 16-bit integer.

This defines what’s required of a Shebang, and can be included in the conditions of other Yara rules. Instead of having to redefine the same feature in every rule, they can simply include that Shebang rule in their condition.

Regular rules

After 3-5 private rules, the XProtect Yara file goes on to enumerate 372 normal rules, including this one:

rule XProtect_MACOS_SOMA_JLEN
{meta:
description = "MACOS.SOMA.JLEN"
uuid = "4215C9D4-57D5-4D30-82E1-96477493E8D5"
strings:
$a0 = { 4c 8d 3d ?? 74 0b 00 4c 8d 25 ?? ?? 0b 00 4c 8d 2d ?? ?? 0b 00 48 8d 5d c0 }
$a1 = { 73 62 06 91 d4 03 00 f0 94 42 21 91 }
condition:
Macho and ( ( $a0 ) or ( $a1 ) ) and filesize < 5MB
}

This rule has its internal code name as its description, and has been assigned the UUID shown. It then defines two binary strings, a0 and a1, the former containing ‘wild’ values expressed using the question mark ?. The condition for satisfying the rule is that the file must:

• be a Mach-O binary, and
• contain either a0 or a1, and
• its size must be less than 5 MB.

Further details about Yara rules are given here.

Implementation

There are standard implementations that can check files against custom sets of Yara rules. Rules are normally compiled into binary form from their text originals before use. Full details are given on VirusTotal.

Apple’s use of Yara files is mysterious, as for some years all the descriptions used arbitrary code names as obfuscation. When the source of all the rules is given in plain text, it’s hard to see what purpose that served, and it meant that users were told that MACOS.0e32a32 had been detected in an XProtect scan, for instance. Thankfully, Apple has more recently replaced most of those with more meaningful names.

I’m grateful to Duncan for asking me to explain this, and hope I have been successful. I’m also grateful to isometry and an anonymous commenter for straightening out the confusion over the Shebang.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5311. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds eight new detection rules, for MACOS.BANSHEE.MA, MACOS.BANSHEE.MA2, MACOS.SOMA.GEGO, MACOS.POSEIDON.B, MACOS.TIMELYTURTLE.FUNA, MACOS.TIMELYTURTLE, MACOS.TIMELYTURTLE.INDRBYSE and MACOS.TIMELYTURTLE.INDR. Banshee, Poseidon and TimelyTurtle are new names in XProtect’s Yara rules.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5311

Sequoia and Tahoe systems only

This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5311 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

XProtect is the front-line tool in macOS for detecting known malware. When a downloaded app is run for the first time and put through Gatekeeper checks, those rely on detection rules defined in the XProtect.yara file inside the XProtect bundle in /System/Library/CoreServices. Those are updated periodically to extend their coverage as new malware is detected and analysed by Apple’s security engineers. This article looks at how they have changed over the last six years.

My starting point is XProtect version 2103 released on 2 May 2019, in the heyday of macOS 10.14.4 Mojave. That contains a total of 92 rules in a text file of 42,903 bytes, for an average rule size of 456 bytes. Among those are many old chestnuts such as Bundlore.

My end point is version 5310 released this week, on 12 August 2025, for macOS 15.6 Sequoia and earlier. That contains a total of 372 rules in a text file of 969,662 bytes, giving an average rule size of 2,572 bytes. Still among those are the same old chestnuts including Bundlore.

Thus the number of rules is now 4 times what it was six years ago, and they take over 22 times as much space.

For the period up to the end of 2023, I have analysed XProtect’s Yara file in updates every 6 months, in May and November, or the closest update available. From the start of 2024 updates became more frequent, and I have therefore analysed the last update in each month. In late 2024, XProtect in macOS Sequoia started using iCloud to deliver its XProtect data updates. For this analysis I have excluded version 5273, which was only released via iCloud and wasn’t provided through the regular softwareupdate route used by all previous versions.

The number of Yara rules increased steadily until updates became more frequent in 2024, following which there was a very steep rise early that year. Since then they have continued to rise more steeply than before 2024, but now appear more linear, as seen in the red line of regression. Over this period, hardly any Yara rules have been removed.

Total size of the Yara file has followed a similar pattern, with little change until the start of 2024. It then peaked briefly before reducing slightly, pausing a little, then undergoing a step increase from 288 KB to 877 KB. Growth has been steadier for the last year, although it appears to be on track to reach 1 MB in 2026.

Average size of Yara rules changed little between 2021-2023, but increased greatly with the addition of some very large rules in June-July 2024. It has since declined slowly, as more recent rules have been far smaller.

This prodigious growth in the number of Yara rules and their size has inevitably had its effect on the time taken to complete Gatekeeper checks that include XProtect scans. macOS Tahoe has been promised to limit that, by not scanning notarized apps with XProtect, so improving app launch times.

Given that remarkably few old Yara rules have been removed over the last six years, this growth has been inevitable. However, unless old malware is incapable of being run on Macs still supported by XProtect updates, it’s hard to see how it could be safe to remove old rules. When support for running x86 code (except that for “older unmaintained gaming titles”) is dropped from macOS 28, many older Yara rules could be dropped from XProtect updates without putting Apple silicon Macs at risk, but even that isn’t an easy decision. In the meantime, at least our faster Macs should be able to complete XProtect scans more quickly.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5310. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a single new detection rule for MACOS.SOMA.AUENA, further extending its coverage of Soma/Amos.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5310

Sequoia systems only

This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5310 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Six years ago, in July 2019, Macs came closer to disaster than at any time before or since. Millions of Mac users around the world had, at some time or other, installed Zoom conferencing software, and in doing so had unknowingly put their Macs at risk. For their convenience, the old Zoom installers of that time also installed a hidden web server that was left running. That was capable of reinstalling the Zoom client, and had been discovered to contain an easily exploitable vulnerability that exposed all those Macs to remote attacks.

The only solution was for Apple to harness its old Malware Removal Tool, MRT, to remove that web server from all Macs before they came under attack. Although MRT had been widely criticised for what others considered to be weakness, on this occasion it proved its value. MRT version 1.45 was released by Apple on 10 July 2019, and averted that potential catastrophe.

Three years later, in the summer of 2022, Apple replaced MRT with its successor, XProtect Remediator or XPR, which has been vastly improved, and still contains the remnants of MRT in its MRTv3 scanning module. As Apple documents almost nothing about XPR, it has been up to others to dive deep inside it, among them Koh M Nakagawa, @tsunek0h, of FFRI Security. While others have merely scratched the surface, he has just presented a superb and deep account of XPR at Black Hat USA. You can download the slides for his presentation from here.

Status_code 30 PlugInCanceled

If you check XPR scans using SilentKnight or XProCheck, you’ll be aware that for many months some of them are terminated prematurely with a status_code of 30 and the message PlugInCanceled. This most commonly affects Adload scans, and still occurs in beta-releases of macOS 26 Tahoe. According to Koh’s research, the Adload scanning module alone contains over 1,000 Yara detection rules, accounting for the long time it takes whenever XPR runs a set of scans.

Before XPR started terminating its scans as it does now, a full set could take an hour or more, so XPR has started using a timer. If the scan exceeds the time allowed, then it will be abruptly terminated, resulting in this status_code and message. There’s nothing the user can do to avoid it, and we’re surprised that XPR continues to exhibit this behaviour.

Laptop Macs

The other significant limitation in XPR affects those using MacBook Pro, MacBook Air and MacBook models. Because XPR scans take a substantial amount of energy, even when run almost entirely on the E cores of Apple silicon Macs, daily full scans will only be run when those laptops are using mains power, and won’t be run at all on battery.

As XPR scans are also normally run when a Mac is awake but only under a light load, it’s possible for a laptop to go several days without running an XPR scan. The only solution is to leave it connected to mains power, awake and doing little else for an hour or so, when it should seize the opportunity to catch up with that and other important background tasks with similar requirements.

Unfortunately, XPR won’t warn you that it hasn’t run any scans for several days, but SilentKnight and XProCheck will.

Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5309, and to XProtect Remediator for all macOS from Catalina onwards, to version 153. As usual, Apple doesn’t release information about what security issues these updates might add or change.

Yara definitions in this version of XProtect add a single new detection rule for MACOS.SOMA.JUENB, part of the Soma/Amos family.

XProtect Remediator doesn’t change the list of scanner modules.

There are extensive changes to the Bastion rules, which add a new definition for common system binaries, extend Rule 1 coverage to include support folders for more browsers, tweak Rules 3 and 14-17, and add new Rules 18-24.

You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-153 and XProtectPlistConfigData_10_15-5309.

Sequoia and Tahoe systems only

The XProtect update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5304 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

We’re now into August, Apple has released the last substantial updates to macOS before the arrival of Tahoe, so where does macOS stand now?

macOS Sequoia has just had its last scheduled update to 15.6 before it’s expected to enter the first of its two years of security-only updates. The main benefits of this update are an important fix to restoring Macs in DFU mode using either the Finder or Apple Configurator, and its long list of security updates, 81 vulnerabilities in total. If you’re already running Sequoia, it’s an important update.

Sequoia is fully supported on the following Macs:

• iMac 2019, all T2 iMacs including iMac Pro from 2017
• MacBook Air 2020 and later, but not 2018 or 2019
• MacBook Pro 2018 and later (all T2 models)
• Mac mini 2018 and later
• Mac Pro 2019 and later
• all Apple silicon Macs.

macOS Sonoma is now entering its second and final year of security-only updates, and in the latest to 14.7.7 has around 50 vulnerabilities fixed. Although that’s a lot less than in 15.6, those are still important if you’re staying with Sonoma for the time being.

Sonoma is fully supported on the following Macs:

• iMac 2019
• all Intel Macs with T2 chips
• all Apple silicon Macs.

macOS Ventura has probably had the last of its security updates, although in the past Apple has sometimes released one more update in the autumn/fall. Its latest update to 13.7.7 has around 41 vulnerabilities fixed, making it essential if your Mac can’t be upgraded to Sonoma or later. If your Mac is supported by Sonoma, now is the time to plan upgrading it so that it can continue receiving security updates from September.

Tahoe

macOS Tahoe has now entered the public phase of its beta-testing, with the fourth version provided to developers. While much of the debate surrounds its Liquid Glass and new look, it does bring new features such as a Phone app to Macs. So far it appears internally stable and doesn’t look likely to be delayed for major bugs to be wrangled.

Tahoe is fully supported on the following Macs:

• MacBook Pro 16-inch 2019, and 13-inch 2020 with four Thunderbolt ports,
• iMac 2020,
• Mac Pro 2019,
• all Apple silicon Macs.

Although the first couple of versions of Tahoe presented themselves to older apps and scripts as macOS 16, since beta 3 it has been thoroughly macOS 26 regardless of how it’s asked. As this hasn’t been mentioned in Apple’s release notes, it’s unclear what it will do in the final release. If you have apps or scripts that could break when they discover the version of macOS running is 26, now is the time to send Apple feedback to make your case for it to report as version 16.

Older Macs

Open Core Legacy Patcher, OCLP, is being updated in the hope that it will be able to run macOS Tahoe on at least some unsupported models, although that probably won’t be available until the end of this year. You can follow progress here, where you’ll see some of the challenges its developers are facing. Another site worth watching is Mr. Macintosh on YouTube.

Next stop, probably in September, should be:

• macOS 26.0 Tahoe
• macOS 15.7 Sequoia
• macOS 14.8 Sonoma

if Apple remains consistent with previous numbering. Farewell to Ventura, old friend!

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5305. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a single new rule for MACOS.SOMA.JLEN, part of the Amos/Soma family of malware.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5305

Sequoia systems only

This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5305 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

This week’s security data updates were quite a surprise. We’ve grown accustomed to Apple tweaking XProtect’s data most weeks, but this week was a bit different, and came with an update to XProtect Remediator as well, the first in four months. This article explores what they have brought.

Although this security data all goes under the name of XProtect, there are three different protection systems involved.

The traditional XProtect contains a set of ‘Yara’ rules used when performing Gatekeeper scans of new executable code, most notably when a quarantined app is first run, although recent macOS also runs XProtect checks on other occasions. Those rules are used to determine whether the code being scanned is known to be malicious, and if it’s found to be positive, macOS refuses to run that code and you’re told to trash the app.

XProtect Remediator only runs in Catalina and later, where it performs daily background scans to detect and remove software it believes to be malicious. It currently contains 24 separate scanning modules, each designed to detect and ‘remediate’ a different family of malware. Some of its modules also use the detection rules in traditional XProtect, so are improved by regular XProtect data updates. Surprisingly, if XProtect Remediator detects and removes malware, you aren’t notified, although that is recorded in the log and reported as an Endpoint Security event that can be detected by some third-party security software.

Inside the XProtect Remediator app are two files used by the third XProtect, which detects potentially malicious activity such as tampering with parts of a browser’s files. This is therefore referred to as XProtect Behavioural, or by the name it gives to the detection rules it uses, Bastion. Unlike the other two XProtects, this doesn’t rely on performing static checks, but is watching constantly for malicious activity. Although it records that in its local database, at present it doesn’t inform the user, but reports the activity to Apple, to help it acquire intelligence to improve the battle against malware.

XProtect

XProtect version 5304, provided by Apple on 8 July, makes substantial changes to its Yara detection rules to add what appears to be a new family of malware, code-named Bonzai. New rules refer to five different forms, which are most likely to be different components in the same malware, or separate variants, named Bonanza, Barricade, Blaster, Bonder and Banana. It’s likely that independent security researchers will identify these in the coming days, but for the moment the public name of this malware isn’t known.

Looking through these new Yara rules, they look most likely to be for a ‘stealer’, a type of malware that’s currently prevalent, and steals your secrets to send them to a remote server. There are references to Chrome, Brave, Edge and Firefox extensions, and most interestingly some of the malware has been compiled from code written in the Go language, which is becoming popular in cross-platform malicious code.

The last times that Apple added detection rules as substantial as these were in XProtect version 5284 for Adload and Bundlore, and in 5269 for Dolittle, each being major threats.

Bastion

Until now, the behavioural rules used by Bastion have evolved steadily, and the most rules added in one release has only been two, when XProtect Remediator version 123 came with rules 8 and 9, and changes to rule 7, back in January 2023. This update brings four new rules:

• Rule 14 detects sending AppleEvents to Safari, Firefox or Chrome.
• Rule 15 detects sending AppleEvents to the Finder or Terminal.
• Rule 16 detects Mach lookups for com.apple.pasteboard.1.
• Rule 17 detects writing shell files hidden in ~/ or /etc, such as ~/.zlogin, or /etc/zlogin.

The first two may be intended to detect AppleScript being used to control those browsers, the Finder or to run scripts in Terminal. Rule 16 may also be related to Apple’s recent announcement on controlling access to the pasteboard in macOS 26. Rule 17 concerns settings files commonly used by command shells, readily seen if you reveal hidden files for your Home folder.

These may well be related to Bonzai, and enable Apple to get a better idea of what is going on out here in the wild, and focus its efforts in improving its detection.

XProtect Remediator

Once samples of malware have been obtained, developing and testing new Yara rules to detect it is relatively quick, and often uses AI to accelerate the process. Writing a new scanning module for XProtect Remediator is more complicated, and takes more time. It may well be that an additional Bonzai scanner is already on its way, and might be delivered in a further update in the next couple of weeks, perhaps with some fine-tuning of the new Bastion rules. I’ll be keeping a lookout for those.

Above all, it will be interesting to see what changes are made in third-party security software, and how well those tackle what appears to be novel malware for macOS.

Apple has just released updates to XProtect for all supported versions of macOS, bringing it to version 5304, and to XProtect Remediator for all macOS from Catalina onwards, to version 152. As usual, Apple doesn’t release information about what security issues these updates might add or change.

Yara definitions in this version of XProtect add two private rules for Shebang, to match shell scripts by ‘shebang’, and _golang_macho, to match machos compiled by Golang. There are also 19 new rules for a novel family of what appear to be stealers based on the name BONZAI, including MACOS.BONZAIBONANZA.AUTO, MACOS.BONZAIBONANZA.TAAP, MACOS.BONZAIBONANZA.TAFI, MACOS.BONZAIBONANZA.VACA, MACOS.BONZAIBONANZA.VASN, MACOS.BONZAIBONANZA.FU, MACOS.BONZAIBONANZA.SC, MACOS.BONZAIBARRICADE.PE, MACOS.BONZAIBARRICADE.PA, MACOS.BONZAIBARRICADE.KE, MACOS.BONZAIBLASTER.FU, MACOS.BONZAIBLASTER, MACOS.BONZAIBLASTER.TA, MACOS.BONZAIBONDER.SO, MACOS.BONZAIBONDER.PE, MACOS.BONZAIBONDER.TEPL, MACOS.BONZAIBONDER.LA, MACOS.BONZAIBONDER.FU, and MACOS.BONZAIBANANA.

XProtect Remediator doesn’t change the list of scanner modules.

There are changes to the list of Bastion rule 2 paths, and four new Bastion rules 14-17. These cover sending AppleEvents to browsers, the Finder and Terminal, mach-lookup for com.apple.pasteboard.1, and writing to a long list of shell-related hidden directories in the user’s Home folder.

These are probably the greatest changes to XProtect’s Yara rules and Bastion rules for more than a year.

You can check whether these updates have been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install these as named updates in SilentKnight, their labels are XProtectPayloads_10_15-152 and XProtectPlistConfigData_10_15-5304.

Sequoia and Tahoe systems only

The XProtect update has already been released for Sequoia and Tahoe via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5304 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Much of the data handled on and off our Macs and devices is protected by encryption. That has been designed to ensure encryption can’t be broken in a reasonable amount of time using current and future computing resources. Using conventional computers, for instance, it would take a great many years to break data encrypted using 256-bit AES, so in practice this has been considered to fully secure, for the past.

Threat

For the last 50 years or so, researchers have been working on quantum computers that could radically change that. Instead of using normal binary bits with values of 0 and 1, those use qubits measured in terms of probability, making them non-deterministic. That changes the way they work, and some tough problems in the binary world can be speeded up so much that, given a suitable quantum computer, they could compute in far shorter times. This has already been applied to greatly reduce search times in big data, and has the potential to break most recent forms of encryption.

Progress in making suitably powerful quantum computers to be able to decrypt data encrypted using classical techniques has been slow, but we’re now reaching the stage where that’s likely to be feasible in the next year or three. Now is the time to start deploying more advanced forms of encryption to protect our data from the imminent future.

Data in transit

In February last year, Apple announced that iMessage was transitioning to the use of protocols that are quantum-secure, and those were introduced the following month in macOS 14.4, iOS and iPadOS 17.4 and watchOS 10.4. When macOS 26 Tahoe and its matching OSes are released in a couple of months, they bring further important steps towards fully secure encryption, in encrypted network connections using quantum-secure mechanisms in TLS 1.3.

Classical encryption is at its most vulnerable when encryption keys are exchanged over the Internet, and public key systems can be completely broken by quantum methods. Thus, Apple’s first changes are being made to protect data in transit, where it can be intercepted and stored for later decryption using a quantum computer. Securing iMessage is an important start, and the new features in Tahoe and its sisters extend similarly improved protection to other data transfers.

Apple’s operating systems provide support for encryption and related techniques in CryptoKit, making quantum-secure methods available to third-party apps as well. For OS 26, CryptoKit gains Module-Lattice based key encapsulation or ML-KEM, part of the FIPS 203 primary standard for general encryption. Signatures gain the Module-Lattice based digital signature algorithm or ML-DSA, part of FIPS 204.

Data in storage

Whereas public key cryptography systems can be completely broken by quantum attacks, the news for symmetric key schemes such as those used in FileVault and APFS encryption is considerably better. Although quantum computers will be able to break classical techniques more quickly, that should prove neither quick nor easy.

In Intel Macs with T2 chips and Apple silicon Macs, encryption keys are protected by the Secure Enclave, never leave it, and are never exposed to the main CPU. Attempts to gain access through the Secure Enclave are subject to robust defences: for example, the Secure Enclave Processor allows only 5 attempts to enter a Mac’s password before it increases the time interval enforced between entry attempts, and after 30 unsuccessful attempts no more are allowed at all, and the Mac has to be fully wiped and reset.

Trying to remove internal storage is designed to frustrate the attacker. Although internal storage is referred to as an SSD, the storage used isn’t complete in the sense that you couldn’t remove it and install it in another computer, and most of its disk controller functionality is performed by sections in the host chip, including its Secure Enclave. Even models like the Mac Studio that have socketed storage don’t make this easy: remove its special SSD module and it won’t work in another Studio unless it has been completely wiped and reset, destroying its keys and contents.

Apple’s strategy for the protection of encrypted internal storage is thus intended to block access at every level, so that post-quantum brute-force decryption would have little if any impact should it become available in a few years. The standard encryption method used, AES-256 in XTS mode, may need to be revised as quantum decryption becomes more feasible, and Apple is now recommending that doubling the key size should be sufficient to make encryption suitably resistant to forcing with a quantum computer.

Summary

• Future quantum computers will be able to break some classical encryption methods.
• Public key methods used to protect data in transit across the Internet are the most vulnerable to quantum attack.
• macOS 14.4 and iOS 17.4 have started progressively replacing iMessage protection to make it resistant to quantum attack.
• OS 26 will extend that protection to cover connections over TLS 1.3, where supported by servers.
• Protection already provided to stored data, such as FileVault, is considered to remain robust.
• Encryption of static data can be made more robust to quantum cryptography by doubling key size from 256 to 512 bits.

Resources

Quantum computing (Wikipedia)
Post-quantum cryptography (Wikipedia)
FIPS 203-206 (NIST standards)
Securing iMessage with PQ3 (Apple)
macOS Tahoe TLS 1.3 support (Apple)
Cathie Yun presentation Get ahead with quantum-secure cryptography, WWDC 2025 (via Apple Developer app etc.)
CryptoKit for developers (Apple)

From its first announcement of Apple silicon Macs on 22 June 2020, there has been speculation as to when support of Intel models will cease. Now Apple has given exceptionally clear details of its future intentions, and we have a clearer idea of what’s coming in macOS Tahoe, we can make plans at last. This article looks at the years ahead. In each case, major events are scheduled to occur with the annual transition of macOS to the next major version, normally in September-October.

2025

Final security update for macOS 13 Ventura, ending support for:

• iMac 18,1-3
• MacBook 10,1
• MacBook Pro 14,1-3.

If you’re still running Ventura on a Mac capable of Sonoma or later, now is the time to plan the upgrade.

2026

Final security update for macOS 14 Sonoma, ending support for:

• MacBook Air 8,1-2.

First release of an Arm-only version of macOS, 27. However, that and all its updates will continue to include full support for running Intel binaries using Rosetta 2 translation. macOS 27 will be the last major version that supports Rosetta 2 fully in Virtual Machines.

2027

Final security update for macOS 15 Sequoia, ending support for:

• iMac 19,1-2
• iMac Pro
• Mac mini 8,1
• MacBook Air 9,1
• MacBook Pro 15,1-4 16,3.

First release of macOS 28, with full Rosetta 2 support removed. Limited Intel binary support will continue for “older unmaintained gaming titles” only. As a result, virtual machines running macOS 28 will no longer be able to run most Intel binaries.

2028

Final security update for macOS 26 Tahoe, ending support for all remaining Intel models:

• iMac 20,1-2
• Mac Pro 7,1
• MacBook Pro 16,1-2 16,4.

T2 firmware updates are almost certain to cease with the end of support for macOS 26. Major third-party vendors are likely to stop providing Universal binaries, as they too drop support for macOS 26 and Intel models. Apple may decide to remove x86 support from Xcode 29, but hasn’t yet made any statement either way.

Benefits of upgrading macOS in Intel models

Although macOS Sequoia and Tahoe have brought some new features for Intel Macs, much of Apple’s emphasis now requires Arm systems. Major reasons for upgrading your Intel Mac to the most recent version of macOS it can run include:

• Third-party support. Major software vendors like Microsoft normally only support their products on versions of macOS still supported by Apple.
• Safari is only updated in supported versions of macOS.
• Bug fixes. Although new versions bring their own bugs, the chances of an existing bug being fixed in the current release of macOS are far greater than it being fixed in an older version.
• Security vulnerabilities. Only the current version of macOS gets a full set of fixes in each round of security updates, and the older two supported versions often lag the current one.
• Enhancements. Some new features are still provided for both platforms.
• Compatibility. If you already use Apple silicon Macs, or intend doing so, they are more compatible when running the same version of macOS. One topical example is Tahoe’s new ASIF disk image format.
• Quantum-secure encryption. Apple has already started to transition to cryptographic techniques designed to remain secure as and when quantum computers are used in the future to break older methods. This started with iMessage last year, and Apple has announced that macOS 26 Tahoe will support quantum-secure encryption in TLS. This is unlikely to be added retrospectively to older versions of macOS.

I hope you find that helpful in your planning, and wish you success in whatever you choose.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5303. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds two new rules, for MACOS_SOMA_JUEN and MACOS_SOMA_LLJU, continuing to extend its coverage of the Amos/Soma family of malware.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5303

Sequoia systems only

This update has just now been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5303 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Update:

The update was released via iCloud at 2010 GMT.

We rely on FileVault and APFS to protect our secrets by encrypting the volumes containing our documents and data. How they do that is a mystery to many, and raises important questions such as the role our passwords play, and how recovery keys work. This article attempts to demystify them.

Naïve encryption

A simple scheme to encrypt a disk or volume might be to take the user password, somehow turn it into a key suitable for the encryption method to be used, and employ that to encrypt and decrypt the data as it’s transferred between disk storage and memory.

There are lots of weaknesses and difficulties with that. Even using a ‘robust’ user password, it’s not going to be memorable, sufficiently long or hard to crack, and there’s no scope for recovery if that password is lost or forgotten.

FileVault base encryption

In Macs with T2 or Apple silicon chips when FileVault is disabled, everything in the Data volume stored on their internal SSD is still encrypted, but without any user password. This is performed in the Secure Enclave, which both handles the keys and performs the encryption/decryption. That ensures the keys used never leave the Secure Enclave, so are as well-protected as possible.

Generating the key used to encrypt the volume, the Volume Encryption Key or VEK, requires two huge numbers, a hardware key unique to that Mac, and the xART key generated by the Secure Enclave as a random number. The former ties the encryption to that Mac, and the latter ensures that an intruder can’t repeat generation of the same VEK even if it does know the hardware key. When you use Erase All Content and Settings (EACAS), the VEK is securely erased, rendering the encrypted data inaccessible, and there’s no means to either recover or recreate it.

This scheme lets the Mac automatically unlock decryption, but doesn’t put that in the control of the user, who therefore needs to enable FileVault to get full protection.

FileVault full encryption

Rather than trying to incorporate a user password or other key into the VEK, like many other encryption systems FileVault does this by encrypting the VEK using a Key Encryption Key or KEK, a process known as wrapping.

When you enter your FileVault password, that’s passed to the Secure Enclave, where it’s combined with the hardware key to generate the KEK, and that’s then used together with hardware and xART keys to decrypt or unwrap the VEK used for decryption/encryption.

This has several important benefits. As the KEK can be changed without producing a new VEK, the user password can be changed without the contents of the protected volume having to be fully decrypted and encrypted again. It’s also possible to generate multiple KEKs to support the use of recovery keys that can be used to unlock the VEK when the user’s password is lost or forgotten. Institutional keys can be created to unlock multiple KEKs and VEKs where an organisation might need access to protected storage in multiple Macs.

APFS encryption

True FileVault requires all keys to be stored in the Secure Enclave, and never released outside it. Intel Macs without T2 chips, and other protected volumes such as those on external storage can’t use that, and in the case of removable storage need an alternative that stays on the disk. For that, APFS uses the AES Key Wrap Specification in RFC 3394, using a secret such as a password to maintain confidentiality of every key.

APFS also uses separate VEKs and KEKs, so enabling the use of multiple KEKs for a single VEK, and the potential to change a KEK without having to decrypt and re-encrypt the whole volume, as in FileVault. In APFS, VEKs and KEKs are stored in and accessed from Keybags associated with both containers and volumes. The Container Keybag contains wrapped VEKs for each encrypted volume within that container, together with the location of each encrypted volume’s keybag. The Volume Keybag contains one or more wrapped KEKs for that volume, and an optional passphrase hint. These are shown in the diagram below.

Apple’s documentation refers to several secrets that can be used to wrap a KEK, including a user password, an individual recovery key, an institutional recovery key, and an unspecified mechanism implemented through iCloud. Currently, for normal software encryption in APFS, only two of those appear accessible: a user password is supported in both Disk Utility and diskutil‘s apfs verb, while diskutil also supports use of an institutional recovery key through its -recoverykeychain options. Individual and iCloud recovery keys only appear available when using FileVault, in this case implemented in software, either on Intel Macs without a T2 chip, or on all Macs when encrypting an external volume.

Because keybags are stored on the disk containing the encrypted volume, if the disk is connected to another Mac, when macOS tries to mount that volume, the user will be prompted to enter its password, and can then gain access to its contents. When FileVault is used to protect a Data volume on the internal SSD of a T2 or Apple silicon Mac, that volume can only be unlocked through the Secure Enclave of that Mac, and it isn’t possible to unlock it from another Mac (that’s also true when FileVault hasn’t been enabled on that volume).

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5302. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a new rule for MACOS_SOMA_FA_LE, again extending coverage of the Amos/Soma family of malware.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Tahoe available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5302

Sequoia systems only

This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5302 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Starting up a Mac, iPad or iPhone begins a series of processes progressing from their small boot ROMs to user login, starting up the services required for the operating system and booting the array of hardware in the chip. Early phases, before the kernel is booted, leave little in the way of records, just a few ‘breadcrumbs’ in NVRAM, but the kernel and processes it starts write a great many entries in the log. This article describes a few of those, concentrating on macOS 15.5, with additional information on iPadOS and iOS 18.5.

Logs

These were obtained from logarchives made soon after normal startup on:

• Mac mini M4 Pro, booting macOS 15.5 in Full Security mode from the internal SSD;
• iPad Pro 11-inch (4th generation)(Wi-Fi), with an M2 booting iPadOS 18.5 normally;
• iPhone 15 Pro, booting iOS 18.5 normally.

Logarchives were opened in LogUI and all log entries (excluding Signposts) were extracted for the first 5 seconds following the start of kernel boot and saved to a LogUI JSON file. Following correction for time adjustments (see below), those contained:

• for macOS, 20,000 entries in a total of 5.7 seconds;
• for iPadOS, 10,000 entries in a total of 5.7 seconds;
• for iOS, 10,000 entries in a total of 5.6 seconds.

Each set of entries opens with an entry recording the first moment of the boot process, for example
08:23:33.343017 === system boot: CCB8E0AC-5B94-4789-B951-BF0B893FF45F
following which there is a gap of over 5 seconds during which preboot is completed. The next entry then records the start of kernel boot, for example in macOS with
08:23:38.536777 kprintf initialized

Periods between those two entries were 5.2 seconds for macOS, 5.3 seconds for iPadOS, and 5.1 seconds for iOS.

Times and their correction

One potential source of major error in using log entries during startup results from clock time corrections. When started up, Macs and Apple’s devices appear invariably to have clock times about 6 seconds in advance of UTC. This is corrected about 4 seconds into kernel boot, and marked in two log entries such as
00.827884 === system wallclock time adjusted
00.860742 === system wallclock time adjusted
The first adjustment normally sets the clock back slightly more than necessary, but the second corrects that more accurately.

Effects on timestamps in log entries can appear confusing, as entries prior to time adjustment are given later timestamps than entries written after the adjustments have been made. This may give the impression that the order of log entries is incorrect, and any time calculations that depend on times recorded before and after adjustment require compensation by the two adjustments made. All times given below are taken from records made before system wallclock time adjustment, thus don’t require correction.

Time adjustments may need to be taken into consideration when accessing Endpoint Security events, as some may be written before adjustments are made, so might appear to be out of kilter with later events. This could apply to boot events for the launchd Subsystem, for example.

Log entries

Shortly after the start of kernel log entries with the initialisation of kprintf, the kernel banner is written, but only in macOS
Darwin Kernel Version 24.5.0: Tue Apr 22 19:53:27 PDT 2025; root:xnu-11417.121.6~2/RELEASE_ARM64_T6041

Virtual memory, logging and other fundamental features are then prepared, and in macOS (not iPadOS or iOS) TXM, the Trusted Execution Monitor, is started
TXM [Log]: build variant: txm.macosx.release.TrustedExecutionMonitor_Guarded-135.100.3
followed by the announcement of two stages of preboot, at 0.11 seconds after the start of kernel boot:
iBoot version: iBoot-11881.121.1
iBoot Stage 2 version: iBoot-11881.121.1

It’s notable that macOS gave an iBoot version of 11881.121.1, but iPadOS and iOS gave a slightly later version of 11881.122.1.

According to Apple, TXM (together with SPTM) is active on all three platforms, although it only appears to be well-reported in macOS. Apple explains: “Secure Page Table Monitor (SPTM) and Trusted Execution Monitor (TXM) on iOS, iPadOS, macOS and visionOS are designed to work together to help protect page tables for both user and kernel processes against modification, even when attackers have kernel write capabilities and can bypass control flow protections.” TXM then enforces the policies that govern code execution.

The kernel then turns its attention to loading Core Crypto support, reported in detail in all three platforms, and support for Image4 files, used extensively during and after boot:
0.295967 Darwin Image4 Extension Version 7.0.0: Tue Apr 22 19:44:19 PDT 2025; root:AppleImage4-320.100.22~1926/AppleImage4/RELEASE_ARM64E
and security policy is loaded (reported in macOS only).

AMFI and credential management

All three platforms then report loading of Apple Mobile File Integrity (AMFI), which obtains the model designator from the device tree:
AMFI: queried model name from device tree: Mac16,11
AMFI: queried model name from device tree: iPad14,3
AMFI: queried model name from device tree: iPhone16,1
which is probably the simplest way to confirm the model identifier from the log at this stage. On iOS only, AMFI next reports disabling Swift Playgrounds JIT:
AMFI: disabling Swift Playgrounds JIT services on iPhone devices

The kernel then turns to management of credentials with Credential Manager, which works with secrets managed by the Secure Enclave Processor (SEP) (all platforms). One key log entry to look for is the report of SEP Key Store startup,
"AppleSEPKeyStore":326:0: starting (BUILT: Apr 22 2025 19:45:09) ("normal" variant 🌽 , 1827.120.2)

Startup of hardware systems continues, with Bluetooth reported early, followed by IOThunderboltFamily, and the Apple Neural Engine ANE. In macOS only, the remains of an old copyright notice will then appear:
Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved.
iPadOS and iOS report Backlight startup in
AppleARMBacklight::start: Using new Backlight Architecture 1

CPU cores

After those, in macOS only, the log records registration of CPU cores and their clusters, then starts each in turn. Prior to this, all code has been run on a single core, but once the others have been started, multiple cores are available. The exact log entries recording this may vary between different M families, but typically run as follows:

• ml_processor_register>pset_find(cluster_id=0) returned pset -1
• ml_processor_register>pset_create(cluster_id=0) returned pset 0
• ml_processor_register>cpu_id 0x0 cluster_id 0 cpu_number 0 is type 1
• repeated to create each cluster and allocate CPUs to them, then
• cpu_start() cpu: 0
• arm_cpu_init(): cpu 0 online
• for each CPU in turn.

Although the iPad tested has an M2 chip, no such sequence was reported for its CPU cores in the log.

Security policy

macOS reports Gatekeeper status and the start of AppleSystemPolicy:
AppleSystemPolicy GK status: enabled
AppleSystemPolicy Per file changetime scans: enabled
Security policy loaded: Apple System Policy (ASP)
AppleSystemPolicy has been successfully started

APFS

APFS follows, with differences between log entries according to platform. Initial loading is announced in each, giving the version number
apfs_module_start:3403: load: com.apple.filesystems.apfs, v2332.120.31, apfs-2332.120.31.0.2, 2025/04/22
In macOS only, NFS is announced shortly afterwards
com_apple_filesystems_nfs: successfully loaded NFS module
and handling individual file system devices follows.

Boot devices are recorded in full:
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16GFamilyIO/ans@9600000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP2048Z Media/IOGUIDPartitionScheme/Container@2/AppleAPFSContainerScheme/AppleAPFSMedia
/AppleAPFSContainer/Macintosh HD@1 (macOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleT811xIO/ans@77400000/AppleASCWrapV4
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0512Z Media/IOGUIDPartitionScheme/Container@1 (iPadOS)
Got boot device = IOService:/AppleARMPE/arm-io@10F00000/AppleH16IO/ans@F9400000/AppleASCWrapV6
/iop-ans-nub/RTBuddy(ANS2)/RTBuddyService/AppleANS3CGv2Controller/NS_01@1/IOBlockStorageDriver
/APPLE SSD AP0128Z Media/IOGUIDPartitionScheme/Container@1 (iOS)

Each platform states the BSD root in a paired entry:
BSD root: disk3s1
, major 1, minor 15
By that time, the boot process is well underway and log entries are being made every few microseconds.

Key points

• Log entry times need to be corrected when they straddle clock adjustments marked by === system wallclock time adjusted
• === system boot: marks the start of preboot, following which there are no log entries for over 5 seconds before kernel boot starts.
• Start of Trusted Execution Monitor (TXM) is only logged in macOS, although it’s also active in iPadOS and iOS.
• iBoot versions may differ between macOS, and iPadOS/iOS.
• An early log entry from AMFI reports the model designator.
• AMFI reports disabling Swift Playgrounds JIT services on iPhones.
• In macOS only, CPU clusters and cores are registered, and started up individually.
• macOS then reports Gatekeeper (GK) status and the start of AppleSystemPolicy.
• The boot device is reported in full.
• Throughout these, many other services and hardware features are started up.
• During early kernel boot, macOS writes 20,000 log entries in about 5.7 seconds, iPadOS and iOS 10,000.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5301. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds a new rule for MACOS_AMOS_BO_EN, extending coverage of the Amos/Soma family of malware.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5301

Sequoia systems only

This update has already been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5301 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5300. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version modifies an existing rule for MACOS.a6d7810, whatever that might be.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5300

Sequoia systems only

This update has just been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5300 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Updated 2215 10 June 2025 with iCloud release information.

Apple has just released an update to XProtect for all supported versions of macOS, bringing it to version 5299. As usual, Apple doesn’t release information about what security issues this update might add or change.

This version adds three new rules, for MACOS_ODYSSEY_A, MACOS_ODYSSEY_B and MACOS_SOMA_M.

You can check whether this update has been installed by opening System Information via About This Mac, and selecting the Installations item under Software.

A full listing of security data file versions is given by SilentKnight and SystHist for El Capitan to Sequoia available from their product page. If your Mac hasn’t yet installed this update, you can force it using SilentKnight or at the command line.

If you want to install this as a named update in SilentKnight, its label is XProtectPlistConfigData_10_15-5299.

Sequoia systems only

This update has now been released for Sequoia via iCloud. If you want to check it manually, use the Terminal command
sudo xprotect check
then enter your admin password. If that returns version 5299 but your Mac still reports an older version is installed, you may be able to force the update using
sudo xprotect update

Updated 1845 GMT 4 June 2025 with iCloud availability at last.

In the next few months, many of us will replace our Macs, and pass on our old ones to relatives, purchasers, or for recycling. This article explains how best to prepare your Mac so that you don’t unintentionally give away anything sensitive to its next owner, or lose anything in the process.

Back up and sign out

Your first steps should ensure that your Mac doesn’t take with it anything that you might miss. That means making at least one full backup, and ensuring you have stored additional copies of important documents in archives.

One store you might forget are its keychains, that could contain old passwords that you might need to recover in the future. While you’re most likely keeping current passwords in the keychain shared in iCloud, older ones might remain, particularly in your old Mac’s login keychain. That should be in its backup, but keeping another copy is wise, and will include any security certificates you might not have used recently.

Next come third-party apps and subscriptions that need to be signed out or transferred. Check carefully through the Applications folder to ensure that you haven’t forgotten any that are still valid. Among those is the need to deauthorise your old Mac for Apple media, something you should do using one of its media apps such as Music or TV, or iTunes if it’s running an older version of macOS.

If it’s an Intel Mac and its firmware password has been enabled, start it up in Recovery and disable that before going any further.

T2 and Apple silicon

If it’s an Intel Mac with a T2 chip, or an Apple silicon Mac, your task is almost complete, as all that’s required now is to Erase All Content and Settings (EACAS).

There is one important exception to this, if you added any more containers or volumes to its internal storage. They aren’t protected by FileVault and the Secure Enclave, so need to be erased separately before using EACAS. This is most secure if those extra volumes or containers were also encrypted, but as you’re about to use EACAS, that should make it well nigh impossible for anyone to piece together the remains of your extra volumes on its SSD.

Start EACAS from System Settings > General > Transfer or Reset > Erase All Content and Settings…. In older versions of macOS that still use System Preferences, open them and it’s offered as a command in the app menu there. Once that’s done, all that remains is to remove that Mac from your account in the Apple Account pane on another Mac or device.

EACAS handles all the signing out that’s required, and disables Find My Mac and Activation Lock for you. But most importantly it ensures that no one can access the contents of its Data volume, by destroying the encryption keys used to encrypt that volume. Without those keys, it’s practically impossible for anyone to break that encryption and recover any of the protected data.

If your old Mac is going for recycling, you might like to open it up and physically destroy its internal storage, just to be safe.

Intel Macs without T2

EACAS is only available in Macs with T2 or Apple silicon chips. If your Mac doesn’t have either of those you’ll need to perform each step manually, going through

1. disable Find My Mac and Activation Lock
2. sign out of iCloud
3. sign out of iMessage
4. reset NVRAM
5. unpair all Bluetooth devices
6. erase the Mac and, if you’re passing it on to someone else, install macOS
7. remove that Mac from your account in Apple ID settings.

The biggest challenge is how to erase its storage securely. If it’s going for recycling, you can open it up and physically disrupt its storage, but when you’re passing that Mac on you obviously can’t do that.

If its internal storage is a hard disk, or Fusion Drive, the traditional solution is to perform a Secure Erase using Disk Utility. However, Apple has removed that from Sequoia, so you’ll need to create an external bootable disk with Sonoma or earlier to enable you to do that.

Secure Erase neither works nor is it wise when trying to clean an internal SSD, though. The most practical solution is to turn FileVault on, leave the Mac to complete encrypting the whole of its Data volume, then start it up from an external bootable disk and erase the internal SSD from there.

.AppleSetupDone

In the past, some have recommended deleting the .AppleSetupDone file in /var/db/, which then caused the Setup Assistant to launch when that Mac was next started up, to create a new local user. For a Mac that’s going to be used by someone else, this has never been a wise move, and Apple has stopped that from working in macOS Sonoma 14.0 and later. It’s far better to use EACAS to reset that Mac, then Setup Assistant will run when it next starts up.

Checklist

• Back up
• Make additional copies of important documents, keychain(s)
• Sign out from or transfer third-party apps
• Deauthorise for Apple media
• Disable firmware password (Intel)
• Delete any extra containers or volumes if they’ve been created on internal storage.
• Erase All Content and Settings (T2, Apple silicon), or manual list above
• Remove from Apple Account
• Physically destroy internal storage (if recycling).