Apple released a new KBase article on April 21st 2026, where the intended audience is IT admins and device management service developers. (For device management service developers, these are the vendors and other folks who build MDM servers.) The KBase article is available via the link below:
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:
- Every connection must generate a fresh, temporary key pair using elliptic curve math.
- Both parties use Elliptic Curve Diffie-Hellman Ephemeral key exchange (ECDHE) to agree on a shared session key without transmitting it between them.
- 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.
![https://example.jamf.com/img/display/this/package.jpg"](https://example.jamf.com/img/display/this/package.jpg"){kind=link}
![https://example.jamf.com/img/full/this/package.jpg"](https://example.jamf.com/img/full/this/package.jpg"){kind=link}