Swif enables administrators to retrieve and securely store Linux device encryption recovery keys. This ensures that encrypted devices can be accessed and managed securely, even in scenarios requiring recovery. Follow the steps below to configure and manage Linux encryption policies with recovery key management.
Steps to Retrieve Encryption Keys
1. Create a Linux Encryption Policy
Log in to the Swif Admin Dashboard.
Navigate to Device Management > Policies and create a new Linux Encryption Policy.
Include the Force Passphrase field in the policy configuration. This field ensures the Swif agent enforces passphrase usage on the device.
2. How the Swif agent retrieves and saves Linux encryption recovery keys
When a Linux device is enrolled, the Swif agent and Desktop App work together to ensure a valid recovery passphrase is stored in MDM.
What the agent checks
Look up in MDM: The Swif agent checks the MDM database for a recovery passphrase associated with this device.
Validate if present:
If a passphrase exists and is valid (it can decrypt the device): the agent confirms it and no user action is required in the app.
If no passphrase exists or validation fails: the Swif Desktop App prompts the signed-in user to provide an active disk passphrase (e.g., their current LUKS passphrase).
Important: two places users may enter a passphrase
At device boot:
Users always enter their disk encryption passphrase at boot. This is required by the OS and is unrelated to Swif’s in-app prompt.In the Swif Desktop App (only if needed):
If the MDM server doesn’t have a recovery passphrase for the device, or the stored passphrase fails validation, the app shows an “Encryption Passphrase” window. The user enters their current working disk passphrase.
After successful verification, Swif will:Generate a new Swif-managed recovery passphrase (separate from the user’s login/boot passphrase).
Securely save that recovery passphrase to the MDM database for admin recovery and audit.
What users will see (typical flow)
Boot device → enter disk passphrase (always required by OS).
If Swif needs to capture/refresh recovery info → Swif app shows a one-time passphrase prompt.
User enters their current disk passphrase → Swif validates → generates and stores a Swif recovery passphrase → prompt closes.
3. User Interaction
If the Swif Desktop App opens:
The user will be asked to enter the current valid passphrase for the device.
The Swif agent will:
Generate a new passphrase based on the provided input.
Send this new passphrase to the MDM server for secure storage.
4. Recovery Header File Creation
After a valid passphrase is created:
If there is any issue with the recovery header file, the agent will generate a one-time recovery header file.
The recovery header file will be sent to the MDM server, which will upload it to S3 for secure storage.
The MDM server will send the passphrase and the recovery header URL to the ST-API for device management purposes.
5. Daily Passphrase Validation
The Swif agent performs a daily check to validate the passphrase stored in the MDM database. This ensures that the stored passphrase remains correct and operational.
6. Viewing Recovery Keys in Swif
Once the process is complete, you can view the recovery key and header recovery file link in the Swif Admin Dashboard:
Navigate to Device Details > Security for the specific device.
Here, you will find:
Recovery Key: The passphrase associated with the device.
Header Recovery Link: A downloadable URL for the recovery header file stored in S3.
7. Benefits of Managing Encryption Recovery Keys with Swif
Data Security: Ensures encrypted devices remain secure with enforced passphrase policies.
Recovery Assurance: Simplifies recovery in case of data corruption or key loss.
Centralized Management: Admins can access recovery keys and header files directly from the Swif platform.
8. FAQ
If your Linux device encryption status is false, you can use this article to verify it.
9. Admin notes
The Swif recovery passphrase is distinct from end-user secrets. It’s stored in MDM and visible to authorized admins for recovery workflows.
If validation fails repeatedly (e.g., user mistypes, keyslot drift), the app will re-prompt until a working passphrase is provided or the flow is canceled.
Rotations: any time the device’s disk keys are changed outside Swif, the app may prompt again so Swif can validate and refresh the stored recovery passphrase.
10. Troubleshooting tips
User insists their passphrase is correct but validation fails:
Confirm the passphrase works at boot. If yes, check for custom LUKS keyslot changes or TPM-bound slots. Have the user try the passphrase that successfully unlocks at boot.No prompt appears but MDM shows “missing passphrase”:
Ensure the Swif Desktop App is running and the device is online. Trigger a policy sync; the app will prompt if recovery data is still missing.Security concern:
Remind users the in-app prompt collects the passphrase only to verify and derive/store a separate recovery passphrase. The user’s own passphrase is not saved in MDM.
For additional support or questions about managing Linux encryption recovery keys, contact Swif Support at support@swif.ai.
Swif Policy glossary – see All Linux policies article for context.