How To: Prepare your network for stricter security requirements with Apple

By: Thomas Bosboom, Consulting Engineer

At Apple, we believe that every student deserves technology that is secure, private, and trustworthy by default. We want the devices in your school to connect to the right services, the right way, every time. That’s why we have to keep raising the bar on TLS security as the standards evolve.

Starting with version 27.0 of iOS, iPadOS, macOS, watchOS, tvOS, and visionOS, Apple operating systems will enforce stricter network security for the system processes that power device management — and may refuse connections to servers that don't meet the new requirements.

When it comes to device management in schools, we know that a handful of servers do an enormous amount of work behind the scenes: your MDM, your enrollment service, your app distribution, your software updates. And, we also recognize that the network path to those servers is shared infrastructure. It's rarely owned by one team, it's often maintained by a vendor, and it tends to keep running long after anyone last looked at its TLS configuration.

This article will provide pointers on how to make sure this is smooth for your org. The full details are in our support article: Prepare your network environment for stricter security requirements, which is the source of truth for this topic. Everything below is a shorter on-ramp for school IT admins.

What's Changing

The new TLS requirements apply to network connections involved in:

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

Two useful exceptions to know up front: SCEP servers (reached while installing a configuration profile or resolving a DDM asset) and content caching servers are not affected.

At a glance, servers in the affected paths will need to:

• Support TLS 1.2 or later (TLS 1.3 recommended).
• Offer ATS-compliant ciphersuites with Perfect Forward Secrecy (any TLS 1.3 suite, or TLS 1.2 with ECDHE).
• Present valid certificates meeting ATS standards. Minimum RSA 2048 / ECDSA 256, SHA-256 or stronger leaf hash, valid trust chain.
• Negotiate the Extended Master Secret extension (RFC 7627) if they're still on TLS 1.2.

Note: If your MDM is vendor-hosted and kept current — Jamf Cloud, Mosyle, Kandji, Microsoft Intune, Addigy, or similar — your provider is already engaged on this and their TLS configuration is largely out of your hands. Expect guidance from them, file it, and focus your audit on the servers you operate yourselves.

What You're Likely to Find

In schools running on-prem MDM or self-hosted distribution, the common findings tend to be:

• A certificate signed with a legacy SHA-1 or undersized RSA key, still in rotation because it’s always worked.
• A TLS 1.2 configuration that never enabled Extended Master Secret.
• An older load balancer or reverse proxy whose ciphersuite list predates PFS enforcement
• Plaintext HTTP still answering on an internal redirector in front of an otherwise modern server

None of those are difficult to remediate individually. The work is in finding them before a device on a future OS does.

How to Check Your Environment

The support article walks through this end-to-end. In practice, the flow for a school IT team will follow the following steps:

1. Install the Network Diagnostics Logging Profile on a representative test device running iOS, iPadOS, macOS, watchOS, tvOS, or visionOS 26.4 or later. Restart the device after installation. (The profile and exact installation steps are in the Apple Support article.)
2. Run your normal workflows on that device — enroll it, install profiles and apps, trigger a software update check, and perform anything else that would touch your organization's servers in a typical day. The goal is to generate traffic to every server your fleet would realistically reach.
3. Collect a sysdiagnose from the test device and transfer it to a Mac.
4. Filter the log using the log show command provided in the article. You're looking for entries tagged ATS Violation or ATS FCPv2.1 violation. Each one names the domain, the process that made the connection, and the specific violation.
5. Validate individual servers with nscurl --ats-diagnostics https://example.com:8000/ and look for a PASS result under the test labelled ATS with FCP_v2.1 mode enabled.
6. Remediate — this might mean updated TLS configuration, a new certificate, or a conversation with the vendor operating the server. When you open a ticket with a third party, share this article and the specific warning text you observed.

If the audit comes back clean, you're done. Archive the sysdiagnose and move on. If it doesn't, you have a concrete remediation list well ahead of the release.

Going Deeper: A Single Log Query for the Whole Audit

The support article's log show example is a starting point. In practice, narrowing the predicate to the processes that actually drive MDM, enrollment, app distribution, and software updates surfaces violations faster and with less noise. After you've collected a sysdiagnose from your test device, run this against the unpacked system_logs.logarchive:

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"
    OR m:"ATS FCPv2.1 violation"
)
'

That's every system process Apple uses for the affected workflows, filtered to the network subsystem, filtered again to the two warning categories you care about. Each result names the server, the process that reached it, and the specific violation — which is the trio of facts you need to file a ticket with a vendor or open a change request internally.

This log information is also available in a sysdiagnose, so you can run through a user workflow on a device, take a sysdiagnose immediately & and then check it

Warning Messages You Might See

For each entry, the log line names the offending server, the violation category, and the remediation path. Use the following as a lookup when triaging results from the query above.

Warning [ATS violation]: Ciphersuite([negotiated ciphersuite]) not offered in ATS negotiated for server: www.example.com

• Meaning: The server negotiated a non-PFS ciphersuite that isn’t offered when the client enforces ATS.
• Remediation: Servers must support PFS ciphersuites (any TLS 1.3 ciphersuite and TLS 1.2 ciphersuites with ECDHE).

Warning [ATS violation]: TLS version <1.2 negotiated for server: www.example.com

• Meaning: The server negotiated a version of TLS older than TLS 1.2. TLS 1.0/1.1 are deprecated and already not offered by default.
• Remediation: Update servers to negotiate TLS 1.3 whenever possible (minimally TLS 1.2).

Warning [ATS Violation]: ATS certificate trust requirement not satisfied for server: www.example.com

• Meaning: The server's certificate didn't pass default server trust evaluation because it didn't meet the minimum requirements.
• Remediation: Update the server's certificate to meet the requirements. If the certificate is in the auto-enrollment profile anchor certificates, remediation isn't required.

Warning [ATS violation]: RSA key size [n] bits is less than minimum 2048 bits for server: www.example.com

• Meaning: The server's certificate was signed with an RSA key smaller than 2048 bits.
• Remediation: Update the server's certificate to meet the minimum key size.

Warning [ATS violation]: ECDSA key size [n] bits is less than minimum 256 bits for server: www.example.com

• Meaning: The server's certificate was signed by an ECDSA key smaller than 256 bits.
• Remediation: Update the server's certificate to meet the minimum key size.

Warning [ATS violation]: Leaf certificate hash algorithm (n) is not at least SHA-256 for server: www.example.com

• Meaning: The server's certificate didn't use a SHA-2 hash with digest length of at least 256 bits.
• Remediation: Reissue the certificate with a SHA-256 (or stronger) leaf hash.

Warning [ATS violation]: Did not use TLS when opening connection for server: www.example.com

• Meaning: Plaintext HTTP was used instead of HTTPS.
• Remediation: Update the server to support HTTPS.

Warning [ATS FCPv2.1 violation]: Signature algorithm rsa_pkcs15_sha1 negotiated by server: www.example.com

• Meaning: The server chose rsa_pkcs15_sha1 as the signature algorithm.
• Remediation: Update configuration to prefer modern signature algorithms.

Warning [ATS FCPv2.1 violation]: Server certificate signed using signature algorithm [signature algorithm] not advertised in ClientHello for server: www.example.com

• Meaning: The server's certificate was signed using a signature algorithm not advertised in the ClientHello.
• Remediation: Update the certificate to use a signature algorithm with a TLS codepoint, and not rsa_pkcs15_sha1.

Warning [ATS FCPv2.1 violation]: TLS 1.2 negotiated without extended master secret (EMS) for server: www.example.com

• Meaning: The server negotiated TLS 1.2 and didn’t negotiate the EMS extension.
• Remediation: Update to TLS 1.3, or update the TLS 1.2 configuration to negotiate EMS (RFC 7627).

What FCP_v2.1 Actually Requires of a Server

FCP_v2.1 is the Common Criteria TLS profile that the new requirements align to. In server-owner terms, that means:

• Support TLS 1.2 or later, with TLS 1.3 recommended.
• For servers still on TLS 1.2, support — at minimum — key exchange providing Perfect Forward Secrecy (ECDHE), AEAD ciphersuites based on AES-GCM with SHA-256, SHA-384, or SHA-512, and the extended master secret extension (RFC 7627).
• Update certificates to meet ATS requirements for key size, signature algorithm, and validity.

You can confirm an individual server meets the bar with:

nscurl https://example.com:8000 --ats-diagnostics --verbose

Look for a PASS result under the test labelled ATS with FCP_v2.1 mode enabled. A passing line looks like:

Configuring NIAP TLS package version requirements
---
FCP_v2.1
ATS Dictionary:
{
    NSRequiresNIAPTLSPackageVersion = "FCP_v2.1";
}
Result : PASS
---

A Note on Timing

The article says "Starting with version 27.0." Treat that as your planning horizon. For environments where server-side changes involve change windows, vendor tickets, or certificate renewals with external CAs, the audit is worth running now rather than in the week the release ships.

For More Information

• Prepare your network environment for stricter security requirements — the definitive article, including the full warning-message table and remediation guidance
• App Transport Security — for your server owners and vendors
• The Apple Platform Deployment guide — for your broader MDM and deployment context
• Apple Developer Forums — discussion and Q&A with Apple engineers and other admins working through the same changes

Questions? Please Reach Out!

We've covered the main considerations for school IT admins preparing their networks for the stricter security requirements coming with the next major release, but if you have additional questions — or would like to talk through what an audit looks like in your specific environment — please feel free to reach out to your local Apple Education team, your Customer Success Manager, or AppleCare Enterprise Support. We're always happy to help.