Interesting. I&#x27;m guessing that only gets used by minor &quot;feature&quot; updates (to e.g. Webkit, or iTunes), and not the full &quot;OSX Update 10.11.x&quot; releases.<p>My suspicion is for anecdotal reasons: I recently Internet-restored my MBP. This pushed it back down to OSX 10.11.0, so it had quite a few OS point-updates to go install. But before I let it do any of those, I enabled FileVault2 and let it finish encrypting. I then had the &quot;pleasure&quot; of watching this sequence of events repeat itself several times, a sequence of events which had never occurred before El Capitan:<p>1. The OS asks to restart to install an update.<p>2. The OS reboots and sits at the (UEFI?) drive-unlock pretend-login screen until I enter my password.<p>3. The OS boots into something that looks like my &quot;regular use&quot; OS—the Menu Bar appears, the cursor appears and starts working, and my regular wallpaper is rendered—but the Finder doesn&#x27;t start, nor do any of my account&#x27;s Startup Items or LaunchAgents (not sure about global LaunchDaemons.)<p>4. The screen (still with HID cursor control enabled!) gets covered in a fullscreen <i>window</i> (not a fullscreened app taking up a Space; wrong transition effect) that has the appearance of a big black screen with an Apple logo and a progress bar. You know, like the boot screen, or iOS&#x27;s update mode, or a Mac&#x27;s UEFI firmware update mode. But it&#x27;s definitely just an app, running within whatever instance of OSX this is.<p>5. Having completed the update, the computer reboots again, I enter my drive-unlock password again, and I&#x27;m back into my regular-use session.<p>---<p>Previous to El Capitan, OSX Update packages would trigger a much simpler process, equivalent to the process Windows currently goes through:<p>1. Ask the user to &quot;reboot&quot;;<p>2. instead of rebooting, stop all userland processes and enter a single-user&#x2F;maintenance runlevel;<p>3. run some special privileged (kext?) code that installs&#x2F;unpacks&#x2F;shoves the update and directly manipulates the framebuffer to render a progress bar;<p>4. actually reboot.<p>---<p>It wouldn&#x27;t make sense to change from the old process to the current one if it was just for the sake of putting the system into an SIP-disabled mode. Like you said, Apple-signed installers can flout SIP restrictions.<p>It only makes sense to add the extra reboot to the process if you&#x27;re rebooting into the recovery OS, because having the recovery OS do the work <i>is itself the goal</i>, rather than just an idea born out of necessity.<p>If you&#x27;re wondering about the &quot;still has my wallpaper&quot; part, though: it&#x27;s not unprecedented for the recovery OS to be &quot;fed&quot; data from the regular-use OS, so that there&#x27;s a continuity of control when you reboot into the recovery OS. For example, the recovery OS will receive a copy of any wi-fi AP keys you entered into the System keychain in the regular-use OS, so that you can re-install OSX even if you don&#x27;t remember your wi-fi password.<p>(I say &quot;will receive a copy&quot; instead of &quot;accesses&quot; because it gets these even if the regular-use OS is sitting in the FileVault2 &quot;locked&quot; state from the recovery OS&#x27;s perspective—or has already been blown away entirely—where it couldn&#x27;t possibly just mount the volume to read your System keychain. It seems to be more that the regular-use OS will push a copy of these thing over into the recovery OS when you update them.)