You configure App Transport Security to require modern TLS by keeping exceptions to a minimum and only relaxing them for clearly justified endpoints. Prefer strong cipher suites and certificate validation defaults rather than broad per-domain overrides. Review any ATS exceptions during release testing, because each exception expands the attack surface for interception or downgrade of app traffic.
What “strong TLS settings” means under App Transport Security
On iOS, app transport security is the policy layer that tells the operating system what your app will accept when it opens network connections. Strong TLS settings mean you let ATS enforce modern TLS by default, and you only weaken it for narrowly scoped endpoints when there is a documented business or technical reason. The goal is to keep transport security strong without turning exceptions into a habit.
In practice, that means treating ATS as the baseline and exceptions as temporary risk decisions. For most apps, the secure default is enough: modern TLS, strong ciphers, certificate validation, and no reliance on obsolete protocols. When a backend cannot meet that standard, the exception should be explicit, domain-specific, and revisited rather than left to drift across releases.
How to structure ATS exceptions without weakening the app
The cleanest configuration is the one with the fewest exceptions. Prefer the system defaults first, then add only the smallest override needed for a specific endpoint or capability. A broad global relaxation is usually the wrong trade-off because it silently lowers the protection for every request the app makes, not just the one legacy service that forced the exception.
When an exception is unavoidable, keep it as narrow as possible and align it with the exact transport property that needs relief. That usually means avoiding broad “allow insecure loads” style settings and instead targeting a single domain or narrowly defined trust requirement. This keeps the rest of the app on the strongest path and limits the blast radius if the exception is abused or misapplied.
Strong ATS posture also depends on how your app validates the server. TLS is not only about encryption in transit, it is also about making sure the client is talking to the intended server. If you relax validation too far, the app becomes easier to intercept through captive portals, malicious Wi-Fi, enterprise proxies, or downgrade paths that exploit weak configuration rather than protocol flaws.
What to check before you ship an ATS change
Release testing should include a review of every ATS exception, not just functional connectivity tests. An endpoint that “works” with a relaxed setting may still be weaker than you expect if it accepts older TLS, relies on weak server configuration, or behaves differently behind a proxy. Review the exception list as part of your security sign-off, not as an afterthought once the app is already in distribution.
It also helps to test the failure mode, not only the success path. Confirm that the app still behaves safely when the server presents an unexpected certificate chain, when transport negotiation fails, or when a legacy endpoint is removed. If the application silently falls back in ways you did not intend, that is usually a sign the ATS policy is not as tight as you think.
For broader mobile hardening, pair ATS review with the rest of your mobile security checklist. NHI Management Group’s Mobile App Security Guide is a useful companion when you want to place TLS policy alongside certificate handling, key storage, and mobile app testing discipline.
Risk and Threat Considerations
Weak ATS settings mainly increase interception and downgrade risk. If the app accepts overly broad exceptions, an attacker who can influence the network path may have an easier route to read, alter, or redirect traffic that the app should have protected by default.
Failure mechanism: The app bypasses modern transport expectations for one or more endpoints, which can allow downgraded TLS negotiation, weaker certificate handling, or broader exposure to man-in-the-middle interception.
Impact: Sensitive API traffic, session material, or user data may be exposed or manipulated in transit, and the weakness can persist across releases if the exception is never revisited.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | ATS governs secure TLS transport for app communications. |
| Recommendation — Enforce V12 requirements for strong TLS and certificate validation on all app connections. | ||
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | TLS settings directly control confidentiality and integrity of data in transit. |
| Recommendation — Require SC-8 protections for sensitive app traffic and disallow weak transport exceptions. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of Cryptography | Strong TLS settings are part of using cryptography to protect data in transit. |
| Recommendation — Apply A.8.24 to mandate strong cryptographic transport settings and review exceptions. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Secure transport configuration is a network hardening concern for internet-facing app traffic. |
| Recommendation — Harden network transport settings and remove unnecessary insecure connection exceptions. | ||
Practitioner Guidance
What to verify: Treat every ATS exception as a controlled deviation. Verify that the endpoint truly requires it, that the override is as narrow as the platform allows, and that the server owner understands the operational reason for the exception.
Common mistake: Teams often approve an exception to unblock a release and then leave it in place indefinitely. That is the point where a temporary compatibility fix becomes a standing transport downgrade.
Practitioner takeaway: Use ATS to make the secure path the default, then manage any exception as a time-bound risk decision with an owner, a review date, and a clear removal criterion.
Related resources from NHI Mgmt Group
- How should security teams implement App Transport Security across iOS apps and backend services?
- What are the signs that an iOS app is not properly enforcing App Transport Security?
- What should teams do when App Transport Security cannot be enabled globally in an iOS app?
- iOS App Transport Security (ATS)
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org