CGNAT & Mobile Carrier IPs: Block or Allow?

You spot a fraudulent order, note the IP address, and block it. Reasonable — except that IP might belong to a mobile carrier, and behind it could be several hundred completely legitimate shoppers. Welcome to the world of carrier-grade NAT (CGNAT), one of the most misunderstood traps in IP-based fraud filtering. This fundamentals piece explains why mobile IPs behave so differently, and how to make smart block-or-allow decisions.

What is CGNAT, and why does it exist?

The internet is running out of IPv4 addresses. There are only about 4.3 billion of them, and there are far more devices than that. To cope, mobile carriers and many ISPs use carrier-grade NAT: instead of giving every phone its own public IP, they route large pools of customers through a small number of shared public addresses.

The result: a single public IPv4 address exposed to your Shopify store might represent hundreds or even thousands of individual subscribers behind the carrier's network. When you look at "the IP that placed this order," on mobile you are often looking at a shared gateway, not an individual person.

• Home broadband: typically closer to one household per public IP (though this is changing).
• Mobile carrier via CGNAT: many, many subscribers behind each public IP.

Why this breaks naive IP blocking

Signals. The single most important thing to understand: a mobile carrier IP is a shared resource, not an individual identity.

This has two consequences that trip up merchants constantly:

1. Blocking a mobile IP over-blocks. Ban the address a fraudster used, and you may simultaneously ban every legitimate customer who happens to route through the same carrier gateway. On a busy carrier IP, that could be hundreds of real shoppers. You'll never see the lost sales — they just quietly fail to check out.

1. Rate-limiting a mobile IP misfires. "Three orders from one IP in a minute is suspicious" is a fine rule for a home connection. On a CGNAT gateway serving thousands of subscribers, three orders a minute is completely normal traffic. Blanket velocity rules keyed on the raw IP will flag legitimate mobile activity.

The mobile channel is also huge — for many stores it's the majority of traffic. Over-blocking mobile isn't a minor edge case; it can quietly cap your revenue.

So, block or allow?

The answer is nuanced: generally allow mobile carrier IPs, but don't treat them as trustworthy — treat them as low-information. A mobile IP tells you very little on its own, so you should lean on other signals rather than blocking the address.

Allow (don't hard-block) when:

• The connection is a recognized mobile carrier serving your customer regions.
• The only "signal" is the IP itself. A shared carrier IP is not evidence of fraud.
• You'd otherwise be tempted to apply an IP-level velocity block — resist it for CGNAT ranges.

Scrutinize (but still don't block on IP alone) when:

• The mobile IP is paired with other red flags: mismatched billing/shipping, a brand-new account, unusual order value, or device signals that don't add up.
• The "mobile" IP is actually a VPN or proxy dressed up to look mobile — worth detecting separately.

The rule of thumb: fraud decisions on mobile should be driven by per-order and per-account signals, not per-IP signals. The IP is too shared to carry the weight.

How to handle CGNAT correctly on Shopify

Shopify's raw order data shows you an IP, but it won't tell you that the IP is a heavily shared carrier gateway. You need a fraud layer that understands connection type and shifts its logic accordingly.

Best control. Shieldy — Fraud Filter classifies each connection — mobile carrier, residential, hosting, VPN, proxy, Tor — and adjusts how much weight the IP carries. Instead of a crude IP ban, you get behavior tuned to the connection:

1. Enable connection-type detection so mobile carrier traffic is recognized as such.
2. For mobile/CGNAT connections, rely on AI fraud scoring driven by order- and account-level signals rather than IP velocity.
3. Reserve hard IP blocks for connection types where the address actually identifies an entity — hosting, data-center, and abusive VPN/proxy ranges.
4. If you must limit abuse from a shared gateway, throttle by account or device fingerprint, not by the raw shared IP.

Because enforcement runs at checkout through Shopify Functions, you can block the genuinely fraudulent order without nuking the shared gateway that hundreds of real customers ride.

Catching fraud that hides behind mobile IPs

None of this means mobile is a fraud-free safe harbor. Fraudsters know CGNAT provides cover, and some deliberately route through mobile-looking connections. The trick is to catch them without the blunt IP hammer:

• Watch for proxy/VPN masquerading as mobile. Some anonymization services advertise "mobile" IPs. Connection-type detection that can tell a genuine carrier from a proxy is essential.
• Score the order, not the IP. A mismatched billing country, a freshly created account, a rush order of high-resale-value goods — these travel with the fraudster regardless of which shared IP they're behind.
• Use device and behavioral signals. These persist even when the IP is shared and rotating.
• Layer country rules. A "mobile" connection claiming to be from a region your carrier list doesn't cover deserves a second look.

The takeaway

Carrier-grade NAT means a mobile IP is a crowded shared hallway, not a private address. Blocking or rate-limiting that hallway to stop one bad actor slams the door on everyone else walking through it — and on mobile, that's most of your customers. The correct posture is to allow mobile carrier IPs by default and move your fraud decisions to per-order and per-account signals, where the evidence actually lives.

Want fraud filtering that understands the difference between a shared mobile gateway and a data-center bot? Set up connection-aware rules with Shieldy and stop over-blocking your mobile shoppers.