IP hijacking vs. IP theft: what's the difference?

Your customers notice when an application stops responding, an API becomes unreachable or a connection takes an unexpected path. They rarely see the routing and address records behind it. Understanding IP hijacking and IP theft helps your team protect that customer experience—and choose a supply relationship that supports your network long after an address is first assigned.

IP hijacking changes the route; address theft targets control

IP hijacking usually describes an unauthorized BGP announcement that attracts traffic for someone else's address space. The attacker may announce a prefix from an unexpected autonomous system, or announce a more-specific prefix that other networks accept. Traffic can be diverted, intercepted or dropped even while the legitimate address registration remains unchanged.

IP address theft describes unauthorized control or use of address resources. That can involve a compromised registry or supplier account, falsified authorization, or changes to resource records. A routing hijack can be one way to misuse addresses, but a stolen account and a false BGP announcement are different problems with different recovery paths.

Does “IP theft” also mean intellectual-property theft?

Yes. In another context, IP means intellectual property: software code, trade secrets or other protected work. That subject concerns information and rights over creative or commercial assets. Here, IP means Internet Protocol addresses. Keeping the meanings separate helps you send a routing incident to your network team and an information-security incident to the people who can actually resolve it.

For a closer look at the routing mechanism, see our guide to IP address hijacking and Cloudflare's BGP hijacking explanation.

Protect the connections your customers already depend on

An address can sit inside a customer's allowlist, an API integration, a DNS record or a remote-access configuration. An interruption therefore reaches beyond your router: support tickets rise, transactions can fail and customers may need help restoring access. Renumbering introduces another round of coordination, testing and updates.

The commercial objective is straightforward: keep services reachable, detect unexpected changes early and make recovery easier. That is why address protection belongs in the same conversation as capacity, connectivity and continuity—not in a document that nobody opens until there is an outage.

Look at routing and resource records separately

When routing changes but the records do not

Imagine that your hosting prefix is still registered as expected, but an external route monitor sees a new origin ASN. Start by checking whether your team or an authorized upstream made a planned change. If not, compare announcements from more than one network, identify the affected prefix and contact the upstreams carrying the unexpected route. A single local view may miss what customers elsewhere are seeing.

When account access or authorization changes

If contact details, credentials, resource records or routing authorizations change unexpectedly, treat account control as a separate workstream. Secure access, preserve the change history and work directly with the relevant registry or address supplier to restore the correct records. Fixing a BGP announcement alone will not restore a compromised account.

When a configuration mistake looks like an attack

An incorrect origin ASN, an outdated ROA or an overly broad route export can disrupt legitimate traffic without an attacker. Check recent changes alongside external observations. A clear record of your prefixes, authorized origins and upstream contacts shortens the distance between an alert and the right fix.

Build protection around a reachable service

Authorize the routes you intend to announce

A Route Origin Authorization (ROA) associates a prefix with an authorized origin ASN and a maximum announcement length. Keep it aligned with your actual deployment, including legitimate multiple-origin arrangements. A wrong ASN or prefix length can make your own announcement appear invalid to networks that apply origin-validation policy.

RPKI-based Route Origin Validation (ROV) lets networks assess those announcements. A valid result means the origin and prefix length match a covering authorization; it does not validate every hop in the path. An invalid result is a mismatch, while NotFound means no covering authorization was found. Router policy determines how those results affect traffic. Our RPKI guide explains the building blocks.

See the network from your customers' side

Monitor origin changes, new more-specific announcements and reachability from multiple locations. Combine those observations with application checks: a route can exist while a customer-facing service still fails. Give alerts a clear owner and current upstream contact details so detection leads to action.

Protect the accounts that can change your addresses

Use strong, unique credentials, multifactor authentication where available and individual access for the people responsible for resource administration. Keep recovery contacts current and remove access that is no longer needed. These practical steps protect the controls your network relies on every day.

For engineering detail, the primary references are RFC6811 on origin validation and RFC7115 on operational deployment. Test routing-policy changes before applying them widely, so protection supports customer connectivity.

Make the first response about restoring customer service

1. Identify the customer impact. Record affected prefixes, services, locations and the time the disruption began. Check from outside your own network.
2. Compare the intended and observed state. Review origin ASNs, ROAs, resource records and recent changes to distinguish a route problem from an account problem.
3. Bring the right parties together. Give your upstream and address supplier the exact prefixes and evidence. Secure account access if resource control is affected.
4. Verify recovery where customers connect. Recheck routes and applications from multiple networks, then keep monitoring for recurrence.

Having this information ready saves time when your team is under pressure. It also makes it easier for your supplier to help without repeatedly asking you to reconstruct the incident.

Choose an IPv4 supplier that stands behind continuity

Good routing practice protects one part of the journey. Your business also needs a dependable relationship behind the addresses themselves. Buying a block does not remove the registry layer, and a broker introduction does not make the broker your continuity provider.

LARUS supplies IPv4 directly and makes continuity central to the relationship. Lu Heng sets out the first-party case in his analysis of registry risk and LARUS Continuity, including its record through a live registry crisis. For your team, the value is a provider to work with on supply and continuity as your customers grow.

Build the next stage of your network with Unlimited IPv4

New customers should create opportunity, not a scramble for addresses. With Unlimited IPv4 and LARUS Continuity, you can put capacity and continuity into the same expansion plan. Start with the services and locations you want to grow, and build the address relationship around the business your customers rely on.

Frequently asked questions

Can someone hijack an IP address without owning it?

Yes. An unauthorized route can divert traffic without changing the registered resource holder. That is why checking only the registry record will not reveal every routing incident.

Will RPKI prevent every form of IP theft?

RPKI origin validation addresses unauthorized route origins. Account security protects administrative access; route monitoring helps reveal changes; supplier continuity supports the address relationship. Together, these measures address different ways a service can be disrupted.

Does a VPN or firewall solve BGP hijacking?

A VPN can protect traffic carried inside its encrypted tunnel, and a firewall controls traffic at your boundary. Neither changes an unauthorized BGP announcement elsewhere on the Internet. Routing protection and monitoring remain essential.

Why lease directly from LARUS?

You get a direct IPv4 supply relationship built around continuity and growth. Your team can focus on connecting customers, with LARUS as the provider behind the address capacity.