Guides · Access and governance
Device posture
Device posture lets your vault check that a device's system disk is encrypted before it hands that device a credential. Use it so a lost, unencrypted laptop was never trusted with broker tickets or certificates in the first place.
- Windows · macOS · Linux
- Needs a vault server
- Self-reported
How it works
Every MangoSSH device that is a member of a Cloud Vault or Self Hosting Vault reads its own disk encryption state and reports it to the vault server. The check runs without admin rights. The app re-reads the disk and reports about every 5 minutes while it runs, and checks its report is current right before it asks for a credential.
When a device asks for a credential, the server judges the report it has stored against the vault's policy. A report older than 15 minutes counts as no report at all, so a device cannot pass by reporting once while healthy and going quiet.
The device tells the server its own state. A modified client could lie, as with any client-side control. What the check reliably does is stop an honest device that is in a bad state, and show you the state of the fleet. It is not hardware attestation.
What is checked on each OS
One check exists in this version: is the disk the operating system runs from encrypted?
| OS | How it is read | Counts as encrypted |
|---|---|---|
| Windows | The BitLocker protection status Windows reports for the system drive (usually C:), read through a hidden PowerShell. | BitLocker on (including a locked volume). Suspended protection, encryption still in progress, decryption, and device encryption still waiting for activation all count as not encrypted. |
| macOS | fdesetup status | “FileVault is On.” An encryption still in progress reads as unknown. |
| Linux | findmnt finds the device behind /, then lsblk lists the layers under it. | A crypt (dm-crypt, normally LUKS) layer anywhere under the root filesystem, including LVM on LUKS. |
Each report carries one of three answers, Encrypted, Not encrypted or Unknown, plus a short detail such as “BitLocker protection suspended” or “LUKS (dm-crypt) under /dev/mapper/…”. Unknown fails the check: the device could not prove it is encrypted, for example because PowerShell or lsblk could not run.
Modes
| Mode | What happens to a device that fails |
|---|---|
| Off | Nothing. Devices still report, and admins can still see the fleet. This is the default. |
| Warn | The credential is issued. The device shows as Warning to admins, and its user sees a warning. |
| Block | The credential is refused with the reason. The device shows as Blocked. |
Admins are not exempt: an admin's unencrypted laptop is the device this matters most for. An admin cannot lock themselves out, because changing the mode needs only the admin role, not a passing device.
What it gates
The vault server applies the check when it issues:
- PAM Broker tickets;
- browser share links, judged on the device creating the link;
- SSH certificates from the MangoSSH CA.
It does not gate vault sync or direct connections to hosts whose credentials a device already holds. Pair it with the PAM Broker when you need credentials to depend on the check.
Turn it on
You need to be a vault admin. The setting lives on the vault server and applies to every device in the vault. It appears in two places, and both change the same value:
- Dashboard → Policies, in the Global section: Require an encrypted disk.
- Dashboard → PAM Dashboard → Pending requests, in the Approval security box: Require an encrypted disk.
Set it to Warn first and wait a day.
Open PAM Dashboard → Device posture (under Access) and fix or follow up on every device that is not Compliant.
Switch to Block once the list is clean.
The change is saved on the vault server immediately. With the mode left at Off, nothing changes for anyone.
See the fleet
PAM Dashboard → Device posture shows this device's own reading first, then a table of every device that has reported: device, OS and version, disk encryption with its detail, status, and when it last reported. The header counts how many are compliant and shows the current mode. A member who is not an admin sees only their own device.
| Status | Meaning |
|---|---|
| Compliant | Passes under the current mode, with a recent report. |
| Warning | Fails, and the mode is Warn. Hover the status for the reason. |
| Blocked | Fails, and the mode is Block. |
| No recent report | No report in the last 15 minutes: MangoSSH is closed on that device, it cannot reach the server, or it is an older version that does not report. Under Block, such a device is refused until it reports again. |
Fix a failing check
A user finds out in one of two ways. When the device's standing changes, MangoSSH shows a toast such as “⚠ Device policy warning: disk encryption is off on this device (BitLocker off)”, or, under Block, “⛔ This device fails the vault's device policy …”. Under Block, a refused request also names the reason: “This vault's device policy refuses this device: disk encryption is off on this device (BitLocker off).”
Encrypt the system disk.
- Windows: turn on BitLocker or Device encryption for the system drive in Windows settings. If the detail says protection suspended, resume protection. If it says still encrypting, wait for encryption to finish. If it says waiting for activation, device encryption has not been switched on yet, which on many PCs happens when you sign in with a Microsoft or work account.
- macOS: turn on FileVault in System Settings → Privacy & Security, and let it finish.
- Linux: the root filesystem must sit on LUKS. Encrypting an existing root in place is rarely practical, so this usually means reinstalling with disk encryption chosen in the installer. Check with
lsblk: acryptdevice should appear above your root partition.
Let MangoSSH re-check. The app re-reads the disk at most every 5 minutes. To check at once, restart MangoSSH, then open PAM Dashboard → Device posture and confirm this device reads Encrypted.
Keep MangoSSH running and connected. The server only trusts a report from the last 15 minutes, so “has not reported its security posture recently” means the app needs to be open and able to reach the vault server, or updated to a version that reports.
Troubleshooting
| Symptom | Likely cause |
|---|---|
| Unknown on Windows | PowerShell could not run or returned nothing within 15 seconds, or Windows reports no BitLocker status for the system drive. |
| Unknown on Linux | findmnt or lsblk is missing or failed. Both come with util-linux. |
| Unknown on macOS | FileVault is still encrypting. It passes once fdesetup status reports “FileVault is On.” |
| Refused after encrypting | The last reading is up to 5 minutes old. Restart MangoSSH and try again. |
| “Not reported recently” | “this device has not reported its security posture recently …”. MangoSSH was closed, offline, or too old to report. Update it and keep it open while you connect. |
| No mode selector | The Policies page shows no Require an encrypted disk control when this device has no Cloud Vault or Self Hosting Vault configured. |