Osquery BitLocker Info Table

The Osquery BitLocker Info Table is an osquery table that exposes BitLocker status and configuration details from Windows endpoints. It returns fields such as whether a drive is encrypted, what protectors are present, and related volume metadata, which helps security teams inventory disk encryption and recovery settings.

What the table tells you about BitLocker at scale

The osquery BitLocker Info Table turns local BitLocker state into queryable endpoint telemetry. Instead of checking a single device manually, teams can ask which volumes are encrypted, which protectors exist, and whether recovery-related settings look consistent across Windows hosts.

That matters because disk encryption is only useful operationally if it can be inventoried and validated. A table like this helps close the gap between policy and reality, especially on fleets where encryption may be enabled unevenly or where recovery configuration drifts over time.

Fields, status, and configuration visibility

At a practical level, the table is about evidence. Encryption status shows whether a drive is protected; protector fields help distinguish TPM-only setups, PIN-based setups, and other recovery-related arrangements; volume metadata gives defenders context for what was observed on the endpoint.

That visibility is important because BitLocker is not a single binary condition. Two laptops can both be “encrypted” while still carrying very different operational risk, depending on whether recovery material is escrowed, whether protectors are present, and whether the configuration matches the organisation’s standard build.

For teams using osquery broadly, this table fits the same investigative model as other host inventory queries. The osquery Guide is useful background for how scheduled queries and fleet visibility turn endpoint state into repeatable checks.

Why endpoint encryption inventory matters

Disk encryption is meant to reduce exposure when a device is lost, stolen, repurposed, or accessed offline. If encryption is disabled, misconfigured, or only partially deployed, the endpoint can become a direct path to cached data, local secrets, browser sessions, and other sensitive material.

This is also why the table is valuable in incident response and assurance work. A fleet-wide query can quickly identify devices that need follow-up, and it can help confirm whether recovery posture matches what the organisation expects after onboarding, rebuilds, or policy changes.

When defenders want the broader context for Windows hardening around encryption, the Windows Endpoint Hardening Guide provides a useful adjacent view of how BitLocker sits alongside other platform protections. For a deeper focus on encryption design, the Disk Encryption Guide: BitLocker and FileVault covers deployment choices, TPM options, and recovery key handling.

How practitioners use the data operationally

Security teams usually use this kind of table for three jobs: inventory, exception handling, and verification. Inventory answers “which hosts are encrypted”; exception handling identifies systems that need remediation or compensating controls; verification checks that the expected protectors and recovery settings are actually present.

That makes the table useful for both baseline enforcement and drift detection. If a device appears unencryted, unexpectedly lacks a protector, or reports metadata that does not match the standard build, the query result becomes the starting point for investigation rather than the final answer.

Used well, the table gives defenders a fast, repeatable way to separate compliant endpoints from risky ones without having to touch each machine individually.

Risk and Threat Considerations

BitLocker gaps create a straightforward but serious exposure: if a Windows endpoint is not encrypted, or if recovery and protector configuration is weaker than expected, offline access to the device becomes much easier after theft, loss, or unauthorized physical access.

Failure mechanism: The control fails when encryption is absent, incomplete, or inconsistently configured, allowing an attacker or finder to access stored data outside normal operating-system protections.

Impact: Sensitive files, cached credentials, browser data, and locally stored business information may be exposed, and recovery complexity increases if the organisation has not tracked the device state accurately.

Practitioner Guidance

What to watch for: Treat this table as a validation source, not just an inventory source. A healthy-looking endpoint fleet can still hide exceptions if recovery protectors are missing, if encryption is stale after reimaging, or if local policy drift has changed the actual BitLocker posture.

Practitioner takeaway: Use the query output to drive a closed loop, inventory first, then reconcile exceptions, then confirm that the device state matches the organisation’s encryption standard.

Related resources from NHI Mgmt Group

• How should security teams decide whether a new osquery table is worth adding to an endpoint fleet?
• What are the signs that an osquery table design is too privacy invasive for production use?
• What should teams do when a new osquery table needs review and approval from maintainers?
• Osquery File Table