Endpoint Security

Hardening baselines

Applying a defined security configuration — CIS Benchmark, Microsoft Security Baseline, or DISA STIG — reduces the attack surface by disabling unused services, enforcing audit policy, restricting credential exposure, and enabling exploit mitigations.

Antivirus and EDR

Microsoft Defender Antivirus is the built-in AV layer. Defender for Endpoint (MDE) adds behavioural detection, threat intelligence, automated investigation, and the advanced hunting query interface. Third-party EDR (CrowdStrike, SentinelOne) replaces or supplements these capabilities.

Device encryption

BitLocker encrypts the OS volume using TPM-backed key protection. Proper deployment requires Secure Boot, a TPM 2.0 chip, and key escrow to Entra ID or Active Directory before encryption is enforced — so keys are retrievable when users are locked out.

Local administrator control

Unmanaged local admin accounts are a persistent lateral movement risk. Windows LAPS rotates the local administrator password automatically and stores it in Entra ID or AD, making the credential unique per device and auditable.

Conditional Access and compliance

Entra Conditional Access uses device compliance state from Intune as a gate for cloud resource access. Non-compliant or unmanaged devices can be blocked from Microsoft 365, SharePoint, and other services — without VPN.

Vulnerability and patch exposure

Unpatched endpoints are the most common initial access vector. Defender Vulnerability Management scores exposure per device based on installed software, OS version, and configuration weaknesses — and integrates with Intune for remediation tracking.

TPM and hardware requirements

BitLocker with TPM binding provides the strongest protection — the key is sealed to the TPM and released only when boot measurements match the expected PCR values. Requires TPM 1.2 minimum; TPM 2.0 is required for Autopilot and Windows 11 compliance policies. Devices without a TPM can use a USB startup key, but this is not suitable for unattended deployment.

Intune BitLocker policy

Configure via Endpoint security > Disk encryption or via a Settings Catalog profile. Key settings: require encryption on OS drive, enforce TPM-only or TPM+PIN protector, configure recovery key backup to Entra ID, and set the encryption method (XTS-AES 128 or 256). Require device encryption in the compliance policy to gate Conditional Access.

Key escrow to Entra ID

Keys escrow silently when the BitLocker policy applies and the device is Entra joined or hybrid joined. Escrow failure is silent — no error appears on the device or in Intune. Verify escrow by checking Entra ID > Devices > [device] > Recovery Keys. Force re-escrow using Manage-bde -protectors -adbackup C: if keys are missing.

PCR7 binding and patch risk

Patches that modify Secure Boot databases or UEFI CA certificates can break PCR7 binding, triggering BitLocker recovery on next boot — even when encryption and keys are configured correctly. Suspend BitLocker for one reboot before applying high-risk patches (especially those involving Secure Boot or UEFI) to pilot rings first.

Recovery workflow

When a user hits a recovery screen: retrieve the 48-digit recovery key from Entra ID (Devices > [device] > Recovery Keys) or from on-prem AD (using the BitLocker Recovery Password Viewer in ADUC). After recovery, investigate why recovery was triggered — PCR7 change, TPM clear, or policy conflict — before the device returns to service.

Device Encryption vs BitLocker

Consumer editions of Windows use Device Encryption (a simplified BitLocker subset) which activates automatically on compatible hardware. Enterprise environments should use full BitLocker with explicit policy to control protector type, algorithm, and key escrow. Device Encryption does not appear in the Intune Disk encryption report.

Intune compliance settings for security

Key compliance checks for a security baseline: minimum OS version, BitLocker enabled, Secure Boot on, code integrity on, Defender real-time protection active, and maximum allowed threat severity from Defender for Endpoint set to Medium or lower.

Conditional Access: Require compliant device

The "Require device to be marked as compliant" grant control in Entra Conditional Access blocks access from any device not registered in Intune or not meeting the compliance baseline. Apply to Microsoft 365 apps at minimum. Exclude emergency access (break-glass) accounts from all CA policies.

Noncompliance grace period

Set a grace period (typically 1–3 days) before a device is officially marked noncompliant. This gives users and IT time to respond to a compliance drift before access is blocked. For high-security environments, set grace period to 0 for immediate blocking.

Named locations and network-based CA

Trusted IP ranges (office networks, VPN exit nodes) can be defined as Named Locations in Entra. CA policies can require compliant device OR trusted location — reducing friction for desk-based users while enforcing MDM enrollment for remote access.

Sign-in risk and user risk policies

Entra ID Protection (P2 licence) generates risk signals based on impossible travel, leaked credentials, and anomalous sign-in patterns. Risk-based CA policies require MFA re-authentication or password change when elevated risk is detected — without requiring admin intervention.

Monitoring compliance drift

Intune Devices > Monitor > Noncompliant devices shows current noncompliance by reason. The Conditional Access Insights and Reporting workbook in Entra shows which policies are blocking sign-ins and for which users — essential for validating policy before enabling enforced mode.

CVSS vs EPSS for prioritisation

CVSS (Common Vulnerability Scoring System) rates severity — but high-CVSS vulnerabilities are not always actively exploited. EPSS (Exploit Prediction Scoring System) estimates the probability a CVE will be exploited in the wild within 30 days. Combining both gives a better triage signal than CVSS alone.

Defender Vulnerability Management

MDE Plan 2 includes Defender Vulnerability Management, which scores each device's software inventory against the CVE database and flags configuration weaknesses. Security recommendations appear in the Defender portal and can be pushed as Intune remediation tasks.

Patch ring timing relative to CVEs

CVSS ≥ 9.0 or CISA KEV listed? Deploy to all rings within 14 days of patch availability — compress the standard ring schedule. Actively exploited zero-days may warrant emergency out-of-band deployment to production if compensating controls are insufficient.

Intune update compliance

Intune Devices > Monitor > Feature update failures and Quality update compliance show per-device patch state. Devices that have not applied a quality update within the deadline window appear as non-compliant — combine with the compliance policy to gate CA access.

End-of-support exposure

Devices running Windows versions past end-of-support (Windows 10 21H2 reached EOS November 2023) receive no security patches. Defender Vulnerability Management flags EOS OS versions as high-risk. Prioritise feature update rollout for devices on EOS builds.

Software inventory gaps

LOB applications installed outside of Intune app management may not appear in the Defender software inventory. Use Export-IntuneDeviceReport combined with Get-StaleDevices to cross-reference managed vs detected software, identifying unmanaged installs that may carry CVE exposure.