What should teams do when App Transport Security cannot be enabled globally in an iOS app?

When global enforcement is not immediately possible, teams should treat the exception as temporary and tightly controlled. They should document the business need, isolate the affected domains, and work with network, web, product, and security owners to remove the exception over time. The goal is to minimize exposure while preserving a path to full HTTPS support.

What to do when ATS cannot be enabled globally

app transport security is a policy control, so the practical question is how to contain the exception without normalising it. The right pattern is to make the exception narrow, time-bound, and owned, then keep pressure on the underlying transport issue until the app can move to HTTPS everywhere.

That means documenting why the exception exists, limiting it to the smallest possible domain set, and tracking a removal plan with the teams that control the app, backend, and content paths. The exception should be reviewed as a security debt item, not treated as a permanent configuration choice.

How to scope the exception without weakening the app

Do not use a broad global bypass if only a subset of traffic still depends on legacy transport. Prefer domain-specific ATS exceptions, then isolate the affected hosts, subdomains, or endpoints so the rest of the app still benefits from enforced transport protections. This preserves the default secure posture while keeping the noncompliant surface area visible.

Practitioners should also verify whether the weak link is truly the application, or whether it is one backend dependency, embedded web content, analytics call, or third-party integration. That distinction matters because the remediation path is different: you may be able to fix a single dependency faster than reworking the full app transport model.

Where possible, pair the exception with compensating controls such as certificate validation discipline, minimal data exposure over the affected path, and tight ownership of the affected domains. If the affected traffic carries credentials, tokens, or sensitive user data, the exception should be treated as materially higher risk.

What a cleanup plan should look like

The cleanup plan should identify who owns the legacy endpoint, who can change it, and what milestone removes the exception. Teams should track progress against a concrete target, such as replacing HTTP-only dependencies, updating server-side redirects, or removing obsolete SDKs that still require insecure transport.

It is also useful to align product and web owners early, because these exceptions often survive when no single team feels accountable for the end state. Security can set the control expectation, but the implementation path usually depends on platform, backend, and content owners working from the same remediation backlog.

If the exception exists because of an external dependency, teams should require a decision on whether to replace the dependency, proxy it through a secure path, or formally accept the residual risk for a limited period. The key is that the exception remains explicit and reviewable.

Risk and Threat Considerations

A global ATS bypass expands the chance that traffic will travel over weaker transport paths, which increases exposure to interception, downgrade abuse, and manipulation of content or credentials. The longer the exception stays open, the more likely it becomes that insecure transport is quietly relied on by new features or integrations.

Failure mechanism: A broad exception can allow sensitive requests, tokens, or content to move over endpoints that lack modern transport protections, creating a larger interception and tampering surface.

Impact: User data, session material, and application trust can be exposed, and later remediation becomes harder because insecure dependencies tend to spread once they are tolerated.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.DS-2 — Data-in-Transit Protection	ATS exceptions concern protecting data while it moves between app and server.
Recommendation — Use PR.DS-2 to enforce secure transport for app traffic and retire insecure exceptions.
NIST SP 800-53 Rev 5	SC-8 — Transmission Confidentiality and Integrity	ATS is about protecting transmitted data from interception or tampering.
Recommendation — Apply SC-8 to require encrypted, integrity-protected transport for app communications.
ISO/IEC 27001:2022	A.8.24 — Use of cryptography	ATS exceptions relate to enforcing secure transport and limiting exposure on insecure channels.
Recommendation — Use A.8.24 to mandate secure transport and document any temporary exceptions.

Practitioner Guidance

What to prioritise: Identify the exact domains still requiring the exception and rank them by sensitivity of the data they carry. Endpoints handling authentication, session state, or personal data should be first in the removal queue.

What to verify: Confirm that each exception is domain-scoped, documented, and has a named owner and removal date. If you cannot explain why a domain still needs the bypass, the exception is already too broad.

Decision rule: If the exception protects only a single legacy integration, keep the rest of the app on ATS and treat the legacy path as temporary technical debt. If the exception is platform-wide because the architecture depends on insecure transport, the issue is architectural and should be escalated for redesign.

Practitioner takeaway: The safest way to live with an ATS exception is to make it small, visible, and short-lived, then remove it as soon as the last dependency can support secure transport.