Assisted setup recovery material

Hardened fresh-image setup finishes Clevis-only by default. Adding an optional customer-controlled manual keyslot afterward is your choice, based on your recovery policy and threat model.

The hardened hosted installer and cloud-init setup path does not generate or leave a plaintext LUKS recovery passphrase on the server by default. During fresh-server setup, temporary bootstrap material is kept in runtime storage, managed unlock is bound through LUKS and Clevis, and the temporary bootstrap slot is removed after managed unlock is proven.

That leaves the fresh setup path Clevis-only unless you add your own local recovery material. Panocrypt does not store customer recovery passphrases and cannot show one later.

Existing LUKS volumes keep their existing independent keyslots when Panocrypt managed unlock is added, unless you explicitly authorize their removal.

Default setup result

After hardened assisted setup, expect:

• one Panocrypt-managed Clevis keyslot for unattended boot unlock;
• no generated /root/panocrypt-luks-recovery-passphrase.txt file;
• no temporary setup passphrase file left on the unencrypted root disk.
• no permanent manual fallback slot unless you add one.

This is intentional. A generated recovery passphrase written to the server can be copied into old provider snapshots, cloud-init caches, filesystem journals, or deleted blocks. Hardened fresh-server setup avoids creating that artifact.

Optionally add your own recovery material

If your policy calls for an independent manual path, create a customer-held recovery passphrase or key file from the encrypted system, then store it outside Panocrypt.

First generate the recovery material in the customer-controlled system your team uses. Then add it to LUKS from the encrypted server:

export LUKS_DEVICE="/dev/disk/by-id/YOUR_DEVICE"
sudo cryptsetup luksAddKey "$LUKS_DEVICE"

Use your distro’s normal LUKS recovery process if your team uses key files, hardware-backed storage, or another local recovery ceremony.

Test it before you rely on it

Before you rely on the recovery path, prove it opens the LUKS device.

Set the LUKS device path for the target. Use the exact device from your setup run or a stable /dev/disk/by-id/... path when possible.

export LUKS_DEVICE="/dev/disk/by-id/YOUR_DEVICE"

sudo cryptsetup open --test-passphrase "$LUKS_DEVICE"

The command should exit successfully. It checks the passphrase without opening a mapper device.

For a root disk, keep provider console, KVM, rescue, or break-glass access available until you have also verified an unattended reboot.

Store it outside Panocrypt

Store the recovery material in the customer-controlled place your team uses for break-glass infrastructure access: a password manager, secrets vault, hardware-backed process, sealed recovery record, or another internal system with the right approvals and audit trail.

Panocrypt does not back this material up. If the recovery material is lost and managed unlock cannot run because early-boot networking, CA trust, source policy, or another boot-time dependency is broken, Panocrypt cannot recover the disk for you.

If the issue is early-boot networking or TLS trust, use the Bind an existing encrypted root disk guide for the initramfs networking and CA certificate requirements.

Avoid storing recovery material in provider user-data, cloud-init, shell history, logs, screenshots, tickets, or server images. If you temporarily place material on the host for an internal ceremony, remove it promptly according to your policy and do not clone images that contain it.

Higher-assurance rotation after setup

For most teams, the practical control is to add a customer-held recovery path from the encrypted system, test it, store it outside Panocrypt, and keep provider images or snapshots that might contain recovery material out of reuse.

If your threat model requires stronger cleanup after a fresh-server setup, plan a rotation after the server has booted from the encrypted root:

1. Add a new customer-controlled LUKS recovery passphrase or keyslot from the encrypted system.
2. Test the new recovery path.
3. Remove any older local recovery keyslot you no longer want.
4. Remove and rebind the Panocrypt-managed Clevis keyslot if you want the managed unlock metadata created only after the encrypted system is in place.

Changing keyslots changes local unlock paths. It does not, by itself, make an old copied LUKS header useless. If your threat model includes an attacker who may have both an old LUKS header copy and the old recovery passphrase, use a planned cryptsetup reencrypt procedure to rotate the LUKS volume key, then bind Panocrypt again from the new header state. Treat old provider snapshots, images, and backups from before that rotation as sensitive.

This is separate from running-host protection. After a LUKS volume is unlocked, the host has the material needed to read the disk in memory. If your threat model includes access to a running host or host memory, consider platform controls such as confidential-computing instances or other memory-protection features in addition to disk encryption at rest.

When you might need it

You might need the recovery passphrase when:

• Managed unlock is disabled or denied.
• The server cannot reach Panocrypt from initramfs.
• Early-boot networking is missing or broken.
• The initramfs CA certificate bundle is missing and TLS validation fails.
• Source IP policy no longer matches the boot-time network path.
• You removed the Panocrypt-bound keyslot and kept only local recovery paths.

The recovery passphrase is not a replacement for fixing those problems. It is the local break-glass path that keeps you in control while you repair them.

Customer-held recovery boundary

Assisted setup leaves keyslot policy with the customer. Panocrypt operates the managed Clevis unlock path. Any additional local recovery passphrase or independent keyslot is yours to create, test, store, and remove.