KRIs for endpoint security

The KRIs in this domain measure the operational reality of your endpoint security program: not whether an EDR tool is purchased, but whether it is deployed, running in prevention mode, reporting actively, and covering the right assets. They measure the controls that determine how far an attacker gets after landing, encryption that prevents physical device theft from becoming a breach, host firewalls that contain lateral movement, DNS filtering that breaks command-and-control channels before they're established.

If you are standing this up from scratch, start with how to build a KRI program and the consolidated KRI reference library, which maps every domain to one CIS-aligned catalog.

KRI inventory

1. EDR agent coverage and prevention mode rate

What to measure. Two related metrics tracked together: (1) percentage of in-scope endpoints with an active, reporting EDR agent, and (2) percentage of those agents operating in prevention mode (actively blocking) rather than detection-only (monitoring/audit) mode.

Why it matters. EDR coverage gaps are the security program's blind spots. Endpoints without an active, reporting agent are invisible to your detection and response capability, they don't appear in threat hunts, they don't surface in SIEM correlation, and they don't respond to containment commands. Coverage gaps consistently cluster in the highest-risk locations: remote offices, legacy hardware, recently acquired environments, and development systems where agents are excluded "to reduce friction." Prevention mode matters as much as coverage: an agent in detection-only mode that observes ransomware executing without blocking it provides forensic data after the fact, not protection before the fact.

• EDR platform (CrowdStrike Falcon, Microsoft Defender for Endpoint, SentinelOne, Palo Alto Cortex XDR, Carbon Black): agent coverage dashboard and policy enforcement mode report
• Asset inventory (CMDB, Axonius, Tanium, Runzero): total in-scope endpoint count vs. EDR-enrolled endpoint count, the gap is your coverage risk
• Microsoft Intune / SCCM: managed device count cross-referenced against MDE enrollment
• Network discovery: endpoints seen on the network (DHCP, NAC, switch ARP tables) that are not in the EDR console, unmanaged devices with network access

How to calculate.

• Coverage rate: (Endpoints with active, reporting EDR agent) ÷ (total in-scope endpoints) × 100
• Prevention mode rate: (EDR agents in prevention/protect mode) ÷ (total enrolled agents) × 100
• Coverage gap severity: segment gap by asset class, internet-facing servers, privileged workstations, and executive devices should be at 100%

Status	Criteria
Green	>98% overall coverage; 100% prevention mode for servers and privileged workstations; coverage gap analytics run weekly; auto-enrollment configured for new device provisioning
Amber	93–97% coverage; or prevention mode <95% across fleet; or coverage gap reporting monthly rather than continuous
Red	<93% coverage; or any internet-facing server without EDR; or agents predominantly in detection-only mode; or coverage gaps not tracked

2. Endpoint compliance posture rate

What to measure. Percentage of enrolled endpoints meeting all defined compliance policy requirements, including OS patch level, EDR agent health, full-disk encryption status, host firewall state, and screen lock configuration, as reported by endpoint management or MDM platforms.

Why it matters. Compliance posture is the composite health signal for your endpoint fleet. An endpoint that passes every individual check (EDR enrolled, OS patched, encrypted) but has a disabled firewall or a failed agent update is still a risk. The compliance posture rate measures the intersection: the percentage of endpoints that are fully compliant with all baseline requirements simultaneously. It's more useful than tracking each control individually because it surfaces endpoints that are failing multiple controls at once, the highest-risk devices in your fleet.

• Microsoft Intune / Microsoft Defender for Endpoint: device compliance report, compliance status per policy per device; drill-down to non-compliant reasons
• CrowdStrike Falcon: host management, agent health, policy assignment, last check-in, prevention policy mode
• Tanium: endpoint health dashboard, compliance status across defined health checks
• Jamf (macOS): smart group for compliant vs. non-compliant devices; compliance policy criteria
• Conditional Access integration: non-compliant devices blocked from corporate resource access, count of blocked access attempts from non-compliant devices as a corroborating signal

How to calculate. (Endpoints passing all compliance policy requirements) ÷ (total enrolled endpoints) × 100 Track separately by device class: servers, executive workstations, standard workstations, developer workstations, different risk weights apply

Status	Criteria
Green	>97% compliance posture; non-compliant devices automatically isolated from sensitive resources; compliance drift alert within 24 hours of failure
Amber	90–96%; or non-compliant devices retaining full network access; or compliance posture not monitored continuously
Red	<90%; or no compliance posture enforcement; or no mechanism connecting device health to access control decisions

3. Full-Disk encryption coverage rate

What to measure. Percentage of endpoints with full-disk encryption enabled and confirmed active through endpoint management tooling, not self-reported or assumed, but verified cryptographically or via management agent attestation.

Why it matters. An unencrypted endpoint is a reportable breach event waiting for a lost laptop. The regulatory arithmetic is simple: in most US states and under GDPR, a lost or stolen device containing personal data triggers notification requirements unless the data was encrypted. Full-disk encryption converts a physical loss event into an operational inconvenience rather than a regulatory incident. At 99% coverage, one in a hundred devices is a notification risk. The challenge is verification: BitLocker "enabled" does not equal BitLocker "protecting", suspended encryption (common after updates), failed TPM initialization, and recovery key escrow failures all create false assurance.

• Microsoft Intune: GET /deviceManagement/managedDevices?$filter=operatingSystem eq 'Windows', isEncrypted field per device; or Device Compliance report filtered by encryption requirement
• CrowdStrike Falcon: host detail API, GET /devices/entities/devices/v1 with device_id, device_policies.global_config.settings.disk_encryption_enabled field
• Jamf (macOS): GET /JSSResource/computers/id/{id}/subset/GeneralAndUserAndHardware, filevault_2_percent_encrypted field; smart group for FileVault Status is Enabled
• SCCM: SQL query, SELECT Name, UserName, Encrypted FROM v_GS_BITLOCKER_DETAILS WHERE Encrypted = 0, returns unencrypted managed Windows devices
• macOS MDM: MDM command SecurityInfo response includes FDEEnabled and FDEPersonalRecoveryKeyCMS, confirm both present

How to calculate. (Endpoints with encryption enabled AND recovery key escrowed to management platform) ÷ (total endpoints) × 100 Track separately: BitLocker for Windows, FileVault for macOS, recovery key escrow is the quality signal

Status	Criteria
Green	>99% encrypted with recovery key escrowed; encryption status verified through management platform (not self-reported); servers with encryption appropriate to their environment
Amber	96–98%; or encryption enabled but recovery keys not escrowed (renders encryption unverifiable and unrecoverable); or encryption status checked manually rather than through continuous reporting
Red	<96%; or any executive or privileged-user device unencrypted; or encryption status unknown for a portion of the fleet; or BitLocker suspended on devices pending update for >7 days

4. Anti-Malware prevention mode and signature currency

What to measure. Two connected metrics: (1) percentage of endpoints with anti-malware/EDR in active prevention mode (blocking known malicious activity, not just logging it), and (2) percentage of endpoints with current threat intelligence signatures updated within the defined freshness window.

Why it matters. An EDR or AV agent in audit/detect-only mode is a forensics tool, not a prevention control. Prevention mode is frequently disabled during troubleshooting or to "reduce false positives" and never re-enabled, becoming the default state for a growing percentage of the fleet without anyone intentionally deciding that was acceptable. Signature currency matters because the detection efficacy of definition-based components drops significantly for threats first seen after the last update. An agent with 14-day-old signatures has no detection coverage for any malware variants released in the past two weeks.

• CrowdStrike Falcon: GET /devices/entities/devices/v1, device_policies.prevention.settings for prevention policy; agent_version, last_seen for agent health
• Microsoft Defender for Endpoint: GET /api/machines, healthStatus field; onboardingStatus; Security recommendations API for devices with outdated signatures
• SentinelOne: GET /web/api/v2.1/agents, isActive, threatStatus, agentVersion, lastActiveDate, policyName for prevention policy assignment
• Intune Antivirus report: GET /deviceManagement/deviceCompliancePolicySettingStateSummaries filtered for antivirus settings, signature version age per device
• SCCM Endpoint Protection: SQL, SELECT ResourceID, AntivirusEnabled, RealTimeProtectionEnabled, SignatureUpToDate FROM v_GS_AntimalwareHealthStatus WHERE SignatureUpToDate = 0

How to calculate.

• Prevention mode: (Agents with prevention/protect policy active) ÷ (total enrolled agents) × 100
• Signature currency: (Agents with signatures updated within 24 hours) ÷ (total agents) × 100; track 24h, 48h, and 7-day freshness buckets

Status	Criteria
Green	100% servers in prevention mode; >98% workstations in prevention mode; >99% of agents with signatures <24 hours old; policy prevents unapproved mode changes
Amber	Prevention mode 93–99%; or signatures 24–72 hours old on >5% of fleet; or mode changes possible without security team approval
Red	Prevention mode <93%; or any significant device class (servers, privileged workstations) not in prevention mode; or signatures >7 days old on measurable fleet percentage; or audit-only mode used as organizational default

5. Exploit prevention and attack surface reduction coverage

What to measure. Percentage of endpoints with exploit prevention controls active, including memory protection (ASLR enforcement, DEP/NX), attack surface reduction (ASR) rules, credential guard, and application isolation features, specifically for high-risk asset classes (servers, developer workstations, privileged access workstations).

Why it matters. Anti-malware catches known bad. Exploit prevention controls stop novel attacks that haven't yet been characterized as malware. ASR rules block the techniques attackers use after landing on an endpoint, disabling Office macro execution from child processes, blocking credential theft from LSASS, preventing executable content in email. These controls are frequently licensed but not configured, or configured in audit mode and never enforced. They represent meaningful risk reduction at no additional tool cost in environments running Windows 10/11 or macOS 13+.

• Microsoft Defender for Endpoint: ASR rules report, GET /api/machineconfiguration/aspolicyusers or Security Center → Reports → Attack surface reduction rules; rule status (Block/Audit/Disabled) per rule per device group
• Windows Defender Credential Guard status: Get-ComputerInfo -Property DeviceGuardSecurityServicesRunning, value should include CredentialGuard
• CrowdStrike Falcon Prevent: exploit prevention settings, process hollowing prevention, credential theft prevention, script execution prevention
• SentinelOne: Behavioral AI and Interoperability settings, static AI, behavioral AI, anti-exploitation mode
• macOS Gatekeeper: spctl --status, enabled/disabled; XProtect update currency
• Intune endpoint security profiles: exploit protection settings deployment status

How to calculate. (Endpoints with exploit prevention policy deployed and enforced) ÷ (total endpoints in scope for exploit prevention) × 100 Scope: at minimum, all servers and privileged workstations; ideally all managed endpoints

Status	Criteria
Green	Exploit prevention policy in enforce mode on all servers and privileged workstations; ASR rules in block mode for all high-risk rule categories (credential theft, Office macro execution, LSASS access); Credential Guard enabled on privileged access workstations
Amber	Exploit prevention configured but ASR rules predominantly in audit mode; or Credential Guard not deployed to privileged access workstations; or configuration drift from policy baseline not monitored
Red	No exploit prevention controls configured; or ASR rules entirely in audit mode treated as equivalent to block; or LSASS protection disabled across fleet

6. DNS and web content filtering enforcement rate

What to measure. Percentage of endpoints with DNS-level filtering and web proxy/secure web gateway (SWG) controls applied to all browsing sessions, including sessions from remote and mobile endpoints not on the corporate network, blocking known malicious domains, command-and-control infrastructure, and prohibited content categories.

Why it matters. DNS filtering is one of the highest-value, lowest-friction controls available. It blocks C2 communications before an attacker can issue commands to a compromised endpoint. It blocks phishing domains before a user can enter credentials. It blocks malicious download sites before a file reaches the browser. Critically, it works even when the user has clicked a malicious link, it's a technical backstop for the moment the human control fails. The coverage gap that matters most is remote users: filtering that only applies when on the corporate network protects nobody working from home or in a coffee shop.

• Cisco Umbrella / Cisco Secure DNS: roaming client deployment report, agents active by device; policy enforcement for remote users
• Cloudflare Gateway: device enrollment status; filtering policy active for enrolled devices
• Zscaler Internet Access: client connector deployment, endpoints routing through ZIA vs. bypassing
• Microsoft Defender SmartScreen + DNS over HTTPS: Windows endpoint policy, SmartScreen enabled, DNS filtering policy applied via Intune
• Palo Alto GlobalProtect / SWG: client deployment and policy enforcement coverage
• SIEM: DNS query logs, queries not routed through DNS filter (direct queries to public resolvers bypass filtering)

How to calculate. (Endpoints with DNS filtering active for all network paths, including remote) ÷ (total endpoints) × 100 Track separately: on-premises coverage (typically high) vs. remote/off-network coverage (often the gap)

Status	Criteria
Green	>98% of endpoints with DNS filtering applying regardless of network location; roaming agent deployed for remote coverage; filtering active for DNS over HTTPS requests (DoH bypass prevention); block events reviewed for C2 indicators
Amber	85–97%; or filtering applies on-network only with no roaming agent; or DoH bypass not blocked (users can circumvent filtering)
Red	<85%; or no DNS filtering; or filtering present but remote users consistently bypassing through unmanaged DNS resolvers; or no block event review process

7. Browser security posture and extension control

What to measure. Percentage of managed endpoints running current or N-1 supported browser versions, and the percentage of endpoints with browser security policies enforced including: restriction of unapproved browser extensions, safe browsing features active, and pop-up/script blocking configured.

Why it matters. The browser is the most exploited client application in enterprise environments because it is permanently exposed to untrusted content from the internet. Browser extension compromise is an increasingly common attack vector, malicious extensions exfiltrate session tokens, harvest credentials, and serve as persistent footholds on the endpoint. Extension sprawl (hundreds of installed extensions across a fleet) creates an attack surface that most organizations have never inventoried. Browser patching is the most consistently deferred endpoint patching category, with organizations often discovering browsers three to five versions behind at penetration test time.

• Microsoft Intune: device software report, browser versions by device; browser update compliance policy status
• Google Chrome Enterprise / Chrome Browser Cloud Management: browser version report, extension inventory, policy enforcement status
• Microsoft Edge for Enterprise: GET /deviceManagement/managedDevices with Edge version filter; Edge management policy deployment
• Browser extension audit (Chrome Enterprise): extension inventory with permissions assessment; flag extensions with tabs, webRequest, cookies, history permissions for review
• Group Policy / Intune: browser security policies, extension allowlist enforcement, safe browsing policy, SmartScreen, pop-up blocking configuration; deployment status

How to calculate.

• Browser currency: (Endpoints on current or N-1 browser version) ÷ (total endpoints) × 100
• Extension compliance: (Endpoints with extension policy enforced, allowlist or restricted to approved set) ÷ (total managed endpoints) × 100

Status	Criteria
Green	>95% on current or N-1 browser version; browser extension policy enforced with approved allowlist; auto-update enabled and monitored; high-risk extensions (password managers that exfiltrate, session token stealers) blocked by policy
Amber	85–94% current browser version; or extension policy defined but not enforced; or no extension inventory for the fleet
Red	<85% on current browser; or no browser extension control; or browsers with critical unpatched CVEs in production; or no centralized browser management

8. Removable media control compliance rate

What to measure. Percentage of endpoints with removable media (USB storage devices) controlled through policy, either fully blocked, restricted to approved/encrypted devices, or requiring authorization before use, with audit logging of all media connection events.

Why it matters. Removable media is a data exfiltration and malware introduction vector that predates most modern security tooling and remains undercontrolled in most environments. The Stuxnet worm propagated through USB drives. Insider threats routinely use USB devices for data exfiltration precisely because they bypass most network-based DLP controls. Removable media control doesn't require blocking all USB, many legitimate workflows require it. It requires that media connections are controlled, authorized, and audited.

• Microsoft Intune: device control policy deployment status, USB block/allow/audit policy per device group; policy report showing compliant vs. non-compliant
• CrowdStrike Falcon Device Control: policy enforcement coverage, GET /policy/combined/device-control/v1 for policy assignments; GET /alerts/queries/alerts/v1?filter=type:'DeviceControl' for events
• SentinelOne Device Control: USB allow/block policy coverage by device
• Windows Group Policy: Computer Configuration → Administrative Templates → System → Removable Storage Access, deployment status via GPRESULT
• Audit logs: USB connection events (Event ID 2003 for Intune policy; Windows Event Log 20001 for device installation), volume and policy violation rate

How to calculate. (Endpoints with removable media control policy enforced) ÷ (total endpoints) × 100 Track separately: blocked outright vs. controlled/audited, distinguish between organizations with legitimate USB needs and those where blocking is feasible

Status	Criteria
Green	>98% of endpoints with media control policy enforced; all connection events logged and centrally audited; unauthorized devices auto-blocked; approved device exceptions documented and time-limited
Amber	85–97%; or policy defined but unenforced on portions of the fleet; or logging active but not reviewed; or blanket exceptions for entire device classes
Red	<85%; or no removable media policy; or uncontrolled USB connections from privileged workstations or servers; or insider threat incident attributable to removable media without prior detection capability

Deriving these KRIs by source type

From Microsoft Defender for Endpoint (MDE) + Intune

curl -H "Authorization: Bearer $TOKEN" \
  "https://api.securitycenter.microsoft.com/api/machines" | \
  jq '.value | group_by(.healthStatus) | map({status: .[0].healthStatus, count: length})'

curl -H "Authorization: Bearer $TOKEN" \
  "https://api.securitycenter.microsoft.com/api/machines?$filter=healthStatus ne 'Active'" | \
  jq '.value | length'

curl -H "Authorization: Bearer $TOKEN" \
  "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?$select=deviceName,complianceState,isEncrypted,osVersion" | \
  jq '.value | group_by(.complianceState) | map({state: .[0].complianceState, count: length})'

Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Ids
Get-MpPreference | Select-Object -ExpandProperty AttackSurfaceReductionRules_Actions

curl -H "Authorization: Bearer $TOKEN" \
  "https://api.securitycenter.microsoft.com/api/machineconfiguration/aspolicyusers"

manage-bde -status

GET https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?$filter=isEncrypted eq false&$select=deviceName,userPrincipalName,isEncrypted,operatingSystem

GET https://graph.microsoft.com/v1.0/informationProtection/bitlockerRecoveryKeys?$filter=deviceId eq '{deviceId}'

From CrowdStrike Falcon

curl -H "Authorization: Bearer $FALCON_TOKEN" \
  "https://api.crowdstrike.com/devices/queries/devices/v1?limit=5000" | \
  jq '.resources[]' | \
  xargs -I{} curl -H "Authorization: Bearer $FALCON_TOKEN" \
  "https://api.crowdstrike.com/devices/entities/devices/v1?ids={}"

curl -H "Authorization: Bearer $FALCON_TOKEN" \
  "https://api.crowdstrike.com/devices/queries/devices/v1?filter=status:'Reduced Functionality'" | \
  jq '.resources | length'

curl -H "Authorization: Bearer $FALCON_TOKEN" \
  "https://api.crowdstrike.com/policy/combined/prevention/members/v1?id=<policy_id>" | \
  jq '.resources[] | {hostname: .hostname, policy_mode: .device_policies.prevention.applied}'

curl -H "Authorization: Bearer $FALCON_TOKEN" \
  "https://api.crowdstrike.com/alerts/queries/alerts/v1?filter=type:'DeviceControl'+status:'new'&sort=created_time|desc&limit=100"

curl -H "Authorization: Bearer $FALCON_TOKEN" \
  "https://api.crowdstrike.com/policy/combined/device-control/v1"

From Jamf (macOS)

curl -H "Authorization: Bearer $JAMF_TOKEN" \
  "https://yourjamf.jamfcloud.com/api/v1/computers-inventory?section=LOCAL_USER_ACCOUNTS&section=DISK_ENCRYPTION" | \
  jq '.results[] | {name: .general.name, filevaultEnabled: .diskEncryption.fileVault2Status}'


curl -H "Authorization: Bearer $JAMF_TOKEN" \
  "https://yourjamf.jamfcloud.com/api/v1/computers-inventory?section=APPLICATIONS" | \
  jq '.results[] | {name: .general.name, browsers: [.applications[] | select(.name | test("Chrome|Firefox|Safari|Edge")) | {name: .name, version: .version}]}'

From DNS Filtering Platforms (Cisco Umbrella, Cloudflare Gateway, Zscaler)

curl -H "Authorization: Bearer $UMBRELLA_TOKEN" \
  "https://management.api.umbrella.com/v1/organizations/{orgId}/roamingcomputers" | \
  jq '{total: (.data | length), active: [.data[] | select(.type == "roaming" and .status == "active")] | length}'

curl -H "Authorization: Bearer $UMBRELLA_TOKEN" \
  "https://reports.api.umbrella.com/v2/organizations/{orgId}/activity?from=-7days&limit=500&categories=malware,c2,ransomware" | \
  jq '.data[] | {endpoint: .internalIp, domain: .domain, category: .categories}'

curl -H "Authorization: Bearer $CF_TOKEN" -H "X-Auth-Email: $CF_EMAIL" \
  "https://api.cloudflare.com/client/v4/accounts/{accountId}/devices" | \
  jq '.result | group_by(.last_seen_day) | length'

From Chrome Browser Cloud Management / Google Admin

curl -H "Authorization: Bearer $GOOGLE_TOKEN" \
  "https://www.googleapis.com/admin/directory/v1/customer/my_customer/devices/chromebrowsers?projection=FULL" | \
  jq '.browsers[] | {deviceName: .deviceName, chromeVersion: .chromeVersion, lastRegistrationTime: .lastRegistrationTime}'


curl -H "Authorization: Bearer $GOOGLE_TOKEN" \
  "https://www.googleapis.com/admin/directory/v1/customer/my_customer/devices/chromebrowsers?projection=FULL" | \
  jq '.browsers[] | .extensionCount' | sort | uniq -c