Android Network Monitoring Warning: Read the Trust Change

Three notices look similar on a phone, and only one of them is about a certificate. A VPN status line, a trust-store warning and a managed-device banner each name a different control, and the app on screen at the moment may own none of them. Reading the exact wording first saves you from deleting the wrong thing. Work the five checks below in order and stop at the first that fails, because the right action changes completely at each step.

Step 0: identify which notice you are looking at

The wording matters more than the icon. A VPN status notice means an app holds an active VpnService. A certificate warning means something is installed in a trust store. A managed-device notice means an administrator applied policy, which may have installed trust as part of that policy.

When the text is literally "Network may be monitored", the sender is the system rather than the VPN provider: Android prints that line whenever an app holds an active VpnService, so a mainstream commercial client produces it without putting anything in the trust store. Two of the three notices can be true at once, which is why the complaint usually names the wrong one. If the sentence says a CA is installed, the VPN is a suspect at most, and uninstalling it may leave the warning exactly where it was.

Step 1: find the credential and its store

On Android 9 through 12 the path is Settings, then Security, then Encryption and credentials, then Trusted credentials; Android 13 and later move the same screen under Security and privacy, then More security settings, and OEM skins rename the levels again, so search the settings app for Trusted credentials when the path does not match. The User tab holds authorities installed by a person or an app, and the System tab holds what shipped with the build. An authority pushed by management appears through the device policy or inside a work profile rather than as a casual tap in the user store.

Record the issuer, the validity dates and whoever installed it. If the entry is not in the user store at all, stop here, because it is a system or managed item and it is not yours to delete from a settings screen. Deleting the wrong row there is how a phone loses Wi-Fi or a work login while the trust question stays unanswered.

Step 2: separate a VPN profile's CA from the phone's trust

An OpenVPN profile, or any client that authenticates its server over TLS, can carry a CA used only by that client to verify its own server. A WireGuard profile carries no CA at all: it relies on public-key pairs, so an authority sitting in Android's trust store can never have come from a WireGuard config. That profile-local certificate reaches no other application, and copying it into the system trust store is a separate operation with a separate blast radius. Keeping the two apart is the whole point of this step, because only the second one changes what other apps will accept.

A VPN profile containing a CA is therefore not evidence of interception, and a VPN app is not the owner of a trust entry it never created. The test is cheap: stop the VPN and re-read the notice. If the certificate warning is still there, the VPN did not put it there and removing the app will not remove it.

Step 3: tell a server authority from a client identity

A client identity certificate and its private key authenticate this device to a server. A CA is trusted to authenticate servers to applications. They are stored together and look similar in a list, yet they do entirely different jobs.

Removing a client identity can break Wi-Fi or VPN authentication while doing nothing about HTTPS trust, and removing a CA affects every app that accepts that authority. Decide which of the two you are looking at before pressing anything, because the answer names the owner and the recovery path.

Step 4: ask which apps actually trust it

Android's Network Security Configuration sets the application boundary. Apps targeting API 24 or later trust system authorities by default, while apps targeting API 23 or earlier also trust user-added authorities by default, and an app can name its own anchors, add per-domain rules, or opt out of the defaults entirely.

So "installed on the phone" is not a description of every app's HTTPS trust: a user-added authority may be honoured by an older app, ignored by a current one, and explicitly trusted by an app that ships its own anchors. If the authority was installed for work Wi-Fi, a private web service or an approved inspection setup, the useful question is which applications and profiles depend on it. The Network Security Configuration guide is the reference for how far an installed authority reaches on a given app, and it is the part most summaries of this warning leave out.

Step 5: decide, then record the owner and the exit plan

If the authority is expected, document who installed it, which connections rely on it and how it will be retired. Trusting an authority is a meaningful decision even when no interception is happening today, because the trust is what makes interception possible later.

If it is unexpected, investigate through the device or service owner before entering sensitive data on that phone. If it is obsolete, remove that specific item through whoever installed it, after checking what depends on it, and never start by clearing all credentials. Hiding the warning changes the display and nothing else. A private key or a full profile should never be uploaded to a public certificate-checking service to settle the question.

Before you leave the screen you want three answers: who installed it, which connections rely on it, and how it gets retired.