Network Address Translation is often described as a security feature. Many networks rely on NAT with the assumption that it “blocks incoming traffic” and therefore provides protection similar to a firewall.
This assumption is widespread, convenient — and fundamentally incorrect.
At its core, NAT rewrites packet headers. It changes source or destination addresses (and often ports) so that multiple internal hosts can share a single external IP address.
That is all. No security model is implied. No policy is enforced. NAT does not decide which traffic is allowed or forbidden — it only translates addresses.
In most consumer setups, NAT is combined with state tracking. Outbound connections create temporary translation entries, and only packets matching those entries are forwarded back inside.
From the outside, unsolicited inbound packets are dropped. This behavior feels like filtering, even though the decision is based on translation state, not on security rules.
A firewall enforces intent. It answers questions like: which hosts may talk to which services, under which conditions, and in which direction.
NAT answers a different question entirely: how should packet addresses be rewritten so replies can find their way back.
The fact that both mechanisms track state does not make them equivalent.
As soon as you add port forwarding, NAT stops looking protective. Incoming connections are suddenly allowed — not because the network became less secure, but because translation rules were added.
At this point it becomes clear that NAT was never making a security decision. It was merely following mapping rules.
Designing a network under the assumption that NAT provides security leads to fragile systems. When the topology changes, or when IPv6 removes the need for NAT entirely, the illusion collapses.
Security should be explicit, inspectable, and intentional. NAT provides none of these properties.