# Automatic unlocks for LUKS with Panocrypt policy

Panocrypt lets a LUKS-encrypted Linux server reboot without a typed passphrase
when unlock policy allows. It does that without escrowing disk keys. The path
is built around standard Linux disk-encryption pieces: LUKS for encrypted
volumes, `dm-crypt` for block-device encryption, and Clevis for network-bound
unlock.

Panocrypt adds the operational layer around those pieces: enrollment, source
policy, manual approval, one-time unlocks, unlock decision history, and managed
unlock revocation.

Managed unlock is separate from optional disk encryption setup. If your server
already uses LUKS, the existing-LUKS bind path can use only your
distribution's `cryptsetup`, Clevis, and the standard Clevis `tang` pin. No
Panocrypt host agent is required for that bind or unlock path.

If you want the smallest proof first, start with
[Test a temporary LUKS volume](https://docs.panocrypt.com/getting-started/test-luks-volume/). It uses
only your distribution's LUKS and Clevis packages, does not touch a boot disk,
and lets you prove allow, deny, and optional manual approval behavior.

## What automatic unlock means

Panocrypt decides whether it should participate in a future managed unlock.
The encrypted device still owns the local LUKS header, local unlock material,
and customer-held recovery paths.

Clevis binds one LUKS keyslot to that device's Panocrypt unlock URL. At boot
time, Clevis runs in the initramfs, asks Panocrypt to participate in the
recovery exchange, and opens the Panocrypt-bound LUKS keyslot only if policy
allows the request.

Panocrypt does not receive the LUKS passphrase, local unlock key, or disk
plaintext. The service stores unlock policy, device state, unlock history, and
its side of the cryptographic relationship.

For the narrower trust boundary, see
[No custody of disk keys](https://docs.panocrypt.com/trust/non-escrow/).

## The Linux pieces

On the server, managed unlock uses familiar Linux components.

| Piece | Role |
|---|---|
| `dm-crypt` | Performs the block-device encryption and decryption. |
| LUKS | Manages encrypted volumes, keyslots, tokens, and recovery material. |
| Clevis | Binds a LUKS keyslot to a network-bound unlock policy. |
| Panocrypt | Provides the policy-controlled, Tang-compatible recovery service and unlock decision evidence. |

If a device already uses LUKS, the bind path can use standard distro
`cryptsetup`, Clevis, and the Clevis `tang` pin. No Panocrypt-specific host
agent is required for that existing-LUKS bind path.

If a [supported fresh provider image](https://docs.panocrypt.com/providers/) does not yet use LUKS, the
[Test assisted setup](https://docs.panocrypt.com/getting-started/fresh-test-server/) and
[Assisted fresh-server setup](https://docs.panocrypt.com/setup/supported-disk-encryption/) paths can
set up LUKS and connect managed boot unlock on supported provider images.

Read [LUKS keyslots and Panocrypt binding](https://docs.panocrypt.com/concepts/luks-keyslots/) for the
keyslot model, customer-held recovery material, and removal boundary.

## Boot-time flow

On a root disk, Clevis runs early inside the `initramfs` before the normal
system starts. That environment needs networking, DNS or a reachable Panocrypt
endpoint, CA certificates, and the Clevis hooks needed to unlock the root
device.

At unlock time:

1. Clevis reads the local encrypted unlock metadata from the LUKS header.
2. Clevis asks Panocrypt to participate in the recovery exchange.
3. Panocrypt evaluates device state, source policy, approval requirements, and
   other unlock controls.
4. If policy allows the request, Clevis combines Panocrypt's response with the
   device's local encrypted metadata and opens the LUKS keyslot.
5. If policy denies the request, Panocrypt does not participate. The disk
   remains locked unless the operator uses customer-held recovery material or
   another independent local unlock path.

For the trust proof behind this exchange, including where the unlock key lives
and why Panocrypt does not escrow it, read
[No custody of disk keys](https://docs.panocrypt.com/trust/non-escrow/).

## What automatic unlock is not

Automatic unlock is not a proprietary disk format, key escrow service, data
recovery service, remote wipe control, or guarantee that every future boot will
succeed.

Disabling unlocks stops Panocrypt from participating in future managed unlock
for that device. It does not lock a host that is already running, remove keys
from memory, modify a LUKS header remotely, or delete independent local
keyslots. See [Disable unlocks](https://docs.panocrypt.com/operations/disable-unlocks/) for the
operational boundary.

## What policy can decide

Panocrypt policy controls whether the service will participate in a future
managed unlock. A device can be broad or narrow depending on the risk model.

Common control points include:

- Device lifecycle state.
- Verified source IPv4 or IPv6 address.
- CIDR ranges and shared Network Access lists.
- Initial defaults set by the enrollment key.
- Device tags.
- Manual approval requirements.
- One-time unlock allowance.
- Temporary deny decisions after a denial.
- Managed unlock revocation.

Examples:

| Policy shape | Use it when |
|---|---|
| Allow only the server's current registered IP. | You want the smallest routine reboot path for a fixed server. |
| Allow a provider CIDR or shared Network Access list. | A fleet boots from known provider networks. |
| Allow `0.0.0.0/0` and `::/0`, but require manual approval. | A device roams or has unpredictable source IPs, but a human must approve every managed unlock. |
| Disable managed unlock. | A device has left the fleet or should stop receiving Panocrypt-managed unlock. |
| Allow once. | A device needs one planned managed unlock without permanently broadening policy. |

For a fixed server, you can do the opposite: allow only the boot-time source
IP or provider CIDR and let routine reboots unlock automatically when the
device is otherwise allowed.

Use [Source IP and one-time unlocks](https://docs.panocrypt.com/operations/source-ip-and-one-time-unlocks/)
after a device is bound, and [Disable unlocks](https://docs.panocrypt.com/operations/disable-unlocks/)
when you need the decommissioning boundary.

## Manual approval and notifications

Manual approval adds a human decision before a covered device can complete a
managed unlock. Approval groups decide which tagged devices require approval
and which members or User Groups can approve, deny, or defer requests.

An approval is single-use. It permits the next successful managed unlock for
that approved request. It is an operator-approved one-use unlock, similar in
outcome to the device-level **Allow once** control, but routed through
approvers. A later reboot or a new unlock request needs a new decision unless
policy has changed.

Approval does not create a general 30-minute unlock window. The short
collection window exists so a retrying Clevis client can collect the one
approved recovery response.

Read:

- [Approval groups](https://docs.panocrypt.com/operations/approval-groups/) for coverage and approver
  dynamics.
- [Mobile notifications](https://docs.panocrypt.com/operations/mobile-notifications/) for registration,
  test notifications, and removal.

## Choose a safe test

Use the [docs overview](/) to choose the smallest proof that answers your trust
question.

After any binding path succeeds, go to
[Source IP and one-time unlocks](https://docs.panocrypt.com/operations/source-ip-and-one-time-unlocks/)
to test allowed sources, denied sources, and **Allow once**. Use
[Disable unlocks](https://docs.panocrypt.com/operations/disable-unlocks/) and
[Approval groups](https://docs.panocrypt.com/operations/approval-groups/) for those controls.