MDM software still leaves identity governance gaps for IAM teams

At a glance

What this is: This article reviews MDM software and concludes that device controls alone do not close the governance gap between endpoints, SaaS access and user lifecycle management.

Why it matters: It matters because IAM teams can mistake device hardening for access governance, leaving SaaS entitlements, offboarding and visibility gaps unresolved across managed endpoints.

Context

MDM is a device-control discipline, not a complete identity governance model. It can enforce configuration, restrict apps and support remote lock or wipe actions, but those controls do not tell IAM teams who still has access to SaaS applications, whether access is still justified, or whether offboarding has happened everywhere it should.

In hybrid work environments, the governance problem is the gap between endpoint management and identity lifecycle control. When device policy becomes the visible control plane, organisations can overlook the harder question of whether access rights, user lifecycle events and application discovery are actually aligned across the estate.

Key questions

Q: How should security teams connect MDM with identity governance?

A: They should connect MDM to joiner, mover and leaver workflows so device enrolment, app entitlement and account status change together. The goal is not just a compliant endpoint but a current access picture. If device posture changes but permissions do not, the organisation still carries stale access risk across SaaS and internal systems.

Q: Why can a compliant device still leave access risk unresolved?

A: Because device compliance only says the endpoint is managed, not that the user’s application access is current, minimal or removed after role changes. Excess entitlements, stale tokens and unmanaged SaaS accounts can persist even when the device itself is locked down.

Q: What breaks when offboarding only unenrols the device?

A: The account can remain active across SaaS tools, collaboration platforms and admin consoles after the endpoint leaves management. That leaves a former user or contractor with usable access even though the device appears to be removed from control.

Q: Should organisations prioritise SaaS discovery before expanding MDM reporting?

A: Yes, if the goal is identity governance rather than endpoint administration. Discovery shows which applications and access paths exist, which is essential before MDM reports can be interpreted as part of a wider control picture.

Technical breakdown

Why MDM visibility does not equal identity governance

MDM platforms manage the state of the device, the installed apps and some policy enforcement on the endpoint. Identity governance, by contrast, governs accounts, entitlements, approvals and revocation across connected services. A device can be compliant while the user behind it still has excessive SaaS access, stale permissions or unmanaged third-party accounts. That is why MDM reports are useful signals, but not a substitute for access lifecycle control or application discovery.

Practical implication: Treat MDM telemetry as an input to identity governance, not as evidence that access is already under control.

How endpoint control can mask overexposed SaaS access

The main architectural trap is assuming that device management and identity management move in lockstep. They do not. MDM can prove a phone or laptop is enrolled, encrypted or locked down, yet the same user may retain access to apps discovered through SSO, direct integrations or unmanaged credentials. This creates a governance blind spot where the endpoint looks secure while the identity layer remains over-permissioned or undiscovered.

Practical implication: Cross-check device enrolment data against SaaS discovery and entitlement records before declaring access risk contained.

Why access revocation must follow user lifecycle, not device policy

Revoking a device from management is not the same as removing access from the person, the account or the app. User lifecycle events such as joiner, mover and leaver changes must trigger access review and revocation across the identity stack. Otherwise, MDM becomes a containment layer that still leaves standing access behind in cloud apps, collaboration tools and admin consoles.

Practical implication: Tie offboarding and move events to application revocation workflows, not just endpoint unenrolment.

Threat narrative

Attacker objective: The objective is to preserve usable access to corporate apps and data even when the endpoint itself is being managed or restricted.

1. Entry begins when a managed or personally owned device is enrolled and given policy control, which creates a false sense of governance if the identity behind it is not also mapped.
2. Credential or access abuse follows when the same user keeps valid application entitlements, tokens or SSO-backed access that are outside the MDM control boundary.
3. Impact occurs when overexposed access persists after device policy changes or offboarding, allowing continued access to corporate resources even though the endpoint appears controlled.

Breaches seen in the wild

• JumpCloud breach 2023: North Korean hackers breached JumpCloud and abused its device commands framework against a few customers; all admin API keys were reset.
• Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MDM is a governance signal, not a governance model. Device management can prove that a laptop or phone is enrolled, encrypted or policy compliant, but it cannot by itself answer whether the person behind the device still has the right apps, roles and tokens. IAM teams that equate endpoint control with access control are measuring the wrong layer. The practical conclusion is that MDM data must be treated as one input into identity governance, not the end state.

The core blind spot is lifecycle misalignment between endpoints and entitlements. Device policy can change instantly while application access persists for days, weeks or longer in SaaS and admin tools. That gap is where offboarding failures, mover drift and orphaned access hide. For IAM programmes, the issue is not whether MDM works on the device, but whether access review and revocation are triggered across the identity stack when device state changes.

Endpoint security can create assurance inflation if discovery is weak. A well-managed fleet can obscure unmanaged SaaS connections, direct app logins and shadow access paths that never touch the MDM console. The governance lesson is that discovery and entitlement visibility must extend beyond enrolled devices into the application layer. Practitioners should assume that an enrolled device may still sit inside a much larger and messier access reality.

Device governance and identity governance now need a common operating picture. The article’s strongest signal is that modern IAM programmes cannot separate endpoint posture from access lifecycle decisions. That does not make MDM an IAM replacement; it makes MDM a dependency that must be correlated with provisioning, deprovisioning and SaaS inventory. Teams that keep these domains separate will keep missing the same exposure pattern.

Identity surface sprawl is the right concept for this problem space. The article points to a broader issue than mobile management alone: every device enrolled, every app connected and every account issued expands the identity surface that must be governed together. The practitioner takeaway is to manage the relationship between devices, accounts and applications as one lifecycle, not three disconnected controls.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity surface sprawl: the problem is not that MDM is ineffective, but that device governance expands the number of places IAM teams must reconcile policy, access and lifecycle state. When devices, apps and accounts are handled as separate workflows, assurance becomes fragmented and offboarding gaps persist.

The practical shift is toward control correlation rather than control substitution. Endpoint management should feed identity decisions, especially where SaaS discovery, revoke workflows and lifecycle events need to close the gap between managed devices and unmanaged access.

For practitioners

• Correlate device enrolment with entitlement records Join MDM inventory to SaaS discovery and access data so a managed endpoint is never mistaken for a governed identity. Look for users whose devices are compliant but whose app access is undocumented, overbroad or no longer justified.
• Trigger revocation from lifecycle events Use joiner, mover and leaver events to drive application revocation, not just device unenrolment. Offboarding should remove account access across SaaS, admin consoles and direct integrations even when the endpoint remains in circulation.
• Separate endpoint compliance from access assurance Report MDM compliance and access governance as different control outcomes. A locked or enrolled device should never be used as evidence that the underlying user, account or application permissions are appropriately constrained.
• Audit unmanaged app connections Review direct app logins, SSO exceptions and third-party integrations that bypass the MDM console. These paths often hold the permissions that device controls cannot see or revoke.

Key takeaways

• MDM can secure endpoints without resolving whether the accounts behind those endpoints still have appropriate access.
• The real governance gap is the mismatch between device policy enforcement and identity lifecycle events such as offboarding and role changes.
• IAM teams should correlate device state, SaaS discovery and entitlement revocation before treating MDM compliance as a security outcome.

Key terms

• Mobile Device Management: Mobile Device Management is the practice of enrolling, configuring, monitoring, and controlling endpoints through central policy. It gives security and IT teams a way to enforce device posture, app restrictions, and remote response actions across phones, tablets, laptops, and other managed devices.
• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• SaaS Discovery: SaaS discovery is the process of identifying all sanctioned and unsanctioned software-as-a-service applications in use across the organisation. It matters because cloud assurance increasingly depends on seeing where apps share data, what permissions they hold, and which identities can reach them.
• Credential Revocation: Credential revocation is the process of disabling a secret, token, or key so it can no longer authenticate or authorize action. It is the operational half of detection, because exposed credentials remain dangerous until they are invalidated and replaced across every dependent system.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.