Share:
Most IT teams have a working answer to the question "are our devices encrypted?" The answer is usually BitLocker or FileVault, and the evidence is usually a compliance report from whatever management tool is in use. For a large portion of the Windows estate, that answer is accurate.
The problem tends to sit in the remainder. Across most enterprise environments, there's a portion of the device fleet that doesn't fit neatly into the current management picture:
- Older machines provisioned before adoption of current standards.
- Devices acquired through a merger or acquisition, arriving with whatever the previous IT team had deployed.
- Laptops in security-sensitive departments where someone once made a decision to use a third-party encryption tool instead of BitLocker.
- Endpoints where the device history is genuinely unclear.
For these devices, the standard compliance report doesn't give a reliable answer. And without a way to detect what's actually running at the driver level, IT has no way to know which tool is doing the encrypting — or even if any tool is.
How encryption details are fragmented across tools
BitLocker and FileVault remain the dominant choices for Windows and Apple disk encryption, respectively, in most environments, and for good reason -they are the standard encryption modes for these operating systems and are well understood by most IT teams.
However, this isn't universal. Some open-source alternatives like VeraCrypt have real presence in enterprises, where IT or security teams prefer software that can be independently audited. Some teams deploy third-party tools for volume-level encryption alongside BitLocker, covering specific drives or containers rather than the full system disk. Others inherited their encryption setup from a previous IT team and never fully rationalized it.
There's a risk with using such open-source encryption tools. TrueCrypt, a widely used tool, was officially discontinued in 2014, and its developers explicitly recommended migrating to BitLocker. This means that any organization with endpoints that haven't been fully refreshed in the past decade is likely to have some TrueCrypt presence. This is not a deliberate choice, but accumulated history — and it matters not just as a visibility question but as a security one, since TrueCrypt has known, unpatched vulnerabilities that have been public since 2015.
None of this happens because IT teams are careless. It happens because organizations accumulate history, and the current management console only shows what it manages.
Consequences of having encryption details dispersed across tools
The consequences of not knowing which tool is active on a given device tend to surface at the worst possible moments.
The most common is a compliance audit. Frameworks like ISO 27001, HIPAA, GDPR, and even cyber insurance assessments require evidence that endpoints are encrypted. If most devices can be covered by a BitLocker or FileVault report but a portion cannot, IT faces a choice between a manual investigation and submitting incomplete evidence. Manual investigation at any meaningful scale is slow, and it tends to surface exactly the gaps nobody wants to find mid-audit.
A more frequent version of this problem surfaces during device provisioning. An IT admin repurposing a used laptop, or preparing a device for a new user, discovers that they don't know which tool was used to encrypt the device. They have no visibility over the encryption history, and end up searching across all of the tools they use for encryption just to locate the recovery keys.
The third scenario carries the most serious consequences: a device gets lost or stolen from a part of the estate with unclear history. At that point, the honest answer to "was that device encrypted?" might genuinely be "we don't know" — which is not an answer anyone wants to give to a data protection officer.
Why standard reporting misses this
The core issue is straightforward. Most endpoint management tools report on the devices they manage using the encryption method they deployed. They don't look across the full estate at the driver level to identify what's actually running, regardless of how the device was set up.
That's a reasonable design for a management tool. It becomes a problem when there are heterogeneous devices, with the device history scattered across multiple organizations and tools.
A device that was encrypted with VeraCrypt by a previous IT team won't appear in a BitLocker compliance report. A device still running TrueCrypt may not appear anywhere useful. The gap between what the report covers and what actually exists on the estate is invisible until something forces it into view.
What IT teams should be asking
Getting ahead of this problem starts with a few honest questions:
- Can you identify whether devices in your estate that predate the current encryption standard were encrypted using a known tool such as VeraCrypt, TrueCrypt, or DiskCryptor?
- Have any third-party encryption tools been deployed across the organisation — whether organisation-wide or by individual teams or departments?
- Are devices acquired through mergers, acquisitions, or partnerships fully accounted for in your current management tooling?
For organisations that can answer yes to any of these, the gap between "we have a BitLocker compliance report" and "we know the encryption status of every Windows device" is worth closing before the next audit or incident makes it unavoidable. It's also worth noting that while BitLocker status can be reliably reported, detecting third-party tools like VeraCrypt, TrueCrypt, and DiskCryptor typically relies on driver indicators and scoring heuristics — and may not be conclusive in every case.
Tools like ManageEngine DEX Manager Plus are built to address exactly this gap — giving IT teams visibility into encryption status across their Windows estate, including devices managed outside the current standard tooling.
Meet the author