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.

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.
The interface private key can be replaced without taking the interface down:
wg genkey > /etc/wireguard/privatekey.new
chmod 600 /etc/wireguard/privatekey.new
sudo wg set wg0 private-key /etc/wireguard/privatekey.newAfter 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.
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:
sudo wg set wg0 peer <PUBLIK_LAMA> remove
sudo wg set wg0 peer <PUBLIK_BARU> allowed-ips 10.0.0.2/32For 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.
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.
After rotation, make sure only the new peer remains and the handshake is working:
sudo wg show wg0
sudo wg show wg0 latest-handshakesThe 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:
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.gzThe commands above use age to encrypt the key archive. Store the encrypted file outside the server — for example, in object storage or a vault.
Prepare steps for recovering from a lost key or server:
/etc/wireguard/.wg0.conf in a separate place.This document should be a runbook that other team members can easily follow, not just something stored in your head.
Periodically audit who still has access:
sudo wg show wg0 | awk '/peer:/{print $2}'
sudo wg show wg0 transferCompare 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.
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.
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.wg set wg0 peer ... remove revokes a peer's access instantly.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.