Respond to a security incident

Read this before you need it. Each step names the exact control and what it does and doesn't do.

A device is lost or stolen

1. Remove it from the network. Open Devices, find the device, open its ⋯ menu and choose Remove from network. Within about 10 seconds it loses all peers and no peer accepts traffic from it.
2. Stop it from rejoining. Removal doesn't end the device's session, so a device owned by a person can rejoin on its own. To prevent that:
   • turn on Settings → Device Management → Manual device approval, so a rejoining device waits for approval, and
   • if the device was signed in under your account, open its page before removing it and click Force log out. For anyone else's device, ask its owner to do the same from their account.
3. Rotate what it could reach. Treat credentials stored on, or reachable from, the device as exposed: SSH keys, browser sessions, service passwords.
4. Review recent activity. In Logs → Admin panel, search for the device's name. On Business and Enterprise, check Logs → Networking for connections from its address.

On Linux and macOS, a device's keys and session token are stored unencrypted in its state folder (readable only by root). Anyone who copied that folder can act as the device until its session is revoked or expires; removing the device alone isn't enough (see step 2). See Device security.

A person's account is compromised, or someone leaves

1. Remove their devices. On Devices, search for their name (the search matches the owner's display name, not their email) and choose Remove from network for each device. Do this first: removing the person doesn't disconnect their devices.
2. Remove them from the network. On Members, open their ⋯ menu and choose Remove member. This also revokes the auth keys they created in this network. If your identity provider manages them through provisioning, deactivate them there instead: that suspends them in the network and ends their device sessions.
3. Revoke their API tokens. Tokens keep working after their creator is removed. Find their api_token.create entries in Logs → Admin panel, then revoke those tokens in Settings → Keys → API access tokens.
4. Check their changes. In Logs → Admin panel, set Range to 30d or 90d and search for their name or email.
5. Disable them at your identity provider as well. Unless the network uses provisioning, Peerlify doesn't check the provider after sign-in, so this alone doesn't end their Peerlify access, but it stops new sign-ins.

A policy change is causing an outage

1. Open Access → History.
2. Make the last working version the OLD side of the comparison and click Restore v<n>. See Policy history and rollback.
3. If the restore is refused, the error tells you why: a failing test, invalid groups, the plan's group limit, or a tag you don't manage. Fix that rather than working around it.

The restored policy reaches devices within about 10 seconds. Connections opened under the bad policy stay open; remove the device to cut a specific one off.

You need to cut off a whole network

There is no "pause network" control. Your options:

• Replace the access policy's rules with none, which denies all new connections between devices, and remove the shadowing rules. The console stays usable. Existing TCP connections stay open.
• Remove devices from the network one by one.
• Ask Peerlify support to suspend the network. A suspended network's devices go offline within seconds.

Afterwards

• Export what you need: the audit log has no export, so record the relevant entries before they scroll out of view. Activity logs are deleted after 90 days.
• Review who holds Owner, Admin and IT admin, and which auth keys and API tokens exist.
• If you turned on manual device approval as a stopgap, decide whether to keep it.

Next steps

• Remove a device or a person
• Audit log
• Security model