TL;DR - Android 17 enables certificate transparency (CT) verification by default for apps that target API level 37. On Android 16 CT existed but apps had to opt in. The detail that decides whether this is a Tuesday problem or a project is where your certificates sit relative to two different mechanisms: Google's own documentation states that CT verification is not performed on connections that use custom trust anchors, while the Android Enterprise guidance warns that connections relying on private or internal certificates may fail unless those domains are explicitly opted out using a custom Network Security Configuration. The opt-out is application configuration, which means for third-party apps you do not control, you cannot fix it from your MDM console. What you need to do: identify which flows depend on internal certificates, work out which of those live in apps you control, and get the app-side opt-out built before the fleet finishes upgrading.
By The Numbers
| Item | Value |
|---|---|
| Platform change | CT verification on by default |
| Trigger | Apps targeting Android 17 (API level 37) |
| Previous behaviour | Opt-in on Android 16 (API 36) |
| CT covers | Publicly-trusted CAs |
| Custom trust anchors | CT not performed (Android docs) |
| Internal / private certs | May fail unless domains opted out (Android Enterprise) |
| Opt-out location | App's network security configuration |
| Published analysis | 23 September 2026 (HTTP Toolkit) |
I have a test handset on my desk that exists for exactly one reason: to find out whether a security control that looked fine on paper survives contact with a real device. It has spent the last two years being the phone that rejects a proxy certificate, or accepts it, depending on which build I flashed last. This week it went and did the first genuinely interesting thing it has done in a while, and the failure it produced is not the failure most people are expecting from this change.
Because the mainstream reading of Android 17's certificate transparency change is "your internal CA stops working". That reading is wrong in a way that will cost you a week if you act on it, and wrong in a different way that will cost you a week if you dismiss it entirely.
Let me walk you through what actually changed, why the exemption Google documents does not cover the case you are probably worried about, and the three checks that tell you where you sit.
What actually changed
Two sentences from Google's own documentation carry the whole change.
From the behaviour changes list for apps targeting Android 17: "If an app targets Android 17 (API level 37) or higher, certificate transparency (CT) is enabled by default. (On Android 16, CT is available but apps had to opt in.)"
From the Android Enterprise what's-new page for Android 17: "Certificate Transparency (CT) verification will be enabled by default for network connections to protect against MitM attacks. Connections relying on private or internal certificates may fail unless those domains are explicitly opted out using a custom Network Security Configuration."
So the change is a default flip, not a new capability. CT support arrived in Android 16 (API level 36) and sat behind an opt-in that almost nobody used. Android 17 makes it the default for apps built against the current API.
Certificate transparency itself is not mysterious. It is a public, append-only log system, defined in RFC 6962, where certificate authorities record the certificates they issue. A client that enforces CT checks that the certificate it is being shown has evidence of being logged, in the form of signed certificate timestamps. The purpose is to make a rogue certificate visible: if someone persuades a public CA to issue a certificate for your domain, that certificate has to be recorded somewhere the world can audit.
That mechanism has an obvious and important property, and it is the hinge of this whole post: CT only makes sense for publicly-trusted CAs. A private CA that your organisation runs for its own devices is not issued by a body that logs to public CT logs, and no public log would accept its submissions. Google's own CT documentation for enterprises says CT applies to CAs that are supported out of the box, and that manually installed CAs are not covered.
The exemption, and why it does not mean what you think
Here is the sentence from the Android network security configuration documentation that has been quoted in every thread about this change:
"Note: Certificate transparency verification isn't performed on connections that use custom trust anchors."
Read alone, that looks like a complete answer. Your internal CA is a custom trust anchor, therefore CT does not apply, therefore nothing changes. I have seen that sentence used in internal chat to close the topic, and the people using it are not being lazy; they are reading a real Google document accurately.
The problem is that "custom trust anchor" has a specific meaning in Android's configuration model, and it is narrower than "any certificate our organisation installed". A custom trust anchor is a trust anchor the application declares for itself in its network security configuration. That is a statement made by the app about which CAs it will trust, and it is expressed in a config file that ships with (or is injected into) the app.
An internal CA that your organisation installs onto devices through your MDM or a device policy controller is not the same thing. It arrives via the device management path, not the app's configuration, and the Android Enterprise guidance is explicit that connections relying on private or internal certificates may fail unless those domains are explicitly opted out using a custom Network Security Configuration.
So there are two mechanisms that sound identical in a meeting and behave differently in production:
- App-declared custom trust anchors: CT verification is not performed. Exempt by design.
- Enterprise-installed private or internal CAs used for connections: may fail unless the domain is opted out, and the opt-out is in the application's configuration.
That second bullet is the one that generates service desk tickets, and the reason it does is not the certificate. It is where the fix has to live.
The exemption is real, and it lives in application configuration. That is the whole problem, because most service desks cannot deploy an application configuration change to software they do not build.
Why the opt-out location is the actual story
If you run the fleet, you have a mental model where device trust is something you control centrally: your MDM pushes profiles, your CA issues certificates, your Wi-Fi trusts that CA for EAP-TLS, and you have one place to go when it breaks.
CT breaks that model politely and completely. The documented remedy is a per-domain opt-out expressed in the app's network security configuration. For the apps your organisation builds, that is a code change, a release, and a rollout - entirely doable, and worth starting now rather than after the first ticket. For a third-party app you do not build, you cannot write that file. Your options reduce to: ask the vendor to ship an exemption, find out whether the app already handles it, or accept that the connection fails and route around it.
That is why this is not a "policy change you can deploy on a Friday afternoon". It is a discovery exercise about dependencies you did not necessarily know you had, followed by whatever remediation the owner of each app can actually perform.
There is a second-order effect worth flagging to whoever owns your corporate Wi-Fi: the same Android 17 release also enables Encrypted Client Hello and introduces Local Network Protection, which together make a set of network-monitoring techniques that used to be routine on managed mobile networks significantly harder. If your security model assumed you could see inside mobile TLS traffic, or observe which internal hosts a phone is talking to, that assumption is being removed by the platform in this release, not by a policy decision you get to review. CT is the piece that shows up as a broken certificate; ECH and Local Network Protection are the pieces that show up as gaps in your visibility.
The three checks I would run this week
1. Inventory which flows on Android devices depend on a certificate that is not publicly trusted.
Corporate Wi-Fi with EAP-TLS against your internal CA, TLS inspection appliances, internal web apps, captive portals, MDM enrolment endpoints, VPN profiles, and any line-of-business app that talks to an internal service over TLS. Write the list down. Most organisations have never had to enumerate this, because it has quietly worked for a decade.
2. Classify each flow by who owns the app.
For every flow, ask whether the app terminating that connection is one you build, one you can influence, or one you cannot touch. Flows in the first bucket get a network security configuration change and a release train. Flows in the third bucket need a vendor conversation, and those conversations have lead times measured in quarters, so they should start this week rather than after a device upgrade breaks.
3. Confirm the Android Enterprise exemption path and where it is documented.
Android Enterprise documentation for Android 17 covers the CT default and references the domain-level opt-out. If you run a managed fleet, confirm the current guidance with your EMM vendor as well as Google, because the EMM is what surfaces these settings to you, and there is a real difference between "the platform supports an exemption" and "your console has a field for it today".
Key Takeaways
- CT is now on by default for apps targeting API 37. Android 16 had it behind an opt-in that almost nobody enabled. The default flip is the change.
- CT applies to publicly-trusted CAs. Google's own guidance says CT covers out-of-the-box CAs and that manually installed CAs are not covered, which is why your private internal CA is not automatically the casualty.
- Custom trust anchors are exempt, and that word is narrower than it sounds. The exemption covers trust anchors an application declares for itself, not every certificate installed by your MDM.
- Internal-certificate connections may still fail. Android Enterprise warns they can fail unless those domains are explicitly opted out using a custom Network Security Configuration.
- The opt-out lives in app configuration. For software you build, that is a code change. For third-party apps, you cannot deploy it at all, and that is the real project.
- This release also enables ECH and Local Network Protection. If your mobile security model depends on visibility into device traffic, that assumption is being retired by the platform.
- Start with an inventory, not with a fix. The teams that struggle here are the ones who discover their internal-certificate dependencies at the same moment the devices upgrade.
FAQ
Does Android 17 break my internal certificate authority?
Not automatically. Google's documentation states that certificate transparency verification is not performed on connections that use custom trust anchors, and that CT applies to publicly-trusted CAs. Your internal CA becomes a problem where it is used in a way that CT applies to, which is why the inventory matters more than the blanket answer.
What is a custom trust anchor in this context?
A trust anchor declared by the application itself in its network security configuration. That is different from a CA your organisation installs onto the device through your MDM or device policy controller.
Why do the Google docs seem to contradict each other?
They answer different questions. The network security configuration note describes behaviour for app-declared custom trust anchors. The Android Enterprise note warns that connections relying on private or internal certificates may fail unless the domains are opted out. Both are true, and the difference is which mechanism installed the certificate.
Can I fix this from my MDM?
Not directly. The documented opt-out is a per-domain setting in the application's network security configuration. You can control the platform and the device; you cannot write configuration into an app you do not build.
Which Android versions are affected?
CT is available from Android 16 (API level 36), where it was opt-in. Android 17 (API level 37) enables it by default for apps targeting that level.
Does this affect corporate Wi-Fi using EAP-TLS with an internal CA?
It depends on how the trust is established for that connection, which is exactly why the first check is an inventory rather than an assumption. Treat every internal-certificate flow as a question to answer, not as a setting you can reason about from the platform version alone.
Why is this happening at all?
CT makes rogue certificates from publicly-trusted CAs visible, which is why it is a default worth having. The collateral is that it also catches connection patterns that were never designed with public logging in mind, including some that organisations legitimately rely on.
What should I do first?
Enumerate the flows, classify them by who owns the app, and start the vendor conversations for the ones you cannot change. Then handle the app-side configuration changes you can control. The platform change is shipped; the remediation calendar is yours to choose.
My Take
What I find interesting about this one is that the technical change is small and the organisational change is not. Google flipped a default. The default is defensible, the mechanism is sound, and the intent - make certificate forgery by public CAs auditable - is one I would support if it were my call.
The consequence is that a capability many organisations have quietly depended on for a decade is now mediated by a per-app configuration file, and per-app configuration is not a surface most IT teams have ever been asked to manage. We have spent years building tooling to manage devices and certificates, and this landed one layer further up, in other people's applications.
The reasonable response is not to fight the change. It is to notice how much of your internal trust model was implicit. The list you build this week, of which flows depend on which certificates and who owns each app, is useful regardless of what Android does next, because it is the same list you would need if a CA of yours were ever compromised. The platform just decided that this is the week you write it down.
Mathew Clark Founder, SecureInSeconds Currently: has a test phone that has rejected more certificates than most staff have laptops
Further Reading
- Behaviour changes for apps targeting Android 17 (Android Developers)
- What's new for enterprise in Android 17 (Android Enterprise)
- Network security configuration, including the custom trust anchor note (Android Developers)
- Android Certificate Transparency Policy (Android Developers)
- Android 17 enables certificate transparency, and breaks custom CAs (HTTP Toolkit, 23 September 2026)
- Certificate Transparency for enterprises (GoogleChrome/CertificateTransparency)
- F5 BIG-IP: a 9.8 you reach through the auth header, with no credentials
- 440 GitHub Apps were running on leaked private keys
