Most networks ask the wrong question at the door.
A traditional firewall asks "is this IP allowed?" An identity-aware mesh asks "is this person allowed, on this device?" That substitution changes what a rule means and what an investigation looks like.
Why the IP question fails
Static IP allowlists were workable when devices stayed at desks. They never recovered from the laptop. The address a user reaches you from depends on which café they walked into; the address you allowlisted yesterday is now the address someone else is sitting behind. So you widen the rules, and the wider they get the less they mean.
Gateway VPNs papered over this by giving every authorised user an address behind the gateway. That answers "did they go through the gateway?" but not "who, and on which laptop?" when the rules are written by subnet.
What changes in an identity-aware mesh
In a mesh VPN, every device has its own cryptographic identity: a key pair created on the device, whose public half the coordination service knows. That makes two things possible.
The source of a packet is provable. In Peerlify, each pair of devices has its own encrypted session. When a packet arrives, the receiving device checks that its source address belongs to the device whose session decrypted it. One device can't send traffic pretending to be another, so "this came from 100.100.0.7" really means "this came from devbook-pro".
Rules can name people and roles, not ranges. Peerlify's access policy is a JSON document whose rules select sources and destinations by tag (tag:prod-app), group (group:ops), role (role:admin), a user's email, or a specific device, down to protocol and port:
{
"name": "ops-to-database",
"action": "accept",
"source": ["group:ops"],
"destination": ["tag:prod-db"],
"ports": ["5432"],
"protocol": ["tcp"]
}The control plane expands those names into the current set of devices, and the device that receives a connection enforces the rule. When someone joins the ops group, or a server is tagged prod-db, the rule follows without anyone editing an IP list.
The downstream effects
Two come up most:
- A lost laptop is one device, not a shared secret. Remove the device in the console and online peers drop it from their peer list within seconds (typically under ten). The person's other devices keep working, and there is no shared VPN password to rotate.
- Investigations start from a device. On Business and Enterprise plans, activity logs record each connection by overlay address, port, protocol, bytes and path, as reported by the device. Because each overlay address belongs to exactly one device, and each device to a member, a connection traces back to a machine and its owner.
What it doesn't fix
Identity-aware doesn't mean trustworthy-by-default. The device still has to be enrolled, the member still has to belong to the network, and a rule still has to allow the connection. A new Peerlify network starts with an allow-all rule so you can get connected; the first real job is to replace it.
Removing someone from your identity provider also isn't enough on its own: an enrolled device keeps its Peerlify session until you remove the device or the member in the console. Offboarding should do both.
Identity gives you the vocabulary. You still have to write the policy. But "is this person allowed, on this device?" is the right question to ask first, and everything else builds on it. For the full picture, see the access control model and Peerlify's security model.