When a laptop walks out of a coffee shop, full-disk encryption is the difference between “lost hardware” and “reportable data breach.” Telivy checks every Windows and Mac device your agent reaches and flags the ones whose disks aren’t actually protected — including the ones the end user thinks are encrypted but aren’t. This page explains how that detection works, what your client will see in the portal, and where the rule is known to be noisy (so your tech doesn’t waste a Tuesday chasing a false positive on a Hyper-V host).Documentation Index
Fetch the complete documentation index at: https://support.telivy.com/llms.txt
Use this file to discover all available pages before exploring further.
What this is
The Telivy agent inspects each drive on a device during its scan and returns the disk’s encryption state — provider, method, percentage encrypted, and whether protection is currently active. If a disk isn’t encrypted, Telivy raises an Unencrypted Disk Per Device finding, one per non-encrypted volume. The check runs whenever the agent performs its disk encryption collection (once per day per device), so you get a fresh read on a predictable cadence rather than a one-time snapshot.Why it matters to MSPs
A missing or misconfigured disk encryption setting is one of the cheapest possible findings to remediate and one of the most expensive to ignore:- Lost or stolen device → reportable breach. HIPAA, state breach-notification laws, and most cyber insurance carriers treat data on an unencrypted device as compromised the moment the device is out of the owner’s hands. Encrypted? It’s a lost laptop. Unencrypted? It’s a notification event with legal and PR cost.
- Cyber insurance gating. A growing share of carriers require attestation that endpoints are encrypted. “We assumed BitLocker was on” is not an attestation. Telivy gives recurring, agent-backed evidence on a defined cadence.
- Cheap fix, high signal. BitLocker and FileVault are free, native, and silent for the user once enabled. Most “unencrypted” findings come from devices where it was never turned on, was suspended for a firmware update and never resumed, or only encrypted the OS volume and not the data drive.
How Telivy detects it
At a high level, the Telivy agent asks the operating system “is this volume protected, and if so, how?” — then applies a single rule to decide whether to raise a finding. A disk is considered encrypted when either:- The OS reports protection status as On (the volume is fully encrypted and protection is active), or
- The OS reports protection status as Unknown but the volume is Locked (a locked encrypted volume that hasn’t been unlocked yet — still protected at rest)
- Protection status Off (no encryption configured)
- Protection status Unknown with the volume unlocked (we cannot positively confirm encryption)
- Encryption suspended or paused (e.g. BitLocker suspended for a firmware update and never resumed)
Detection logic in detail
Windows (BitLocker)
Windows (BitLocker)
On Windows, Telivy uses
Telivy does not collect or transmit BitLocker key protector details (for example which TPM or recovery key protectors are configured).Encryption method representation
manage-bde output as the primary source for BitLocker volume status. If manage-bde is not available on the endpoint, the agent falls back to the BitLocker WMI provider (the same structured BitLocker data administrators query through WMI/CIM).For each volume the agent captures:| Field | What it means |
|---|---|
ProtectionStatus | WMI: 0 = Off, 1 = On, 2 = Unknown. From manage-bde, the equivalent protection state is parsed from text output. |
LockStatus | WMI: 0 = Unlocked, 1 = Locked |
EncryptionMethod | Cipher in use — format depends on source (see below) |
EncryptionPercentage | How much of the volume has completed the encryption operation (0–100); interpret together with protection status |
MountPoint | Drive letter (e.g. C:, D:) |
CapacityGB | Volume size |
- When data comes from WMI, encryption methods map to numeric codes:
| Code | Method |
|---|---|
| 0 | None |
| 1 | AES-128 |
| 2 | AES-256 |
| 3 | AES-128 with Diffuser |
| 4 | AES-256 with Diffuser |
| 5 | XTS-AES-128 |
| 6 | XTS-AES-256 |
| 7 | XTS-AES-256 (Hardware) |
- When data comes from
manage-bde, encryption method appears as human-readable text (for exampleAES 128), not those numeric codes.
Encrypted ifProtection status vs. percentage. The finding logic keys off whether protection is actively on, not the percentage alone. A volume that is 100% encrypted but shows protection Off (for example BitLocker suspended) is not treated as encrypted because data can still be reachable in that state. Conversely, a partialProtectionStatus = 1, OR (ProtectionStatus = 2ANDLockStatus = 1). Otherwise → finding.
EncryptionPercentage usually means encryption was paused, still in progress, or impacted by events such as hibernation or disk errors. BitLocker does not define a stable long-term meaning for partial encryption outside those transitional scenarios.macOS (FileVault)
macOS (FileVault)
On macOS, the Telivy agent reads FileVault status from the OS and reports the encryption method as
FileVault. The same protection-status logic applies: FileVault on and active counts as encrypted; FileVault off or paused does not.Linux
Linux
Linux endpoints are not currently in scope for this finding. The Telivy agent does not yet inspect LUKS / dm-crypt status, and Linux devices will not produce Unencrypted Disk Per Device findings either way. If your client runs Linux servers that need encryption attestation, treat that as a manual control today.
What this looks like in the portal
The finding shows up wherever device-level findings are reviewed in a Risk Assessment.| Field | Value |
|---|---|
| Finding name | Unencrypted Disk Per Device |
| Severity | Critical |
| Scan type | Devices (agent-collected) |
| Per-finding granularity | One finding per unencrypted volume |
| Finding value | Unencrypted disk on {hostname}: {drive letter} |
| Captured details | Drive letter, capacity (GB), encryption method, encryption percentage, protection status label |
| References | NIST SP 800-111 (Storage Encryption), CISA Data Encryption guidance |
How MSPs use this in practice — Analyze → Prioritize → Commit
Analyze. Filter the findings list to Unencrypted Disk Per Device for the assessment. Group by hostname to see which devices have any unencrypted disk vs. which have multiple. Pay attention to the drive letter — an unencrypted C: is the OS volume and is your top priority; an unencrypted D: or external drive often holds the data drive on workstations and engineering laptops. Prioritize. Critical severity by default — but prioritize by who’s holding the device. Owners, finance, HR, and anyone with access to PHI / PII go first. Production servers on physically-secured racks can move to a planned remediation window. Hyper-V hosts and virtualization servers may be false positives — confirm before remediating (see below). Commit. Push the remediation into your standard endpoint workflow:- For Windows fleets managed by Intune or a Group Policy, push BitLocker via policy and store keys in Azure AD.
- For macOS managed by Jamf / Kandji, enable FileVault by configuration profile and escrow the recovery key.
- For unmanaged or BYOD endpoints, use the finding as the trigger for a hardware-management conversation with the SMB owner.
Example scenario
A 40-employee accounting firm runs an annual Telivy assessment as part of their MSP’s QBR cycle. The first scan returns:- 22 unencrypted disk findings across 14 devices
- Of those, 9 are C: drives on partner laptops that were assumed to be encrypted because BitLocker had been enabled at imaging time — but a 2024 Windows feature update suspended BitLocker for the install and the suspension was never resumed
- 5 findings are external D: drives on workstations where staff store working files
- The remaining 8 are on a Hyper-V host where the underlying physical storage is encrypted (see caveats below)
Known limitations and false positives
- Encryption suspended ≠ encrypted. If BitLocker was suspended for a Windows feature update and the device hasn’t rebooted enough times to auto-resume, the volume reports
ProtectionStatus = 0. The fix ismanage-bde -protectors -enable C:or letting Windows auto-resume after the next boot — not enabling BitLocker from scratch. - Partial encryption percentage. A value below 100% typically reflects encryption in progress, a pause, hibernation, manual stop, or problems such as bad sectors. Do not treat partial percentage as a steady-state “half encrypted” posture; align remediation with protection status and BitLocker event logs.
- Linux is not covered. Findings will not appear for Linux endpoints regardless of LUKS state. Document Linux disk encryption as a manual control if the client’s compliance scope requires it.
- External and removable media. USB drives plugged in at scan time may be reported, while drives that weren’t connected won’t be. Treat removable-media encryption as a policy and training problem, not just a finding-list problem.
Common misunderstandings
“BitLocker is enabled, why is this still flagged?” “Enabled” and “actively protecting the volume” are not the same thing. The most common cause is a suspended BitLocker session left over from a firmware or feature update. Checkmanage-bde -status — if Protection Status: Protection Off, the volume is not actually protected even though encryption is configured.
“We have one finding per device, right?”
No — Telivy emits one finding per unencrypted volume, not per device. A laptop with an encrypted C: and an unencrypted D: produces one finding (for D:). Sort by hostname when scoping a remediation effort.
“This means we’re compliant once it’s clean.”
Encryption is one control out of many that compliance frameworks (HIPAA, PCI, NIST CSF) expect. A clean finding list here is a strong attestable control, but it is not a substitute for a documented encryption policy, key escrow, or device inventory. Use Telivy’s evidence in your QBR and compliance narrative — don’t treat the finding list as the entire story.