Starting as early as the next major OS release, Apple devices will refuse to connect to any device management service, Mobile Device Management (MDM) server, enrollment endpoint, or app distribution infrastructure that does not meet tightened TLS standards. Non-compliant servers will simply stop working for enrollment, device management, app delivery, and software updates.
Here's what's changing, what breaks if you're not ready, and how to check your setup before it affects your fleet.
Apple's updated App Transport Security (ATS) enforcement applies to all connections your Apple devices make to management infrastructure. The affected areas include MDM and Declarative Device Management (DDM), Automated Device Enrollment (ADE), configuration profile installation, app installation (including enterprise distribution), and software updates.
To stay connected, servers must meet all of the following requirements:
This applies across macOS, iOS, iPadOS, watchOS, tvOS, and visionOS. Presumably, this will apply for version 27 of all the above operating systems.
If any server in your device management infrastructure does not meet these requirements when enforcement kicks in, Apple devices will refuse to connect. That means:
Essentially, your MDM stops doing its job silently, from the device's perspective.
It might be obvious that an old self-hosted MDM server (like one that you created for testing or training) might not meet the requirements.
But there are a lot of moving pieces in managing your Apple devices! It’s possible that in your device management stack, there are some non-compliant elements. Some example components of your infrastructure might include:
Keep in mind that just because https://server.pretendco.com/ is compliant, https://server.pretendco.com:8443/ might not be.
For this upcoming change, it's only connections to your servers and the servers of your vendors that you need to worry about. Apple-hosted services are Apple's responsibility to keep compliant.
That said, Apple has long advised that you should not intercept connections from Apple devices to Apple services using HTTPS Interception (SSL Inspection). If your network does intercept those connections, they effectively become your connections, and your responsibility to keep compliant.
Apple also specifically mentioned that connections to a SCEP service while installing a configuration profile or resolving a DDM asset are exempt from the requirements.
Because there are so many potential pieces that might not be compliant, start your audit now so you have plenty of time to remediate or replace those elements.
Apple included a practical audit process in their notice. Here's the short version:
Step 1 — Install the Network Diagnostics Logging Profile on a test device with at least version 26.4 of the OS (iOS 26.4, iPadOS 26.4, macOS 26.4, watchOS 26.4, tvOS 26.4, or visionOS 26.4). The logging profile enables ATS-level logging so you can see if there are any connections that aren’t compliant. If you’re testing Automated Device Enrollment (ADE) on an iOS or iPadOS device, you can use Apple Configurator on Mac to install the profile at the very start of the Setup Assistant flow.
What about testing Mac and ADE? Well, there’s not really a way to get that logging profile installed before the Remote Management screen in Setup Assistant appears, so it’s probably a good idea to at least test ADE with iOS or iPadOS if you can.
Step 2 — Run your normal enrollment and management workflows on that device to generate representative network traffic across all your infrastructure endpoints.
Step 3 — Collect a sysdiagnose archive from the test device and filter the logs for ATS Violation and ATS FCPv2.1 violation messages. Any server that shows up here needs attention.
Step 4 — Use the nscurl command to validate specific servers individually. Run nscurl --ats-diagnostics --verbose https://[your-server-url] to get a detailed report on what that server supports and where it falls short.
If you're running a self-hosted MDM or using an older on-premises enrollment infrastructure, now is the time to loop in your server admins. Remediation typically means updating your TLS configuration and renewing any certificates that don't meet the new key size or hash algorithm requirements.
Iru's complete infrastructure is fully compliant with Apple's updated ATS requirements. You don't need to do anything on the device management service side. Your enrollment, management, and app delivery connections already meet the new standards.
For teams on legacy or self-hosted device management service platforms, this is the moment to pressure-test your vendor. Ask directly: are your servers TLS 1.3 capable? Do you use PFS ciphersuites? When was your last certificate audit? If the answer is uncertain, you may be looking at an enrollment outage when Apple flips the switch for the new operating systems this autumn (Northern Hemisphere).
Frankly, all of these requirements are quite reasonable and practical. Apple has been progressively tightening requirements for apps on Apple platforms for years. What's new is the scope: this explicitly covers device management service and enrollment infrastructure, not just app connections. It's Apple treating your device management channel with the same security bar as any production HTTPS endpoint.
For IT teams that have deferred TLS hygiene on internal infrastructure because "it's internal traffic," this is the deadline that resets that assumption. Your device management server talks to Apple's servers and to your managed devices. Both directions now need to clear this bar.
Run the audit. Give your server team the requirements. And if you want to skip the infrastructure maintenance entirely, that's a reasonable argument for moving to a fully cloud-managed service management service platform.
Have questions about how Iru handles device management service security? Talk to our team →