Audit device encryption with Microsoft Defender

9 minutes

A device can appear healthy in one console but still need security review when its encryption posture changes, its telemetry becomes stale, or its configuration no longer matches your baseline. Microsoft Defender helps you audit that posture by combining device inventory data, secure configuration assessments, and advanced hunting queries.

In this unit, you examine which Defender telemetry supports encryption auditing, how to query encryption-related assessments, and how to spot anomalies that require investigation. This approach complements the Intune encryption report from the previous unit by giving security operations teams a hunting-focused view of encryption risk.

Audit question	Defender telemetry to use	What you learn
Which devices report encryption-related configuration data?	Secure configuration assessment data	Whether Defender Vulnerability Management evaluates an encryption-related control for the device.
Which devices fail an encryption-related control?	Compliance status in secure configuration assessments	Whether a device is applicable but not compliant with the expected security configuration.
Which devices need priority review?	Device inventory and device context	Whether the device is active, critical, exposed, or part of a specific device group.
Which results look unusual?	Advanced hunting query patterns	Whether encryption state, applicability, or reporting freshness differs from the expected baseline.

Map Defender telemetry to the audit objective

A reliable audit starts with knowing what each telemetry source contributes. Microsoft Defender's endpoint security telemetry doesn't replace your BitLocker policy or Intune encryption report. Instead, it gives you security operations data that helps you validate whether endpoint posture aligns with your expected baseline.

Advanced hunting is a query-based investigation experience in the Microsoft Defender portal. You use Kusto Query Language, also called KQL, to search device, alert, and assessment data.
Defender Vulnerability Management provides secure configuration assessments, which indicate whether a specific device configuration applies to a device and whether the device reports as compliant.

Data source	Role in encryption auditing	Key fields to review
`DeviceTvmSecureConfigurationAssessment`	Provides per-device assessment results for secure configurations.	`DeviceId`, `DeviceName`, `ConfigurationId`, `IsApplicable`, `IsCompliant`, `Timestamp`, `Context`
`DeviceTvmSecureConfigurationAssessmentKB`	Adds readable configuration names, descriptions, risk details, and remediation guidance.	`ConfigurationId`, `ConfigurationName`, `ConfigurationDescription`, `RiskDescription`, `RemediationOptions`
`DeviceTvmInfoGathering`	Adds device inventory context for triage and scoping.	`DeviceId`, `DeviceName`, `OSPlatform`, `Timestamp`, `LastSeenTime`, `AdditionalFields`
Exported secure configuration assessment data	Supports larger audits and offline reporting.	Current per-device configuration snapshot, including applicability and compliance state.

Use the assessment table and knowledge base table together. The assessment table tells you what each device reports. The knowledge base table tells you what the assessment means.

A good audit avoids hard-coding configuration identifiers before you validate them in your tenant. Secure configuration names and availability can differ by platform, licensing and service updates. Start by discovering the encryption-related configurations that Defender currently exposes.

Run a discovery query in Advanced hunting. The query searches the secure configuration knowledge base for names or descriptions that mention BitLocker or encryption.

DeviceTvmSecureConfigurationAssessmentKB
| where ConfigurationName has_any ("BitLocker", "Encryption", "Encrypt")
    or ConfigurationDescription has_any ("BitLocker", "Encryption", "Encrypt")
    or RiskDescription has_any ("BitLocker", "Encryption", "Encrypt")
| project ConfigurationId,
          ConfigurationName,
          ConfigurationCategory,
          ConfigurationSubcategory,
          ConfigurationImpact,
          ConfigurationDescription,
          RiskDescription,
          RemediationOptions
| order by ConfigurationImpact desc, ConfigurationName asc

Query step	Purpose	Audit value
Search names and descriptions	Finds encryption-related secure configurations without assuming a fixed identifier.	Keeps the audit resilient when configuration names change.
Project configuration details	Shows the readable assessment name, risk and remediation guidance.	Helps you decide which assessment belongs in your encryption audit.
Order by impact	Places higher-impact configuration findings first.	Supports risk-based prioritization.

After you identify the relevant configuration rows, use their ConfigurationId values to inspect device-level results. This two-step pattern reduces false assumptions and makes the audit easier to explain to another administrator.

Audit encryption posture with advanced hunting

A posture audit answers three practical questions: Does the assessment apply to the device? Does the device report as compliant? Is the result recent enough to trust? The following query joins assessment results with knowledge base details and the latest device inventory record.

let EncryptionConfigurations =
    DeviceTvmSecureConfigurationAssessmentKB
    | where ConfigurationName has_any ("BitLocker", "Encryption", "Encrypt")
        or ConfigurationDescription has_any ("BitLocker", "Encryption", "Encrypt")
        or RiskDescription has_any ("BitLocker", "Encryption", "Encrypt")
    | project ConfigurationId,
              ConfigurationName,
              ConfigurationCategory,
              ConfigurationSubcategory,
              ConfigurationImpact,
              RiskDescription,
              RemediationOptions;
let LatestDeviceInfo =
    DeviceTvmInfoGathering
    | summarize arg_max(Timestamp, *) by DeviceId
    | project DeviceId,
              InventoryDeviceName = DeviceName,
              OSPlatform;
DeviceTvmSecureConfigurationAssessment
| where IsApplicable == true
| join kind=inner EncryptionConfigurations on ConfigurationId
| join kind=leftouter LatestDeviceInfo on DeviceId
| project AssessmentTime = Timestamp,
          DeviceName,
          InventoryDeviceName,
          OSPlatform,
          ConfigurationName,
          IsCompliant,
          IsApplicable,
          ConfigurationImpact,
          RiskDescription,
          RemediationOptions,
          Context
| order by IsCompliant asc, ConfigurationImpact desc, AssessmentTime desc

Result pattern	What it means	How you respond
`IsApplicable` is true and `IsCompliant` is false	The device is in scope for the assessment but fails the expected secure configuration.	Compare the finding with the Intune encryption report and inspect the device details.
`IsApplicable` is true and `IsCompliant` is true	The device passes the encryption-related assessment.	Use the result as supporting audit evidence.
Device inventory fields are missing	Defender has assessment data but limited current inventory context.	Confirm onboarding state, sensor health, and device identity.
`Context` contains extra details	Defender provides additional assessment-specific information.	Use the context to refine the next query or investigation step.

Use the query output as an audit queue rather than a final decision by itself. Defender telemetry gives you a security assessment view. Intune remains the best place to validate policy assignment, encryption readiness, recovery key escrow and compliance policy state.

Detect anomalies that need investigation

An anomaly is a result that does not fit your expected encryption baseline. In this scenario, you look for devices that fail encryption-related assessments, devices with stale assessment timestamps and devices where multiple encryption-related controls do not align.

The following query creates a compact anomaly view. It groups encryption-related assessment results by device and highlights devices that fail at least one applicable control or have old assessment data.

let FreshnessThreshold = 7d;
let EncryptionConfigurations =
    DeviceTvmSecureConfigurationAssessmentKB
    | where ConfigurationName has_any ("BitLocker", "Encryption", "Encrypt")
        or ConfigurationDescription has_any ("BitLocker", "Encryption", "Encrypt")
        or RiskDescription has_any ("BitLocker", "Encryption", "Encrypt")
    | project ConfigurationId, ConfigurationName, ConfigurationImpact;
DeviceTvmSecureConfigurationAssessment
| where IsApplicable == true
| join kind=inner EncryptionConfigurations on ConfigurationId
| summarize LatestAssessment = max(Timestamp),
            ApplicableControls = dcount(ConfigurationId),
            FailedControls = countif(IsCompliant == false),
            FailedControlNames = make_set_if(ConfigurationName, IsCompliant == false),
            HighestImpact = max(ConfigurationImpact)
    by DeviceId, DeviceName, OSPlatform
| extend AssessmentAge = now() - LatestAssessment
| where FailedControls > 0 or AssessmentAge > FreshnessThreshold
| order by FailedControls desc, HighestImpact desc, AssessmentAge desc

Potential Anomaly	Why it matters	Investigation
One or more failed controls	The device does not match the expected secure configuration.	Review Intune policy state, BitLocker status, and Defender device details.
Stale assessment timestamp	The device does not provide recent evidence.	Check sensor health, onboarding status, network connectivity and last seen time.
High-impact failed control	The finding has greater influence on security posture.	Prioritize the device before lower-impact findings.
Repeated failures in one device group	The issue can be caused by shared policy, hardware or deployment conditions.	Group by OS version or device model if available.

If you need recurring evidence outside advanced hunting retention, export secure configuration assessment data and store snapshots in your reporting platform. Exported assessment data represents the current state at export time, so historic audit trends depend on saving each snapshot.

Turn audit results into an investigation workflow

A useful encryption audit produces action, not only a list. Start with high-impact failed assessments, then correlate the Defender result with the Intune encryption report, compliance status, and device details. This sequence helps you separate true encryption gaps from reporting delays or stale telemetry.

Step	Action	Outcome
1	Discover encryption-related secure configurations in the knowledge base.	You know which Defender assessments belong in the audit.
2	Query applicable device assessment results.	You identify devices that pass or fail the encryption-related controls.
3	Add device inventory context.	You prioritize by operating system, join type, or business criticality.
4	Detect failed or stale results.	You focus investigation on devices that present audit risk.
5	Correlate with Intune.	You confirm policy, encryption readiness, encryption status, and compliance impact.

This workflow gives you a repeatable way to audit encryption posture from the security operations side.

Feedback

Was this page helpful?