This Autumn, iOS 27 May Refuse Connections to Badly Configured Servers

What actually changes at version 27.0

Apple's document is addressed to IT administrators and device management developers, and its language is unambiguous: starting with version 27.0 of iOS, iPadOS, macOS, watchOS, tvOS and visionOS, the operating system "might refuse connections to servers with outdated or non-compliant TLS configurations."

The change is a tightening of App Transport Security, the policy Apple has enforced on app network traffic since 2016, now extended to a set of system processes. Today, on version 26.4 and later, a non-compliant connection produces a warning in the system log and proceeds. On version 27 the same connection produces an error and stops.

Which connections are covered

Six activities fall inside the perimeter: mobile device management, Declarative Device Management, Automated Device Enrolment, configuration profile installation, app installation including enterprise distribution, and software updates. Two are explicitly excluded — SCEP servers reached while installing a profile or resolving a DDM asset, and content caching servers, even when the cached asset is an app or a system update.

Ordinary app traffic is not the subject here. An organisation whose internal API is behind on TLS will not see its own app break because of this document. What will break is the plumbing that puts the app on the device in the first place.

The requirements, in plain terms

Servers must negotiate TLS 1.2 or later, and Apple recommends 1.3. A server still on 1.2 has to clear three further bars: key exchange with Perfect Forward Secrecy, meaning ECDHE; AEAD ciphersuites built on AES-GCM with SHA-256, SHA-384 or SHA-512; and the extended master secret extension defined in RFC 7627. Certificates have their own floor — at least a 2048-bit RSA key or a 256-bit ECDSA key, and a SHA-2 signature on the leaf. Plaintext HTTP is refused outright.

Read individually, none of these is exotic; a server configured from scratch in 2026 would satisfy all of them by default. The extended master secret requirement is the one most likely to catch a working system, because it addresses a 2015 protocol weakness and many appliances shipped compliant TLS 1.2 without ever enabling it.

How to find out before September

Apple's procedure does not involve guessing. Install the Network Diagnostics Logging Profile on a representative test device running version 26.4 or later — but, importantly, not yet version 27, since a blocked connection on 27 can hide the failures that would have come after it. Run the device through its normal enrolment and installation workflows, collect a sysdiagnose, and filter the log archive for events tagged ATS Violation or ATS FCPv2.1 violation. Each event names the domain, the process that opened the connection, and the specific constraint that was broken.

Individual servers can then be checked directly with nscurl --ats-diagnostics https://example.com/, looking for a PASS in the FCP_v2.1 section.

The coverage advice is the part most likely to be skipped and most likely to matter: different device roles reach different servers. A kiosk iPad, a shared iPad, an engineer's Mac and a sales iPhone can each touch infrastructure the others never see, and testing one configuration proves nothing about the rest.

The uncomfortable part is the third-party vendor

Apple says plainly that remediation "might require significant time, especially for servers maintained by external vendors." That sentence carries most of the operational risk. An organisation can reconfigure its own load balancer this week. It cannot reconfigure the MDM provider's endpoint, the enterprise app distribution host it licenses, or the appliance whose vendor stopped shipping firmware updates in 2023. Each of those is a support ticket, a contractual conversation, or a migration.

Apple's guidance for that case is to send the vendor the support article together with the exact warning lines observed — which is more useful than a general request, because the warning text names the violated constraint and the remedy in the same breath.

For everyone who is not an administrator

If you use an iPhone or a Mac that your employer does not manage, this changes nothing you will notice. If your device is enrolled with an employer or a school, the visible symptom of an unprepared fleet would be an update or an app installation that fails without explaining itself, once the fleet is on version 27 — and the fix would sit on the organisation's side, not Apple's.

This is a familiar Apple pattern, and it has been running for a decade: publish a deadline, spend a release cycle warning, then enforce. We saw a version of it in the security work behind iOS 26.6.1's WebKit patches, where the fixes were the visible half of a longer campaign. The difference this time is that the enforcement date is attached to a consumer release millions of people will install within days of it appearing.