Google Is Linking Phone Numbers to Android Accounts: The Technical Breakdown and How to Stop It

Over the past several months, Google Play Services has started verifying the phone number on an Android device and attaching it to every Google account signed in on that device. That includes secondary profiles, corporate work accounts, development environments, and pseudonymous handles. At no point does it show the user a consent prompt.

The change first surfaced in a detailed Reddit thread on r/Android. Testing by Android Authority and Kaspersky, plus discussion on Slashdot and Hacker News, backed it up. Most users find out when an automated email from noreply-phone-verification@google.com tells them their personal SIM’s number has been verified on an account they kept isolated from their main identity.

Nothing here is a breach or malware. Google’s Android Help Center describes the behavior as the default, and the page was updated between late 2025 and early 2026 to say so. It is an opt-out data linkage running at the OS level, and for anyone who keeps personal, professional, and pseudonymous identities apart, it undoes that separation.

This post covers how the “Constellation” subsystem works, the two verification pathways (legacy silent SMS and the GSMA Open Gateway), what the linkage does to your OPSEC, and how to audit and remove it.

From per-account verification to device-wide identity graphing

For years, Google used phone number verification for a single job – confirming that the SIM in the device matched the number on a single primary Google account. That supported RCS in Google Messages, account recovery, and basic 2FA. Requests were tied to one account context and usually needed the user to start them or agree.

The scope is now much wider, and identity management people call the result deterministic identity graphing. Google’s Android Help Center page (support.google.com/android/answer/7521240) says:

“On your device, phone number verification is turned on by default. We verify the phone number and add them to all Google Accounts that are signed in on the device. This applies to both current and future accounts and phone numbers.”

That turned a per-account security tool into a device-wide default, with no notification, consent dialog, or opt-in step during Android setup. The system assumes you agree to tie the hardware’s cellular identity to every account you sign in with.

Say you have a personal Gmail account, a corporate Google Workspace account, and a burner account for testing untrusted apps or poking at hostile infrastructure. Constellation links your real phone number to all three. Inside Google’s backend, three identities that used to be separate can now be resolved as one entity.

How Constellation works

Phone number verification on modern Android is not a single API call. It is a layered system in Google Play Services (com.google.android.gms) that draws on device telemetry, baseband queries, and carrier-side infrastructure. Google’s internal name for it is “Constellation.”

The debug interface

Google gives end users no granular control over Constellation, but it has a hidden debug activity. The open-source Play Services reimplementation microG turned it up in GitHub issue #2994, on RCS support. With ADB access on a compatible build, you can launch it like this:

adb shell am start -n com.google.android.gms/.constellation.ui.ConstellationDebugActivity

The activity shows the verification state machine: current status, the cryptographic tokens tied to the SIM, the carrier response data used to validate the hardware, and the list of Google Account IDs (GAIDs) the verified number has been pushed to. It also makes clear that Constellation runs as a persistent background service, watching the device’s telephony state and syncing it with Google’s identity servers.

Two verification pathways

Kaspersky‘s mid-2026 analysis found that Constellation picks between two methods depending on device model, Android version, and what the mobile network operator (MNO) supports.

Legacy: Type 0 silent SMS and baseband queries

Older devices, and networks without modern API gateways, get a Type 0 SMS, also called a silent ping. A Type 0 message carries a specific Protocol Identifier (PID) that tells the baseband processor to acknowledge receipt to the tower, updating the carrier’s Home Location Register (HLR) or Visitor Location Register (VLR), without passing the payload to the application processor or the UI. Play Services uses it to query the SIM’s ICCID (Integrated Circuit Card Identifier) and IMSI (International Mobile Subscriber Identity).

You will never see these pings in your SMS inbox, but they cross the carrier’s signaling network. On some billing setups, mainly prepaid carriers and certain enterprise MVNOs, they can trigger SMS origination charges or show up in deep carrier signaling logs. Because the method depends on traditional SMS signaling, it is also still theoretically open to SS7/Diameter interception and SMS gateway spoofing.

Modern: GSMA Open Gateway and the Camara API

On newer devices with participating tier-one carriers, Google has moved to direct carrier API queries, which avoid the vulnerabilities and costs of silent SMS. This path uses the GSMA Open Gateway initiative and the Camara API framework, specifically the Number Verify API. The device’s cellular data connection is routed through the carrier’s core network. The carrier’s API gateway matches the IP address and cellular session data to the active MSISDN (Mobile Station International Subscriber Directory Number) and returns a cryptographically signed token to Play Services.

This skips the SMS network, so there are no delivery delays, no SMS spoofing, and no per-message charges. The price is deep, continuous, privileged integration between Google and the operator. You cannot choose between the two pathways. The Constellation logic hardcodes the choice from the carrier’s MCC/MNC (Mobile Country Code / Mobile Network Code) and the device’s current network capabilities.

The RCS dependency

RCS is the lever that makes this verification hard to refuse. It is the messaging standard behind “Chat features” in Google Messages, with end-to-end encryption (E2EE), read receipts, typing indicators, high-resolution media, and cross-platform interoperability. Unlike SMS, which routes through the carrier’s signaling infrastructure whatever your Google account state, RCS runs through Google’s proprietary Jibe servers.

Jibe needs continuous cryptographic proof that the SIM tied to a phone number is physically present and active in the requesting device. Google’s support documentation, and several technical analyses, agree on the consequence: turning off phone number verification at the OS level forces Google Messages back to unencrypted SMS and MMS for all conversations.

So the privacy-preserving choice costs you a core feature. Google has pushed RCS hard as the better and more secure replacement for SMS, which makes it the messaging default Android users expect. Most people will not give up E2EE and modern messaging to avoid the identity linkage, so they accept the linkage.

Google justifies the wider scope as anti-fraud and anti-spoofing. It has confirmed that verified numbers feed Android’s fake call detection. When both caller and recipient have numbers verified through Constellation, on-device machine learning models can spot spoofed numbers and block spam calls more reliably. That benefit is real. It also comes from enlarging the data linkage surface and shrinking user anonymity.

privacy implications

The privacy and security communities reacted badly. An Android Authority poll found that 85% of respondents trust Google’s services less because of this change. The operational consequences matter more than the sentiment, especially for high-risk threat models.

Account compartmentalization collapses

The groups hit hardest:

• Security researchers and penetration testers who keep dedicated, isolated accounts for testing, vulnerability disclosure, and contact with malicious infrastructure. A real-world phone number on those accounts gives an adversary a direct attribution path to the researcher.
• Journalists and confidential sources who depend on burner accounts and separate profiles. A phone number linkage can deanonymize a source or expose a journalist’s methods to state-sponsored surveillance.
• Professionals who keep personal and corporate Google Workspace environments strictly apart. A personal number showing up in a work account’s recovery options can break internal security policy, data residency law, or compliance requirements such as HIPAA or GDPR.

The number does not have to be visible on the account profile to do damage. It sits in Google’s internal identity graph as a shared, deterministic identifier across accounts that were previously unlinked, and for compartmentalization purposes that is the same as zero separation.

Recovery paths get tangled, SIM swaps get worse

A verified phone number drives account recovery and authentication: password recovery by SMS, SMS-based 2FA, and sign-in with phone number plus device passcode. Once one number is silently attached to several compartmentalized accounts, their recovery paths are tied together. An attacker who takes over the number, through SIM swapping, carrier social engineering, or physical device extraction, can start recovery on every linked account at once. Compromising several independent recovery channels used to be the cost of attacking compartmentalized accounts. Now one SIM is a single point of failure for all of them.

Metadata and the carrier trust boundary

Even if RCS messages are end-to-end encrypted, verification itself exchanges sensitive identifiers (ICCID, IMSI, IP addresses) between the device, Google’s servers, and the carrier. As the Electronic Frontier Foundation (EFF) has said in related contexts, relying on platform-level verification means trusting both the platform and the telecom provider with your hardware identity.

The toggle bug

People who find the feature and switch it off in Android settings often report that it switches itself back on. Reports on r/degoogle and the GrapheneOS forums describe “Verify phone numbers automatically” reverting after a restart, a Play Services update, or a stretch of network activity. Google has not acknowledged a bug.

The most plausible explanation is that the RCS provisioning service in Play Services re-triggers the Constellation verification routine. If you disable the master toggle but keep using RCS chats, the Jibe client sees that the active SIM has no valid verification token. It then broadcasts an intent to Constellation, which flips the master toggle back on and starts a fresh handshake to restore RCS. That is a dark pattern loop, and the only reliable way to break it is to disable RCS “Chat features” in Google Messages too. As covered above, that leaves you on unencrypted SMS.

How to audit and remove the Phone Number Linking

One setting will not fix this. The OS toggle only prevents future linkages and does not remove your number from accounts it has already been linked to.

Disable automatic verification at the OS level

This stops Constellation from starting new handshakes for future accounts or newly inserted SIMs.

1. Open Settings.
2. Tap Google (on some OEM skins, Google services and preferences).
3. Open the All services tab.
4. Scroll to Privacy & security.
5. Tap Phone number verification.
6. Turn off Verify phone numbers automatically.
7. If a warning says this will disable RCS or Chat features, accept it if you want the setting to stay off.

Some users report success enforcing this from a desktop browser at myaccount.google.com/phone, though the OS toggle is the main control.

Audit every account and remove the number

1. In a secure browser, go to myaccount.google.com/personal-info.
2. Scroll to Contact info and tap Phone.
3. Review the numbers on the account. Your device’s primary SIM number is probably there even though you never added it to this account.
4. Select the unwanted number and choose Delete or Remove.
5. Repeat for every Google account signed in on the device: personal accounts, corporate Workspace accounts, secondary aliases, and any forgotten burners.

Mitigation for high-risk threat models

If you need strict compartmentalization and cannot accept the identity graphing built into Google Play Services, the standard toggles are not enough.

• GrapheneOS or CalyxOS with sandboxed Play Services: restrict Play Services through the OS permission manager and revoke READ_PHONE_STATE and SEND_SMS. This will break RCS and probably Google Pay and Wallet.
• Drop RCS in Google Messages: move to an E2EE messenger that does not depend on Jibe or carrier MSISDN verification, such as Signal, Threema, or Session. These rely on cryptographic keys and usernames, not SIM-based identity.
• Dedicated hardware: the strongest defense against hardware-level identity linkage is physical separation. Keep a burner device with a prepaid SIM and a separate Google account ecosystem that never touches your personal or professional hardware.

Watch for re-enablement

Because of the toggle bug, check Settings > Google > All services > Phone number verification periodically. If it has turned itself back on, disable it again and temporarily turn off RCS in Google Messages to break the loop.

Google’s position and the wider pattern

Google’s documentation confirms the default-on behavior and the account-wide linkage. It says the feature supports “account sign-in, account recovery, emergency services, and communication features,” and that Google and mobile carriers “periodically check that numbers still belong to the user.”

It does not explain why existing users got no explicit consent prompt, why highly sensitive identity linkage is opt-out instead of opt-in, or why the disable toggle often fails to stick. Google has not issued a formal public statement on the OPSEC concerns the security community has raised.

The change fits a pattern of Google tying hardware identifiers, accounts, and platform access more tightly together. Google has begun limiting new Gmail accounts to 5 GB of free storage unless the user verifies a personal phone number, which critics say pushes people to hand over their numbers and erodes anonymity for new users. It is also deepening carrier integration through partnerships with Deutsche Telekom, Telefónica, and AT&T under GSMA Open Gateway. Taken together, these point toward phone number verification becoming a fixed part of Google’s identity and anti-abuse infrastructure, in line with an industry-wide push for verified, real-world identity as a condition of platform access. Privacy advocates read that as the end of digital pseudonymity.

Conclusion

Making phone number verification a default, device-wide, account-wide behavior shifts the balance between convenience, security, and privacy on Android. The benefits are real: smoother RCS messaging, easier account recovery, and better anti-spoofing. They come from changing how physical hardware relates to digital identity.

If you have one Google account and no particular threat model, you will probably barely notice. If account separation is part of your privacy, security, or professional practice, the change matters a lot. The linkage persists, the opt-out does not undo existing associations, and the RCS dependency makes turning verification off expensive.

So audit. Check your device settings, remove the number from every account’s recovery info, and decide with the trade-offs in front of you whether Google’s messaging stack is worth using.

Frequently asked questions

Is this silent phone number linking a data breach or a security vulnerability?

No. It is documented Google behavior, and its support documentation describes the default-on verification and account-wide linkage. The concern is privacy, consent, and operational security. Nobody outside Google gained unauthorized access.

Will disabling “Verify phone numbers automatically” remove my number from accounts it has already been linked to?

No. The OS-level toggle only prevents future linking. For each account, go to myaccount.google.com/personal-info and remove the number from “Contact info.”

Does this affect Android Work Profiles and managed corporate accounts?

Yes. Constellation applies the linkage to all Google accounts authenticated on the device, including those inside Work Profiles. If your organization has strict rules about mixing personal data with corporate Google Workspace, the automatic linkage can create serious compliance and security problems.

Will disabling phone number verification permanently break RCS?

In almost all cases, yes. RCS in Google Messages needs an active, valid verification token tied to the SIM. With OS verification off, Google Messages falls back to unencrypted SMS and MMS for all conversations.

Why did I get an email from noreply-phone-verification@google.com?

Constellation sends it when it finishes a verification handshake with your carrier and pushes the verified MSISDN to a Google account. Getting it on an account you considered separate is the clearest sign the device-wide linkage has happened.

Can GrapheneOS or custom ROM users avoid this?

Only partly. GrapheneOS and CalyxOS users get this behavior if they have installed Sandboxed Google Play Services and granted it telephony permissions, because the mechanism lives in Play Services and not in the base Android Open Source Project (AOSP) code. Fully de-Googled ROMs without Play Services are not subject to Constellation.

Does this affect SMS-based two-factor authentication (2FA)?

Yes. Linking your primary SIM to all your accounts makes that SIM the default recovery and 2FA path for each of them. That raises your exposure to SIM swapping, since compromising one SIM can reach the recovery flows of every linked account.