KRIs for mobile and BYOD security

The KRIs in this domain measure whether your mobile security program, whether fully managed, BYOD, or hybrid, is producing the control coverage and visibility that the business access these devices carry actually requires.

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. Mobile device management (MDM) enrollment rate

What to measure. Percentage of mobile devices accessing corporate email, applications, or data that are enrolled in MDM and subject to device management policies, segmented by device ownership (corporate-owned vs. BYOD) and by access type.

Why it matters. Devices not enrolled in MDM are invisible to your endpoint management and security monitoring capability. They can't be remotely wiped, can't have security policies enforced, can't be confirmed as running current OS versions, and can't be assessed for device health before granting access to sensitive data. Enrollment rate is the prerequisite for all other mobile security controls.

• MDM platform (Intune, Jamf, VMware Workspace ONE, Kandji): enrolled device count vs. expected device population
• Identity provider: mobile sign-ins from devices not registered in MDM, gap between sign-in activity and enrollment
• Conditional Access policies: access attempts from non-compliant or unenrolled devices, blocked count vs. successful count
• HR: employee count and BYOD program participation rates, expected device population estimate

How to calculate. (Devices enrolled in MDM with policy applied) ÷ (estimated total devices accessing corporate resources) × 100 BYOD-specific: (BYOD devices enrolled or in MAM without MDM) ÷ (total BYOD devices accessing corporate resources) × 100

Status	Criteria
Green	>95% corporate-owned devices enrolled; >80% BYOD devices enrolled or in MAM; Conditional Access blocking unmanaged device access to sensitive data
Amber	80–94% corporate; or BYOD access to sensitive data without enrollment requirement
Red	<80% corporate-owned enrolled; or unmanaged devices with access to sensitive corporate data; or no MDM program

2. Device OS currency rate

What to measure. Percentage of enrolled mobile devices running a current or N-1 supported OS version, segmented by iOS and Android, and the rate of devices running versions with known critical vulnerabilities.

Why it matters. Mobile OS updates fix exploitable vulnerabilities. A device running iOS or Android more than two major versions behind the current release is carrying unpatched vulnerabilities that are publicly known and for which exploit code frequently exists. MDM provides the visibility into OS versions across the fleet, without it, you don't know.

• MDM platform: device inventory with OS version per device; compliance policy configuration for minimum OS version
• Intune: device compliance report filtered by OS version; non-compliant devices due to OS version
• Jamf: Smart Group for devices below minimum OS version
• CVE databases: mobile OS vulnerability history, correlate devices on specific OS versions with known CVEs

How to calculate. (Enrolled devices on current or N-1 OS version) ÷ (total enrolled devices) × 100 Critical exposure: (Devices running OS versions with CISA KEV vulnerabilities), count

Status	Criteria
Green	>95% on current or N-1; MDM compliance policy enforces minimum version; access blocked for devices below minimum version
Amber	85–94%; or minimum version enforced but not access-blocked for non-compliance
Red	<85%; or no OS version enforcement; or devices with KEV vulnerabilities and no remediation path

3. Mobile application security controls coverage

What to measure. Percentage of corporate mobile applications (both internal and approved third-party apps) deployed through managed channels, corporate app store or MDM push, and the percentage of sensitive corporate applications wrapped with Mobile Application Management (MAM) controls (data encryption, copy-paste restriction, remote wipe).

Why it matters. Apps installed outside managed channels bypass your application security controls. MAM policies on sensitive applications ensure that corporate data accessed through those apps is encrypted, can't be copied to personal apps, and can be wiped remotely without affecting personal data on the device.

• MDM managed app catalog: apps deployed via managed channels vs. apps accessing corporate data detected in conditional access logs
• MAM policy configuration (Intune App Protection Policies, Jamf Connect, Workspace ONE): apps with data protection policies applied
• Conditional Access: app-based conditional access, access to corporate email/data limited to managed app clients
• Mobile Threat Defense: apps with risky behaviors detected on enrolled devices

How to calculate. (Corporate applications with MAM/data protection policy applied) ÷ (total corporate applications requiring data protection) × 100

Status	Criteria
Green	All email and sensitive data apps with MAM policy; managed app catalog used for approved application distribution; app-based Conditional Access blocking unmanaged client apps
Amber	MAM on email clients but not all data-access applications; or approved apps deployed but without MAM data protection policies
Red	No MAM program; or corporate data accessible through any unmanaged app the user chooses to install

4. Mobile threat defense (MTD) coverage rate

What to measure. Percentage of enrolled mobile devices with an active Mobile Threat Defense agent, detecting device-level threats including malicious apps, network attacks, OS exploits, and jailbreak/root detection.

Why it matters. MDM manages device configuration. MTD detects threats. A device can be MDM-enrolled with all policies applied, and still be compromised through a malicious app or network attack that MDM has no visibility into. MTD is the mobile equivalent of EDR, the detection layer for threats that get through configuration management.

• MTD platform (Lookout, Zimperium, Microsoft Defender for Endpoint mobile, CrowdStrike Falcon for Mobile): agent deployment report, enrolled vs. reporting
• MDM integration: MTD agent status visible in MDM compliance data (Intune + Defender, Jamf + Lookout integrations)
• MTD threat event volume: device threats detected per month by category (malicious app, network attack, OS vulnerability, jailbreak)

How to calculate. (Devices with active MTD agent reporting) ÷ (total enrolled devices) × 100

Status	Criteria
Green	>90% of enrolled devices with active MTD; MTD signals integrated into MDM compliance (non-compliant device loses access on threat detection); threat events reviewed by security team
Amber	70–89% MTD coverage; or MTD deployed but not integrated with MDM compliance
Red	<70%; or no MTD program; or MTD deployed without integration into access control decisions

5. BYOD data isolation effectiveness

What to measure. Whether BYOD devices accessing corporate data have a verified containerization or separation mechanism that prevents corporate data from mixing with personal apps, and whether that separation has been validated rather than assumed.

Why it matters. BYOD without data isolation means corporate email, files, and application data coexist with personal content on the same device, accessible to personal apps, potentially backed up to personal cloud accounts, and potentially exposed if the device is compromised through a personal app. MAM containerization provides the separation, but it needs to be verified, not assumed.

• MDM/MAM platform: App Protection Policy compliance status per BYOD device, policy applied and enforced
• Conditional Access: BYOD devices verified as compliant with MAM policy before accessing corporate resources
• Intune App Protection report: data transfer between corporate and personal apps, blocked events confirm policy enforcement
• User acceptance testing records: MAM policy validation, tested that corporate data cannot be pasted into personal apps

KRI values.

• Containerization coverage: (BYOD devices with verified MAM containerization applied) ÷ (total BYOD devices accessing corporate data) × 100
• Policy enforcement events: count of blocked data-to-personal-app transfers per month (signals policy is active)

Status	Criteria
Green	100% of BYOD devices with MAM containerization verified through Conditional Access; blocked transfer events confirm policy is enforcing; selective wipe tested
Amber	MAM policy assigned but not verified through Conditional Access; or coverage gaps for BYOD devices accessing email
Red	BYOD accessing corporate data without any containerization; or no BYOD data isolation policy

6. Lost and stolen device response rate

What to measure. Percentage of reported lost or stolen mobile devices for which remote wipe or remote lock was executed within the defined SLA, and whether the remote wipe command was successfully confirmed.

Why it matters. A lost or stolen device with unencrypted corporate data, active session tokens, and no remote wipe capability is a breach waiting to be discovered. Remote wipe capability is only as good as the SLA for executing it, a device reported lost Friday afternoon that gets wiped Monday morning has been uncontrolled for 72+ hours.

• MDM platform: wipe/lock command execution records and confirmation status
• IT helpdesk: lost device reports with timestamp and MDM action timestamp, SLA calculation
• MDM wipe confirmation: confirmed wipe vs. pending wipe (device offline), devices that couldn't be wiped due to being offline

How to calculate. (Reported lost/stolen devices with remote wipe or lock executed within SLA) ÷ (total lost/stolen device reports) × 100 SLA definition: typical best practice is wipe initiated within 1 hour of report; confirmed within 24 hours

Status	Criteria
Green	>99% wiped or locked within 1 hour of report; 24/7 MDM wipe capability; wipe confirmation tracked; unconfirmed wipes monitored for device reconnection
Amber	Wipe within 1–4 hours; or business-hours-only capability; or wipe confirmation not tracked
Red	Wipe SLA >4 hours; or no 24/7 MDM capability; or discovered devices not in MDM (can't be wiped)

Deriving these KRIs by source type

From Microsoft Intune

• Enrollment report: GET /deviceManagement/managedDevices?$filter=operatingSystem eq 'iOS' or operatingSystem eq 'Android' via Graph API, count enrolled vs. expected population
• OS compliance: GET /deviceManagement/deviceCompliancePolicies/{id}/deviceComplianceDeviceStatuses, filter non-compliant devices by OS version reason
• App Protection Policy status: GET /deviceAppManagement/managedAppRegistrations, apps registered for MAM; GET /deviceAppManagement/managedAppStatuses for protection status
• MTD compliance: Intune + Defender integration → device risk level in compliance policy; filter high/medium risk devices currently in compliance

From Jamf (iOS/macOS)

• Smart Groups for OS compliance: Create Smart Group Operating System Version is less than <minimum>, count as non-compliant
• Enrollment rate: Jamf Pro reports → Device Enrollment Report; compare against expected population from HR/procurement
• Lost device commands: Jamf Pro → Computer Management → Remote Commands; lost mode activation records with timestamp

From Mobile Threat Defense Platforms (Lookout, Zimperium, Microsoft Defender Mobile)

• Agent coverage: Platform dashboard shows enrolled vs. reporting agents; calculate coverage rate
• Threat event log: Threats by category (malware, network, vulnerability, jailbreak) per device, aggregate by device owner type (corporate vs. BYOD)
• API integration: Lookout REST API, Zimperium zConsole API for threat event export to SIEM

From Conditional Access / Identity (Entra ID, Okta)

• Device compliance signals: Sign-in logs filtered for deviceDetail.isCompliant: false, count of sign-ins from non-compliant devices; if Conditional Access is blocking them, count should be near zero for sensitive resources
• Unmanaged device access: Sign-in events where deviceDetail.trustType is null or AzureAD registered (BYOD) without MAM, these are accessing corporate resources from unmanaged context
• App-based CA: Sign-in events where clientAppUsed: Browser or legacy client accessing corporate data, should be blocked by app-based CA if MAM is enforced