Don’t Use Source IP Addresses As The Primary Authentication Mechanism

In certain US industries, usually legacy businesses with low margins and heavily regulated, it is still quite common to use source IP address as an authentication mechanism on the public internet. Now, never mind that in the age of cloud computing and SaaS applications, it is rare for cloud providers to use static IP addresses and in some extreme cases, the public IP address rotates every few minutes.

I used to work with a client whose entire ecosystem (vendors, suppliers, customers, etc) were all operating under the assumption that every connection over the public internet would involve static IP addresses. By 2010 (and beyond, probably before), this was becoming extremely difficult to rectify with the day-to-day experience. Every new project that involved B2B Integration or customer interactions (B2B users accessing applications the client hosted) seemed to start over at the beginning of the “we need static source IP addresses”, again, with no recollection of the last fifteen projects where that assumption failed to hold. There was much argument, debate, and hurt feelings every time. As this group of companies adopted cloud-hosted solutions, it became harder and more expensive to create stable situations where the source IPs were static addresses. Some of the companies woke up to reality and stopped assuming static IP addresses or just used a cloud-hosted solution for the next project without even considering the legacy static IP address requirements / assumptions. Good for them, but it created further problems with the actors that were still assuming static IP addresses in all situations.

On, at least, one occasion I watched a project team (and their network engineering accomplices) add each source IP address to an ACL with the assumption that eventually the list would repeat. Months and many 100s of source IP addresses later, they had not yet reached the end of the list. No one seemed to be able to accept that they couldn’t use a static list of source IPs as a reliable, primary authentication mechanism (or as anything meaningful). Eventually, a client certificate was provided for authentication purposes to the calling organization and we all moved on with our lives. That was only after much debate about whether or not “using an X509 public-private key-pair was as reliable as using a source IP address for authentication”. There are so many concerning things wrong that statement, I’m not sure where to begin:

• Using a source IP address as a primary authentication mechanism is not safe, has never been safe, and never will be safe.
• A client certificate as an authentication mechanism for a service call is generally a safe approach.
• If you don’t understand the previous two bullet points, you have no business being in a technical, decision-making capacity in an IT department.

I don’t think I ever convinced a couple of individuals that the client certificate was the authentication solution that they really wanted.

On another occasion, I was at a client site that used “Source IP address” as the “Something You Have” part of “Something You Know; Something You Have”. Today, this is referred to as Multi-Factor Authentication. Source IP Address is generally NOT considered a reliable “Something You Have” mechanism.

On yet another occasion, I had a client that had deployed an API Gateway where the authentication step included:

• Source IP Address validation
• Client Certificate
• OAuth2 Access Token (Client Credentials Grant)
• Half dozen custom HTTP headers with various pieces of information that had to be exactly right.

I’m going to call this an extreme overkill. More time was spent managing the source IP address validation component than anything else. The client certificate or OAuth2 Access Token would have been sufficient.

Using a source IP address as your primary authentication mechanism is one of those ideas that looks clean on a whiteboard and then immediately collapses in the real world. It’s fragile, unreliable, and often outright dangerous. Source IP ACLs as a primary form of authentication:

• doesn’t represent identity
• Is relatively easy to bypass with IP spoofing
• is complicated by broken assumptions when NATting and shared infrastructure.
• becomes complicated because IP addresses can be dynamic and unstable
• becomes meaningless with VPNs and proxies (the resource being protected no longer sees the caller’s true location).
• breaks in modern architectures (cloud & microservices)
• provides no protection against credential theft or session hijacking
• is a poor fit with Zero Trust Architecture
• provides little or no protection against insider and lateral movement risk
• is an endless source of operational headaches

The Issues

IP Addresses Don’t Represent An Identity

I’ll repeat that again. IP Addresses don’t represent an identity.

It doesn’t matter if it is static or dynamic, public or private, on a network you own or not.

An IP address identifies a network location, not a user, device, process, or other principal.

• Multiple users can share one IP (think NAT, corporate networks, wifi, mobile carriers).
• One user can have many IPs (VPNs, roaming devices, cloud workloads).
• You’re authenticating “where traffic came from,” not “who sent it.”

Easy To Bypass With IP Spoofing

Attackers can forge / spoof source IPs in certain scenarios:

• Stateless protocols (like UDP) are especially vulnerable.
• Even in TCP, attackers can abuse misconfigured systems or trust boundaries.

If your system trusts IP alone, you’re basically saying: “If it looks like it came from here, I believe it.” This is not authentication; it’s wishful thinking.

NAT And Shared Infrastructure Break Assumptions

With Network Address Translation:

• Hundreds or thousands of users may appear as a single public IP.
• Blocking or allowing that IP affects everyone behind it.
• You can’t distinguish legitimate users from the malicious ones by IP address.
• Scenarios with multiple layers of NATs makes this even more dubious — imagine trying to troubleshoot it. I once had a client with an issue involving API calls where there were four layers of NATs.

IP Addresses Can Be Dynamic And Unstable

• ISPs frequently rotate IPs.
• Mobile networks change IPs constantly.
• Cloud instances get reassigned IPs.
• Some Cloud Providers intentionally rotate source IPs of internet egress traffic.

So your “trusted” client might suddenly get locked out — or worse, a different user inherits that IP and gets access.

VPNs and Proxies Make Location Meaningless

Anyone can route traffic through:

• Commercial VPN services
• Residential proxy networks
• Compromised hosts
• There are rotating proxy services that will accomplish the same rotating / random IP address per request (or time frame) for that can be used by anyone.

This completely undermines IP-based trust. You’re not validating origin; you’re validating the last hop, which is meaningless.

Breaks In Modern Architectures (Cloud & Microservices)

In environments using:

• Load balancers
• Reverse proxies
• Service meshes

The “source IP” you see is often:

• The proxy’s IP, not the client’s
• Passed via headers like X-Forwarded-For (which can be spoofed if not handled carefully)

So now you’re trusting metadata layered on top of already weak assumptions.

No Protection Against Credential Theft Or Session Hijacking

IP-based authentication doesn’t verify:

• Passwords
• Keys
• Tokens
• Device identity

If an attacker gains network access from a “trusted” IP range, they’re in. No further checks.

Poor Fit With Zero-Trust Architecture

Modern security assumes: “Never trust, always verify.”

IP-based authentication does the opposite: “Trust this location implicitly.”

That’s why it’s largely deprecated as a primary authentication mechanism.

Insider and Lateral Movement Risk

If a system trusts internal IP ranges (e.g., 10.0.0.0/8):

• Any compromised internal host becomes a launchpad.
• Attackers can move laterally without resistance.

This is a classic failure mode in flat networks, which brings us back to why network segmentation is really important.

Operational Headaches

• Managing allowlists becomes tedious and error-prone.
• Debugging access issues is painful (“why did this IP change?”).
• Scaling across regions or cloud providers becomes messy.
• Imagine a firewall or a WAF with 1000s of source IP restrictions in it that must be maintained (plus all the drama associated with the other issues mentioned earlier).

When IP-Based Controls Do Make Sense

IP-based controls are not useless — they’re just not “good” for primary authentication mechanisms.

Use it as:

• A supplementary control (defense-in-depth)
• Network-level filtering (firewalls, geo restrictions)
• Conditional access signals (risk scoring)

Better alternatives

Instead of relying on source IP address as an authentication mechanism in any form, consider:

• Strong authentication (passwords + MFA)
• Mutual TLS (MASSL / MATSL) with propert secrets storage best practices
• API keys with rotation
• OAuth2 / Identity Tokens (this is my go to solution for many use cases).
• Device identity and posture checks

Summary

Using source IP as your primary authentication mechanism is like recognizing someone solely by the street they walked in from. It might work in a quiet village. On the modern internet, it’s an invitation to get burned.

Source IP address may be an acceptable secondary form of authentication, but even that has a long list of exceptions and questionable scenarios.

Notes:

• AI / GenAI / ChatGPT / etc were not used to generate this article.
• I used em dashes in my writing before the current GenAI wave was a thing. Not planning on changing now..
• Names have been changed to protect the guilty.
• None of the hostname or users used in examples actually exist.
• Feel free to post any comments or suggestions below.