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.