Overview

The Linux Encryption Recovery Policy helps administrators maintain recoverable access to LUKS-encrypted Linux devices managed by Swif.

The policy can:

Require Swif to validate that the device has a working encryption passphrase.
Generate and store a separate Swif-managed recovery passphrase for the device.
Maintain recovery information that authorized administrators can retrieve from Swif.
Control whether the user is prompted for an encryption passphrase during device startup.

The policy supports both company-owned and BYOD Linux devices.

Important: Encryption recovery settings affect access to encrypted data. An incorrect or untested configuration can prevent a device from starting or make encrypted data unrecoverable. Test the policy on a nonproduction device before deploying it broadly.

For a detailed explanation of how Swif retrieves, validates, and stores recovery information, see Retrieve Linux Device Encryption Recovery Keys.

Supported Encryption Method

Swif supports Linux full-disk encryption based on LUKS, or Linux Unified Key Setup. The Swif agent uses the cryptsetup utility to work with the device’s existing LUKS configuration and recovery keyslots.

Requirement	Support
Operating system	Linux
Encryption	LUKS-based disk encryption
Required utility	`cryptsetup`
Device ownership	Company-owned and BYOD

The policy does not initially encrypt an unencrypted disk. Use the appropriate Linux encryption deployment process before applying recovery management.

How Swif Recovery Key Management Works

When Force Passphrase is enabled, the Swif agent and Swif Desktop App work together to verify and maintain a usable recovery credential.

The typical process is:

The Swif agent checks whether Swif already has a recovery passphrase for the device.
If a stored passphrase exists, the agent validates that it can unlock the encrypted device.
If the passphrase is present and valid, no user action is required.
If no recovery passphrase exists or validation fails, the Swif Desktop App asks the signed-in user for a current working disk-encryption passphrase.
Swif validates the passphrase entered by the user.
Swif generates a separate, unique recovery passphrase for that device.
The recovery passphrase is added to an available LUKS keyslot without replacing the user’s existing disk passphrase.
Swif securely stores the managed recovery passphrase for authorized administrative recovery.
When applicable, Swif also creates and stores a LUKS recovery header file.
The agent performs ongoing validation to confirm that the stored recovery passphrase remains usable.

The user’s existing boot passphrase and the Swif-managed recovery passphrase are separate credentials. Swif does not replace the user’s existing LUKS passphrase during this process.

Before You Begin

Before creating the policy:

Enroll the Linux device in Swif and confirm that it is online.
Verify that the device uses LUKS encryption.
Confirm that cryptsetup is installed and available.
Confirm that the user knows a current passphrase that successfully unlocks the encrypted disk.
Ensure that the Swif Desktop App is installed and running if user input may be required.
Confirm that authorized administrators can access the device’s Security page in Swif.
Back up critical business data separately from the encrypted device.
Test recovery-key creation and retrieval on a nonproduction device.
If you plan to enable Skip Passphrase Prompt, test cold boot, restart, update, recovery, and offline scenarios before production deployment.

To verify the encryption type, an administrator can use read-only commands such as:

lsblk -f

For a known LUKS device:

sudo cryptsetup luksDump /dev/<encrypted-device>

Do not modify or remove LUKS keyslots as part of routine verification.

Create the Policy

In the Swif Admin Dashboard, go to Device Management > Policies.
Create a new policy.
Select Linux Encryption Recovery Policy.
Enter a descriptive policy name.
Configure Force Passphrase.
Configure Skip Passphrase Prompt.
Assign the policy to one test device or a small test device group.
Wait for the device to receive and apply the policy.
Complete any passphrase request shown by the Swif Desktop App.
Confirm that the recovery key appears under Device Details > Security.
Test the intended startup and recovery behavior before expanding deployment.

Recommended Configuration

Standard Company-Owned Workstation

Setting	Recommended value
Force Passphrase	Enabled
Skip Passphrase Prompt	Disabled

This configuration maintains a Swif-managed recovery credential while preserving the normal boot-time disk passphrase prompt.

BYOD Device

Setting	Recommended value
Force Passphrase	Enabled when organizational recovery management is required and disclosed
Skip Passphrase Prompt	Disabled

Skipping the boot passphrase prompt is generally not recommended for personally owned devices.

Unattended or Special-Purpose Device

Setting	Recommended value
Force Passphrase	Enabled
Skip Passphrase Prompt	Enable only after a documented security review and successful testing

Use this configuration only when unattended restart is an operational requirement and the organization accepts the reduced boot-time authentication control.

Setting Explanations

Force Passphrase

Ensures that a valid recovery passphrase is enforced and validated for the encrypted device.

The default value is Disabled.

Value	Behavior
Enabled	Swif checks for a stored recovery passphrase, validates it, and starts the recovery-key workflow when the credential is missing or invalid.
Disabled	The policy does not require Swif to enforce and validate a managed recovery passphrase.

When enabled, the user may see an Encryption Passphrase prompt in the Swif Desktop App. The user must enter a current passphrase that can unlock the LUKS volume.

After successful validation, Swif generates and stores a separate device-level recovery passphrase. The user’s entered passphrase is used for validation and is not saved in Swif as the managed recovery passphrase.

Recommended value: Enabled.

Skip Passphrase Prompt

Controls whether the device skips the encryption passphrase prompt during startup.

The default value is Disabled.

Value	Behavior
Enabled	The device is configured to skip the interactive encryption passphrase prompt during startup when the supported recovery configuration can provide unattended unlock. Note, `Skip Passphrase Prompt` can be enabled if and only if `Force Passphrase` is enabled.
Disabled	The normal startup encryption passphrase prompt remains in place.

Security warning: Enabling this setting changes the device’s boot-time security model. A device that can unlock its encrypted storage without a user-entered passphrase may provide less protection after theft or unauthorized physical access, depending on the device’s configuration and other security controls.

Before enabling it:

Confirm that unattended boot is a documented business requirement.
Require a strong operating-system login credential.
Maintain Secure Boot and other platform security controls where supported.
Restrict physical access to the device.
Verify that the Swif recovery key is available.
Test what happens after firmware, kernel, bootloader, initramfs, and encryption configuration changes.
Maintain a documented recovery procedure.

Recommended value for workstations and BYOD: Disabled.

How the Settings Work Together

Force Passphrase	Skip Passphrase Prompt	Expected use
Disabled	Disabled	No managed passphrase enforcement; normal startup prompt remains.
Enabled	Disabled	Recommended baseline. Swif maintains a recovery passphrase while the user continues entering a disk passphrase at startup.
Enabled	Enabled	Managed recovery with unattended startup behavior. Use only for approved special-purpose devices after testing. Note, `Skip Passphrase Prompt` can be enabled if and only if `Force Passphrase` is enabled.

Boot Passphrase and Swif App Prompt

Users may encounter two different passphrase prompts.

Startup Encryption Prompt

This prompt appears before the operating system starts and unlocks the encrypted disk.

It normally appears during every startup unless Skip Passphrase Prompt is enabled and the device successfully uses its supported unattended-unlock configuration.

Swif Desktop App Prompt

This prompt appears after the user signs in when Swif needs to create, validate, or refresh the managed recovery credential.

The user should enter the current disk-encryption passphrase—the same passphrase that successfully unlocks the LUKS volume—not merely the Linux account password unless they are the same.

After the passphrase is validated, Swif creates a separate recovery credential. The Swif app prompt should close after the recovery workflow completes successfully.

View Recovery Information in Swif

After recovery information is successfully saved:

Open the Swif Admin Dashboard.
Select the affected device.
Go to Device Details > Security.
Locate:
- Recovery Key: The Swif-managed recovery passphrase for the device.
- Header Recovery Link: A link to the stored LUKS recovery header file, when available.

Limit access to this information to authorized administrators. A recovery passphrase can unlock the encrypted device and must be handled as a highly sensitive secret.

For more details, see Retrieve Linux Device Encryption Recovery Keys.

Recovery Considerations

The Swif recovery passphrase provides an independent way to unlock the device when the user’s normal disk passphrase is unavailable.

Before an emergency:

Confirm that a recovery key is present for every required device.
Validate the recovery workflow on representative test devices.
Restrict and audit administrator access to recovery information.
Maintain an independent backup of critical data.
Document the encrypted device path and recovery steps for each supported Linux distribution.
Keep the recovery header associated with the correct device.

Critical warning: Restoring a LUKS header is a high-impact operation. A header restore replaces keyslot information with the content from the backup. Using the wrong or outdated header can make current passphrases unusable or permanently prevent access to encrypted data. Only a qualified Linux administrator should perform a header restore after confirming the target device and maintaining an additional backup. See the cryptsetup luksHeaderRestore documentation.

Do not test a recovery passphrase by removing an existing working keyslot. Use a controlled recovery procedure that preserves current access.

Company-Owned and BYOD Considerations

Company-Owned Devices

For company-owned devices:

Enable Force Passphrase to maintain a unique recovery credential.
Keep Skip Passphrase Prompt disabled for normal laptops and workstations.
Limit recovery-key access to authorized IT and security personnel.
Test recovery after operating-system and boot-component updates.
Confirm that keys are available before offboarding, password changes, or device repair.

BYOD Devices

For BYOD devices:

Inform the owner that Swif will add and store a separate recovery credential for the encrypted device.
Confirm that organizational recovery access is permitted by company policy and the enrollment agreement.
Keep Skip Passphrase Prompt disabled unless there is an exceptional, documented requirement.
Avoid using the recovery credential to access personal data except through an authorized recovery or security process.
Remove organizational recovery access appropriately during unenrollment or offboarding according to your procedures.

The policy manages recovery for the encrypted Linux device. It does not create a separate work-only encrypted container.

Verify the Policy

After applying the policy:

Confirm that the policy reports as installed in Swif.
Complete the Swif Desktop App prompt if one appears.
Confirm that Recovery Key is populated under Device Details > Security.
Confirm that Header Recovery Link is available when the recovery header has been uploaded.
Restart the device during a controlled maintenance window.
Verify that startup behavior matches the Skip Passphrase Prompt setting.
Confirm that the user can sign in normally.
Confirm that the device returns online in Swif.
Follow your approved test procedure to validate that recovery information is usable without deleting existing keyslots.

Troubleshooting

The Swif Desktop App Repeatedly Requests a Passphrase

The passphrase may not be able to unlock the encrypted volume, or the LUKS configuration may have changed.

Confirm that the passphrase successfully unlocks the disk during startup.
Make sure the user enters the disk-encryption passphrase rather than an unrelated Linux account password.
Check for recent manual keyslot changes, passphrase rotation, TPM enrollment, or encryption reconfiguration.
Confirm that the Swif agent and Desktop App are running and online.
Review the policy command history and agent logs.

If the disk passphrase works at startup but Swif validation continues to fail, contact Swif Support with the Linux distribution, encryption layout, and relevant logs. Do not include the actual passphrase in a support ticket.

No Prompt Appears but Swif Shows a Missing Recovery Passphrase

Confirm that Force Passphrase is enabled.
Confirm that the policy is assigned to the device.
Verify that the Swif Desktop App is running in the signed-in user’s session.
Confirm that the device is online.
Trigger a policy sync.
Review whether another user session is active or the app prompt is behind another window.

Recovery Key Is Not Visible in Swif

Confirm that the user completed the passphrase prompt successfully.
Wait for the device to synchronize with Swif.
Refresh Device Details > Security.
Confirm that cryptsetup is installed.
Confirm that an available LUKS keyslot exists.
Review the policy command result for validation or upload errors.

Skip Passphrase Prompt Is Enabled but the Device Still Prompts

Confirm that the policy installed successfully.
Verify that the root or target encrypted volume uses the supported LUKS configuration.
Confirm that the Swif-managed recovery credential is present and valid.
Review recent kernel, initramfs, bootloader, firmware, TPM, or encryption configuration changes.
Restart the device during a maintenance window and capture the exact prompt or error.
Revert to the normal passphrase-prompt configuration if unattended unlock cannot be validated safely.

Do not remove a working passphrase or keyslot to force unattended unlock.

Skip Passphrase Prompt Causes a Boot Failure

Use the existing disk passphrase or Swif recovery passphrase through the supported recovery interface.
Retrieve the recovery key from Device Details > Security using an authorized administrator account.
Restore the normal interactive passphrase behavior after the device is accessible.
Review the boot and encryption configuration before re-enabling the setting.

If header recovery is required, stop and follow your organization’s approved LUKS recovery procedure. Do not restore a header until the device and backup have been positively matched.

Recovery Validation Fails After a Passphrase or Keyslot Change

Changes made outside Swif can cause the stored recovery information to require validation or refresh.

Confirm that at least one known passphrase still unlocks the volume.
Allow the Swif Desktop App to request and validate a current working passphrase.
Confirm that the refreshed recovery key is stored in Swif.
Avoid deleting keyslots unless you have verified alternative access and current backups.

Encryption Status Is False or Unknown

Confirm that the expected volume is LUKS-encrypted.
Run lsblk -f and identify the encrypted device and mapped volume.
Confirm that cryptsetup is installed and operational.
Check whether the root filesystem uses a custom or unsupported encryption layout.
Trigger an agent sync and review the device encryption status again.

The Header Recovery Link Is Missing

Confirm that the recovery workflow completed.
Check whether Swif determined that a recovery header needed to be generated and uploaded.
Confirm that the device was online during the upload.
Review the command history and agent logs for header-generation or upload errors.

The recovery key may be available even when even a header link is not shown. Contact Swif Support if your recovery procedure requires the header file.

Security and Compliance Impact

A centralized recovery key helps organizations recover encrypted devices without sharing one passphrase across the fleet. Swif creates a separate device-level recovery passphrase and preserves the user’s existing disk passphrase.

For a secure deployment:

Enable Force Passphrase on devices that require organizational recovery.
Keep Skip Passphrase Prompt disabled unless unattended boot is required.
Treat recovery keys and header files as highly sensitive secrets.
Limit access using least-privilege administrator roles.
Review access to recovery information.
Maintain independent data backups.
Test recovery without deleting working credentials.
Review the policy after encryption, boot, firmware, or hardware changes.
Revoke or rotate recovery access when required by offboarding or incident-response procedures.

This policy supports encryption recovery, business continuity, and access-control objectives, but it does not independently guarantee data recovery or make the organization compliant with a particular framework.

Notes

Swif recovery management supports LUKS-based encryption and requires cryptsetup.
Force Passphrase and Skip Passphrase Prompt are disabled by default.
The Swif-managed recovery passphrase is separate from the user’s existing passphrase.
The user’s current passphrase is used to validate access; the separately generated recovery passphrase is stored in Swif.
Recovery information is available only after the device completes the required validation and synchronization.
Keyslot or encryption changes made outside Swif may trigger another validation prompt.
Skipping the startup prompt changes the device’s physical-access threat model.
A recovery key is not a substitute for an independent data backup.
Never include recovery keys or user passphrases in support logs, screenshots, tickets, or chat messages.

Summary

The Linux Encryption Recovery Policy helps maintain recoverable access to LUKS-encrypted Linux devices.

For most company-owned workstations and approved BYOD deployments:

Enable Force Passphrase.
Keep Skip Passphrase Prompt disabled.
Ask the user to enter a current disk-encryption passphrase if the Swif Desktop App prompts them.
Confirm that the separate recovery key appears under Device Details > Security.
Restrict recovery-key access to authorized administrators.
Test recovery using a controlled process that preserves existing keyslots.
Enable unattended startup only for approved special-purpose devices after a security review and successful testing.

For detailed recovery-key retrieval and storage behavior, see Retrieve Linux Device Encryption Recovery Keys.

Linux Encryption Recovery Policy