Learn WireGuard - Key Rotation & Security Lifecycle
Episode 12 of 23

Learn WireGuard - Key Rotation & Security Lifecycle

This episode covers the WireGuard security lifecycle: rotating keys live with wg set, a graceful rotation strategy that does not cut connections, secure key backups, peer audits, and disaster recovery procedures when keys or configuration are lost.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Introduction

A WireGuard key is both an identity and an access credential. When a key becomes suspicious, when an employee leaves, or when policy demands periodic rotation, you must be able to replace keys without taking down the entire network. This is the essence of key rotation.

Episode 12 covers live key rotation practices, a smooth graceful rotation strategy, safe backups, peer audits, and disaster recovery procedures. This is an operations-oriented episode — what you do every week, not just a one-time setup.

Live Key Rotation

Replacing the Interface Private Key

The interface private key can be replaced without taking the interface down:

Rotate the interface private key
wg genkey > /etc/wireguard/privatekey.new
chmod 600 /etc/wireguard/privatekey.new
sudo wg set wg0 private-key /etc/wireguard/privatekey.new

After wg set wg0 private-key ..., the new public key is automatically derived from the new private key. All peers that knew the old public key cannot handshake again until they are updated. That is why rotation must be carefully sequenced.

Replacing a Peer's Key

Swapping a peer's public key is just as easy: remove the old peer and add the peer with the new key. If a peer's private key leaked, do this on the opposite side:

Replace a peer's public key
sudo wg set wg0 peer <PUBLIK_LAMA> remove
sudo wg set wg0 peer <PUBLIK_BARU> allowed-ips 10.0.0.2/32

Graceful Rotation Strategy

A Sequence That Does Not Cut the Connection

For an active client, rotation can be done with almost no disruption if the sequence is right. The key: update the receiving side first, so the old connection stays valid until the other side is ready.

  • The server adds the client's new public key as an additional peer.
  • The client replaces its private key with the new one.
  • The server removes the peer with the old public key.

Until the second step happens, the old connection still works. As soon as the client switches keys, the next handshake uses the new key, which the server already knows. Verify the rotation result with wg show wg0 latest-handshakes.

Verifying After Rotation

After rotation, make sure only the new peer remains and the handshake is working:

Audit after rotation
sudo wg show wg0
sudo wg show wg0 latest-handshakes

Backup and Disaster Recovery

Safe Key Backups

The private key is the only asset that cannot be recreated — if it is lost, the peer on the other side must be updated. Store an encrypted backup in a separate location:

Encrypt the key backup
tar czf wg-keys.tar.gz /etc/wireguard/privatekey /etc/wireguard/wg0.conf
age -r <RECIPIENT_PUBLIC_KEY> -o wg-keys.tar.gz.age wg-keys.tar.gz

The commands above use age to encrypt the key archive. Store the encrypted file outside the server — for example, in object storage or a vault.

Disaster Recovery Procedure

Prepare steps for recovering from a lost key or server:

  • Restore the encrypted key archive and put the files back in /etc/wireguard/.
  • Generate new keys if the old ones are considered compromised, then distribute them to all peers.
  • Keep a copy of every node's wg0.conf in a separate place.
  • Test the recovery procedure periodically in a staging environment.

This document should be a runbook that other team members can easily follow, not just something stored in your head.

Audit and Peer Hygiene

Reviewing the Peer List

Periodically audit who still has access:

Audit active peers
sudo wg show wg0 | awk '/peer:/{print $2}'
sudo wg show wg0 transfer

Compare the public key list with the list of authorized devices. Unknown peers should be revoked immediately with wg set wg0 peer <key> remove. A transfer column that has not moved in months is also a sign that a peer is unused.

Periodic Rotation Policy

Set a simple policy: rotate the server private key every few months, rotate client keys when a device is lost or an employee leaves, and audit peers every quarter. This policy will become part of the production checklist in episode 21.

Closing

Episode 12 completed the security lifecycle: live key rotation via wg set, a graceful rotation sequence that minimizes downtime, encrypted backups with age, peer audits, and tested disaster recovery procedures.

Key takeaways:

  • wg set wg0 private-key replaces the interface key without a restart.
  • Smooth rotation: add the new key first, then remove the old one.
  • wg set wg0 peer ... remove revokes a peer's access instantly.
  • Key backups must be encrypted and stored off the server.
  • Audit peers periodically: remove unknown or unused ones.
  • Keep a disaster recovery runbook tested in staging.

In episode 13 we cover the WireGuard security model — the cryptographic primitives Curve25519, ChaCha20-Poly1305, BLAKE2s and SipHash24, the threats handled and not handled, and the limitations you must compensate for yourself.

Learn WireGuard - Key Rotation & Security Lifecycle | Learn WireGuard