Why Google Requires QR Codes for New Accounts (p0f)

Starting in late 2025, Google began requiring QR code scans from an existing Android or iOS device for desktop account signups. The shift was confirmed by Google and reported by TechRadar as part of a broader move away from SMS-based authentication. Didn't matter what IP, what browser, what region. No SMS option. No email fallback. Only solution: just a camera pointed at a screen.

This change broke a lot of existing account-creation setups, and it did it in a way that IP quality alone could not fix. We tested residential mobile proxies, premium VPNs, UK and Japanese exit nodes. None of them got past the QR code wall from a desktop connection. Multilogin's 2026 documentation confirms the same wall affecting their entire user base. If you're coming from the broader guide on creating accounts without a phone number, this is the 2026-specific wall that changed things.

Here's what most guides still get wrong: this isn't about IP reputation. Google's detection runs deeper, down at the TCP/IP fingerprint level. Understanding why Google requires the QR code for new signups is the interesting part, and it says a lot about where device-class detection is heading.

Why Every Proxy and VPN Failed: The p0f Problem

Here's what's actually happening at the network level.

Google uses passive OS fingerprinting, commonly known as p0f, to classify incoming connections before the signup page even fully renders. p0f analyzes TCP SYN packet characteristics: initial TTL values, window size, MSS, TCP options ordering, and the DF bit. Each operating system leaves a distinct signature in these values. Windows 10 looks different from Windows 11, Linux looks different from macOS, and critically, iOS looks different from all of them.

When Google's system detects a desktop OS fingerprint (Windows, Linux, standard macOS), it routes the signup flow to QR code verification. When it detects a mobile OS fingerprint, specifically iOS or Android, it offers SMS verification instead. That's it. That's the whole decision tree at this layer.

The cleanest residential IP on earth won't change this. If the TCP fingerprint says "Windows," it's a QR code. Modern bot detection systems operate at multiple layers simultaneously. FingerprintJS's 2025 analysis documents this multi-layered approach combining server-side TLS fingerprints, client-side JS attributes, and cross-verification. But p0f operates before any of that JavaScript even runs.

The Partial Success That Revealed Everything

Attempt #5 failed, but it revealed the actual bypass mechanism.

We tried a generic mobile proxy provider that offered what they called "iOS fingerprinting." It partially worked. Google's signup page actually showed the SMS verification option instead of the QR code. The first time in our entire testing sequence.

But then a completely different wall appeared. Google sent the verification through an iMessage-style deep link that tried to open Apple's Messages app directly. On a desktop browser, even one spoofing mobile Safari, there's no Messages app to open. The whole flow dead-ended at an "Open in Messages" prompt with no fallback to a standard SMS OTP input field.

So the iOS p0f fingerprint was clearly the key to bypassing the QR code at the network layer. But the browser fingerprint needed to match a device that could plausibly receive SMS through a standard input field, not an app deep link.

That pointed directly to the macOS Safari combination.

Why the iPhone-Network + macOS-Browser Combination Passed

The combination works because of how Google splits verification logic across layers.

macOS Safari is a desktop browser that shares Apple's ecosystem identity. Google's system sees an iPhone TCP fingerprint at the network layer (mobile device, so SMS verification eligible) combined with a macOS Safari browser fingerprint at the application layer (desktop Safari, so standard SMS input field instead of Messages deep link).

Google's verification logic reads this as someone on an iPhone hotspot browsing from their Mac, one of the most common multi-device scenarios in Apple's ecosystem. No flags raised. This is consistent with how browser fingerprinting works in practice: platforms cross-reference network-layer signals against application-layer signals, and any inconsistency is a detection trigger.

What the working stack consisted of

The setup that got routed to SMS in our testing had three parts: a dedicated 5G mobile proxy endpoint (not shared or rotating) exposing a mobile-class TCP fingerprint, an antidetect browser presenting a macOS Safari profile, and a carrier-based non-VoIP number for the SMS step.

Why every layer had to agree

The reason this combination held up comes down to consistency across layers rather than any single magic setting. Google reads the TCP fingerprint (network layer), the browser fingerprint (application layer), DNS, and WebRTC together, and scores any contradiction. The stack that passed told the same story at every layer: a mobile-class TCP fingerprint, a macOS Safari browser, carrier-native DNS, and no WebRTC leak.

The failures were the instructive part. A desktop TCP stack put us straight back at the QR wall. A leaking WebRTC exposed the real machine's OS and broke the picture. A mobile-Safari browser fingerprint triggered Google's Messages-app deep link instead of a standard SMS field. Carrier-native DNS mattered for the same reason: a real iPhone on a carrier uses that carrier's resolvers by default, so a third-party resolver is one more detail that does not match. See the carrier-native DNS deep dive for why DNS is part of the fingerprint.

What happened after signup

Once the fingerprint was consistent, the signup itself was unremarkable: Google offered the standard SMS field instead of the QR code, the OTP arrived on a carrier number (non-VoIP numbers come from the same dashboard), and the account was created. The one finding worth noting is that trust stabilized over roughly a 72-hour window of consistent fingerprinting, after which Google's checks became much less sensitive to exact matching.

What Caused the Failures We Saw

Still getting QR code prompt: Almost always a p0f mismatch. This was the root cause in the majority of our failed attempts. Use VoidMob's fingerprint test to check canvas, WebGL, and device signals before testing the proxy's TCP fingerprint using a local p0f instance. If the fingerprint reads as Linux or Windows, the proxy provider isn't actually modifying the TCP stack. They're just changing the User-Agent header, which does nothing at this layer.

SMS prompt appears but redirects to Messages app: The browser fingerprint is set to iOS Safari (mobile) instead of macOS Safari (desktop). Change the browser profile OS from iOS to macOS while keeping the proxy's p0f as iPhone. Small difference in configuration, completely different result.

OTP never arrives: Number quality issue. VoIP numbers face 60-80% rejection rates on platforms with fraud detection. Google accepts the number but never sends the code. Carrier-based numbers only. For a full breakdown of how platforms identify VoIP numbers at the signal level, see the guide on avoiding VoIP detection.

Account locked after 24 hours: In our experience this came down to fingerprint inconsistency between the creation session and the first re-login. Keeping the same profile and proxy endpoint through the first 72 hours avoided it; rotating IPs during that window was the most common cause of lockouts.

FAQ

Why p0f Is the Signal That Matters in 2026

Google's 2026 QR code requirement isn't going away. If anything, more platforms will adopt similar device-class detection in the coming months. Cloudflare's bot management documentation already describes TCP fingerprinting as a standard signal, and Meta's account creation flow has shown similar patterns in how it classifies device types at the network layer.

We went through multiple proxy types, VPN configurations, and browser fingerprint combinations before landing on this finding. The iPhone TCP fingerprint plus macOS Safari browser fingerprint plus clean carrier IP was the only stack that reliably got routed to SMS instead of the QR code wall in our testing.

The detection layer most people don't know exists is p0f. Once you understand it, the QR code behavior stops being mysterious.