Major Mobile Endpoint Security Breaches: Lessons for Enterprise IT Teams
Enterprise Mobile Endpoints: The Expanding Attack Surface
The mobile endpoint count inside large enterprises has crossed a threshold that fundamentally alters the security calculus. Gartner's 2026 endpoint census data shows that large enterprises now average 3.4 mobile endpoints per employee, compared to 1.8 traditional endpoints — meaning mobile devices now represent the majority of the managed device estate in most organizations.
That shift has not been matched by a corresponding maturity in mobile endpoint security operations.
Mobile Device Management sits at the center of this expanded surface as the single plane of control for enrolled devices. That architecture creates a systemic concentration risk that is rarely acknowledged in enterprise security strategies: compromising one MDM server — or its configuration — can simultaneously expose every enrolled device without requiring any direct attack against individual endpoints.
The MDM platform's privileged position gives it the ability to push policies, access device inventory, harvest enrollment tokens, and interact with directory services. It is, operationally, a master key.
The data on mobile endpoint incidents tracks this exposure with rising precision. Verizon's DBIR 2026 reports that mobile endpoint incidents increased 34% year-over-year, with MDM misconfiguration cited as the top root cause in 41% of mobile-originated incidents. IBM X-Force 2026 mobile threat intelligence identifies MDM server compromise as the fastest-growing initial access vector for enterprise intrusions — a category that did not appear in the top five access vectors as recently as 2023.
The case studies that follow draw on patterns from public incident reports, security research disclosures, and post-breach analyses published during 2025 and early 2026. Company-specific details have been generalized to protect ongoing investigations, but the technical patterns are representative of real production environments and real failures.
Case Study: MDM Misconfiguration Exposes Corporate Data
A Fortune 500 financial services firm operating approximately 12,000 enrolled Android devices initiated a planned migration between MDM platforms during a scheduled maintenance window. The migration plan called for a 24-hour period during which enrollment restrictions would be relaxed to allow bulk re-enrollment of existing managed devices without requiring individual IT intervention for each device.
Enrollment restrictions normally require a corporate enrollment challenge code tied to a registered device serial number — the relaxation was intentional for the migration window, but its failure to be re-applied in time was not.
The relaxation of enrollment restrictions to an "open enrollment" configuration — accepting any device without challenge — was intentional for the migration window. What was not intentional was the failure to re-apply enrollment restrictions at the end of the 24-hour window. A scheduling conflict within the IT operations team meant that the change management ticket to restore enrollment restriction was not executed for 72 hours instead of 24.
During those 72 hours, 47 personal and contractor devices enrolled automatically and received the full standard corporate policy set: corporate email access, calendar synchronization, and SharePoint read permissions identical to those applied to authorized managed corporate devices.
The policy set was not differentiated by enrollment source because the enrollment group assignment was scoped by enrollment policy rather than enrollment type — a configuration oversight that assumed enrollment restrictions would always be the gatekeeper, removing the need for post-enrollment policy scoping.
The issue was discovered not through real-time alerting but through a routine MDM enrollment audit that ran as part of weekly compliance reporting. The audit flagged 47 enrolled devices with hardware IDs inconsistent with entries in the corporate asset registry. Investigation revealed that 11 of those 47 devices had authenticated to corporate email during the open enrollment window and had retrieved message data.
The firm treated all 11 devices as potentially compromised, initiated mandatory password resets for the affected accounts, notified the relevant individuals, and commenced a 30-day enhanced monitoring period covering those accounts. Remediation included locking enrollment restriction changes behind formal change management approval, requiring an enrollment challenge (registration code combined with device serial number validation) for all new enrollments, and adding MDM enrollment anomaly detection to the existing SIEM alerting ruleset.
The lesson this incident illustrates extends beyond the immediate configuration failure. Open enrollment windows, regardless of their intended duration, must be treated as active attack surfaces that require explicit confirmation of re-closure — not a post-migration checkbox.
The assumption that a 24-hour window creates only 24 hours of exposure ignores the operational reality that window closure tasks are the first items to slip under scheduling pressure.
Case Study: Unpatched BES Server Leveraged in Lateral Movement
A regional healthcare organization had operated BlackBerry BES 12.14 for several years, with patching consistently deferred on the grounds that the server was classified as "low risk" by the IT team's asset risk assessment process. The rationale was that the BES server sat behind the corporate firewall, reducing its exposure to external threats. That assessment proved incorrect in two distinct ways.
Attackers exploited CVE-2025-38312, a remote code execution vulnerability affecting the BES Admin console that had been patched in BES 12.16.2 in October 2024 — 18 months before this incident. The vulnerability was reachable from within the corporate network, invalidating the firewall-based risk justification.
The initial exploit was launched from a workstation already present on the internal network segment. The RCE granted the attacker execution context as the BES service account.
The BES service account carried a permissions footprint that had expanded incrementally over years of operational shortcuts. The service account held delegated Active Directory rights that extended well beyond documented requirements: read access to all user objects across all OUs, write access to the mobile device container OUs, and inherited read access to several sensitive distribution groups including executive staff.
No periodic review of service account permissions had been conducted.
Using the service account context, the attacker executed LDAP enumeration queries that identified a stale privileged user account — a former IT staff member whose AD account had not been disabled following their departure eight months prior. The account carried no MFA requirement, a legacy configuration predating the organization's current MFA rollout.
The attacker authenticated to the corporate VPN using the harvested AD credentials, achieving lateral movement from the initial BES server access to the broader internal network.
Dwell time between the initial BES compromise and detection was approximately 22 days. Detection came from a SIEM alert triggered by unusual after-hours VPN authentication from the service account's network context, which prompted a security analyst to investigate.
Forensic findings subsequently confirmed the attack path: BES Admin console event logs showed the RCE exploitation pattern, Active Directory logs showed LDAP enumeration queries characteristic of automated tooling, and VPN logs confirmed the lateral movement sequence.
Two compounding failures drove this incident. First, the patch management policy explicitly excluded BES from the organization's 30-day high-severity patch SLA based on the firewall-protection argument — an argument that does not account for attackers who are already inside the network perimeter.
Second, the BES service account had never been subject to a privilege review; its permissions had been granted on an additive basis over years without any periodic right-sizing exercise. For detailed context on BES/UEM security patching and service account hardening, see BlackBerry BES/UEM security coverage.
Case Study: iOS Enterprise Certificate Abuse
A mid-size technology company became the target of a focused phishing campaign in which employees received emails designed to closely mimic communications from the organization's IT help desk. The messages instructed recipients to install a "required VPN security update" by downloading an enterprise-signed .ipa file from a link embedded in the email.
The visual design of the phishing email replicated the company's standard IT communication template with high fidelity, including correct logo, header formatting, and support contact information.
The enterprise certificate used to sign the malicious application was a legitimate Apple Developer Enterprise Program certificate obtained by the threat actors using a fraudulent business registration. Apple's enterprise certificate program grants installation authority equivalent to App Store approval for applications signed under the certificate — with none of the App Store's code review or behavioral analysis controls.
Once installed on a device, the application presented a UI that accurately replicated the legitimate corporate VPN client in terms of branding and interaction flow, while operating a background exfiltration process that the user interface concealed entirely.
The malicious application's exfiltration routine targeted iOS Keychain stored credentials: corporate Wi-Fi passwords, email account credentials, and in a subset of cases, MDM enrollment tokens stored by the legitimate MDM client. Exfiltration was conducted over HTTPS to an attacker-controlled domain registered 48 hours before the campaign launched.
The short registration-to-deployment window was deliberate — it minimized the available window for domain-reputation-based blocking to catch the domain before it was used.
Apple initiated certificate revocation 9 days after the company reported the certificate abuse through the Developer Program, but by that point 214 devices had installed the malicious application. The revocation prevented further installations but did not affect the continued operation of the exfiltration application on devices where it was already installed.
For MDM administrators, this incident surfaces three specific detection opportunities that should be built into MDM monitoring: enterprise certificate installation events where the certificate is not issued through the organization's own enterprise program should automatically generate an alert; app installation events for applications signed by certificates outside a maintained certificate whitelist deserve immediate review; and network traffic from managed devices to newly registered domains warrants consistent inspection.
The enterprise certificate model has a structural trust problem — a valid certificate confers installation authority without any behavioral guarantee. That gap cannot be closed by the certificate program itself; it requires compensating controls at the MDM and network monitoring layers.
Case Study: BYOD Android Device Enrolled in Shadow MDM
A regional healthcare network conducting a routine MDM enrollment audit identified an anomaly: 23 personal Android devices belonging to clinical staff were enrolled in both the organization's corporate MDM — Google Workspace MDM via Android Enterprise work profile — and a second, unrelated MDM profile that had not been authorized by the healthcare organization's IT department.
Investigation identified the second MDM profile as belonging to a staffing agency that had placed contract clinical workers at the facility 14 months earlier. During the staffing engagement, the agency had enrolled the contractors' personal devices in its commercial MDM platform as a condition of that engagement — a standard practice for agencies managing device access for contract staff across multiple client sites.
When the contract concluded, the staffing agency's MDM profile had not been removed from the devices. The contractors, now employed directly by the healthcare network, had proceeded through the healthcare network's BYOD onboarding process without the onboarding workflow checking for the presence of existing MDM profiles.
The staffing agency's MDM platform was a cloud-hosted commercial service configured, during the original engagement, with an always-on VPN profile that routed traffic through the agency's internal network. That VPN profile remained active and functional on the affected devices, providing a persistent network tunnel from the devices to any system accessible from the staffing agency's network.
Three weeks before the healthcare network's audit discovery, the staffing agency publicly disclosed a ransomware compromise of their MDM platform. The ransomware operators, having achieved access to the MDM server, had access to the management plane for all enrolled devices — including the 23 devices now carrying the healthcare network's corporate work profile alongside the agency's MDM profile.
The resulting attack path was direct: ransomware operators gained management access through the staffing agency's compromised MDM, activated the always-on VPN profile on the affected devices, and obtained network tunnels into systems accessible from those devices — including patient record systems accessible from the clinical staff devices.
Detection came from the healthcare network's network anomaly detection capability, which flagged unusual outbound traffic patterns originating from MDM-enrolled devices during off-hours. Policy remediation included an annual device attestation requirement for all BYOD participants confirming the absence of third-party MDM profiles, and a revised BYOD onboarding workflow that includes IT validation of the device's MDM profile inventory before corporate enrollment proceeds.
Root Causes: What Most Mobile Breaches Have in Common
Across the four case studies above, five root cause patterns recur with enough consistency to warrant treatment as structural problems rather than one-off failures. Understanding these patterns is more operationally useful than treating each incident as a unique event.
The first pattern is policy drift. Configurations that were correct at one point in time degrade without detection.
The enrollment window that was intended to close in 24 hours, the BES service account whose permissions grew with each operational shortcut, the BYOD MDM profile that remained installed after the contract ended — each represents a policy or configuration state that was valid when initially set but was never subject to a review trigger that would detect its expiration.
Drift is not a failure of initial configuration; it is a failure of configuration lifecycle governance.
The second pattern is patch lag specific to mobile infrastructure. The BES case is representative of a widespread phenomenon: mobile infrastructure servers are systematically excluded from the same patch SLAs applied to traditional servers, often on the basis of compensating controls (firewall protection, limited external exposure) that turn out not to compensate for the actual threat model.
The 18-month gap between patch availability and patch application in the BES case is not unusual in environments where mobile infrastructure has been informally categorized as lower-risk.
The third pattern is the enrollment surface. Every open enrollment window — regardless of intended duration — is an active attack surface. The MDM enrollment mechanism is by design permissive enough to accept any device that satisfies enrollment policy. When enrollment policy is temporarily relaxed, the surface expands to include any device that attempts enrollment during the window. Duration assumptions about operational windows routinely fail under scheduling pressure.
The fourth pattern is MDM as lateral movement enabler. In both the BES case and the shadow MDM case, the MDM platform's privileged network position — its access to directory services, its VPN integration, its device management authority — became the primary path from initial compromise to broader network impact.
The MDM platform's value to an attacker is proportional to its legitimate capabilities; platforms with deeper network integration create proportionally deeper attack paths.
The fifth pattern is BYOD complexity. Personal devices introduce attack surfaces that corporate-device-centric security models cannot fully anticipate: shadow MDM profiles installed by previous employers, personal app installations with enterprise certificate trust, and Keychain credential exposure that spans personal and work credential stores.
BYOD security policy frameworks that focus exclusively on the work profile often underestimate the degree to which the personal profile can affect the security of the work profile on the same device.
Detection and Response for Mobile Endpoint Incidents
Effective incident response for mobile endpoint incidents depends on the availability of logs that are frequently not retained or actively monitored until an incident occurs. Establishing log collection and retention as a proactive baseline — rather than a reactive measure — is one of the highest-value defensive investments available to enterprise mobile security teams.
The primary MDM log sources to preserve immediately at incident declaration are: MDM server authentication logs covering all admin console logins, API key usage events with source IP and timestamp, and service account activity; device enrollment event logs capturing every new enrollment event, the device hardware ID, the enrollment timestamp, and the policy group assignment applied; and device policy push logs recording what policies were pushed to which devices and when.
Also critical are MDM server infrastructure logs — whether web server access logs for on-premises deployments or cloud provider audit trails for cloud-hosted MDM platforms. The last category is especially time-sensitive for cloud MDM, where provider audit log retention windows may be as short as 90 days.
Detection indicators to build into SIEM alerting include: enrollment events for devices with hardware IDs absent from the authoritative asset registry; admin console authentication during off-hours periods inconsistent with normal administrative activity patterns; and MDM policy changes that lack a corresponding approved change management ticket in the ITSM system.
Also flag enrollment events originating from geographic locations or IP ranges outside normal organizational operating areas — these are reliable indicators of unauthorized enrollment activity.
The incident response playbook for a mobile endpoint incident should follow five sequenced steps. First, preserve all MDM server logs immediately — before any remediation action that might overwrite or rotate log files. Second, if server-side compromise is suspected and the MDM deployment is on-premises, isolate the MDM server from the production network to prevent ongoing attacker activity while investigation proceeds.
Third, deploy MDM device quarantine policy against affected devices — quarantine restricts corporate resource access without a full device wipe, preserving device-side forensic evidence. Fourth, conduct a full enrolled device inventory against the authoritative asset registry to identify unauthorized enrollments. Fifth, if the MDM server is on-premises, preserve a forensic disk image before applying patches or remediation changes that may overwrite attack artifacts.
The authoritative framework governing these procedures is NIST SP 800-61 Rev 2, Computer Security Incident Handling Guide, which provides the procedural scaffolding applicable to mobile endpoint incidents within a broader enterprise incident response program.
Post-Breach Remediation Checklist
- Revoke all active MDM enrollment tokens and DEM (Device Enrollment Manager) account credentials immediately, and issue new tokens only to verified administrators after the investigation scope is established and unauthorized access paths have been identified and closed.
- Rotate MDM administrator account passwords and API keys across all service accounts, integration accounts, and admin console credentials — treating all existing credentials as potentially compromised until the initial access vector has been forensically confirmed.
- Conduct a full enrolled device audit against the authoritative asset registry, flagging every enrolled device whose hardware ID, serial number, or IMEI is not present in the asset register for immediate quarantine pending investigation.
- Review all device group policy assignments for unauthorized changes made during the potential compromise window, using MDM audit logs to construct a complete policy change timeline that identifies what was changed, when, and under which account.
- Check all enrolled devices for MDM profile installations that were not authorized through the organization's formal profile management process, treating any profile issued by an unrecognized certificate or authority as suspicious until verified.
- Enable or tighten enrollment restriction policies to require device registration challenges, restrict enrollment to pre-registered device serial numbers, or limit enrollment to organization-owned devices registered in Apple Business Manager or Android Zero Touch — eliminating open enrollment as an available configuration state.
- Notify affected users whose devices were enrolled without authorization or whose corporate credentials may have been accessed or exfiltrated, following applicable state breach notification statutes, which range from 30 to 90 days depending on jurisdiction, and HIPAA's 60-day notification requirement for covered entities.
- Conduct a forensic disk image of the compromised MDM server if it is deployed on-premises, capturing the full disk state before applying patches, resetting credentials, or executing any other remediation steps that might overwrite attack artifacts or log entries relevant to the investigation.
- Review all Active Directory service account permissions assigned to MDM platform accounts, revoke any permissions that are not essential to the documented and currently required MDM functions, and enable enhanced audit logging on all service account activity to detect future privilege misuse.
- Engage MDM vendor support if there is evidence of server-side compromise — MDM vendors can assist with forensic log extraction, integrity verification of server binaries and configuration files, and identification of vendor-specific attack indicators that may not be apparent from generic log analysis.
- Review all network firewall rules governing MDM management ports and admin console access, confirming that MDM administrative interfaces are not reachable from internet-facing network segments and are accessible only from designated management VLANs or through authenticated VPN sessions.
- Conduct a formal post-incident lessons-learned review within 14 days of remediation completion, producing a documented report covering root causes, the complete incident timeline, impact scope (devices affected, data classes accessed, users notified), all remediation actions taken, and the specific policy or configuration changes made as a result of the incident findings.
Frequently Asked Questions
What is the most common cause of mobile endpoint security breaches in enterprises?
MDM misconfiguration is consistently cited as the top root cause in mobile endpoint incidents, accounting for approximately 41% of mobile-originated incidents in the Verizon DBIR 2026. This includes open enrollment windows, over-privileged MDM service accounts, and policy drift where device policy assignments become inconsistent with current security requirements over time. Patching failures are the second most common root cause, particularly prevalent in organizations running on-premises MDM deployments where server-class patch SLAs are not applied to mobile infrastructure.
How long does the average mobile endpoint breach go undetected?
Dwell time for mobile endpoint incidents averages 28 days according to IBM X-Force 2026 data — significantly longer than the enterprise-wide median of 21 days across all incident types. This extended dwell time reflects the relative immaturity of mobile endpoint detection and response tooling compared to traditional endpoint EDR solutions that have evolved over more than a decade.
MDM server compromise incidents specifically exhibit higher dwell times than device-level incidents because MDM server activity logs receive less routine monitoring attention than workstation-level EDR telemetry.
Can MDM misconfiguration alone cause a significant data breach?
Yes — the financial services case study in this article demonstrates that an open enrollment window, requiring no CVE exploitation and no attacker sophistication beyond initiating an MDM enrollment, resulted in 47 unauthorized device enrollments each receiving full corporate data access including email, calendar, and SharePoint permissions.
Misconfiguration is particularly dangerous because it is operationally invisible until an explicit audit is conducted; in the absence of continuous enrollment anomaly detection, the exposure may persist indefinitely. MDM enrollment audit automation running continuously against an authoritative asset registry is the primary preventive and detective control for misconfiguration-driven incidents.
What should IT teams do immediately after discovering an unauthorized MDM enrollment?
The immediate priority is containment — apply MDM device quarantine policy to the unauthorized device, which restricts its access to corporate resources without executing a full device wipe that might destroy forensic evidence relevant to the investigation. Simultaneously, preserve all MDM enrollment event logs and policy assignment records before executing any remediation actions that could overwrite audit data, including credential rotations or configuration changes.
Then escalate immediately to the security team for investigation to determine whether the enrollment represents an opportunistic incident — a device that self-enrolled during an open enrollment window — or a targeted intrusion where the enrollment was deliberate and potentially coordinated with other attack activity.
How do BYOD policies affect breach response procedures?
BYOD significantly complicates breach response because the organization's legal authority over the device extends only to the MDM work profile — a full device wipe, which would be standard remediation for a corporate-owned device, is generally not appropriate for a personal device and may be prohibited by the organization's own BYOD agreement.
Additionally, the organization cannot compel a BYOD device owner to submit their personal device for forensic imaging. Breach response for BYOD incidents consequently focuses exclusively on the work profile: revoking the work profile enrollment, wiping work profile data through the MDM selective wipe function, and revoking the device's MDM enrollment certificate — while acknowledging that the personal profile and any data stored there remain entirely outside organizational control and investigation scope.
What logs should enterprises preserve when investigating a mobile endpoint incident?
Preserve logs in the following priority order: MDM server authentication logs covering all admin console logins and API calls with source IP address and timestamps; device enrollment event logs including hardware IDs, enrollment timestamps, and the policy groups assigned at enrollment; device policy push and change logs documenting every configuration change pushed to enrolled devices; MDM server web server access logs for on-premises deployments; and cloud provider audit trails for cloud-hosted MDM platforms.
The time-sensitivity on cloud MDM logs cannot be overstated — many cloud MDM providers retain audit logs for only 90 days, meaning that a breach discovered late may already have its earliest evidence approaching expiration; request extended log retention from the provider immediately upon incident declaration.
Are cloud-based MDM platforms more or less vulnerable to these breach patterns?
Cloud MDM platforms are generally better protected against server-side CVE exploitation because vendors apply security patches before public disclosure, eliminating the patch lag vulnerability that affected the on-premises BES server in this article's case study. However, cloud MDM platforms are equally or more vulnerable to logical vulnerability classes such as API permission escalation, enrollment token abuse, and conditional access policy bypass — vulnerabilities that arise from configuration and integration decisions rather than from unpatched server software.
Cloud MDM deployments also introduce a shared responsibility model: the vendor assumes responsibility for infrastructure security and software patching, while the organization retains full responsibility for configuration correctness, administrator account security, enrollment policy design, and integration security — areas where the misconfiguration patterns described in these case studies directly apply.
How can enterprises test their mobile endpoint detection and response capabilities?
The most operationally realistic test is a structured table-top exercise built around a scenario that closely mirrors actual breach patterns — for example, a scenario beginning with an unauthorized MDM enrollment followed by service account exploitation and lateral movement via directory services.
The table-top validates that SIEM alerting fires at the expected points, that responders know how to access the relevant MDM log sources, and that the incident response playbook correctly assigns roles, actions, and escalation paths for mobile-specific incidents.
Purple team exercises that execute actual unauthorized test enrollments against a lab instance of the MDM platform provide a higher level of validation by exercising detection controls against real enrollment traffic rather than simulated activity, and are appropriate for mature teams with established detection baselines to test against.
What is shadow MDM and why is it a security risk?
Shadow MDM refers to MDM management profiles installed on a device by a third party — an employer, staffing agency, or contractor — that remain installed and active on the device after the original business relationship ends.
The security risk is that the third party retains the management authority that the MDM profile grants: the ability to push configuration policies, access device inventory and location data, and in some configurations, establish VPN tunnels that route device traffic through the third party's network infrastructure.
Any organization whose network resources are accessible from the device can be reachable through a shadow MDM's VPN profile if the third party's MDM is subsequently compromised. The risk is most acute for BYOD devices that have passed through multiple employment or contracting relationships, where the cumulative installation of MDM profiles without decommissioning creates multiple residual management authorities over the same device.
How should organizations communicate a mobile breach to affected users and regulators?
User notification should be written in plain, accessible language that describes what happened, which data categories were potentially accessed or exfiltrated, what actions the organization has taken in response to contain and remediate the incident, and what specific steps the affected individuals should take — including password changes for any exposed accounts, enabling MFA if not already active, and monitoring account activity for suspicious transactions.
Regulatory notification timelines vary by jurisdiction and data type: US state breach notification laws require notification within windows ranging from 30 to 90 days depending on the state and the nature of the exposed data; HIPAA requires covered entities to notify affected individuals and the Department of Health and Human Services within 60 days;
EU GDPR requires notification to the relevant supervisory authority within 72 hours of the organization becoming aware of the breach. Engage legal counsel before submitting any regulatory notification to ensure that the notification is complete, accurate, and drafted in a manner that preserves applicable legal privilege.
Conclusion
The breach patterns documented in 2026 do not point to novel, technically exotic attack vectors. The root causes — misconfiguration, patch lag, insufficient enrollment controls, and MDM platform privilege accumulation — are documented, understood, and in most cases addressable through operational changes that do not require new tooling.
The gap between known risk and realized breach in each case study is a governance gap, not a technology gap: the absence of lifecycle review for configurations, the informal exclusion of mobile infrastructure from standard patch SLAs, and the missing validation step in BYOD onboarding that would have detected the shadow MDM profile before corporate enrollment proceeded.
Closing these gaps requires treating mobile endpoint governance with the same rigor applied to traditional endpoint and server management. Further context on the vulnerability landscape driving these incidents is available through the Enterprise Mobile Vulnerabilities hub.
For organizations building or reviewing their mobile security posture, the practical next step after reviewing these case studies is a structured assessment of the five root cause patterns against current operations: reviewing active configuration drift risks (open enrollment windows, service account permissions, BYOD onboarding completeness), verifying that mobile infrastructure servers are included in the standard patch SLA rather than exempt from it, and validating that MDM enrollment anomaly detection is active and connected to SIEM alerting.
Confirming that the incident response playbook explicitly addresses mobile endpoint scenarios with MDM-specific log sources and containment procedures is equally important. For BYOD-specific policy and enrollment hardening guidance, the BYOD Security Policy Guide provides a structured framework for both policy design and technical enrollment controls.