babgond

I recently gave a talk on how FileVault works on Apple Silicon Macs running macOS Tahoe. As part of doing the research for it, one of the things which stood out to me is how Apple has designed encryption at rest protection for Apple Silicon Macs. If you’re using an Apple Silicon Mac, most of those protections are enabled out of the box for you even if you’re not using FileVault. That’s not me saying to skip enabling FileVault, it’s a recognition of how much work Apple has put into making sure that its devices are protected regardless of the device owner’s decision making. For more details, please see below the jump.

Every Apple Silicon Mac comes equipped with the following:

• Hardware encrypted internal SSD
• Secure Enclave
• AES Engine built into the data path between the SSD and main memory

At the Secure Enclave’s manufacturing time, two keys are created:

Hardware key:

• Unique identifier for device
• Generated by the Secure Enclave’s own true random number generator.
• Written to on-chip fuses through a process that runs entirely within the Secure Enclave.
  • This ensures the UID is never exposed outside the device and is not accessible to Apple, its suppliers, or anyone else.

xArt key

• Generated by xART (eXtended Anti-Replay Technology) – a set of services built into the Secure Enclave specifically to prevent replay attacks.
• Created as a random number

Both keys combine to form the Volume Encryption Key (VEK) that protects the data on the internal SSD’s APFS storage. All three keys stay resident entirely within the Secure Enclave and never leave it.

The AES Engine is then used to handle the encryption and decryption of data. This component is tied to the Secure Enclave using a dedicated isolated hardware connection, which allows the Secure Enclave to securely supply the AES Engine with the required keys. As mentioned earlier, the AES Engine sits directly on the data path between the SSD and main memory. This allows the following:

• Data stored on the SSD flows into the AES Engine before going to main memory.
• The AES Engine handles decryption, using keys supplied by the Secure Enclave, before sending data to memory.
• Data stored in memory flows to the AES Engine before going to the SSD.
• The AES Engine handles encryption, using keys supplied by the Secure Enclave, before sending data to the SSD.

With FileVault not enabled, the key structure looks like this:

What happens when FileVault is not enabled?

• Secure Enclave generates a Volume Encryption Key (VEK) using the Hardware key and the xArt key
• Hardware key is provided automatically by the Secure Enclave to unlock the VEK at the Mac’s boot time.

Effective outcome

• Data stored on the internal SSD is protected against access in the event that the drive is removed and someone tries to read it.
• The Hardware key is required to unlock the drive’s encryption and that key is only stored in that specific Mac’s Secure Enclave.
• There are no additional authentication steps needed to unlock the encryption.

This sounds like decent protection by itself, but Apple strengthens it further when you turn on FileVault. What happens when FileVault is enabled?

Before you turn on FileVault:

• Internal SSD is already encrypted
• VEK is protected only by the Hardware key

When you turn on FileVault:

• Your account’s password is used to create a derived key.
• The key derived from your account’s password is sent into the Secure Enclave and combined with the Hardware key to create a new Key Encryption Key (KEK).
• A new VEK is generated, with the KEK used to unlock the VEK
  • This means that the VEK protecting the SSD’s data moves from one protected only by the Hardware key to one now protected by a combination of the derived key from the user’s password and the Hardware key.
• The existing VEK (which was protected only by the Hardware key) is invalidated.
  • The xART anti-replay protections ensure that the previous VEK can’t be used later to unlock the encryption.
• A recovery key is created in the form of a 24 character random alphanumeric string. This is a derived key similar to the one generated from your user account’s password and the KEK is rewrapped to allow this derived key to also unlock the KEK (and thus the VEK.)

Note: All keys involved and their handling, with the exception of the derived keys created from the user account’s password and the recovery key, stay entirely within the Secure Enclave.

With FileVault enabled, the key structure now looks like this:

Effective outcome

• Unlocking the Mac’s data encryption changes from using something inherent to the Mac (the Hardware key) to also now requiring something you need to provide (your account’s password or the recovery key.)

This change from “something the device already has” to also include “something you provide” is the key difference for data protection between having FileVault enabled or not. It takes protection that’s already strong on Apple Silicon and makes it meaningfully harder for anyone who gets physical access to the drive.

For those who wanted a copy of my FileVault talk at Penn State MacAdmins 2026, here are links to the slides in PDF and Keynote format.

• PDF: https://tinyurl.com/PSUMacAdmins2026PDF
• Keynote: https://tinyurl.com/PSUMacAdmins2026Keynote

As part of the release of Jamf Pro 11.29.0, the ability to run software updates using DDM is available for folks using on-premise installations of Jamf Pro. Information about this is available via the link below:

• Support for Managed Software Updates via Declarative Device Management for Self-Hosted Instances: https://learn.jamf.com/r/en-US/jamf-pro-release-notes-current/Support_for_Managed_Software_Updates_via_Declarative_Device_Management_for_On-Premise_Instances

This change is in response to Apple’s announcement last year that MDM-based Software Update management options were deprecated on macOS Tahoe. Apple’s recent followup announcement that MDM-based Software Update management options no longer work on all Apple 27.0 operating systems underscores the need for DDM-based software update options to be available. 

DDM software updates in 11.29.0 are part of the Software Updates section of Jamf Pro. For on-premise Jamf Pro users, it is the Download and schedule to install option.

All other software update options listed in the Software Updates section are using the MDM commands which no longer work on any of Apple’s 27.0 operating systems.

For more information about how to use the Download and schedule to install option, please see the following link:

• Updating macOS Using Managed Software Updates: https://learn.jamf.com/r/en-US/jamf-pro-documentation-current/Updating_macOS_Using_Managed_Software_Updates

As part of the release of macOS Tahoe, Apple deprecated the MDM-based Software Update management options and said that they would be removed the following year.

Apple has carried through on this and announced publicly that legacy software update management no longer functions in all Apple 27.0 operating systems. This announcement was posted as part of the following documentation:

• WWDC26 device management updates: https://support.apple.com/guide/deployment/device-management-updates-depd638aa061/1/web/1.0 (see the Software update command removal section.)

What this means is that the only Software Update management settings which work on Apple 27.0 operating systems are those which are using declarative device management:

https://developer.apple.com/documentation/devicemanagement/softwareupdatesettings

For those who want to use Jamf Pro’s Blueprints to manage Software Update settings using declarative device management, I have a post on how to do this available via the link below:

https://derflounder.wordpress.com/2025/06/24/deploying-software-update-management-using-blueprints-in-jamf-pro/

Self Service+ 2.23.0 (released on June 8 2026) includes new options for customizing how Self Service+ appears to users. The documentation for these options is available via the following links:

• Configuring Self Service+ Administrator Controls: https://learn.jamf.com/r/en-US/self-service-plus-documentation/Configuring_Self_Service_Administrator_Controls
• Administrator Controls Configuration Profile Example: https://learn.jamf.com/r/en-US/self-service-plus-documentation/Administrator_Controls_Configuration_Profile_Example

One of the customization options called out in the release notes for Self Service+ 2.23.0 is whether or not the Self Service+ menubar icon is visible in the menubar.

For more details, please see below the jump.

You can use the new Self Service+ administrator controls to configure the Self Service+ menubar icon to be hidden using a configuration profile. The example profile shown below includes the necessary settings to enforce hiding the Self Service+ menubar icon:

Before the profile’s installation, the Self Service+ icon appears in the menubar.

Once the profile is installed, the the Self Service+ icon no longer appears in the menubar.

I noticed the following 9to5Mac article by Ben Lovejoy and was interested to see that there was a solution for menubar spacing which could be applied using the defaults command line tool.:

https://9to5mac.com/2026/05/22/how-to-stop-menu-bar-items-being-hidden-behind-the-macbook-pro-notch/

From the article, the following commands can be used to set menubar spacing to an integer value of 8 (half the default spacing of 16):

To revert back to the default spacing of 16:

Note: I needed to log out and log back in to see the menubar spacing changes.

These defaults commands are setting user-level global preferences, which are manageable via a configuration profile. Since this is the case, I decided to see if that meant menubar spacing is manageable via a profile. It is. For more details, please see below the jump.

The following profile matches the behavior of the defaults commands referenced earlier, where menubar spacing is set to an integer value of 8 (half the default spacing of 16):

Before profile installation (macOS is using default menubar spacing of 16):

After profile installation (menubar spacing is set to an integer value of 8, half the default spacing):

As with the defaults commands discussed earlier, I needed to log out and log back in to see the menubar spacing changes applied by the profile.

As a follow-up to my previous post on reporting on Jamf Pro API clients and assigned API roles, I decided to see if I could write a similar script for reporting on the permissions assigned to Jamf Pro local user accounts. With this in mind, I’ve written a script which reports the following:

• The current list of the Jamf Pro user accounts on a Jamf Pro server
• The permissions assigned to those user accounts
• Whether those permissions are assigned directly to the account, or if they are permissions assigned to the account because it is a member of a Jamf Pro user group.

For more details, please see below the jump.

The script is named Jamf_Pro_Local_Account_Permissions_Report.sh and is available via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/main/rtrouton_scripts/Casper_Scripts/Jamf_Pro_Local_Account_Permissions_Report

This script connects to the Jamf Pro Classic API on a Jamf Pro server and reports which Jamf Pro user accounts have which permissions assigned, along with how those permissions are assigned (direct assignment to the user account, or via membership in a user group.)

Three items are required to use this script:

• The URL of the appropriate Jamf Pro server.
• An API client on the Jamf Pro server with sufficient privileges to read the necessary information from the Jamf Pro Classic API.
• The client secret for the relevant API client on the Jamf Pro server.

If setting up an API client with limited rights, here are the required API role privileges for the API client on the Jamf Pro server:

• Read Accounts

The report should include the following information:

• Account Name
• Account ID
• Account Enabled / Disabled
• Privilege Category
• Privilege Name
• Assignment Type

In this example, I have the following Jamf Pro user accounts set up on a Jamf Pro server:

• backup_admin_user_failover
• computer_deletion_service_account
• it_audit_service_account
• jamfpro-enroll

How permissions are assigned to the user accounts:

• backup_admin_user_failover: Member of the Administrator Permissions Group, which has the Administrator privileges set assigned to the group.
• computer_deletion_service_account: Permissions are directly assigned to the user account.
• it_audit_service_account: Member of the Auditor Permissions Group, which has the Auditor privileges set assigned to the group.
• jamfpro-enroll: Member of the Enrollment Permissions Group, which has the Enrollment privileges set assigned to the group.

With the example conditions, you should see similar output to what’s shown below when using the Jamf_Pro_Local_Account_Permissions_Report.sh script to generate a report:

As part of the script’s run, a report will be generated and you’ll be notified of where it is stored. The report will be in TSV format and appear similar to what’s shown below: