To enable this option, there is a /etc/pam.d/sudo_local.template file on macOS Sonoma and later which appears as shown below:

Copying the /etc/pam.d/sudo_local.template file to /etc/pam.d/sudo_local and uncommenting the indicated line allows Touch ID to work as authentication for the sudo tool.

A number of Mac admins have written scripts to apply this PAM configuration to Macs, but there didn’t seem to be a good way to handle this without scripting. However, as part of Apple’s unveiling of Declarative Device Management (DDM) at WWDC 2023, Apple announced that DDM management included the ability to manage sets of tamper-resistant system configuration files for different system services. As of this date, the following services built into macOS can be managed this way:

• sshd
• sudo
• PAM
• CUPS
• Apache httpd
• bash
• zsh

Jamf Pro’s Blueprints supports managing these services via the Service configuration files component. Since enabling Touch ID authentication for sudo is managed using a PAM configuration file, that means that enabling Touch ID authentication for the sudo tool can be accomplished via Blueprints. For more details, please see below the jump.

By default, macOS Tahoe 26.1 ships with a /etc/pam.d/sudo_local.template file that looks like this:

To prepare the desired PAM configuration, you can use the process described below:

1. Make a copy of the /etc/pam.d/sudo_local.template file to a convenient location.
2. Uncomment the last line
3. Save the file and rename it to a file named sudo_local.

The newly-created sudo_local file should appear similar to what’s shown below:

To deploy this change with Blueprints, three things are needed.

1. A zip file which contains both the directory and file structure of the configuration file in question.

The PAM configuration file is stored in the /etc directory, with a directory inside named pam.d, with a file inside the pam.d directory named sudo_local, so a zip file containing a directory named etc, with a directory inside named pam.d, with a file inside the pam.d directory named sudo_local, is needed for this.

For this example, we’ll name the zip file as enable_touch_id_for_sudo.zip.

2. The SHA-256 hash of the zip file

You can use the sha256sum command line tool to get the SHA-256 hash of the zip file, so using a command similar to the one shown below should provide that information:

Assuming our SHA-256 hash is 0ac032ffc0d173ec102ee2d580de2c7511ab59606a56239b8c9a0fd88452c368, you should see output like this when you run the command above:

3. A place to download the zip file from which allows downloading without authentication.

For this example, I’ve set up an S3 bucket in Amazon Web Services named 75d831079efb4d02ada44eed4f8ae093 and set the enable_touch_id_for_sudo.zip file to be publicly accessible from that S3 bucket.

Once I have all the above available, I can set up a Blueprint in Jamf Pro to deploy the Touch ID PAM configuration file as a Service configuration file.

1. Log into Jamf Pro.
2. Select Blueprints
3. Click on Service configuration.

4. Give it a name when prompted. For this example, I’m using Touch ID PAM Configuration.

5. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Touch ID PAM Configuration Deployment Group.

6. Provide the necessary information to download the enable_touch_id_for_sudo.zip file. For this example, the following information is being used:

• Data URL: https://75d831079efb4d02ada44eed4f8ae093.s3.us-east-1.amazonaws.com/enable_touch_id_for_sudo.zip
• SHA-256 Hash: 0ac032ffc0d173ec102ee2d580de2c7511ab59606a56239b8c9a0fd88452c368
• Service definition: PAM

Once everything has been configured, click the Deploy button to deploy the changes to the Macs you want to manage.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Touch ID PAM Configuration Blueprint as being deployed.

On your managed devices, you can verify that the new Touch ID PAM configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom. You should see a Device Declarations section, with a listing for Configuration Files: com.apple.pam.

If you click on the Configuration Files: com.apple.pam listing, it should provide the path to the tamper-resistant directory where it stored the new Touch ID PAM configuration file. This should be the following location:

/private/var/db/ManagedConfigurationFiles/com.apple.pam

Inside that directory will be the etc directory with a directory inside named pam.d, with a file inside the pam.d directory named sudo_local file that you configured for the Blueprint’s zip file. The complete file path to the new Touch ID PAM configuration should be the following:

/private/var/db/ManagedConfigurationFiles/com.apple.pam/etc/pam.d/sudo_local

You will not be able to write to this location, as it is protected by System Integrity Protection (SIP), but you should be able to read from the file and verify the contents are what’s expected.

You should also be able to verify that Touch ID authentication is now working when you use the sudo command line tool.

Hat tip to my colleague Matt Vlasach for coming up with and sharing this idea of enabling Touch ID authentication for sudo using Blueprints.

For those interested, all of the the JNUC 2025 session videos are available on YouTube, though it doesn’t appear that there’s a dedicated YouTube playlist at this point. For convenience, I’ve linked my session here.

Previously, the only option for deploying software update declarations via Blueprints was to specify an individual OS version. Now there is a new option for upgrading the OS version to the latest version a particular Mac can support.

For those familiar with Jamf Pro’s managed software update functionality, the new software update declaration functionality provides the following update options:

• Download and schedule to install
• Latest version based on device eligibility

The Latest version based on device eligibility functionality in the managed software update functionality tells the managed Mac to download and install the latest version of macOS that a particular Mac can support. The Blueprints software update declaration functionality provides that same experience, where you can do the following:

• Set that you want the managed Macs to update their OS version to the latest version of macOS a particular Mac can support.
• Set a deadline that you want to have your Macs updated by.

For more details, please see below the jump.

For this example, I have the goal of updating managed Macs to the latest available version of macOS. As of November 6 2025, that is the following version of macOS:

• macOS 26.1

I want to have them all updated within one day of the release of new OS versions, with the install time set as being 6:00 PM (18:00)

I can set up a Blueprint in Jamf Pro to deploy a software update declaration to enforce this using the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click on Update software to latest version.

4. Give it a name when prompted. For this example, I’m using Update to latest macOS version.

5. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Managed Software Update Deployment Group.

6. In the Software Updates section, I’m choosing the following settings:

• Enforcement type:
  • Latest OS version
• Days after release to enforce update:
  • 1
• Install at (local device time):
  • 18:00

7. Once all the information has been entered and verified to be correct, click the Save button.

8. Click the Deploy button to deploy the changes to the Macs you want to manage.

Note: The days after release refers to the date that the latest version was released. In the case of macOS 26.1, that was on the following date:

• November 3, 2025

By setting the Days after release to enforce update setting to 1 day, that means that Macs receiving this software update declarations will have this deadline to install macOS 26.1:

• November 4, 2025 at 18:00 (6:00 PM in the Mac’s local time zone)

Devices receiving the Blueprint will detect that they are past the deadline set by the software update declaration if the Blueprint is being deployed on the following date:

• November 6, 2025

In this case, the Mac will try to update as soon as possible and provide notifications that it is past the deadline for updating.

Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Update to latest macOS version Blueprint as being deployed.

Note: The options available via Blueprints for software declarations are the ones Apple has specified for software update declarations. For more information about this topic, please see the following link:

https://support.apple.com/guide/deployment/software-update-declarative-configuration-depca14ecd4d/web

On your managed devices, you can verify that the new service background task configuration has been deployed by clicking on the enrollment profile, then scrolling to the bottom. In the case of this example, you should see a Device Declarations section with a listing for Required Software Update. The Required Software Update listing will include the OS version number for the required update.

If you click on that listing, you should see the details of the software update declaration. In this case, since the latest available version of macOS is 26.1, that’s what is listed as part of the software update declaration.

From the user’s perspective, they should see a Notifications center notification appear with two available options:

• Details
• Update

When you click the Details button, you should see behavior similar to what’s shown below:

When you click the Update button, you should see behavior similar to what’s shown below:

Note: The video above has been edited to artificially reduce the amount of time the OS update took to run. Run time of the pre-edited video was 12 minutes 33 seconds.

I built a macOS 26.0.1 VM and saw the serial number appear.

I then upgraded the VM from macOS 26.0.1 to macOS 26.1.0. Poof, no more serial number.

After talking with colleagues in the Mac Admins Slack, I was pointed to a Known Issues entry for Virtualization in the macOS 26.1.0 release notes:

The serial number published for the virtual machine is 0, which prevents iCloud and related applications from functioning correctly. (163294564)

You can’t set a system serial number manually for macOS VMs running on Apple Silicon Macs, so it looks like this state of affairs is with us until Apple fixes it. Hopefully that is soon.

There is an alternative way to get this information though, as it is also available via the System Information app included with macOS. This information should be available regardless of whether the MDM-managed user account is logged in or not. For more details, please see below the jump.

In the System Information app, you can access information about the MDM-managed user account by selecting the Profiles section, then clicking on the MDM Profile listing. If this Mac has an MDM-managed user account, it should be listed as Managed User in the Other Info section at the end of the MDM Profile listing’s information.

In place of listing the account’s username, the Managed User information provides two items of information:

• The account’s assigned UUID identifier (also referred to as a GeneratedUID.)
• The account’s assigned user identifier (also referred to as a UID.)

This information can also be obtained using the system_profiler command line tool, where you should only need the account’s assigned UUID identifier in order to identify the account.

To get the UUID identifier information using the system_profiler tool, the following command can be run:

Running this command should provide output similar that shown below:

To get the account username, run the following command with the UUID identifier in the appropriate place:

Running this command should provide output similar that shown below:

Using this information, see below for an example script showing how you can get the account’s assigned UUID identifier and then use it to identify the managed user’s username:

Running the example script should provide output similar that shown below:

• ~/Library/Logs/JAMF/selfservice_debug.log

The Self Service+ app is sending its logging to the unified system log.  With the right predicates, you can retrieve Self Service+‘s logging when needed by using the log command line tool. For more details, please see below the jump.

The Self Service+ app uses a number of processes and logging subsystems, but you should be able to retrieve them using the following search predicates:

• Process contains: Self Service
• Subsystem starts with: com.jamf.selfserviceplus

For example, the following log command should get all Self Service+ related logging for the last ten minutes:

With log predicates, the ” : ” character can also be used in place of contains and the ”  :^  ” characters can be used in place of BEGINSWITH, so the following command should also work to get all Self Service+ related logging for the last ten minutes:

The resulting logging should look similar to what’s shown below:

If you want to search for logging that contains both logging predicates in common, the following log command should get all Self Service+ related logging which contains both for the last ten minutes:

The resulting logging should look similar to what’s shown below:

• What’s new for enterprise in macOS Tahoe 26: https://support.apple.com/124963

As part the KBase article, the following man page is referenced:

apple_ssh_and_filevault

This can be accessed using the following command:

For more details, please see below the jump.

To unlock FileVault on macOS Tahoe using SSH, you can use the procedure described below:

Pre-requisites:

• Second computer available which can run SSH.
• Target Mac must be using an Apple Silicon processor.
• Target Mac must be running macOS Tahoe or later.
• Target Mac must have FileVault encryption enabled.
• Target Mac must have SSH enabled.

1. Connect from the second computer to the target Mac using the username and network address of the target Mac.

For this example, the target Mac has the following account and network address:

• Account: username
• Network address: computername.local

In this example, the following command is being used to connect from the second computer to the target Mac using SSH:

2. When you connect, you should be informed that the target Mac is locked and that you’ll need to a local username and password to unlock it.

In this example, we’re connecting with the username of an account which is enabled on the Mac to unlock FileVault. Because of this, we should only need to provide the password for that account.

3. Once the password has been provided, the Mac unlocks FileVault and automatically closes the SSH connection between the second computer and the target Mac.

On the target Mac, you should see activity similar to this occurring on the login screen.

4. After a short amount of time, the target Mac should be unlocked. At this point, you should be able to connect again from the second computer to the target Mac using SSH and have access to all expected functionality.

• PDF: https://tinyurl.com/JNUC2025PDF
• Keynote: https://tinyurl.com/JNUC2025Keynote

• Preference domain: com.apple.SetupAssistant.managed
• Key: SkipSetupItems

Apple has the SkipSetupItems key set to store its settings in an array, as described below:

Why this is important is that the array and its list of strings is what’s being interpreted as the setting for the SkipSetupItems key in a management profile. This detail is important in itself because it can lead to multiple management profiles managing what macOS sees as the same setting.

In a case where you have two or more management profiles managing the same setting differently, you get what Apple calls indeterminate or undefined behavior. In a situation like this, macOS may randomly choose to apply one of the settings and ignore any others, or just ignore all of the settings. For more details, please see below the jump.

As an example, you may deploy a management profile to stop the Your Mac is Ready for FileVault screen from appearing.

In that case, there’s now a profile which is deploying the following setting in the SkipSetupItems array:

Later, you may choose to deploy a management profile to stop the Software Update Complete screen from appearing.

In that case, there’s now a management profile which is deploying the following setting in the SkipSetupItems array:

Once the second management profile to suppress the Software Update Complete screen has been deployed, you may now see the following behavior occurring randomly on the Macs it was deployed to:

• The Software Update Complete screen appearing.
• The Your Mac is Ready for FileVault screen appearing.
• Both the Software Update Complete and Your Mac is Ready for FileVault screens appearing.

The fix for this situation is to not deploy separate management profiles containing settings for the SkipSetupItems key. Instead, combine the settings into one management profile with multiple entries in the array. For example, to suppress both the Software Update Complete and Your Mac is Ready for FileVault screens, you would deploy a single management profile with the following settings in the SkipSetupItems array:

For macOS Tahoe 26.0, the following management profile should stop the following screens from appearing:

• Analytics
• Apple Intelligence
• Software Update Complete
• Update Your Mac Automatically
• Your Mac is Ready for FileVault
• Welcome

I have not found a way to suppress this screen using a defaults command, but it is possible to suppress the Software Update Complete screen on macOS Tahoe using a configuration profile. For more details, please see below the jump.

The relevant preference domain and key values are below:

• Preference domain: com.apple.SetupAssistant.managed
• Key: SkipSetupItems
• Value: UpdateCompleted

The profile is available on GitHub via the link below:

https://github.com/rtrouton/profiles/blob/main/SkipSoftwareUpdateCompleteSetup