This setting does not appear to be manageable via MDM or DDM management as of this time, but it can be managed via the pmset command line tool. For more details, please see below the jump.

In the pmset man page , there is an autorestartatconnect setting which is listed as controlling this behavior. The autorestartatconnect setting can be set to an integer value of 0 or 1.

To turn on automatic restart on power connect, the following command should be run with root privileges:

To verify that the setting has been set, run the following command and see if it returns a value of 1.

In the Energy preferences in System Settings, you should see the Start up when power is connected setting is set to Always.

To turn off automatic restart on power connect, the following command should be run with root privileges:

To verify that the setting has been set, run the following command and see if it returns a value of 0.

In the Energy preferences in System Settings, you should see the Start up when power is connected setting is set to Never.

One thing that’s very important to know is that the personal recovery key information is not saved anywhere. You will need to make a record of it when it’s displayed or you will not have it later.

On macOS Tahoe, this recovery key information is not displayed when the same command is run:

However, the recovery key is created. This can be verified by running the following command and verifying that there is an entry for Personal Recovery User:

Here’s what the Terminal output looks like when you turn on FileVault using the fdesetup command line tool and then use the diskutil command line tool to check and see if there is a Personal Recovery User entry:

How to fix this? Fortunately, the fdesetup command line tool includes an option to output relevant information to plist format as part of turning on FileVault using the fdesetup command line tool’s enable option. This information includes the personal recovery key. For more details, please see below the jump.

For example, running the following command will turn on FileVault using the fdesetup command line tool and write a plist file which includes the recovery key to standard output:

Here’s what the Terminal output looks like when you turn on FileVault using the fdesetup command line tool and include the option of exporting to plist format:

The plist output includes the following lines for the recovery key:

In order to save the recovery key and other information stored in the plist to a file, you can run the following command:

Here’s what the Terminal output looks like when you turn on FileVault using the fdesetup command line tool and include the option of exporting to a file named recoverykey.plist which is stored in the /Users/Shared directory:

The recovery key information will not be shown in standard output, but the recovery key will be included in the contents of the /Users/Shared/recoverykey.plist file:

• Genmoji is disabled
• Image Playground is disabled
• Writing Tools are disabled
• Summarizing emails is disabled
• Disable third party cloud-based intelligence service integrations
• Disable non-anonymous login to third party cloud-based intelligence services
• Notes transcription summaries are disabled
• Apple Intelligence reports are disabled
• Mail smart replies are disabled
• Summarizing Safari content is disabled
• Force on-device only dictation

For more details, please see below the jump.

As of Jamf Pro 11.27.0, there is not a Blueprints template available for creating blueprints which manage Apple Intelligence settings so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. You should see an unconfigured Blueprint. Click where it says Untitled blueprint and provide a name.

For this example, I’m using Apple Intelligence Management Settings.

5. To manage all of the settings mentioned above, two components will be needed:

• External Intelligence Settings
• Intelligence Settings

Scroll down in the list on the left-hand side of the browser window to locate the External Intelligence Settings component.

6. Click on the External Intelligence Settings component and drag the External Intelligence Settings component to the Components in this blueprint section.

7. Scroll down in the list on the left-hand side of the browser window to locate the Intelligence Settings component.

8. Click on the Intelligence Settings component and drag the Intelligence Settings component to the Components in this blueprint section.

9. Once added to the Components in this blueprint section, click anywhere on the External Intelligence Settings component to open it for editing.

10. At this point, you will see the Apple Intelligence management settings. Select the following options to apply the following desired settings:

• Allow External Intelligence Integrations:
  • Select False
• Allow External Intelligence Integrations Sign In:
  • Select False

Once all choices have been made and verified, click the Save button.

11. Click anywhere on the Intelligence Settings component to open it for editing.

At this point, you will see all available Intelligence settings which are available for all Apple platforms. To limit to only those options available for macOS, you can click the filter button and then select macOS in OS Type.

12. At this point, you will see the Apple Intelligence management settings for macOS. Select the following options to apply the following desired settings:

• Allow Apple Intelligence Report:
  • Select False
• Allow Genmoji:
  • Select False
• Allow Image Playground:
  • Select False
• Allow Writing Tools
  • Select False

In the Apps section, select the following options to apply the following desired settings:

Mail:

• Allow Smart Replies:
  • Select False
• Allow Summary:
  • Select False

Notes:

• Allow Transcription:
  • Select False
• Allow Transcription Summary:
  • Select False

Safari:

• Allow Summary:
  • Select False

In the section under Apps, select the following option to apply the following desired setting:

• Force On-Device Only Dictation:
  • Select True

Once all choices have been made and verified, click the Save button.

13. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the arrow button.

14. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Apple Intelligence Settings Deployment Group.

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

16. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Apple Intelligence Management Settings Blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it. When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section, where you should see the following items listed:

• External Intelligence Settings
• Intelligence Settings

If you click on each item, you should see the details of what is being managed. In the case of our example, you should see the the following entries for External Intelligence Settings:

• Allow Integrations: No
• Allow Sign In: No

You should see the following entries for Intelligence Settings:

• Allow Apple Intelligence Report: No
• Allow Genmoji: No
• Allow Image Playground: No
• Allow Writing Tools: No
• Allow Mail Smart Replies: No
• Allow Mail Summary: No
• Allow Notes Transcription: No
• Allow Safari Summary: No
• Force On-Device Only Dictation: Yes

https://support.apple.com/126655

For more details, please see below the jump.

The key parts of Apple’s guidance are the following:

When is it happening?

In future versions of Apple’s various platform operating systems, which include iOS, iPadOS, macOS, watchOS, tvOS, and visionOS, Apple is going to be enforcing stricter controls on Transport Layer Security (TLS) connections. (These connections may also be referred to as Secure Sockets Layer (SSL) connections, as SSL is the now-deprecated technology that TLS was built on.)

This change could come as soon as the next major operating system release, which would mean the following operating systems:

• iOS 27
• iPadOS 27
• macOS 27
• watchOS 27
• tvOS 27
• visionOS 27

This does not necessarily mean that this change will be happening once those future operating systems have been released, but Apple is saying that it may happen at that time or at a later point in the future.

What’s affected?

• Mobile device management (MDM)
• Declarative Device Management (DDM)
• Automated Device Enrollment
• Configuration profile installation
• App installation, including enterprise app distribution
• Software updates

What’s that all mean? If I’m interpreting it correctly, it means that the tighter controls on TLS connections are going to be for communication between Apple devices and the following:

• MDM servers
• Apple’s Automated Device Enrollment service (part of Apple Business and Apple School Manager)
• Apple’s app deployment services
• Apple’s software update service

Apple is also explicitly saying there will be some exceptions to these tighter security controls. These exceptions are:

• Network connections to a Simple Certificate Enrollment Protocol (SCEP) server
• Network connections to an Apple content caching server

For those not familiar with SCEP, SCEP servers are intermediaries that sit between a certificate authority which issues digital certificates and the devices which use those digital certificates. In many enterprise environments which issue digital certificates to devices, an MDM server communicates with a SCEP server to get digital certificates for the devices the MDM server is managing, then provides those certificates to the devices which the MDM server is managing by putting the certificate in a configuration profile, then delivering that configuration profile using an MDM command.

Meanwhile, content caching servers are Apple’s solution which allows one device on your network to download Apple updates once and then share them locally with other devices. If there is a content caching server active on your local network, it is effectively a local copy of Apple’s software update servers which is available on your local network and allows you to save bandwidth by having your devices get their updates from that local copy in place of each device individually downloading their updates over the Internet from Apple’s software update service.

I don’t know why these exceptions for SCEP and content caching servers have been made, but my assumption is that Apple examined what would be involved in making these two exceptions also have to comply with the new standards and concluded that it either wasn’t possible or operationally too difficult at this time.

What’s changing?

Affected servers and services must:

• Support TLS 1.2 or later
• Use ATS-compliant ciphersuites
• Present valid certificates that meet ATS standards

OK, what’s all that mean? First, let’s talk about the requirement to enforce TLS 1.2 and later. TLS and the earlier SSL have gone through various versions, with cryptographic strength increasing and bugs being fixed in each new version. To summarize why Apple is requiring TLS 1.2 and later, it’s because older versions of TLS and the older SSL supported communicating using weaker encryption methods which are not supported in TLS 1.2 and later and were subject to vulnerabilities that TLS 1.2 and later are not vulnerable to. By mandating TLS 1.2 and later, Apple is closing off those vulnerabilities and weaker encryption methods by rejecting connections which continue to use these prior versions of SSL and TLS. For those who want to dig deeper into this topic, please see the links below:

https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/
https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data
https://blog.gigamon.com/2021/07/14/what-is-tls-1-2-and-why-should-you-still-care/
https://www.statuscake.com/kb/knowledge-base/why-you-should-still-use-tls1-2-and-not-just-tls1-3/

Next, what the heck is ATS? In this case, it’s App Transport Security (ATS). ATS is a network security feature developed by Apple for its platforms, which mandates that network connections meet certain standards or ATS blocks them. ATS has been used to secure network communication for apps and app extensions. Now with this advisory being published, it looks like Apple is now extending ATS to secure communication between devices and MDM servers along with Apple’s app deployment, Automated Device Enrollment and software update services. So what is ATS requiring?

First, ATS is checking the TLS certificate provided by an MDM server or Apple’s affected services. This certificate must meet the following requirements:

• Have an intact digital signature (this tells ATS that the certificate hasn’t been tampered with.)
• Be unexpired (this tells ATS that the certificate is still within the date range prior to the certificate expiring.)
• Certificate’s subject name matches the DNS name of the server in question
• Has a valid certificate chain (where ATS can verify that the certificate it’s examining was signed by another valid certificate, which may be signed by another valid certificate, and so on all the way back to a Certificate Authority (CA) which is itself trusted by the device.)

Once ATS has run these checks on the certificate, it then makes the following additional checks to verify the following:

• The server certificate must be signed with either a Rivest-Shamir-Adleman (RSA) key of at least 2048 bits, or an Elliptic-Curve Cryptography (ECC) key of at least 256 bits.
• The certificate must use the Secure Hash Algorithm 2 (SHA-2) with a digest length, sometimes called a fingerprint, of at least 256 bits (that is, SHA-256 or greater).
• Data must be exchanged using either the AES-128 or the AES-256 symmetric cipher.
• The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

What’s all this mean? Let’s break it down by each check:

• Certificate must be signed with either an RSA key with a minimum key length of 2048 bits (greater lengths are possible) or ECC key with a minimum length of 256 bits (greater lengths are possible). RSA is an older algorithm, where a greater key length is needed to provide better security. In contrast, ECC is a newer encryption approach which is able to provide equivalent security with a shorter key length. (For perspective, a 256-bit ECC key is equivalent to a 3072-bit RSA key.)

Why are RSA 2048-bit and ECC 256-bit set as the minimums? It’s the difference between “reasonably secure against attack” and “could be successfully attacked and protected communications exposed.” While shorter key lengths like RSA 1024-bit have not been publicly verified to be breakable, it is possible that nation-state adversaries with the resources available to them could break RSA 1024-bit or shorter key lengths if given sufficient time and the motivation to do so. RSA 2048-bit and ECC 256-bit are still considered beyond that level of vulnerability as of this time.

• Certificate must use the Secure Hash Algorithm 2 (SHA-2) with a digest length of at least 256 bits (that is, SHA-256 or greater).

This is referring to the hash algorithm used to sign the certificate. In this case, what is happening is that, as part of generating and signing the certificate, a hash is generated known as a certificate digest (also known as a fingerprint.) This is a unique value for every certificate, where a valid digest verifies the following:

• • The certificate hasn’t been tampered with.
  • The certificate is unique.

If anything in the certificate changes, the digest will change and the hash can no longer be successfully verified (which in turn means the certificate is now rejected as invalid.)

There have been several hashing algorithms used for certificates over the decades, with the SHA-2 family of hash functions producing digests of specific sizes:

• • SHA-256: Produces a digest which is 256-bit in output size
  • SHA-384: Produces a digest which is 384-bit in output size
  • SHA-512: Produces a digest which is 512-bit in output size

There is also the older SHA-1 hash algorithm, which produces digests of smaller size. SHA-1 has been successfully attacked and broken in practice, so it is no longer considered secure enough for securing communication.

• Data must be exchanged using either the AES-128 or the AES-256 symmetric cipher.

What this means is that the data being sent and received must be protected while in transit by specific encryption algorithms. In this case, the specified encryption algorithm is the Advanced Encryption Standard (AES), where the 128 and 256 parts refer to the key length being used:

• • AES-128: Key size is 128 bits in length
  • AES-256: Key size is 256 bits in length

• The link must support perfect forward secrecy (PFS) through Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange.

This has several parts. First, there’s perfect forward secrecy (PFS). This is a security property that ensures that if secure communication was compromised by an attacker getting the private key of a certificate, they could only read the communication which occurred at the time they compromised the communication and afterwards. If the attacker had recorded previous communication from before they had compromised the private key, they would not be able to read that older traffic even though the attacker now has the private key of the certificate.

Next, there’s Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange:

• • Elliptic Curve: This is using elliptic curve mathematics to provide stronger security using smaller key sizes.
  • Diffie-Hellman: This is a method that allows two parties to securely agree on a shared secret over an insecure channel, without ever transmitting the key itself.
  • Ephemeral: This means that the keys used for this communication are temporary, with a new key pair being created for each communication session.

When it all gets put together, this is saying the following:

1. Every connection must generate a fresh, temporary key pair using elliptic curve math.
2. Both parties use Elliptic Curve Diffie-Hellman Ephemeral key exchange (ECDHE) to agree on a shared session key without transmitting it between them.
3. Once the session ends, the temporary key pair is thrown away.

Step three is what ensures perfect forward secrecy (PFS). Since the key pair used for communication is always both temporary and discarded after each communication session, the actual key pair used to secure communication would be gone forever and unavailable to an attacker which compromised the private key at a later point in time.

What’s the end result?

After going through all that, what’s the end result that Apple’s going for? The answer is that they’re trying to both maximize security while still maintaining compatibility with the majority of systems already out in the world. TLS 1.2 is not the latest TLS version, as TLS 1.3 is available and more secure than TLS 1.2.

However, TLS 1.3 is a relatively new version and may not be compatible with all the services that Apple’s devices may need to communicate with. In this case, setting TLS 1.2 as the minimum strikes a balance between network security and operational compatibility. Similar balancing acts are seen in the minimums Apple is setting for certificate signing and certificate digests, where stronger options are available but may have compatibility issues with existing services.

The task for us as IT admins and MDM developers is going to be auditing our systems and MDM solutions, then making updates where needed to ensure they meet Apple’s new security standards before Apple enables App Transport Security for connections to those services. By telling us now that it may come as soon as the next major release of Apple’s operating systems, Apple’s informing us that we may only have until Fall 2026, when we can expect Apple to release the next major operating system versions, to find and make the necessary changes.

PDF: https://tinyurl.com/macaduk2026pdf
Keynote: https://tinyurl.com/macaduk2026key

Previously, Apple Business Manager had required a Data Universal Numbering System (DUNS) number, which are issued to businesses by Dun & Bradstreet (D&B), to be used to verify that the organization looking to set up an ABM instance was in fact a recognized business. Now the verification requirement has changed from using a DUNS number to using a variety of business identification methods on a per-country basis. For the United States, the following business identifier is listed:

• Registration type: Federal Taxpayer Identification Number
• Description: Number assigned by the United States government to identify a business, generally a corporation or partnership.

Taxpayer Identification Numbers (TIN) are assigned by the US Internal Revenue Service to both individuals and organizations. In the case of a business, the TIN for business entities is an Employer Identification Number (EIN).

Apple also references the use of an EIN as part of the instructions on how to verify your organization when signing up for a new Apple Business instance. A DUNS number is referenced in the same instructions, so it appears that while a DUNS number remains an acceptable verification method, it’s no longer the only way Apple accepts business verification.

This message is part of Apple’s transition strategy for Intel-based apps over the course of macOS 26 and macOS 27. The Rosetta 2 support used to run Intel-based apps will continue in its current form on both macOS 26 and macOS 27, but there will be as-yet unspecified changes occurring beyond macOS 27. For more information on this transition, please see the Apple KBase article linked below:

Using Intel-based apps on a Mac with Apple silicon
https://support.apple.com/102527

To help identify if and where Intel-based applications have been installed on Apple Silicon Macs, you can use System Information.app‘s list of installed software to identify which installed applications show up with the following status:

• Kind: Intel

To assist with automating this task, a script is available which uses the /usr/sbin/system_profiler command line tool to detect all Intel-based apps installed in /Applications, /Library or /usr/local and output the list to a logfile named intel_apps_installed.log which is stored in the /var/log directory. For more details, please see below the jump.

The script does the following:

1. Checks to see if the script is being run as root.
2. Checks to see if the designated log file is present and creates it if it isn’t.
3. Uses the /usr/sbin/system_profiler command line tool to pull the complete list of installed applications
4. Filters all applications that are not Intel-based applications.
5. Excludes all Intel-based applications that are not stored in one of the following locations or their included directories:

• /Applications
• /Library
• /usr/local

6. Outputs the following output to the log:

If any Intel-based applications are found in /Applications, /Library or /usr/local, the path to the detected Intel-based application or applications are listed in the log:

/path/to/Intel_based_application_name_here.app

If no Intel-based applications are found in /Applications, /Library or /usr/local, the following is output to the log:

No Intel-based applications found in /Applications, /Library or /usr/local.

The script is available below and also on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/detect_installed_intel_based_apps

As part of this transition process, as of macOS Tahoe 26.4 there is a new window that will be periodically displayed when apps which are Intel-based get launched on Apple Silicon Macs. For example, an earlier version of an Automator app I wrote named Show or Hide Desktop Icons.app is an Intel-based app.

On macOS 26.4 and later, launching this earlier version of the Show or Hide Desktop Icons app will periodically result in the following message being displayed by the OS.

This new message may not be desirable to display in all Mac environments, so Apple has provided management options to prevent this message from being shown. For more details, please see below the jump.

The relevant preference domain and key values are below:

• Preference domain: com.apple.applicationaccess
• Key: allowRosettaUsageAwareness
• Value: Boolean

This setting can be managed by a configuration profile, where setting a boolean value of false will prevent the message from being displayed. Please see below for an example profile. This profile is also available via the following link:

https://github.com/rtrouton/profiles/tree/main/DisableRosettaUsageAwareness

• Background Security Improvements will be automatically installed

You needed to do the following in the Blueprint’s Software Update Settings component:

1. Go to the Background Security Improvements section
2. Select the following options to apply the desired settings:

• Background Security Improvements updates will be installed:
  • Select Allow for Background Security Improvements installation

That enables an installation option, but not the automatic installation option. For more details, please see below the jump.

What installation option is being enabled? As it turns out, what’s enabled is the logged-in user’s ability to manually select installing the BSI update. You can see this by setting the Background Security Improvements installation setting to Allow.

Once that’s been set and deployed to devices, look at System Settings: Privacy & Security: Background Security Improvements on a device that the setting has been deployed to. If there’s a BSI available to install, you’ll see it listed there along with an Install button.

Next, let’s set Background Security Improvements installation to Restrict and deploy the settings to devices.

Now when we look at System Settings: Privacy & Security: Background Security Improvements on a managed device, that section and its Install button have disappeared.

That means that the only install option available now is the automatic install option. Where’s that managed from? That is also managed in the Software Update Settings component, but in a different section. To set management for automatic installation of BSI updates:

1. Go to the Install Actions section
2. Select the following options to apply the desired settings:

• Automatic installs of available security updates:
  • Select Always

When those settings are deployed to devices, you can go to System Settings: Privacy & Security: Background Security Improvements on a managed device and see that the Automatically Install setting is enabled and grayed out. There should also be a message that the setting is managed by your organization.

You can also disable automatic installation of BSIs, but a very important thing to be aware of is that the Automatic installs of available security updates setting is managing all background security updates for macOS, not only BSIs. This includes updates for Gatekeeper, XProtect and verifying the firmware that your Mac uses. Please keep that in mind if you want to disable automatic installs of BSIs.

If you’ve considered this information and still want to disable automatic installs of BSI updates, you can do so by using the following process:

1. Go to the Install Actions section
2. Select the following options to apply the desired settings:

• Automatic installs of available security updates:
  • Select Never

When those settings are deployed to devices, you can go to System Settings: Privacy & Security: Background Security Improvements on a managed device and see that the Automatically Install setting is disabled and grayed out. There should also be a message that the setting is managed by your organization.

• Background Security Improvements will be automatically installed
• Background Security Improvements can be removed

For more details, please see below the jump.

As of Jamf Pro 11.25.2, there is not a Blueprints template available for creating blueprints which manage software update settings so the blueprint will need to be configured manually. To do this, use the following procedure:

1. Log into Jamf Pro.

2. Select Blueprints

3. Click the Create blueprint button.

4. You should see an unconfigured Blueprint. Click where it says Untitled blueprint and provide a name.

For this example, I’m using Background Security Improvements Management Settings.

5. Scroll down in the list on the left-hand side of the browser window to locate the Software Update Settings component.

6. Click on the Software Update Settings component and drag the Software Update Settings component to the Components in this blueprint section.

7. Once added to the Components in this blueprint section, click anywhere on the Software Update Settings component to open it for editing.

8. At this point, you will see the software update management settings. From there, scroll down to the Background Security Improvements section and click the Configure button.

In the Background Security Improvements section, select the following options to apply the following desired settings:

• Background Security Improvements updates will be installed:
• Select Allow for Background Security Improvements installation
• Background Security Improvements updates can be removed:
• Select Allow for Background Security Improvements removal

Once all choices have been made and verified, click the Update button.

You should now see the following items set to Enabled:

• Background Security Improvements installation
• Background Security Improvements removal

9. Once all the settings choices have been made and verified, click the Save changes button.

10. At this point, you should have a blueprint which has all settings configured but where no target scope has been set. To scope this blueprint, go to the Scope section and click the arrow button.

11. Select a Jamf Pro smart or static group. For this example, I’m selecting a static group named Background Security Improvements Settings Deployment Group.

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

18. Once deployed, the Blueprints screen in Jamf Pro should show the newly-created Background Security Improvements Management Settings Blueprint as being deployed.

You can also check on the managed device’s end by opening System Settings: General: Device Management, locating the MDM enrollment profile in the list of profiles and double-clicking on it.

When you scroll to the bottom of the enrollment profile’s window, you should see a Device Declarations section. If you’re deploying a software update configuration via Blueprints, you should see a Software Update listing for Software Update Settings in the Device Declarations section.

If you click on the Software Update Settings listing, you should see the details of what is being managed. In the case of our example where we are setting Background Security Improvements to be automatically installed and allowing the removal option, you should see the the following entries set to On:

• Enable
• Enable Removal