All of us at some time or other find our mind has gone blank and we can’t remember the password we’ve typed in so often before. Or the person who did know that password may no longer be there to recall it for us. At times like these we may need to gain access to a locked Mac. This article looks at how you can do that in an Intel Mac with a T2 chip, or an Apple silicon Mac, running Big Sur or later, in particular macOS Tahoe. If you want information for an older Mac or macOS, this article should be more helpful.

Keyboard

If you’re certain you entered the correct password but it was refused, check the Caps Lock key isn’t on, and check the Mac is using the correct language keyboard in the menu at the top right.

Firmware password (Intel only)

Intel Macs can be protected using a firmware password set and removed in Recovery, and that can normally only be removed if you know the password. If you don’t, the most reliable way to achieve this is to take the Mac to an Apple store, together with proof of purchase or ownership, and ask them to remove the firmware password.

Further information is in this support note, and in Mr. Macintosh’s article.

Don’t just guess

Trying to guess a Mac’s password is doomed to failure: you only have ten attempts before you have to try in Recovery, and an absolute maximum of fifty attempts in total before access to its Data volume is permanently barred, and that Mac has to be restored in DFU mode. Time intervals are also added between attempts, starting at a minute after the third attempt, and rising to eight hours with the ninth.

Once you realise you don’t know the password, click on the ? to the right of the password entry box. If you keep trying to guess, your attempts will soon be delayed by lock periods that grow up to eight hours.

The Mac will then offer you the best option for resetting the password. If the Mac was opted into iCloud Recovery, you’ll then be asked for details of the Apple Account.

This is now handled by the Recovery Assistant, which also helps you use the Recovery Key if iCloud Recovery wasn’t chosen.

If you don’t have Apple Account details or the Recovery Key, the remaining option is to wipe the Mac. That’s offered in the Erase Mac command in Recovery Assistant’s menu.

For these the Mac needs an internet connection. Further details are in this support article. If you’ve forgotten your Apple Account password, Apple’s support article here should help.

Missing owner

Those methods all assume that you’re the owner/user, have simply forgotten your login password, and can recall your Apple Account details or Recovery Key. If the Mac belonged to someone who’s no longer there, and you don’t have access to their Apple Account, you won’t be able to use those options.

There are two further steps now available that you may find helpful. Provided your Apple Account has two-factor authentication enabled, if you’re unable to sign in or reset your password, you can ask Apple to perform account recovery. This isn’t immediate, but provided you can satisfy Apple that your request is genuine, it should prove possible.

As of macOS 12.1 and iOS/iPadOS 15.2, Apple has supported Legacy Contacts, but those must be set up before you need to use them. The Legacy Contact is then provided with an access key they can use in the event that you can’t because you’re dead. Apple also needs to see a copy of the death certificate before giving full access to the account for a period of three years. Full details are here.

Still no solution

If you want to access the Mac but not its contents, it’s straightforward to return Apple silicon and T2 models to factory condition by putting them into DFU mode and restoring them, as explained here. That may not always be a good step, though: when you try to set that Mac up again, it checks in with Apple. If it has been registered as stolen, you could find it becomes unusable.

If all else fails, get expert advice and help from Apple stores, authorised service providers, and from the many independent Mac technicians around the world who are often only too familiar with these problems.

Virtual machines

Depending on how they’re set up, macOS VMs can now support either iCloud Recovery, or a Recovery Key, provided the guest macOS can.

It has been 22 years since Apple’s first version of FileVault was introduced in Mac OS X 10.3 Panther. Since then it has changed beyond all recognition, and has been transformed from a questionable option to an essential feature of Apple silicon Macs. This article explains those changes, and how enabling FileVault is now a no-brainer.

The past

FileVault 1 was very different. For a start, it didn’t attempt to encrypt whole volumes, as that still isn’t built into HFS+ and only became possible in Mac OS X 10.7 Lion, when Apple added a logical volume manager, Core Storage. So this first effort stored your Home folder in an encrypted disk image, something that also proved easy to crack.

Apple’s second attempt at FileVault proved more successful, with Core Storage handling the encryption of whole HFS+ volumes. This required encryption and decryption to be performed in software, in the days when most CPUs didn’t have instructions to accelerate that. When you first enabled FileVault, macOS had to encrypt the entire contents of the boot volume, which before Catalina included the whole of the system as well as user data. Fortunately, Apple engineered this initial encryption to run in the background while you were still using your Mac. Even so, it could take several days before it was complete and FileVault became active.

This improved with time. Intel CPUs gained instructions to accelerate encryption and decryption, storage and processors got faster, and Apple’s new file system APFS has encryption designed into it from the start. What transformed FileVault, though, was the introduction of the T2 chip in 2017.

The T2 chip was designed for FileVault, among its other accomplishments. It contains a Secure Enclave to isolate and protect encryption keys, and a hardware AES encryption/decryption engine that sits between the internal SSD controller and memory. Those ensure that the contents of the internal SSD can be encrypted for FileVault without any detectable overhead. From Big Sur onwards, these are used to encrypt the whole contents of the Data volume when it’s in internal storage, but not the System volume or the SSV from which the Mac boots.

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.

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 means that the primary user’s FileVault password is the same as their regular login password. It doesn’t have to be long and complicated either, as it’s combined with the hardware key to create the KEK.

This has several important benefits. When you first turn FileVault on, no data encryption is needed, as the VEK remains the same, so FileVault’s protection is effective immediately. Because 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.

Recovery keys

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.

When you enable FileVault, you’re given the option of being provided with a recovery key, which you should keep a copy of in a safe place, or using iCloud recovery if you prefer.

In the recent past, some macOS updates have played games with recovery keys, issuing new ones when they weren’t expected. When you first get your recovery key, and any time it changes, you should check to see if it will work correctly. Once your Mac is running fully, open Terminal and type in the command
sudo fdesetup validaterecovery
After entering your admin password, you’ll then be prompted to enter the recovery key to be checked. Type or paste that in carefully, and you’ll be told whether it’s correct or not. Note that Terminal doesn’t display the key when you type or paste it in, and you’ll have to press Return without being able to see or check what you’ve entered. If that new key fails, repeat the command using your previous recovery key instead.

FileVault on other disks

The Secure Enclave and AES engine are only wired up to protect volumes on your Mac’s internal SSD. You can still enable FileVault on bootable external disks, and even in macOS virtual machines. But in those cases, volumes that are protected use Encrypted APFS in software, which does impose a small overhead. In the case of VMs, FileVault is the only effective way to safeguard data in that VM, and is recommended. For external disks you’ll need to weigh up the pros and cons.

Summary

• FileVault in modern T2 and Apple silicon Macs is very different from in the past.
• It now provides excellent cost-free protection to your data when stored on the internal SSD.
• If you opt for a recovery key, check it then and whenever it has changed.
• If your T2 or Apple silicon Mac doesn’t have FileVault enabled, why not?

Some who use SilentKnight for the first time discover that their Mac has been running for months with one of its security systems disabled. As macOS doesn’t have a dashboard to warn you of such dangerous settings, you may not notice until it’s too late. This article explains how to check those essential security settings on Macs with T2 or Apple silicon chips, and how to put them right. Intel Macs without T2 chips are different, and are covered in a previous version.

Secure Boot

Running your Mac in Full Security ensures it gets full protection from its Secure Boot technology. In an Apple silicon Mac this prevents it from loading third-party kernel extensions, and requires recent approved versions of macOS. Check this in System Information by selecting the Controller item in its Hardware section, or in SilentKnight.

This is controlled in Startup Security Utility, accessed from Recovery. Note that it only works with the paired Recovery system, the one you normally use; Apple silicon fallback Recovery doesn’t have this ability.

If you need to run kernel extensions or other software that can’t be loaded in Full Security, use Startup Security Utility to set the Mac to Reduced Security, and enable kexts. Avoid doing this if at all possible.

Settings are different for Intel Macs with T2 chips, where there are three levels of boot security, and the most common reason for reduction from Full Security is to enable that Mac to boot from external drives, something that Apple silicon Macs can do in Full Security.

System Integrity Protection (SIP)

Since El Capitan, macOS has protected all its system files, even down to bundled apps, using System Integrity Protection. This should make it impossible for malware or other software to change those protected files. SIP is also required for a wide range of other security protection, and should be fully enabled unless you have a compelling reason for disabling it partially or completely. In Apple silicon Macs, its status is reported in System Information’s Controller item, but Intel Macs instead give it in the Software section. It’s also checked by SilentKnight and Skint.

You can turn SIP off, something very occasionally needed to perform certain essential tasks. Doing so requires you to start up in Recovery mode, enter a command in Terminal there, and restart; Apple silicon Macs also need to have their boot security reduced in Startup Security Utility before SIP can be disabled.

To enable SIP, start up in Recovery mode, open Terminal, and type the following command:
csrutil enable; reboot
Once that’s done your Mac will restart in normal mode, and you should confirm that SIP is reported as enabled.

If you ever do need to disable SIP, do yourself a favour and put a sticky note on your Mac’s display to remind you to turn it back on.

Gatekeeper/XProtect

Gatekeeper runs checks on apps when they’re opened, and those can include scans for known malicious software using XProtect. As part of your Mac’s frontline protection against malware, you should leave those enabled unless there’s a compelling reason to temporarily disable them. However, I don’t know of anywhere in the macOS GUI that informs you whether these checks are being performed, although they are reported by SilentKnight and Skint.

If it has been disabled, you may be able to enable it using the command
spctl --enable
but chances are that you will instead need to invoke
sudo spctl --global-enable
requiring you to authenticate using your admin password. Be careful with those commands: the hyphens before enable and global-enable aren’t long dashes, but two separate hyphens.

Signed System Volume (SSV)

When you install Big Sur or later, the vast majority of its system files are saved in its System volume. For your Mac to boot from this, it has to be turned into a snapshot, sealed using a tree of cryptographic hashes, and the master seal ‘signed’ by a hash, which is compared against that set by Apple. This signed system volume is extremely secure and thoroughly reliable. On Intel Macs, this is only reported in Disk Utility, but Apple silicon Macs list it in System Information as well. It’s also reported by SilentKnight and Skint.

The SSV should always be enabled. If it isn’t, you’ll need to re-install macOS.

FileVault

Intel Macs with T2 chips and Apple silicon Macs encrypt the whole of the Data volume on their internal SSD. By default, that uses an internally-generated key that’s used automatically when any user logs in. Although it provides good security in most situations, you’re far better off enabling FileVault, as that protects the encryption key with your password as well. This imposes no overhead on accessing encrypted data, and provides valuable protection for your data at no cost.

Check whether FileVault is enabled in Privacy & Security settings, where you can enable it if it’s not already turned on. SilentKnight checks it as well.

macOS and firmware

To ensure your Mac and its apps are best protected from malware, keep its firmware and macOS up to date. As those are updated together, Macs with T2 or Apple silicon chips that are running the most recent release of their major version of macOS will also be running the current firmware, which no longer needs to be checked separately. Check the version of macOS in the About This Mac command at the top of the Apple menu.

Apple lists current supported versions of macOS on its Security Releases page. Those, and versions of security data software, are also listed and detailed here on this page.

If your Mac is running an older release of macOS and its firmware, update them together using Software Update in General settings.

XProtect Remediator scans

This anti-malware scanner performs automatic background scans to detect and remove a wide range of malicious software. It’s normally scheduled to run at least once a day, when your Mac is awake but not busy, and supplied with mains power. You’re wise to check that its scans are being run correctly, and will probably want to know if it has detected and remediated any malware. SilentKnight and Skint run a quick check of its activity over the previous 36 hours, and XProCheck provides detailed reporting and analysis.

Over the last year or so, XProtect Remediator has been using a timer during its scans, and automatically cancelling them if a scan takes longer than allowed. On many Macs, most scans are terminated early, and that results in warnings from SilentKnight and Skint. If you’re concerned, check the reports in XProCheck, where you’ll see that plugin was cancelled with a status_code of 30, as is typical with the timer.

Check:

• the Mac boots in Full Security, if possible,
• SIP is enabled,
• Gatekeeper/XProtect is enabled,
• it has booted from an SSV,
• FileVault is enabled,
• it’s up to date with macOS,
• XProtect Remediator scans are taking place daily.

SilentKnight does all of those and more.

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.

With careful observation and a little knowledge of the startup sequence of an Apple silicon Mac, you can learn a lot about what can and can’t happen during that sequence. This article explains how, with examples from the log of a Mac mini M4 Pro.

In broad terms, startup of an Apple silicon Mac consists of the following sequence of events:

• Boot ROM, which ends in DFU mode if there’s a problem, otherwise it hands on to
• the Low-Level Bootloader (LLB) and iBoot (Stage 2), the firmware, that should end in validating and running
• the kernel, which initially runs on a single CPU core before starting others up and launching launchd, and later
• unlocking and accessing the Data volume, and progressing to
• userspace.

The opening entry in the log is the boot announcement of
=== system boot:
followed by the boot UUID. There’s then a gap of 5 seconds or more before the next entry, which marks the start of kernel boot. Those seconds are the silent phase during which the LLB and iBoot are doing their thing. They don’t write to the Unified log, but leave fragments of cryptic information known as breadcrumbs, which you can’t make use of. The kernel then writes its usual welcome of
kprintf initialized
and the following four seconds or so are filled by log entries from the kernel.

Wallclock adjustment

During this phase, the system clock is synchronised, and wallclock time adjusted, usually twice in rapid succession. This is obvious by step changes in timestamp, usually putting the clock back by several seconds in the first sync, then putting it forward slightly in the second. These play havoc with the timestamps, as you can have two or even more instances of the same time being recorded in the log. Beware of the entries
=== system wallclock time adjusted

Early during the kernel phase, it starts up all the other CPU cores in the chip, and records that in the log. Entries become progressively more varied after launchd is loaded, and this first userspace boot (without Data volume access).

Data volume unlock

With FileVault enabled, by this stage macOS still doesn’t have access to the Data volume. That means all the code run so far, and almost all the data, are immutable, locked in the firmware or the Signed System Volume (SSV). The firmware does access LocalPolicy from another container in the internal SSD, and there’s always the NVRAM, but there’s no access to anything in /Library, including the many property lists there. This also means that processes running before the Data volume is unlocked and mounted can’t write to storage.

Around 10-15 seconds after the start of booting, the login window is displayed, ready for the user to enter their password. Once that has been entered, there’s a watershed moment:
30.845097 com.apple.loginwindow Attempting to unlock the data volume <LFVolume: 0x6000001b8e40: [UUID]: Data>
30.883172 "AppleSEPKeyStore":3814:0: Sending notification for volume [UUID] unlocked (action 1, handle -842987934)
30.885459 com.apple.login volume <LFVolume: 0x6000001b8e40: [UUID]: Data> was unlocked
30.886129 com.apple.loginwindow Unlocked data volume <LFVolume: 0x6000001b8e40: [UUID]: Data>
30.886154 com.apple.loginwindow FileVault volume unlocked, allow authorization
30.887562 com.apple.loginwindowLite -[LWLSystemUnlock unlockSystem]:439: Authorization was successful
30.887587 com.apple.loginwindowLite -[LWLSystemUnlock unlockSystem]:447: logging in user hoakley
The times on those entries were deliberately delayed, as I pressed the Return key for password entry after 30 seconds had elapsed, a good 10 seconds later than I could have done so.

Shortly after that, the kernel manager shuts down, a great many kernel space processes are handed over to continue in userspace, and you’ll then see the kernel report
userspace boot

Before the Data volume is unlocked, log entries are frequent, but hardly a torrent, at around 1,000 per second, and more than 25% of them are written by the kernel. Once the kernel has booted userspace and the Data volume is accessible, log entries are written far more frequently, at an average rate of 5,000 per second, often even higher, with less than 10% of them coming from the kernel.

Phase summary

• Boot ROM, entering DFU mode or handing over to
• Low-Level Bootloader (LLB) and iBoot (Stage 2) firmware, without log entries, handing over to
• the kernel, with wallclock adjustments, until
• Data volume unlocking, then into
• userspace and access to /Library and user files.