What is the difference between managing identities and managing devices in an MSP environment?

Managing identities controls who can authenticate, what they can access, and how access is revoked over time. Managing devices controls the condition and policy state of the endpoints themselves. In modern MSP operations, the two are linked, but identity is the more durable control because it follows the user across devices, locations, and client environments.

Why Identity Management and Device Management Solve Different Problems

Identity management answers the question, “who is this and what should they be allowed to do?” Device management answers, “what is this endpoint, what state is it in, and what policy should it obey?” In an MSP, those are related but not interchangeable. Identity is the durable access layer, while device state is the condition layer that helps decide whether that access should be trusted.

That distinction matters because a user or technician can move between laptops, desktops, virtual sessions, and client environments while their identity remains the same. A device can be replaced, reimaged, patched, quarantined, or retired without changing the person or service behind it. Good MSP design treats the identity as the control point for access decisions and the device as one of the signals that may strengthen or weaken trust.

In practice, this means identity management covers authentication, authorization, entitlement changes, access reviews, and revocation. Device management covers endpoint posture, compliance baselines, encryption state, patch level, enrolled management agents, and whether the endpoint should be considered trusted enough to reach a client tenant or management plane.

How the Difference Shows Up in Day-to-Day MSP Operations

The operational split becomes obvious during onboarding, access changes, and offboarding. When a technician joins, identity management provisions accounts, roles, and access paths. When that technician receives a laptop, device management enrolls, configures, and hardens the endpoint. When the technician leaves, identity management should remove access immediately, while device management should also decommission, wipe, or reassign the hardware if required.

Device controls can reduce exposure, but they do not replace access governance. A fully patched, encrypted device can still be dangerous if the identity attached to it has excessive client privileges. Conversely, a strongly governed identity can still be risky if it signs in from an unmanaged or compromised endpoint. MSPs usually need both: identity for durable authority and device management for trust in the session source.

For that reason, many MSPs pair identity controls with device posture checks and conditional access. That pattern keeps the access decision anchored on who the actor is, while also asking whether the endpoint is in a known-good state before sensitive actions are allowed.

Why the Boundary Matters for Risk, Auditability, and Client Trust

Confusing identities with devices leads to blind spots in privilege review, offboarding, and incident response. If access is granted because a device is known, stolen credentials may still work from another endpoint. If access is tied only to identity and not conditioned on device state, unmanaged or unhealthy endpoints can become a path into client systems. MSPs need both views to understand whether the risk is an account issue, an endpoint issue, or both.

Identity also produces a cleaner audit trail. It is easier to answer who approved access, who used it, and when it was revoked than to rely on device records alone. Device management provides evidence of posture and compliance, but it does not explain why a person was entitled to a client environment in the first place. That is why client reviews often care more about identity governance than about endpoint inventory alone.

Device management becomes especially important where MSP tooling reaches many tenants from one control plane. Strong endpoint hygiene reduces the chance that a managed workstation becomes a springboard into multiple customer environments, but the identity layer still has to limit what that workstation can do once it authenticates.

Risk and Threat Considerations

The main risk is assuming that a managed device is the same thing as a trusted user, or that a trusted user can be safely managed without regard to endpoint posture. Attackers often exploit that confusion by stealing credentials, taking over a technician session, or using a legitimate device to reach more systems than intended.

Failure mechanism: Excessive privileges, weak offboarding, or unmanaged endpoints can let a valid login become broad client access, especially when MSP tools are shared across environments.

Impact: A single identity or endpoint compromise can expand into cross-client exposure, unauthorized administrative actions, and slower containment because the source of trust was modeled incorrectly.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-9 — Identification and Authentication (Service and External System Users)	MSP technicians and tools often authenticate as services or external users across environments.
	AC-6 — Least Privilege	The identity/device split is fundamentally about limiting what access a valid actor can exercise.
	IA-5 — Authenticator Management	Identity management in MSPs depends on credential lifecycle, revocation, and secure handling.
Recommendation — Use IA-9 to govern non-human and external-system authentication paths in managed access flows. Apply AC-6 to keep technician and support access narrowly scoped to required actions. Apply IA-5 to control credential issuance, rotation, protection, and revocation.
ISO/IEC 27001:2022	A.5.16 — Identity management	The question distinguishes who the actor is from the device they use, which is an identity-management concern.
	A.8.1 — User endpoint devices	Device management is about the control and policy state of the endpoint itself.
Recommendation — Define and maintain identity ownership, lifecycle, and access assignment rules. Set endpoint hardening, enrollment, and protection requirements for managed devices.
NIST Zero Trust (SP 800-207)	Zero Trust Architecture	The answer contrasts durable identity with device trust signals used in access decisions.
Recommendation — Use continuous verification so device posture can inform access without replacing identity governance.

Practitioner Guidance

What to prioritise: Treat identity as the source of authority and device posture as a trust signal, not the other way around. If you must choose where to tighten first, focus on access governance, privileged role review, and fast revocation because those controls follow the person across every endpoint they use.

What to verify: Confirm that offboarding removes access even if the device is still present, and that device retirement does not leave active credentials behind. Also verify that client-facing admin actions require both an entitled identity and an acceptable device state, rather than only one of the two.

Practitioner takeaway: In an MSP, identity controls who can act, while device management helps determine whether the session should be trusted, so the strongest design is to separate the authority decision from the endpoint hygiene decision.