Identity-centric UEM after Meraki SM sunset changes endpoint governance

At a glance

What this is: This analysis explains how the Meraki SM sunset shifts endpoint governance from profile-based MDM to identity-centric UEM, with tighter binding between user identity, device control, and network access.

Why it matters: It matters because IAM, endpoint, and network teams now have to decide whether their controls are still split across silos or aligned to a single identity and device governance model.

Context

Identity-centric unified endpoint management is an operating model that binds device control to a directory-backed user identity instead of managing endpoints as separate configuration targets. In this article, that model is presented as the practical answer to Cisco’s Meraki Systems Manager sunset, which creates a forced migration point for teams that still depend on profile-based MDM.

The governance problem is broader than endpoint replacement. When identity, login, configuration, and network authentication are handled in different places, policy drift and offboarding gaps become harder to see. The article frames the shift as a move from disconnected device administration to a cloud directory model that can govern Windows, macOS, Linux, and network access together.

Key questions

Q: What breaks when access management is separated from identity governance?

A: Teams gain the ability to grant access but lose confidence that access remains appropriate over time. That usually shows up as privilege creep, weak offboarding, and poor audit evidence. The result is an IAM programme that can authenticate users but cannot reliably explain or correct entitlement state.

Q: Why does identity-centric UEM matter when a device-management platform reaches end of sale?

A: Because the real risk is not tool replacement, it is control fragmentation during transition. A sunset forces teams to decide whether endpoint management remains a standalone admin function or becomes part of a broader identity and access architecture. The latter is usually more governable when endpoints, users, and network trust must be aligned.

Q: How should teams evaluate agent-based UEM versus profile-based MDM?

A: They should decide based on whether they need local execution authority as well as configuration delivery. Profile-based MDM is narrower and simpler, while agent-based UEM can support deeper lifecycle actions such as scripting, patching, and privilege mapping. The choice should follow the operational requirement, not the vendor label.

Q: How do organisations avoid migration failures when moving to cloud directory-based endpoint governance?

A: By testing profile coexistence, agent trust, and certificate-based network authentication before broad rollout. The practical risk is not only technical incompatibility but also temporary exceptions that become permanent control gaps. Staged cutover, clear unenrollment logic, and certificate validation should be part of the migration plan.

Technical breakdown

How directory object binding changes endpoint governance

In an identity-centric UEM model, the endpoint no longer receives policy as a generic device target. Instead, the device is bound to a directory object, so access, posture, and local controls are linked to the same identity record that governs authentication and authorization. That changes the control plane from endpoint-only administration to directory-driven governance. The article contrasts this with pure-play MDM, where profiles are pushed without an intrinsic identity layer. The practical effect is that identity and device state can be evaluated together, which reduces the split-brain problem common in siloed environments.

Practical implication: map device enrolment, login, and authorization to a single directory lifecycle rather than treating endpoint state as a separate system.

Why agent-based UEM and profile-based MDM are not the same control model

Profile-based MDM mainly delivers configuration payloads through operating system mechanisms, while agent-based UEM adds a persistent local utility that can perform deeper execution tasks such as scripting, patching, and privilege mapping. That means the control surface is not just configuration delivery but local execution authority on the endpoint. For governance teams, the difference matters because the agent becomes part of the trust boundary. The article’s Linux examples show why this matters most where local privilege and lifecycle control are operationally important, not just inventory collection.

Practical implication: inventory which endpoints depend on policy profiles alone and which require a local agent because configuration delivery is no longer enough.

Cloud RADIUS and certificate-based network authentication in the new control plane

The article also links endpoint governance to network authentication by moving Meraki access-point lookups from local databases to cloud-based Cloud RADIUS with EAP-TLS. That shifts the trust decision from a local appliance-centric model to a directory-backed certificate verification path. In practice, network access, device identity, and user authentication become interdependent controls rather than separate layers. This is where the governance model becomes stronger, but also more brittle if certificate templates, client supplicants, or enrollment state are inconsistent across platforms.

Practical implication: validate certificate issuance, supplicant configuration, and network access policy together before migrating the authentication path.

Threat narrative

Attacker objective: The objective is not a named adversary outcome but the operational consequence of fragmented control: inconsistent access governance across endpoint, identity, and network layers.

1. Entry occurs when an organisation keeps a legacy MDM and identity stack in place while the endpoint estate continues to grow across Windows, macOS, and Linux. That creates fragmented control points and increases the chance that one path is not governed consistently.
2. Credential and policy abuse becomes possible when local login, directory identity, and network access are not bound to the same authoritative record. The article’s concern is not a single exploit but the control gap created by split identity enforcement.
3. Escalation happens operationally when unmanaged coexistence between old profiles, new agents, and network authentication creates locks, mismatches, or unenforced privilege paths. The article specifically warns that profile concurrency and certificate mismatches can break governance during transition.
4. Impact is loss of consistent endpoint governance, with offboarding, configuration, and network trust no longer behaving as one lifecycle. That leaves organisations with blind spots rather than a unified policy boundary.

Breaches seen in the wild

• Cisco DevHub breach 2024: A misconfigured script left non-public files on Cisco's DevHub; IntelBroker took them and claimed reuse of hard-coded SSH credentials.

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

Identity-centric UEM is really a directory governance model, not a device-management refresh. The article shows that the key change is where authority lives: in a directory object that governs login, policy, and network trust together. That matters because endpoint controls only become durable when they are tied to the same lifecycle as identity and access. Practitioners should treat the migration as an identity architecture decision, not an MDM procurement event.

Profile-based MDM and agent-based UEM enforce different trust boundaries. Profile-based tooling pushes configuration, but it does not by itself create a persistent local execution layer for deeper lifecycle actions. Agent-based management expands the endpoint trust boundary into local privilege, scripting, and patch orchestration, which means governance must account for that extra authority. The implication is that endpoint control and privilege control can no longer be separated cleanly.

Cloud RADIUS turns network access into an identity lifecycle problem. Once network authentication depends on cloud directory lookups and certificate verification, access continuity depends on enrollment, certificate health, and supplicant consistency. That is an identity governance issue, not just a Wi-Fi problem. Teams should expect authentication failures to surface as lifecycle defects, not merely connectivity issues.

Disconnected identity and device silos create policy drift that looks operational until it becomes security-relevant. The article’s central warning is that separate identity providers, configuration servers, and network authentication paths make it harder to prove who can access what from which device. That weakens offboarding, recertification, and least-privilege enforcement across the endpoint estate. The practitioner takeaway is to collapse control planes where the organisation can actually sustain the operating model.

Unified endpoint governance only works when the migration path is controlled as tightly as the target state. The article’s troubleshooting notes on profile conflicts, agent isolation, and RADIUS mismatches show that transition risk is part of the governance model. Teams that overlook coexistence controls usually end up with temporary exceptions that become permanent gaps. The lesson is to govern the cutover as a lifecycle event, not a tool swap.

What this signals

Directory-bound endpoint governance is becoming the practical baseline for organisations that want one lifecycle across user, device, and network access. The shift matters because it forces teams to stop treating endpoint control as a separate operations function and start aligning it with identity governance. Where that alignment is missing, offboarding, access review, and device posture drift out of sync.

Migration risk is governance risk. The article’s coexistence issues show that profile locks, agent isolation, and certificate mismatches are not just rollout inconveniences. They are signs that the target control model will fail unless the transition is managed as a lifecycle change with explicit control ownership.

For practitioners

• Map endpoint control to directory authority Define the user directory object as the source of truth for login, device policy, and network authorization before decommissioning legacy MDM workflows.
• Inventory coexistence risks before migration Identify profile conflicts, agent isolation risks, and certificate path dependencies across Windows, macOS, Linux, and network access before rollout.
• Validate Cloud RADIUS and EAP-TLS paths Test certificate templates, supplicant settings, and fallback behaviour in a staged environment so network access does not fail during the cutover.
• Separate agent privileges from generic endpoint policy Document which actions require persistent local execution, such as patching or sudoer mapping, and restrict that authority to managed use cases.
• Retire legacy profiles on a controlled timetable Remove old MDM payloads and unenrollment strings before agent initialization so the new governance path is not blocked by concurrent profile locks.

Key takeaways

• The Meraki SM sunset is pushing teams toward identity-centric UEM, where endpoint control and identity governance are managed together.
• The main security value lies in reducing silos between directory identity, device posture, and network authentication, not in changing consoles for their own sake.
• Teams should treat migration, coexistence, and certificate validation as governance tasks, because transition defects can become lasting control gaps.

Key terms

• Identity-Aware Endpoint Management: Identity-aware endpoint management ties device policy to user, admin, and trust-context signals rather than treating endpoints as static assets. The model improves control precision, but only when identity relationships, device state, and entitlement changes are tracked together across the lifecycle.
• Profile-Based Mobile Device Management: A management model that pushes configuration and application settings to endpoints without embedding a broader identity control plane. It is effective for device configuration, but it can leave authentication and lifecycle governance split across other systems.
• Cloud Radius: A cloud-hosted RADIUS implementation that validates network access without depending on an on-premises authentication server. In identity-centric environments, it connects wireless and wired access to directory-backed trust decisions and certificate lifecycles, so certificate issuance and revocation become governance tasks, not just network tasks.
• Agent-Based System: An agent-based system is an AI application that completes work through multi-step execution rather than a single model call. It may plan, reason, retry, and invoke tools in sequence. That structure increases operational flexibility, but it also makes cost, latency, and behavior much harder to predict.

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.