What do MSPs get wrong about combining SSO, MFA, and conditional access?

A common mistake is treating SSO, MFA, and conditional access as standalone features instead of layered controls. SSO improves usability, MFA strengthens authentication, and conditional access applies policy based on context. MSPs still need lifecycle governance, device trust signals, and periodic policy review, or they risk creating convenient access paths with weak enforcement.

Why This Matters for Security Teams

MSPs often combine SSO, MFA, and conditional access as if the stack itself creates trust. It does not. SSO mainly reduces password sprawl, MFA raises the bar for interactive login, and conditional access only works when device, location, risk, and user context are accurate and current. For managed environments, the gap is lifecycle control: account creation, privilege drift, token reuse, and offboarding often sit outside the sign-in flow.

This matters because identity attacks rarely stop at the login screen. Once an attacker or compromised service gains a valid session, they can move through SaaS, admin consoles, and automation paths that were never covered by the original policy design. NHI Management Group’s Ultimate Guide to NHIs notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why identity control failures are often broader than MFA failures alone.

In practice, many security teams discover that “strong login” did not prevent lateral access, because policy was only enforced at sign-in and not at the point where access actually mattered.

How It Works in Practice

The effective model is layered, but each layer has a distinct job. SSO centralises authentication and reduces the number of login surfaces. MFA proves the user or administrator is more likely to be legitimate at sign-in. Conditional access evaluates context, such as device compliance, geo-location, session risk, or network posture, to decide whether access should be allowed, challenged, or blocked.

Where MSPs get into trouble is assuming those controls automatically govern the whole identity lifecycle. If a privileged session is already issued, conditional access may not re-evaluate the decision when the user pivots into another tenant, launches a separate admin tool, or reuses an existing token. That is why current guidance from OWASP Non-Human Identity Top 10 and NIST control guidance such as NIST SP 800-53 Rev 5 Security and Privacy Controls points toward continuous governance, not one-time authentication.

• Use SSO for user experience and centralised authentication, but do not treat it as a substitute for authorization.
• Apply MFA to interactive sign-in, then separate privileged admin access from standard user access with tighter policy.
• Feed conditional access with trustworthy signals, such as managed device state, session risk, and tenant boundaries.
• Review token lifetime, refresh rules, and exception paths for service accounts, break-glass accounts, and delegated admin roles.
• Document who can change policies, how exceptions are approved, and how dormant access is revoked.

The practical test is whether access is re-checked when context changes, not whether a user passed a login challenge once. These controls tend to break down when MSPs manage many tenants with shared admin tooling because token reuse and policy exceptions quickly outpace manual review.

Common Variations and Edge Cases

Tighter conditional access often increases operational overhead, requiring organisations to balance stronger enforcement against support friction and tenant diversity. That tradeoff becomes especially visible in MSP environments, where a single engineer may need access to multiple customer stacks, each with different device standards, logging requirements, and acceptable risk thresholds.

Best practice is evolving on how aggressively to challenge admins in shared service models. Some teams push for device-bound access and short sessions; others allow narrower exceptions for emergency support. The key is that exceptions must be explicit, time-bound, and reviewed, not hidden behind a “trusted admin” shortcut. NHI Management Group’s Ultimate Guide to NHIs — Key Challenges and Risks is clear that visibility and offboarding remain weak points across many organisations.

Two edge cases deserve special attention:

• Service accounts and automation. SSO, MFA, and conditional access are usually human-facing controls, so they do little for API keys, scripts, and unattended jobs unless separate NHI governance exists.
• Break-glass access. Emergency accounts should bypass normal friction only under tightly controlled conditions, otherwise they become permanent back doors.

Where MSPs support legacy applications, these controls also degrade because older tools may not support modern device signals, token binding, or step-up challenges, leaving policy enforcement inconsistent across the estate.

Related resources from NHI Mgmt Group

• What do IAM teams get wrong about stronger MFA and conditional access?
• What do security teams get wrong about access control when they focus only on login authentication?
• What do security teams get wrong about SSH logging for privileged access?
• What do security teams get wrong about role-based and attribute-based access control in large environments?