Apple’s Stricter TLS Requirements Are Coming — Here’s Why Intune Admins Can Relax

Apple just quietly raised the security bar for every MDM-managed device on the planet. On April 21, 2026, Apple published support article HT126655 with a deceptively calm title: “Prepare your network environment for stricter security requirements.”

Starting as early as the next major release of iOS, iPadOS, macOS, watchOS, tvOS, and visionOS, Apple operating systems will refuse connections to servers that don’t meet a new, stricter TLS bar — and this applies directly to the most critical workflows in any Apple-at-work environment:

• Mobile Device Management (MDM)
• Declarative Device Management (DDM)
• Automated Device Enrollment (ADE)
• Configuration profile installation
• App installation (including enterprise LOB apps)
• Software updates

If your MDM service, your enrollment endpoints, or any server referenced inside a config profile doesn’t meet Apple’s new requirements — enrollment breaks. App installs break. Profiles fail to install. Updates stall.
Cue the understandable panic across every Intune admin: “Is Intune affected? Do we need to do anything? Is Microsoft ready?”

I had the same questions. So I did what Apple actually tells you to do in the article — I tested it. Locally, on my own Mac, against real Intune endpoints, and then validated with a full sysdiagnose on a managed device.

Here’s the short answer up front, so you can breathe: Intune’s core cloud endpoints already meet Apple’s new FCP v2.1 standard. Zero ATS violations. Validated end-to-end.
The longer answer — what Apple changed, why they changed it, and the handful of things that are actually your responsibility to check — is what the rest of this post is about.

What Apple Is Actually Changing?

Before we panic or pacify, let’s get precise about what Apple is actually enforcing.

The scope: six workflows that matter:

Apple’s new rules apply to network connections directly involved in the following activities:

• Mobile Device Management (MDM) — every command, every check-in
• Declarative Device Management (DDM) — status channel, declarations, activations, assets
• Automated Device Enrollment (ADE) — the Setup Assistant pane that pulls your MDM profile
• Configuration profile installation — every .mobileconfig your device downloads
• App installation — including enterprise LOB app distribution
• Software updates — managed software update flows

If a server involved in any of the above fails the new TLS bar, the connection is refused. No fallback, no warning toast, no “try again later.” It just doesn’t work.

The exemptions: two narrow but important ones:

Apple carved out two specific exceptions:

• SCEP servers — connections to SCEP servers during profile installation or DDM asset resolution are not affected. Your on-prem NDES/SCEP infrastructure gets a pass.
• Content caching servers — even when requesting assets related to app installation or software updates, content caches are exempt.

Everything else in the six workflows above is in scope. Full stop.

The requirements: three things your servers must do

At a high level, any server in the scope above must meet three conditions:

1. Support TLS 1.2 or later. TLS 1.3 is recommended. TLS 1.0 and 1.1 are already off the table.
2. Use ATS-compliant cipher suites. This means Perfect Forward Secrecy (any TLS 1.3 suite, or TLS 1.2 with ECDHE), AEAD ciphers based on AES-GCM with SHA-256/384/512, and for TLS 1.2 specifically — the Extended Master Secret extension (RFC 7627).
3. Present valid certificates that meet ATS standards. Minimum RSA key size 2048 bits, ECDSA minimum 256 bits, leaf certificates signed with SHA-256 or better, no rsa_pkcs15_sha1 signatures, and signature algorithms that are properly advertised in the TLS ClientHello.

For the full specification, Apple points to two developer docs that you’ll want bookmarked:

• App Transport Security
• Functional Package for Transport Layer Security version 2.1 (FCP v2.1 / NIAP)

The timeline: sooner than you think

Apple’s language is careful but clear: “Starting as early as the next major software release.” Read in context — with sysdiagnose tooling already shipping in the 26.4 point releases — this strongly points to iOS/iPadOS/macOS 27 as the enforcement vehicle, historically announced at WWDC in June and shipped in September.

That gives you roughly five months to audit, remediate, and validate. For any server owned by a third-party vendor with a slow change-management process, that window is tighter than it looks.

Why Apple Is Doing This?

It’s tempting to read this as Apple being Apple — raising the security bar because they can. But the “why” here is more specific, and worth understanding if you’re going to explain this change to your security team.

Alignment with NIAP FCP v2.1:
The acronym soup in Apple’s article — FCP v2.1, NIAP, NSRequiresNIAPTLSPackageVersion — isn’t arbitrary branding. It’s Apple aligning its platform with a specific, well-established security baseline:

• NIAP is the National Information Assurance Partnership — a U.S. government body (NSA + NIST) that sets security standards for products used in national security systems.
• The Functional Package for Transport Layer Security (FCP) is NIAP’s formal specification for what a compliant TLS implementation must look like.
• Version 2.1 is the current iteration, and it’s the standard that U.S. federal, defence, and many allied-government procurement processes already require.

By enforcing FCP v2.1 at the OS level for critical device management traffic, it’s like: “Every iOS, iPadOS, macOS, watchOS, tvOS, and visionOS device in the world will now meet the same TLS bar that the U.S. Department of Defense requires for its own procurement.” That’s a significant step. It also quietly solves a commercial problem — organisations with government or regulated workloads no longer need to bolt on custom TLS enforcement to meet compliance. The platform does it for them.

The end of “TLS 1.2 is fine”. For years, “TLS 1.2 or higher” has been the industry shorthand for good enough. Apple is now drawing a sharper line. TLS 1.2 is still allowed, but only if it’s configured correctly — specifically with:

• Perfect Forward Secrecy via ECDHE key exchange (no static RSA)
• AEAD cipher suites based on AES-GCM (no CBC-mode ciphers)
• The Extended Master Secret extension (RFC 7627) — which closes a class of TLS 1.2 protocol attacks like the Triple Handshake

Servers running “TLS 1.2 with defaults” from a few years ago will almost certainly fail on EMS alone. That’s not a theoretical risk — it’s the single most common reason legacy TLS 1.2 deployments break against modern ATS checks.

Crypto hygiene catches up with reality:
The rest of the requirements are a tidy-up of long-deprecated cryptography:

• No RSA keys below 2048 bits — SHA-1 era hardware, still surprisingly common in internal CAs
• No ECDSA keys below 256 bits — trivially weak by modern standards
• No SHA-1 leaf certificates — SHA-1 has been deprecated for a decade, but self-signed and internal PKI often still carries it
• No rsa_pkcs15_sha1 signature algorithms — a specific weak signature scheme that has no place in a 2026 MDM path
• No plaintext HTTP — surprisingly, still a violation worth listing

None of these are new. Apple is simply refusing to keep carrying the legacy any further in the paths that matter most — the ones that install configuration, push apps, and deliver software updates.

Why MDM specifically?
Of all the traffic on a managed device, the MDM/DDM/ADE path is the highest-trust channel there is. A compromise there means an attacker can:

• Push arbitrary configuration profiles
• Install arbitrary apps
• Force software update behaviour
• Intercept enrolment and hijack device identity

A weak TLS configuration on any server in that chain is a downgrade or MITM opportunity against the most privileged channel on the device. It’s the one place where “mostly secure” isn’t an acceptable answer.
That’s the real “why?” Apple isn’t tightening the screws for the sake of it — they’re closing the softest remaining attack surface on their most sensitive workflow.

Does Intune Fulfil the Requirements?

This is the question that matters to anyone running Apple devices through Intune. I rely on Microsoft’s general TLS posture statements but didn’t wanted to have a “trust the cloud” assumption. Apple gave us two validation tools in HT126655 — so I used both, against real Intune endpoints, on my own Mac.

Here’s what I did, and what I found.

Method 1 — Local endpoint validation with nscurl

Apple ships nscurl as part of macOS — no installation, no profile, no lab. It tests any URL against the full ATS matrix, including the new FCP v2.1 mode. The only line that matters for this audit is this one:

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

I ran this against the core Intune MDM endpoints an Apple device actually talks to during enrolment, check-in, profile install, app install, and Company Portal flows.

The test command, for anyone who wants to reproduce:

nscurl https://manage.microsoft.com --ats-diagnostics --verbose

And for batch-checking several endpoints at once, filtering only the FCP v2.1 result:

The results:

Every endpoint in the active Apple MDM path passed Apple’s FCP v2.1 test.

A word on false positives:

During the sweep, one host (m.manage.microsoft.com) returned a FAIL. On investigation — TLS 1.2 ✓, ECDHE-ECDSA-AES256-GCM ✓, EMS ✓, SHA-256 leaf ✓ — the failure was a certificate hostname mismatch: the CDN behind it was serving an *.azureedge.net wildcard SAN that does not cover m.manage.microsoft.com.

Important context: this host is not in the current macOS MDM/enrolment path. If it were, enrolment would already be broken today, because macOS already rejects hostname mismatches. The authoritative Microsoft Learn Intune endpoints reference does not list it as an active enrolment host.

Method 2 — Real-world validation via sysdiagnose

nscurl tests one endpoint at a time. It can’t tell you what mdmclient, profiled, appstored, o managedappdistributiond will actually do on a live device against a real tenant. For that, Apple prescribes the sysdiagnose route — and it’s the authoritative test.

The full procedure is covered later in-detail, but the short version is:

1. Install the Network Diagnostics Logging Profile on a Mac running macOS 26.4+
2. Restart the device
3. Run real MDM workflows against the tenant
4. Collect a sysdiagnose
5. Run Apple’s log show query against the archive

Here’s the query, verbatim from HT126655:

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'"

The result:

Log  - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0

Zero ATS violations. Zero FCP v2.1 violations. Across every MDM-related process, across every connection the device actually made to my Intune tenant, during real workflows.

This is the authoritative result. nscurl proves individual endpoints pass; the sysdiagnose query proves the device’s actual behaviour passes. Both methods agree.

The verdict

Intune’s cloud endpoints meet Apple’s stricter FCP v2.1 TLS requirements today. No remediation required on Microsoft’s side for the Apple MDM path. Enrolment, check-in, profile installation, app distribution, and Company Portal all operate within Apple’s new security bar.

Which is the answer most admins have been waiting for. But it’s not the whole answer — because there are still a handful of things in an Apple-Intune environment that you own, and those do need checking. That’s the next section.

What’s Actually in Scope for You

Intune’s core path is clear. But “Intune is fine” doesn’t mean “your tenant is fine.” A managed Apple device in a real organisation talks to more than just Microsoft’s cloud, and Apple’s new rules apply to every server in the six in-scope workflows — regardless of who runs it.

Here’s the practical breakdown of what Microsoft handles versus what you own.

What Microsoft already handles:

If your tenant only ever talks to Microsoft cloud and Apple cloud, you’re done. But almost no real tenant is that clean.

What you actually own:

These are the failure points Apple will surface in your sysdiagnose logs — none of them are Microsoft’s responsibility to fix.

1. Custom configuration profiles referencing third-party URLs: Any .mobileconfig you ship through Intune that references an external server — VPN concentrators, custom Wi-Fi RADIUS endpoints, internal CA distribution points, MDM webhooks, captive portal check URLs — those servers must meet FCP v2.1.

2. LOB / enterprise app distribution from non-Microsoft origins: If you push iOS or macOS LOB apps via Intune and the install URL points to your own CDN, S3 bucket, internal artifact server, or vendor download URL — that origin is in scope. Intune’s own CDN (*.manage.microsoft.com) is fine; your origin may not be.

3. Custom DDM asset servers: If you’ve started authoring custom DDM declarations that resolve assets from your own server, that server is now MDM-path-critical. The exemption for SCEP does not extend to DDM asset hosts.

4. PKG / DMG download URLs in macOS scripts and shell deployments: Any curl-style download in an Intune macOS shell script that pulls an installer over HTTPS hits the same ATS bar when invoked by an MDM-related process. Vendor download URLs are the most common offenders here — installer CDNs are notoriously slow to roll out modern TLS.

5. Internal PKI distribution and CRL/OCSP endpoints (edge case): SCEP itself is exempt. CRL/OCSP responders referenced by your trust profiles, however, are not explicitly exempt in Apple’s article. If your internal CA’s CRL distribution point is on a host serving plain HTTP or weak TLS, it’s worth auditing — even if it doesn’t break enrolment today, it’s on a tightening trajectory.

6. Self-hosted enrolment URLs (account-driven enrolment): If you’ve configured account-driven user enrolment with a custom service discovery URL on your own domain, that endpoint is in the ADE/enrolment path and must comply.

What you can ignore:

Apple’s article is narrowly scoped to the six device-management workflows. Don’t audit your entire estate — audit the right paths.

A practical audit checklist

Before the next major OS release, walk through every Intune-deployed configuration with this lens:

•  List every URL referenced inside every Apple configuration profile
•  List every install URL for every iOS, iPadOS, and macOS LOB app
•  List every download URL inside every macOS shell script and deployment package
•  List every custom DDM asset server (if you use custom declarations)
•  List your account-driven enrolment service discovery host (if applicable)
•  Test each of the above with nscurl --ats-diagnostics and capture the FCP v2.1 result
•  For any FAIL — open a ticket with the server owner, share Apple’s HT126655, and request remediation

If that list is empty, you’re done. If it isn’t, you now know exactly where to spend your remediation effort — and you have five months to get it done before the next major OS release lands.

How to Validate Your Own Tenant

Apple gives you two validation paths in HT126655. Use both. nscurl is fast and cheap for endpoint-level checks; sysdiagnose is the authoritative real-world test. Below is the full 10-step procedure, in the order Apple prescribes, with the practical adjustments that matter for an Intune-managed Apple estate.

Step 1 — Plan your test coverage:

Different device configurations talk to different servers. To get full coverage, run the audit across each combination that exists in your tenant:

• Environment — production, staging, test
• Device type — iPhone, iPad, Mac, Apple Watch, Apple TV, Apple Vision Pro
• Role — sales, engineering, accounting, kiosk, shared device
• Enrolment type — Automated Device Enrolment, account-driven user enrolment, profile-driven enrolment, Shared iPad

If you only test one device type with one user persona, you’ll miss endpoints that only get hit by other configurations. List every distinct combination you support, then test each.

Step 2 — Local pre-check with nscurl:

Before touching test devices, sweep the obvious endpoints from any Mac. No profile, no restart, no enrolment needed.

for url in \
  https://manage.microsoft.com \
  https://r.manage.microsoft.com \
  https://i.manage.microsoft.com \
  https://portal.manage.microsoft.com \
  https://fef.msua01.manage.microsoft.com
do
  echo "===== $url ====="
  nscurl "$url" --ats-diagnostics 2>/dev/null \
    | awk '/FCP_v2.1$/{flag=1} flag{print; if(/Result/){print "---"; flag=0}}' \
    | head -5
done

Replace the FEF host with the one matching your tenant’s Azure region (msua01, msub01, msuc01, msue01, etc.). Add any custom URLs from your audit checklist.

Expected result for compliant endpoints: FCP_v2.1 → Result : PASS

Step 3 — Install the Network Diagnostics Logging Profile:

Download Apple’s Network Diagnostics Logging Profile and install it on a representative test device running iOS 26.4, iPadOS 26.4, macOS 26.4, watchOS 26.4, tvOS 26.4, or visionOS 26.4 or later. The logging payload only emits the necessary detail on these versions.

Critical caveat for ADE testing on iPhone or iPad: the profile must be installed before the device reaches the Device Management pane in Setup Assistant. Use Apple Configurator on a Mac to push the profile to the device while it’s at the early Setup Assistant screens. If you wait until enrolment completes, the ADE traffic itself won’t be logged — which is the traffic you most need to validate.

Step 4 — Restart the test device:

Apple explicitly requires a restart after profile install. Skip this and the logging subsystem won’t fully engage. Restart, then proceed.

Step 5 — Run your real workflows:

Use the device the way it’s used in production. The goal is to generate traffic to every server that might be in scope. At minimum:

• Complete enrolment (ADE or user-driven, whichever applies)
• Trigger a configuration profile install
• Push and install an app from Intune (Store, VPP, and LOB if you use them)
• Force an MDM check-in (sudo profiles renew -type enrollment on macOS)
• Trigger a DDM declaration update if you use custom DDM
• Initiate a managed software update if available

Don’t just leave the device idle — that won’t surface much. Do real work.

Step 6 — Collect a sysdiagnose:

The diagnostic archive contains the log events you need. Apple’s collection method differs per device type — see Apple’s device-specific instructions. On macOS the shortcut is Ctrl + Option + Shift + Command + Period.

The resulting .tar.gz file lands in /var/tmp/ (macOS) or appears in the device’s diagnostics share. Transfer it to a Mac for analysis.

Step 7 — Run Apple’s log show query

Expand the archive, cd into the top-level directory, and run Apple’s exact query:

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'"

A clean tenant returns:

Log  - Default: 0, Info: 0, Debug: 0, Error: 0, Fault: 0

Any non-zero count means at least one in-scope connection violated the new rules. Drop the --info filter or pass --debug for more detail.

Step 8 — Interpret the warnings:

When the query returns events, each one carries three details:

• Domain — which server failed
• Process — which Apple process made the connection (tells you the workflow)
• Warning — exactly which constraint was violated

Apple documents two warning prefixes: Warning [ATS Violation] for general ATS policy failures and Warning [ATS FCPv2.1 violation] for FCP v2.1-specific failures. The full mapping:

The remediation column tells the server owner exactly what to fix. Send it with the ticket.

Step 9 — Validate remediated servers individually:

After the server owner reports a fix, re-test that server in isolation before re-running the full sysdiagnose:

Look for the FCP_v2.1 block and confirm Result : PASS. Only then move on.

Step 10 — Remediation playbook:

When you find violations:

1. Identify the server owner — internal team, MDM-adjacent vendor, third-party SaaS, or your own infrastructure.
2. Send Apple’s HT126655 article with the specific warning text from your logs. Don’t paraphrase Apple’s requirements — quote them.
3. Set a deadline tied to the next major OS release window. “Before iOS/macOS 27 GA” is the right framing.
4. Track remediation per endpoint — one ticket per non-compliant host.
5. Re-validate with nscurl immediately after the fix, and with a fresh sysdiagnose at the end of the audit cycle.

Document the final state. A signed-off compliance log saves you the second round of questions when the OS release lands and someone asks “are we ready?”.

The Bottom Line

Apple is raising the TLS bar for every device-management workflow on every Apple platform. The change is real, the timeline is short, and the enforcement is hard — failed connections, no fallback.

But for Intune-managed Apple estates, the headline is straightforward.

What’s settled

• Intune’s cloud endpoints already meet Apple’s FCP v2.1 standard. Validated end-to-end via both nscurl and a real-device sysdiagnose. Zero ATS violations.
• Microsoft has nothing to remediate on the core MDM, DDM, ADE, profile, app, or Company Portal paths.
• SCEP and content caching are exempt. Your NDES infrastructure does not need to change for this.

What you need to do

1. Audit your custom URLs — anything inside config profiles, LOB app install URLs, macOS shell script downloads, custom DDM asset hosts, account-driven enrolment endpoints.
2. Test each one with nscurl --ats-diagnostics.
3. Run a real-device sysdiagnose validation against your tenant — exactly the procedure in Section 6.
4. Track and remediate any FAILs against the warning table. Send vendors Apple’s HT126655 with the specific log line.
5. Document the final state. When the next major OS release lands and someone asks “are we ready?”, you have the answer in writing.

What you don’t need to do

• Panic.
• Audit every server in your estate. Apple’s scope is narrow — six specific workflows. Stay inside it.
• Treat TLS 1.3 as mandatory. TLS 1.2 with PFS, AEAD ciphers, and EMS is fully compliant.

The wider point

Apple is doing what Apple does — pushing the platform forward, ahead of the rest of the industry, with little ceremony. FCP v2.1 enforcement on the MDM path is the kind of change that lands quietly in a support article, breaks badly-configured servers six months later, and is forgotten as “obviously the right thing to do” within a year.

The admins who get ahead of it are the ones who treat HT126655 as a checklist, not a warning. Run the audit now, while the OS still tolerates the old behaviour. The five-month window between today and the next major release is the only soft landing you’re going to get.

If your tenant looks like mine — Intune at the core, a manageable handful of custom URLs at the edges — this is a one-afternoon job. If it doesn’t, it’s still better to find out today than the morning after iOS 27 ships.

Run the test. Read the logs. Fix what fails. Move on.

Appendix / Resources

Apple official documentation

• HT126655 — Prepare your network environment for stricter security requirement https://support.apple.com/en-us/126655
• App Transport Security (ATS) — Preventing Insecure Network Connections https://developer.apple.com/documentation/Security/preventing-insecure-network-connections
• NSRequiresNIAPTLSPackageVersion — https://developer.apple.com/documentation/bundleresources/information-property-list/nsrequiresniaptlspackageversion
• Identifying the Source of Blocked Connections https://developer.apple.com/documentation/security/identifying-the-source-of-blocked-connections
• Network Diagnostics Logging Profile + sysdiagnose collection  https://developer.apple.com/feedback-assistant/profiles-and-logs/

Microsoft Intune references

• Network endpoints for Microsoft Intune https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/intune-endpoints
• Microsoft Intune service architecture https://learn.microsoft.com/en-us/intune/intune-service/architecture/

Standards and specifications referenced

• NIAP Functional Package for TLS v2.1 — National Information Assurance Partnership
• RFC 7627 — TLS Session Hash and Extended Master Secret Extension
• RFC 8446 — TLS 1.3
• RFC 5246 — TLS 1.2

nscurl quick reference

Run a full ATS diagnostic against a single URL:

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

Filter only the FCP v2.1 result for a single URL:

nscurl https://example.com --ats-diagnostics 2>/dev/null \
  | awk '/FCP_v2.1$/{flag=1} flag{print; if(/Result/){print "---"; flag=0}}' \
  | head -5

Batch-test multiple URLs:

for url in \
  https://manage.microsoft.com \
  https://r.manage.microsoft.com \
  https://i.manage.microsoft.com \
  https://portal.manage.microsoft.com \
  https://fef.msua01.manage.microsoft.com
do
  echo "===== $url ====="
  nscurl "$url" --ats-diagnostics 2>/dev/null \
    | awk '/FCP_v2.1$/{flag=1} flag{print; if(/Result/){print "---"; flag=0}}' \
    | head -5
done

TLS handshake quick checks (OpenSSL)

Negotiated protocol, cipher, and signature:

openssl s_client -connect HOST:443 -servername HOST -tls1_2 </dev/null 2>/dev/null \
  | grep -E "Protocol|Cipher|Server Temp Key|Signature|Peer sign"

Confirm Extended Master Secret:

openssl s_client -connect HOST:443 -servername HOST -tls1_2 </dev/null 2>&1 \
  | grep -i "extended master secret"

Inspect certificate subject, issuer, and SAN:

openssl s_client -connect HOST:443 -servername HOST -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

openssl s_client -connect HOST:443 -servername HOST -showcerts </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -ext subjectAltName

sysdiagnose — Apple’s authoritative log query:

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'"

Audit checklist:

• Inventory of every custom URL in Apple configuration profiles
• Inventory of every iOS / iPadOS / macOS LOB app install URL 
• Inventory of every download URL inside macOS shell scripts 
• Inventory of custom DDM asset host(s) — if applicable 
• Account-driven enrolment service discovery URL — if applicable 
• nscurl --ats-diagnostics PASS captured for each above 
• Test device on iOS / macOS 26.4+ with Network Diagnostics Logging Profile installed 
• Real workflows executed (enrol, profile, app, check-in, DDM, update) 
• sysdiagnose collected log show query executed — zero violations confirmed 
• All FAILs ticketed with server owners and HT126655 attached 
• Final compliance state documented and shared with security stakeholders