21 spoofing attacks. One engineering omission.

A reference card going around r/cybersources last week organizes the canonical spoofing attacks by OSI layer. DNS spoofing at layer 7, TLS spoofing at layer 5, BGP routing spoofing at layer 3, ARP and rogue WiFi at layer 2, GPS spoofing at layer 1. Twenty-one attacks across seven layers, neatly enumerated.[1]It’s a useful flashcard.

It is also a category error.

These aren’t twenty-one attacks. They’re twenty-one places where a protocol decided to act on a sender’s claim without verifying it. The fifty-year history of network security has been bolting cryptographic identity binding onto each one of those places, in order, with deployment lagging the design by ten to twenty years every time.

Once you see spoofing as a single engineering omission expressed at different layers, the entire taxonomy becomes legible — and so does the question of which spoofing attacks are still going to land on your environment in 2026.

The shape of every spoofing attack

Pick any spoofing attack from the list. ARP spoofing, GPS spoofing, DNS spoofing, email spoofing, BGP route hijacking. The structure is identical:

• A protocol exchanges a message containing a claim about identity, origin, or routing.
• The receiver makes a decision based on that claim — cache the mapping, route the packet, render the page, accept the wire transfer.
• The protocol provided no cryptographic mechanism for the receiver to verify the claim. Or it provided one and the receiver skipped it. Or it provided one and the receiver couldn’t use it because the rest of the deployment was incomplete.

That’s the shape. The layer label tells you which protocol contains the unverified claim. It doesn’t tell you anything deeper than that.

Compare a few of the canonical examples and the unity becomes obvious.

ARP spoofing.The claim: “I am the MAC address for this IP.” Verification: none. ARP was designed in 1982 with no authentication mechanism, on the assumption the LAN was a trusted broadcast domain. The attacker on the same segment sends a forged reply and the receiver caches it.[2]

BGP route hijacking.The claim: “My autonomous system originates this prefix.” Verification: until RPKI, none. BGP was designed in 1989 to run between operators who had trust agreements with each other, and the protocol assumed operators wouldn’t lie about routes. When operators (or their attackers) lied anyway, the protocol had no way to tell.

DNS spoofing.The claim: “This name maps to this address.” Verification: until DNSSEC, none. DNS was designed in 1983 to scale, not to authenticate, and resolvers accepted whatever a recursive nameserver returned.

TLS spoofing.The claim: “I am the server for this hostname.” Verification: a chain of certificates rooted in a certificate authority the client trusts — and that verification often did its job, until the attacker compromised a CA or persuaded one to issue a fraudulent certificate. Certificate Transparency closed the “CA quietly issued a bad cert” gap by making issuance publicly auditable.[3]

GPS spoofing.The claim: “I am satellite N at this orbital position, transmitting this navigation message.” Verification: for civilian GPS until very recently, none. GPS was designed in the 1970s by the U.S. military, and the civilian signal was published unauthenticated. Galileo’s OS-NMA, the first widely deployed cryptographically authenticated civilian satellite navigation, only entered operational service in 2025.[4]

Five attacks, five different layers, one structure. The receiver acted on a claim the protocol gave it no way to verify.

The patches all do the same thing

Look at what we built to fix each one and the unity gets stronger.

Every entry in the right column does the same thing in different wrapping: it binds the claim being made at that layer to a cryptographic key the receiver can verify, and it gives the receiver a way to check that the key belongs to the entity the claim names.

DNSSEC binds DNS records to a chain of trust rooted in the root key signing key.[5] RPKI binds BGP route announcements to signed Route Origin Authorizations issued by the regional internet registry that allocated the prefix.[6] 802.1X binds network admission to an EAP-authenticated identity. WPA3-SAE binds WiFi peer presence to a mutually authenticated key exchange. SPF/DKIM/DMARC bind email-from claims to DNS-signed authorization records and a published policy. Certificate Transparency binds CA issuance to a public audit log so unauthorized certificates surface within hours.

Same primitive every time: cryptographic binding of a claim to a verifiable key.The layer changes, the protocol changes, the algorithms change. The shape doesn’t.

Why deployment is the actual problem

If the patches all exist and all do the same thing, why is spoofing still a problem? Because the patches all share another property: deployment is incomplete and unevenly distributed.

DNSSEC has been a published standard since 2005. As of 2025, fewer than 30% of zones globally are signed, and stub-resolver validation is rarer still — most clients accept whatever their recursive resolver tells them.[5]RPKI deployment crossed 50% of global IPv4 prefixes only in 2024, and BGPsec (which authenticates the entire path, not just origin) has effectively zero production deployment. Civilian GPS authentication via OS-NMA only became operational in 2025 and won’t reach handsets at scale for years. ARP authentication via Dynamic ARP Inspection requires switch feature support that many enterprise edge networks still don’t configure. SPF and DKIM are widely deployed; DMARC enforcement (rather than monitoring) is a distinct, smaller fraction of inbox domains.

The pattern: the design is solved, the deployment is partial, and the deployment gap is where active spoofing attacks land. When you read about a 2026 spoofing attack — an internet routing leak, a DNS cache poisoning at a small ISP, a phishing campaign using a homoglyph domain, a GPS spoof against shipping — the attack almost always exploits a layer where the cryptographic patch exists but isn’t deployed at the specific node that mattered.

What this means for defenders

The OSI taxonomy is fine for flashcards. It is a poor working model for defenders, because it groups attacks by which protocol holds the unverified claim — not by what the defender actually has to do about it.

A more useful working frame is three questions:

1. What claim am I trusting?At every protocol boundary in your environment — DNS resolution, TLS handshake, IAM token issuance, MFA push, OAuth consent, agent tool call — the receiver is making a decision based on a claim about identity or origin. Enumerating those claim points is most of the threat model.

2. What verification mechanism exists, and is it configured? The cryptographic patch usually exists. The question is whether your deployment of it is complete. RPKI validation enabled on your transit upstream? DMARC enforcement set to reject, not none? DNSSEC validation on your recursive resolver? FIDO2 enforcement on your IdP, not just offered alongside SMS? Each of those is a binary configuration that either binds the claim or doesn’t.

3. Where does this pattern repeat at the application layer?Modern spoofing isn’t mostly about ARP and BGP anymore. It’s about OAuth consent grants for malicious apps that look like legitimate ones, OIDC silent reauth flows that skip user prompts, agentic AI tool calls where the model accepts a spoofed tool response, and BEC where the email infrastructure was authenticated but the human reading it didn’t know that sender authentication isn’t identity authentication. The engineering omission has migrated up the stack into application and human layers, and the patches are still being designed.

Where this lands on the SecProve domain map

Most of the canonical spoofing list distributes across pillar A: Network Security (A2) for ARP, IP, ICMP, BGP, and rogue WiFi; Cryptography (A15) for TLS, certificate transparency, and the primitives the patches are built on; Identity & Access Management (A6) for the session-layer attacks and modern OAuth / OIDC / FIDO2 work; Zero Trust Architecture (A3) for the principle that ties them together — never act on a claim you haven’t verified, regardless of which side of the perimeter the claim came from.

The flashcard organizes the attacks by where in the OSI stack the unverified claim sits. The domain map organizes the work by which practitioner has to do something about it. Both are right; only one is operational.

The takeaway

Spoofing isn’t twenty-one attacks. It’s one engineering omission — the receiver acting on a claim the protocol gave it no way to verify — expressed at twenty-one places where the omission was made. The patches all do the same thing in different costumes. The reason spoofing still works in 2026 is almost never that the patch doesn’t exist. It’s that the patch isn’t deployed at the specific link that mattered.

Next time someone hands you a flashcard organized by layer, treat it as a list of deployment gaps to audit, not a list of attacks to memorize. The first reading is a study aid. The second reading is a backlog.

References & further reading

1. Nanni, D. Spoofing Attack Types. Link. The reference card this article responds to. A genuinely useful recall aid; the layer-by-layer organization is the canonical way spoofing is taught.
2. Plummer, D. (1982). RFC 826: An Ethernet Address Resolution Protocol. Link. The original ARP specification. There is no authentication in the protocol; LAN trust is assumed.
3. Laurie, B., Langley, A., & Kasper, E. (2013). RFC 6962: Certificate Transparency. Link. CT closes the gap where a CA could issue a fraudulent certificate without the named domain knowing.
4. European Union Agency for the Space Programme (2025). Galileo Open Service Navigation Message Authentication (OS-NMA). Link. The first operational cryptographic authentication of a civilian satellite navigation signal.
5. Arends, R., Austein, R., Larson, M., Massey, D., & Rose, S. (2005). RFC 4033: DNS Security Introduction and Requirements. Link. The DNSSEC framework. Twenty years on, signed-zone deployment remains under one third of authoritative zones globally.
6. Lepinski, M., & Kent, S. (2012). RFC 6480: An Infrastructure to Support Secure Internet Routing. Link. The RPKI architecture. ROA-based origin validation crossed 50% of global IPv4 prefixes only in 2024.