Allowing user-installed certificates expands the app’s trust boundary beyond preinstalled system roots. That can make man in the middle attacks easier if an attacker or tester installs a certificate on the device. In production, limit trust to system CAs and add a custom CA only when there is a clear operational need, especially for controlled environments.
Why the trust boundary changes when an app accepts user-installed certificates
Android apps normally inherit trust from the device and the network stack the developer expects to control. When an app accepts user-installed certificates, it also trusts certificate authorities that the user or another actor can add to the device. That makes certificate validation a weaker control because the app can no longer assume only preinstalled roots are in play.
That matters most when the app handles sensitive data, session tokens, or internal services over TLS. If the trust store is broadened too far, a locally installed CA can turn a device-level change into application-level trust, which is a much larger exposure than many teams realise.
How this creates man-in-the-middle exposure in practice
The immediate risk is that an attacker who can install a certificate on the device, or a tester running an interception proxy, may be able to present a certificate the app accepts. Once that happens, TLS still appears “successful” to the app, but the traffic can be observed or modified in transit. That is why strict trust configuration is a core part of mobile communication security, not just a checkbox.
This is especially relevant for apps that rely on account login flows, APIs, or embedded administrative functions. If the app does not tightly scope trust, a compromised or overly permissive device can become a practical interception point for credentials, tokens, and sensitive payloads.
When to keep custom trust, and when to avoid it
Most production apps should trust only the system CA store unless there is a clear operational reason to do otherwise. A custom CA can be justified in controlled enterprise environments, private backends, or test setups where the trust model is deliberately managed. Outside those cases, user-installed trust usually increases attack surface without improving the security outcome.
When teams do need custom trust, they should treat it as a deliberate exception with a defined scope, not a default setting. The safer pattern is to constrain trust to known servers or known certificate chains, and to verify that the app does not silently inherit broader trust than intended.
Risk and Threat Considerations
The risk is not just interception, but also false confidence. An app may appear to be using TLS correctly while accepting a locally added trust anchor that undermines the real protection. That can expose credentials, API responses, and business data during debugging, on hostile Wi-Fi, or after device compromise.
Failure mechanism: The app trusts a certificate chain that is not part of the intended production trust base, allowing an added root or intermediate CA to validate a forged endpoint certificate.
Impact: Traffic can be decrypted, altered, or replayed by an interceptor, and any secrets or session material carried by the connection may be exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V12 — Secure Communication | TLS trust scope directly affects secure connection validation in mobile apps. |
| Recommendation — Validate server certificates against a narrowly defined trust store and block unintended CA trust. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | MITM over trusted TLS can expose credentials and session material used by APIs. |
| Recommendation — Protect API authentication flows from interception by enforcing strict transport trust. | ||
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | User-added trust can let an attacker impersonate endpoints during a session. |
| IA-5 — Authenticator Management | Certificate trust changes can expose credentials and tokens that need lifecycle protection. | |
| Recommendation — Verify endpoint authenticity so sessions cannot be redirected to forged certificates. Rotate exposed credentials and tokens when trust boundary abuse is suspected. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Mobile trust stores and app network settings are configuration controls with exposure impact. |
| Recommendation — Harden app and device trust settings to prevent unintended certificate acceptance. | ||
Practitioner Guidance
What to verify: Confirm whether the app’s trust configuration differs between debug, test, and production builds, and whether any network security configuration or library setting widens trust beyond system roots. If interception tools work without an explicit test-only exception, treat that as a deployment defect rather than a convenience.
Decision rule: If a custom CA is required, document the environment, scope it to the smallest possible audience, and remove it from general production builds. If the app cannot function without user-installed trust in production, reconsider the architecture before accepting the risk.
Practitioner takeaway: Certificate trust is part of the app’s security boundary, so the default should be the narrowest trust model that still meets a real operational need.
Related resources from NHI Mgmt Group
- How should security teams reduce risk from malicious Android apps that abuse user trust?
- Why do AI agent approval flows increase trust and access risk if the confirmation step is not tightly bound to an authenticated user?
- Why do older Android environments create certificate trust problems for mobile apps?
- Why does weak certificate governance increase risk in zero trust and multi-cloud environments?
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 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org