Audit Your MDM Servers on macOS 26.4, Not 27

Apple’s guidance for auditing the OS 27 TLS changes contains a sentence most administrators will read past: if your test devices run version 27 or later and you hit connection errors, test again on a device running 26.4 or later but earlier than 27, because “non-compliant connections are blocked and these failed connections might prevent testing of subsequent connections in the workflow.”²

Testing on the new OS finds one broken server and hides the rest. On 27, a non-compliant connection fails, and the workflow that depended on it stops. Everything downstream never runs, so it never gets tested. On 26.4 through 26.x the same problems surface as warnings, which means a single pass surfaces every non-compliant server you have.

Two things Apple states directly: on version 27 or later, “non-compliant connections are blocked and the log messages appear as errors instead of warnings,” and you should test on 26.4 or later but earlier than 27 “to identify all affected servers.”² That the connections actually complete on those earlier versions is the reading rather than a verbatim claim, but the recommendation only makes sense if they do. A blocked connection on 26.4 would truncate the workflow exactly as it does on 27.

The instinct is to test on the version that introduces the change. Here that instinct produces an incomplete list, and you find the rest one at a time in production.

TL;DR

Starting with version 27.0 of iOS, iPadOS, macOS, watchOS, tvOS, and visionOS, select system processes enforce stricter TLS requirements on connections involved in MDM, Declarative Device Management, Automated Device Enrollment, configuration profile installation, app installation including enterprise distribution, and software updates.¹ Servers must support TLS 1.2 or later with ATS-compliant ciphersuites and certificates.¹ SCEP and content caching servers are exempt.² Your app’s own networking is not affected. Audit on 26.4 through 26.x, where violations log as warnings rather than blocking, using the Network Diagnostics Logging Profile and a sysdiagnose.²

What Is Actually In Scope

The change applies to a specific list of system activities, not to network traffic generally.¹

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

Two exemptions matter, because both are the kind of server an administrator would otherwise spend a day investigating: connections to a SCEP server while installing a configuration profile or resolving a DDM asset, and connections to content caching servers, even when requesting assets for app installation or software updates.²

Worth stating plainly for developers who arrive here from a headline: your app’s URLSession traffic is not the subject. This is device-management infrastructure. App Transport Security has governed app networking since apps linked against the iOS 9.0 and macOS 10.11 SDKs.³ What changed in 27 is that a set of system processes began applying comparable requirements to management traffic.

The platform list is broader than “enterprise Mac fleet” suggests. Apple names iOS, iPadOS, macOS, watchOS, tvOS, and visionOS.² Apple TV in a conference room and Vision Pro in a design studio both enroll through the same infrastructure.

The Requirements, From the Canonical Source

Apple’s support article states servers must support TLS 1.2 or later, use ATS-compliant ciphersuites, and present valid certificates meeting ATS standards.² The specifics live in the ATS documentation, which is the page to work from.³

Default server trust evaluation must pass: intact signature, not expired, name matching the server’s DNS name, and a chain up to an anchor certificate issued by a CA that is either part of the client OS or installed by a user or administrator.³

On top of that, ATS adds:³

• Certificate signed with an RSA key of at least 2048 bits or an ECC key of at least 256 bits
• Certificate using SHA-2 with a digest of at least 256 bits
• TLS 1.2 or later
• Data exchanged using AES-128 or AES-256
• Perfect forward secrecy through ECDHE key exchange

The last two rarely appear in summaries of this change, including in the violation table Apple publishes for the audit. An administrator who fixes only what the logs name can still be non-compliant on cipher choice.

Auditing Before It Bites

The procedure Apple documents is specific, and each step exists for a reason.²

Use test devices on 26.4 or later, earlier than 27. This is the whole trick. Violations log as warnings, connections succeed, and the workflow continues to the next server.

Install the Network Diagnostics Logging Profile, then restart. It must be installed before any testing, or the log events will not carry the detail needed to identify non-compliant connections.

For Automated Device Enrollment on iPhone or iPad, use Apple Configurator for Mac to install the profile before the device reaches the Device Management pane in Setup Assistant. Enrollment traffic happens early, and a profile installed afterward misses it.

Run your normal workflows. Enroll the device, install apps and profiles, and exercise anything that talks to your servers. The goal is generating traffic to every server that might be affected.

Collect a sysdiagnose, move it to a Mac, expand the archive, and from its top-level directory filter the log:

log show --archive system_logs.logarchive --info \
  -P "p=appstoreagent|appstored|managedappdistributionagent|managedappdistributiond|ManagedClient|ManagedClientAgent|mdmclient|mdmd|mdmuserd|MuseBuddyApp|NanoSettings|Preferences|profiled|profiles|RemoteManagementAgent|remotemanagementd|Setup|'Setup Assistant'|'System Settings'|teslad|TVSettings|TVSetup|XPCAcmeService AND s=com.apple.network AND m:'ATS Violation'|'ATS FCPv2.1 violation'"

Each event carries a Domain, the Process that made the connection, and a Warning naming the constraint violated. One connection can emit several warnings if the server fails several requirements.²

Cover your configurations, not just your devices. Apple’s dimensions are worth copying directly: environment (production, staging, test), device type, role (user group, kiosk, shared device), and enrollment type (Automated Device Enrollment, account-driven, profile-driven, Shared iPad).² Different configurations reach different servers, and a clean audit of one says nothing about another.

watchOS cannot be audited this way. Most of its networking happens out of process and the log command will not work. Apple’s guidance is that testing on iOS likely provides sufficient coverage for Apple Watch connections.²

Reading the Violations

Apple separates the failures into two classes, and the second is where compliant-looking servers fail.

General ATS policy violations, logged as Warning [ATS violation]:²

One useful exemption sits in that table: if the certificate that fails trust evaluation is among the auto-enrollment profile anchor certificates, no remediation is required.²

FCP v2.1 violations, logged as Warning [ATS FCPv2.1 violation]:²

That last row is the one that will surprise people. A server can satisfy the headline requirement, negotiating TLS 1.2 with a modern ciphersuite and a valid certificate, and still fail, because the Functional Package for TLS additionally requires the extended master secret extension. Apple’s remediation is to move to TLS 1.3, or at minimum configure TLS 1.2 to negotiate EMS.²

There is a subtlety here worth keeping straight. ATS’s FCP v2.1 compliance mode is opt-in for apps, via NSRequiresNIAPTLSPackageVersion, and exists for regulated environments.³ That opt-in governs your app’s own client behavior. It has no bearing on the OS 27 system processes, which are applying FCP v2.1 checks to your servers whether or not any app of yours opted into anything.

What Changes on 27

On version 27 and later, non-compliant connections are blocked and the log messages appear as errors rather than warnings.²

Apple notes that several warnings have no direct error equivalent, and that for ciphersuite, TLS version, and signature algorithm problems the exact client-side error “might depend on how the server handles that state.”² Do not expect a clean mapping from warning to error.

The one concrete error Apple documents covers blocked plaintext HTTP, including a redirect that lands on an http:// URL:²

Task . finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022
"The resource could not be loaded because the App Transport Security policy
requires the use of a secure connection."

For validating a single server after remediation, nscurl connects using different combinations of ATS exceptions and narrows down which requirement is failing, without a full sysdiagnose cycle.³

What Remediation Looks Like

The audit produces a list of domains and violations. Turning that into server changes divides into three cases.

Move to TLS 1.3 where you can. Doing so resolves several violation classes at once rather than one at a time. Every TLS 1.3 ciphersuite provides perfect forward secrecy, so the non-PFS ciphersuite warning cannot occur. The extended master secret requirement is specific to TLS 1.2, so it stops applying. Signature algorithm negotiation is stricter by design. Apple’s own remediation column says to update servers to negotiate TLS 1.3 whenever possible, with TLS 1.2 as the minimum.²

If you are pinned to TLS 1.2, three settings carry most of the weight. Enable the extended master secret extension, which is the violation most likely to surprise an otherwise modern configuration. Restrict the ciphersuite list to ECDHE key exchange with AES-128 or AES-256, which satisfies both the PFS requirement and the symmetric cipher requirement together.³ Remove any rsa_pkcs15_sha1 signature algorithm from the server’s preference order.

Being pinned is more common than it sounds. A load balancer terminating TLS, a hardware appliance on a support contract, or an embedded management controller can all be the reason a modern-looking environment negotiates something old.

Certificate problems need lead time of their own. RSA below 2048 bits, ECDSA below 256, and leaf certificates hashed with anything weaker than SHA-256 all require reissuing rather than reconfiguring. That means a CA request, a change window, and coordination with whoever owns the chain. Check the intermediate certificates too, since default trust evaluation walks the whole chain to an anchor.³

One exemption saves work: if the certificate failing trust evaluation is among the auto-enrollment profile anchor certificates, Apple states no remediation is required.² Check that before opening a ticket.

Verify each fix individually rather than re-running the full audit. nscurl connects to a single server using different combinations of ATS exceptions, which narrows down exactly which requirement still fails.³ A full sysdiagnose cycle per iteration is a slow loop when you are waiting on a vendor to redeploy.

Why the Lead Time Matters

Apple says directly that updating server configurations “might require significant time, especially for servers maintained by external vendors.”²

That sentence is the reason to run the audit now rather than when 27 ships broadly. The servers in scope are frequently not yours. An MDM vendor’s endpoints, a software distribution partner, an identity provider fronting enrollment. Finding out in October that a vendor needs a quarter to enable EMS on their TLS 1.2 endpoints is a different problem than finding out in August.

The audit produces a list of domains and the processes that reached them. That list is what you send to vendors, and its specificity is what gets it prioritized. “Your server fails Apple’s new requirements” is easy to deprioritize. “Your endpoint at this domain negotiated TLS 1.2 without extended master secret, which OS 27 blocks for enrollment traffic” is not.

This is the same shape as other changes in this release. macOS 27 stopped prompting before it denies cross-team container access, and menu item images now depend on which SDK you linked against. In each case the platform removed a signal or tightened a default, and the failure arrives looking like something else. Here the something else is an enrollment that hangs.

Key Takeaways

For IT administrators: - Audit on 26.4 through 26.x. Testing on 27 blocks the first failure and hides everything downstream in the same workflow. - Install the Network Diagnostics Logging Profile before testing and restart the device, or the logs will not identify the servers. - Cover configurations rather than devices: environment, device type, role, and enrollment type each reach different servers. - Send vendors the domain, the process, and the specific violation. Lead time on external servers is the binding constraint.

For MDM and device-management developers: - SCEP and content caching servers are exempt. Do not spend the audit on them. - The ATS FCPv2.1 violations are separate from general ATS policy violations, and TLS 1.2 without EMS is the most likely to be missed. - On watchOS the log command will not work. Cover Watch connections through iOS testing.

For everyone reading a headline about this: - Your app’s own URLSession traffic is not what changed. This applies to system processes handling management, enrollment, installation, and update traffic.

FAQ

Does this affect my app’s network requests?

No. The change applies to system processes involved in MDM, DDM, Automated Device Enrollment, configuration profile installation, app installation, and software updates.¹ App Transport Security has governed app networking separately since the iOS 9.0 and macOS 10.11 SDKs.³

Why audit on an older OS version?

Because on 27 the failures block. Apple states that non-compliant connections are blocked and “these failed connections might prevent testing of subsequent connections in the workflow,” and recommends testing on 26.4 or later but earlier than 27 to identify all affected servers.² On those versions the violations log as warnings while connections still succeed.

Which servers are exempt?

SCEP servers, while installing a configuration profile or resolving a DDM asset, and content caching servers, even when requesting assets related to app installation or software updates.²

My server does TLS 1.2 with a valid certificate. Can it still fail?

Yes. The FCP v2.1 checks include TLS 1.2 negotiated without the extended master secret extension, a certificate signed with an algorithm not advertised in the ClientHello, and rsa_pkcs15_sha1 signature algorithms.² ATS also requires AES-128 or AES-256 and perfect forward secrecy through ECDHE.³

Does opting into NIAP compliance in my app change this?

No, and the two are easy to conflate. NSRequiresNIAPTLSPackageVersion opts your app’s own client behavior into the stricter FCP mode for regulated environments.³ The OS 27 system processes apply their own requirements to management traffic independently.

Sources