Apple is about to enforce stricter TLS standards for MDM. Are you ready?

Summary

Apple announced that starting as early as iOS 27, iPadOS 27, macOS 27, watchOS 27, tvOS 27, and visionOS 27, its operating systems will enforce stricter TLS requirements for system processes, including MDM, DDM, Automated Device Enrollment, and app distribution. Servers that don't support TLS 1.2 or later (TLS 1.3 recommended), ATS-compliant ciphersuites, and valid certificates may have their connections refused. SCEP servers and content caching servers are currently exempt. IT admins should audit their infrastructure now using Apple's Network Diagnostics Logging Profile to identify non-compliant servers before fall 2026.

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.

What Apple is requiring

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:

• TLS 1.2 minimum, TLS 1.3 recommended. Any server still running TLS 1.0 or 1.1 will be blocked outright.
• App Transport Security (ATS)-compliant ciphersuites only. Specifically, Perfect Forward Secrecy (PFS) ciphersuites, meaning any TLS 1.3 ciphersuite or TLS 1.2 ciphersuites using Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange. No legacy cipher support.
• Valid server certificates meeting ATS standards. RSA keys must be at least 2048 bits; Elliptic Curve Digital Signature Algorithm (ECDSA) keys at least 256 bits; SHA-2 with a minimum 256-bit digest. Expired or self-signed certificates are out.
• Extended Master Secret (EMS) extension on TLS 1.2 connections.
• HTTPS only. No plaintext HTTP anywhere in the connection chain.

This applies across macOS, iOS, iPadOS, watchOS, tvOS, and visionOS. Presumably, this will apply for version 27 of all the above operating systems.

What breaks if you're non-compliant

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:

• Enrollment fails. New devices cannot be enrolled into management. Zero-touch deployment through Apple Business stops working.
• Management operations break. Profile pushes, configuration changes, and policy enforcement stop reaching devices.
• App distribution stops. Managed apps cannot be pushed or updated.
• Software updates fail. Devices cannot receive OS and security updates through your managed update channel.

Essentially, your MDM stops doing its job silently, from the device's perspective.

Examples of what might be non-compliant

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:

• Web service that a device management service uses to:
• host packages for installing custom packages, such as with the InstallEnterpriseApplication and InstallApplication commands
• host assets for DDM assets
• Services that act as content caching intermediaries, WAN optimizers, TLS-terminating reverse proxies, or reverse proxies, although Apple’s content caching service is specifically exempted
• Services that act as load-balancers
• Web service for Account-driven enrollment methods with Apple devices for service discovery that provides the enrollment URL of the device management service.

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.

How to audit your infrastructure now

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.

If you're on Iru, you're already covered

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).

Why now?

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 →