If your Mac starts to boot but doesn’t get as far as displaying the login window, one of four things should happen:

• if it has been upgraded to macOS 26 Tahoe or later, it might restart into Recovery Assistant;
• it might restart, and repeat the same sequence again;
• it might simply freeze and go no further;
• it might shut itself down again.

The second of those is the most urgent, as it’s in a boot loop, and you need to force it to shut down by pressing and holding the Power button. Although macOS should limit the number of boot loops, don’t leave it to continue looping. If your Mac appears to have frozen, wait for up to an hour before forcing it to shut down, as it could be in the middle of checking and repairing disks, which you shouldn’t interrupt in case it proves successful.

Recovery Assistant

This is a new feature in Tahoe, and uses latest data from Apple to try to recover your Mac automatically. For it to do that it requires an internet connection, preferably over Wi-Fi.

Distinctive to its opening window is its first aid symbol ⊕. Click on the Continue button to move on, and follow its instructions. At the end of that, you should see one of three outcomes:

• no problems were found, and you can restart your Mac back into normal mode;
• problems were found and repaired successfully, so you can restart your Mac back into normal mode;
• problems were found but aren’t fully repaired.

When your Mac restarts, it may show a notification that you need to recover iCloud data. If so, open System Settings and you should see a new item in its sidebar to Recover iCloud Data.

If that doesn’t fix your Mac, you’ll almost certainly need to start up in Recovery and try to fix it there.

Boot loops and freezes

Boot loops happen when a kernel panic occurs during the boot process, before the login window is displayed. When the Mac tries to restart as a result, it hits the same kernel panic, and starts the cycle again. Boot freezes are the opposite: instead of repeatedly cycling through reboot-panic, the boot process comes to a complete halt, normally showing a stuck progress bar on the display. Thankfully neither is in the least common, and should have become even rarer with the introduction of the Signed System Volume (SSV) in Big Sur and later, and the deprecation of third-party kernel extensions.

What you do next on an Apple silicon Mac depends on whether it’s trying to load third-party kernel extensions. As Intel Macs don’t enjoy the same secure boot process, dealing with them is more difficult.

When an Apple silicon Mac is running at Full Security, the only kernel extensions that it loads are those provided in macOS, whose integrity is checked during the boot process. Any third-party kernel extensions included in the Auxiliary Kernel Collection in /Library/KernelCollections remain untouched. Likely causes of kernel panics during booting in Full Security mode include failure of validation of the on-disk root hash of the SSV, and hardware faults or errors, either internal or external.

An Apple silicon Mac running at Reduced Security can load third-party kernel extensions from the Auxiliary Kernel Collection in /Library/KernelCollections when that is explicitly enabled in Startup Security Utility. In the absence of any more probable reason for a kernel panic occurring during booting, it should be assumed that the cause is a third-party kernel extension, and that should be disabled in Recovery mode. This can only be done in paired Recovery, following a single long press of the Power button, not in fallback Recovery.

Restarting in Full Security should then complete normally, and allow the third-party kernel extension to be updated or uninstalled as needed.

Diagnostics and Recovery

In most cases, boot loops and freezes are best assessed by disconnecting all suspect peripherals, running Diagnostics and Disk Utility’s First Aid in paired Recovery mode. If that isn’t available, then Fallback Recovery can be used instead. Unfortunately, the most valuable diagnostic tool for kernel panics, the panic log, usually isn’t accessible when a panic has occurred during boot, although it may be shown when you get the Mac to start up normally again.

Before starting up in Diagnostics, disconnect all peripherals, except those that are essential such as keyboard, mouse/trackpad and any primary external display. Ensure a good Wi-Fi network connection can be made. If the problem occurred when trying to boot from an external disk, or if that Mac had previously been booting from one, it may be better to leave that connected; historically, some older combinations of firmware and macOS panic when an external boot disk has been disconnected but is still expected for the next boot.

On Apple silicon Macs, Diagnostics is unique in relying on a hidden key combination: at the initial Recovery screen, hold Command-D until the Diagnostics Loader starts. This may require download of the disk image from Apple’s servers before testing can proceed. Once loaded, there’s a hidden option for extended diagnostics that can be triggered by holding the Command-E key combination.

Disk Utility is accessed as usual from the main Recovery window.

Advanced tools

Previous tools for the management of kernel extensions included kextload, kextunload and others. In Big Sur and later, these have been replaced by a single command tool kmutil, which is inevitably complex to use. Full details are given in its man page, which is extensive and an excellent source of additional information.

There are at least four kmutil commands that could prove useful:

• kmutil trigger-panic-medic, only available in recoveryOS, clears the AKC at /Library/KernelCollections and forces it to be rebuilt, requiring each kernel extension to be re-approved before it can be loaded. This is intended to be used to recover a system following a kernel panic generated by one of the kernel extensions in the AKC.
• kmutil inspect lists all currently installed kernel extensions according to their collection.
• kmutil clear-staging clears the contents of the staging directory /Library/StagedExtensions.
• kmutil unload -p /path/kextname.kext unloads the kernel extension specified by /path/kextname.kext. This terminates and unloads it, but doesn’t remove the original kernel extension or any staged copy. Unless you also remove the kernel extension and remove it from its collection, it’s likely to load again at the next boot.

In theory, removing the original kernel extension by removing the app which contains it, or deleting it from /Library/Extensions, should trigger kernelmanagerd to remove it from the Auxiliary Kernel Collection and the staging directory /Library/StagedExtensions. However, that won’t take effect until after the next reboot. If the kernel extension isn’t then removed, it may be worth using kmutil clear-staging, and if necessary kmutil trigger-panic-medic in Recovery mode. Remember that kernel extensions may be left unused in staging, and are protected there by SIP, making manual removal tedious at best, and possibly pointless.

While system extensions shouldn’t cause kernel panics or freezes during the boot process, the command tool available to manage them is systemextensionsctl. You can use
systemextensionsctl list
to list all known system extensions and their status.

To remove an orphaned system extension, with SIP already disabled, first list those known using
systemextensionsctl list
to provide the teamID and bundleID. Then use those in the command
systemextensionsctl uninstall teamID bundleID
and don’t forget to re-enable SIP immediately afterwards.

Reinstalling macOS

Historically, reinstalling macOS has often been advocated as a means of addressing boot loops and freezes. In Macs that perform full checking of the integrity of the SSV, Intel Macs with a T2 chip and Apple silicon models, that’s generally unwarranted.

Another option worth considering might be starting up in Safe mode, as that blocks the loading of most third-party components that could cause conflicts before the login window is loaded.

Reviving firmware

One well-known if rare cause of boot looping is a problem with firmware. For Intel Macs with T2 chips and Apple silicon Macs, the preferred solution to that is to boot the Mac in DFU mode, connect another Mac running a recent version of macOS, and perform a Revive from there. This is non-destructive of the SSV and Data volume, unlike a full Restore. Apple provides detailed instructions for you to do this yourself, provided you have the necessary second Mac and cable.

The cable used mustn’t be Thunderbolt, but plain USB-C. That’s because DFU mode doesn’t support Thunderbolt or its cable. Connect that to the designated DFU port on the Mac you’re going to Revive. That can be found in Apple’s note, or in Mactracker.

Summary

• If it starts up in Recovery Assistant (Tahoe and later only), ensure an internet connection and continue with that.
• If it’s stuck in a boot loop, force shutdown with the Power button, and disconnect all non-essential peripherals.
• If it appears frozen, leave it up to an hour in case it’s repairing its disk, before forcing shutdown.
• Try starting up in Recovery.
• For Apple silicon Macs in Reduced Security, disable loading of third-party extensions and set it to Full Security in Startup Security Utility.
• Consider running hardware Diagnostics.
• On Intel Macs consider kmutil trigger-panic-medic in Recovery.
• Try Revive in DFU mode to refresh firmware.
• Good luck!

In the last few months I have had reports from several whose Macs have experienced a “SEP Panic” rather than a regular kernel panic. Although the immediate effects are the same, and my previous advice on how to deal with a kernel panic still applies, this article looks in more detail at what should be exceedingly rare events.

Essentials

If your Mac restarts or shuts down spontaneously, or ‘freezes’ for you to force it to shut down, chances are that was a kernel panic. When it starts up again, look out for the dialog inviting you to send a report to Apple. Expand that so you can see the panic log, copy and paste that into a text document, and save it. That’s the only record you have of that report, and that provides valuable clues as to what went wrong and how you might go about fixing it.

Apple will not contact you in response to sending the panic log. If you want advice or assistance about your Mac, contact Apple Support, and ensure you have your copy of the panic log ready, as they’ll need to see it.

Secure enclave

No matter how secure you try to make an operating system, if its most precious secrets are being processed by the main CPU cores, an attacker will find a way to access them. The proven solution to this is to build in a separate part of the chip with its own processor, and isolate that from everything else – a secure enclave, with its own secure enclave processor, SEP, as patented by Apple 13 years ago.

Two Mac architectures have secure enclaves and SEPs: Intel Macs with T2 (and T1) chips, where the SEP is in the T2/T1, and Apple silicon Macs, where the SEP is an integral part of the chip. These handle several different security features, including biometrics in Touch ID, management of secure encryption keys including those for FileVault, and performing encryption and decryption for the internal SSD.

The SEP runs its own operating system, sepOS, thought to be a derivative of L4, and communicates with the rest of the chip using mailboxes. When the CPU needs something from the SEP, it posts a message in the SEP mailbox, then retrieves the response when the SEP has processed that request.

What could possibly go wrong?

Like all processors, the SEP can hit problems that it can only manage by a reset, and those will result in it panicking, which in turn provokes the kernel running on the CPU to panic. Those problems can result from anything from a hardware fault to a bug in sepOS.

The SEP in a T2 chip is also known to be vulnerable to some exploits including blackbird, which can be used to ‘jailbreak’ a device using checkra1n or with malicious intent.

Reading the SEP panic log

When a kernel panic is the result of a SEP panic, the panic log is different from normal, and contains considerable detail about the SEP and what went wrong with it. As usual, though, much of that information is cryptic to say the least.

The first line in the panic log confirms that the panic originated in the SEP
panic(cpu 1 caller 0xfffffe001f55e344): SEP Panic: […]

You’re then given the version of sepOS
Root task vers: AppleSEPOS-2772.140.4

Unfortunately, further down it disclaims knowledge of that
Firmware type: UNKNOWN SEPOS

The status of the SEP’s mailboxes are given
Mailbox status:
IDLE_STATUS: 0x00000008
INBOX0_CTRL: 0x00105601
OUTBOX0_CTRL: 0x00023301
and
Mailbox entries:
Unavailable
Mailbox queue pointers: […]

This is confirmed as a panic
Debugger message: panic

The version of macOS is given by build number, with details of the kernel running on the CPU
OS version: 24G90
Kernel version: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000
For a T2 chip, the kernel version given should be for a T8010
root:xnu-11417.140.69~1/RELEASE_ARM64_T8010

Apple silicon Macs should then confirm their iBoot versions, first the LLB (Stage 1) then iBoot Stage 2, and whether Secure Boot was used
iBoot version: iBoot-11881.140.96
iBoot Stage 2 version: iBoot-11881.140.96
secure boot?: YES

T2 SEPs don’t normally give an iBoot Stage 2 version, but provide information about the Intel (x86) host
iBoot Stage 2 version:
secure boot?: YES
roots installed: 0
x86 EFI Boot State: 0xe
x86 System State: 0x0
x86 Power State: 0x0
x86 Shutdown Cause: 0x5
x86 Previous Power Transitions: 0x20002000200
PCIeUp link state: 0x94721611

Information is provided about the task running on the CPU, which should normally be the kernel
Panicked task 0xfffffe1fb0037248: 0 pages, 654 threads: pid 0: kernel_task

Towards the end of the panic log are details about kernel extensions. In SEP panics, that includes the SEP Manager
Kernel Extensions in backtrace:
com.apple.driver.AppleSEPManager(1.0.1)[UUID]@0xfffffe001f5366e0->0xfffffe001f566a63
and
last started kext at 242997189818: com.apple.iokit.SCSITaskUserClient 500.120.2 (addr 0xfffffe001ce0f6a0, size 2206)
loaded kexts:
In the list of loaded kernel extensions that follows, ensure there are no third-party entries, unless your Mac is expected to load them.

Actions

Although you should take a SEP panic seriously, there’s no need to panic yourself. This doesn’t mean that your Mac’s SEP has died, has been attacked by malware, or has released all the secrets it protects. A single panic in isolation could well just be chance, and not indicative of anything serious.

Provided that your Mac starts up correctly and then runs normally, your only essential task is to ensure that you capture and keep a copy of the panic log. If you wish, you can run hardware Diagnostics, but I doubt whether that performs any specific test intended to detect problems in the SEP. If you have potentially problematic peripherals, or any third-party kernel extensions, then you should take the hint and try to eliminate them.

If your Mac suffers any further kernel panics, capture their panic logs, and contact Apple Support with those to hand. Alternatively, book your Mac into an Apple store or authorised service provider for them to check it out for you.

Summary

• SEP panics are exceedingly rare, but are readily identified from the first line of the panic log.
• Ensure you copy and save a copy of the panic log.
• Much of the panic log will appear meaningless, but there is some information about version numbers and kernel extensions that may be helpful.
• Follow the normal recommendations, considering hardware diagnostics, and updating/removing potentially troublesome peripherals and third-party kernel extensions.
• If there are any further panics, capture those and obtain support from Apple.

References

How to deal with a kernel panic (this blog)
Apple, Platform Security Guide
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.
Tarjei Mandt, Mathew Soling and David Wang (2016), Demystifying the Secure Enclave Processor, Black Hat USA 16 (PDF)
Blackbird SEP exploit, Apple Wiki.

I’m very grateful to Joe, Marc and another for sharing their SEP panic logs.