Authorization vs authentication for MSPs: How LastPass fixes what RMMs miss (2026)

MSPs, you know the basics: Authentication verifies identity, and authorization governs access. 

But what happens when attackers bypass the first to weaponize remote monitoring and management (RMM) “god mode” privileges in the second?  

Suddenly, it’s not just about who’s requesting access, but what they’re allowed to do once they get it. 

What you’ll discover next: How authentication vs authorization plays out in RMM attacks, actionable steps on locking down authorization, plus how LastPass SaaS Monitoring closes the gaps your RMM can’t see. 

The goal? To give you a practical, battle-tested strategy for staying ahead of RMM attackers this quarter. 

Authz vs authn: Why it’s a risk NOT securing both

If you run an MSP, your RMM platform is your force multiplier. 

It's how your team patches thousands of endpoints, deploys software updates in minutes, and keeps SLAs without burning out. 

That same leverage is also why attackers love it. 

Many of your MSP peers invest heavily in authentication but skimp on authorization controls.  

This results in global procedures that can target ALL clients and RMM agents running with broad, long-lived privileges. Two real-life examples you’re likely familiar with: 

• Kaseya attack (2021): Attackers exploited an authentication bypass flaw to hijack 50-60 MSP servers running Kaseya RMM and then weaponized RMM “god mode” privileges to push ransomware to 1,500+ downstream clients across 17+ countries. 
• SimpleHelp attack (2025): Utility billing software provider’s vulnerable RMM instance (CVE-2024-57727) was hijacked via authentication bypass and then used to deploy ransomware to all downstream utilities. 

So, when something goes wrong – whether it’s a zero-day in the RMM or a phished admin credential – it's almost always authorization, not authentication, that dictates the blast radius. 

What do RMM attacks reveal about the authz vs authn problem? 

Recent RMM incidents reval a clear, disturbing pattern: 

• Attackers don’t just want access to your RMM. They want the ability to do anything and everything with it. 
• That’s why their focus is the “one-to-many" access privileges that makes your business efficient. 

In other words: Once authentication is bypassed, they can weaponize broad authorization privileges to reach every one of your downstream clients. 

For you, that raises three (3) uncomfortable but necessary questions: 

• If one technician's account is compromised today, how many clients could that impact? 
• How many of your RMM procedures or scripts have “run anywhere” privileges? 
• How may SaaS tools are tied to that same identity ecosystem but sit outside your RMM’s view? 

Answering these questions provides clarity on how much risk you’re really facing. 

Is your MSP overfocused on authentication? 

MSP security improvements often focus on: 

• Enforcing FIDO2 MFA + hardware tokens for RMM logins 
• Moving to SSO for internal apps 
• Tightening password policies 
• Adding adaptive rules like geographic location, device health, & IP address for authentication 

All of these are essential. But they share one assumption: The system that sits behind those logins will behave as expected, and users will always act with good intent. 

There are two problems with that assumption: 

1. Software isn’t perfect. Zero-days can bypass that login layer entirely. 
2. People make mistakes. Credentials can be phished, sessions stolen, and access tokens reused. 

Once that happens, your real challenge is no longer, “Did we authenticate that user?” but “What were they allowed to do?” 

What does effective authorization look like for your MSP?

As an MSP, you know effective authorization is less about one big security control but more about targeted choices that shrink your blast radius. 

Here’s what that looks like: 

Least privilege for technicians

• Replace global admin privileges (“domain admin sprawl”) that give attackers high‑level control across many clients at once. This single point of failure conflicts with customer, insurer, and regulator expectations. 
• Give technicians scoped roles (granular RBAC) and ISO 27001-compliant JIT (just-in-time) workflows. 

Procedure guardrails

• Procedures and tenant-wide scripts can’t default to “all roles.” Assign high-impact actions to senior roles only. 
• Mandate peer reviews before running tenant-wide procedures. 

Server hardening

• Restrict access to your RMM server to a list of white-listed IPs or VPN. 
• Patch religiously: Ensure your RMM server is updated to keep up with the latest vulnerability fixes. 
• Disable unused features or services on your RMM server to shrink the attack surface.   
• Enable EDR/ XDR on the RMM server to catch command-and-control activity masked as legit RMM procedures. 
• Log every RMM server interaction and forward them to SIEM/SOAR so you can isolate compromised endpoints and trigger containment workflows. 
• Use a web application firewall (WAF) to block exploits i.e. host behind your firewall if on-prem, to prevent direct internet exposure. 

Segmentation

• Isolate tenants (give each tenant its own RMM zone) for high-risk verticals like healthcare, finance, and government. ^* 

*Remember: Tenant segmentation doesn’t block server-originated commands or the weaponization of server-level privileges to push fake “trusted procedures” to ALL tenants.  

 

At its heart, tenant segmentation prevents one customer’s admins from seeing another customer’s data (lateral movement between tenants).  

 

This is isolation at the customer level, not protection against the hijacking of the control plane (i.e. RMM server) that allows attackers to inherit the same “god-mode” privileges of the RMM server. 

 

This is why server hardening plus procedure guardrails must come first.* 

 

The gap RMMs don’t cover: SaaS sprawl and Shadow IT 

Even if you clearly separate authentication and authorization inside your RMM, there’s a growing blind spot: SaaS sprawl. 

Your clients are increasingly: 

• Signing in to new SaaS apps with their work email 
• Authorizing AI tools, graphic design tools, and niche productivity apps 
• Reusing passwords across logins 

From an attacker’s perspective, this SaaS layer is just as valuable as your RMM: 

• It holds sensitive info like business data, customer records, and banking credentials 
• It’s frequently less monitored than endpoints 

Your RMM “sees” devices but has limited capabilities for SaaS/Shadow IT discovery. 

This is where a SaaS-aware tool like LastPass SaaS Monitoring complements your RMM. 

How SaaS Monitoring supports better authorization decisions 

Think of SaaS Monitoring as giving you an authorization lens across all the cloud tools your clients use, not just the ones you deploy. 

Here’s how a SaaS-aware approach can help you: 

Discover Shadow IT you didn’t authorize

• Identify which apps your clients are logging in to with corporate credentials 
• Spot high-risk categories e.g. unvetted AI tools 

See where authorization doesn’t match reality

• Which users have admin rights they don’t need 

Enforce security policies consistently

• Apply the same least privilege thinking you use in your RMM across SaaS 
• Flag or revoke access when a user’s role changes or an app violates policy 

Provide a new, valuable service to clients

• With SaaS Monitoring, you’ll have reports that show Shadow IT, over-privileged accounts, and unused licenses. 
• This is data your account managers can use in QBR (Quarterly Business Review) conversations to upsell security bundles. 

In other words, you’re extending the authorization story from “What can this tech do inside my RMM?” to “What can this user do across every critical SaaS resource?” 

Positioning LastPass SaaS Monitoring + SaaS Protect in your MSP stack to bridge authn vs authz gaps 

If you already provide password or credential management, you’re halfway to the story your clients need to hear.  

LastPass doesn’t replace RMM authentication. It fortifies authorization where endpoint controls fall short.  

A free, practical checklist for MSP owners

If you're short on time, start here: 

1. Map where authentication happens: RMM, PSA, password manager, SaaS apps 
2. For each system, list basic authorization boundaries: Who has global admin privileges? Who can push updates or scripts to all clients? Who can grant app-wide permissions to third-party tools? 
3. Reduce “god mode” privileges: Disable shared admin accounts and replace with RBAC-approved senior users + MFA. 
4. Build one simple offer: Add SaaS visibility to your RMM-based services. Offer a “Secure Access” package that includes identity protection, SaaS Monitoring, and SaaS Protect. 
5. Use LastPass SaaS Monitoring to surface unapproved apps and turn that data into a short, visual report for each client. Try SaaS Monitoring for free with a Business Max account (no card required). 
6. Show how better visibility into SaaS authorization can limit lateral movement after an endpoint or RMM compromise. 

The narrative shift is important: You aren’t selling “another security tool,” but clear boundaries for people, devices, and SaaS. 

Remember: You don’t need to solve authentication vs authorization perfectly overnight.  

As an MSP, your leverage comes from centralization and automation.  

Strong authentication keeps attackers out. And effective authorization across your RMM and SaaS stacks keeps one vulnerability from turning into a multi-client crisis. 

Sources

Institution of Engineering and Technology: Analyzing the 2021 Kaseya ransomware attack: combined spear phishing through SonicWall SSLVPN vulnerability

Tenable: CVE-2021-30116: Multiple zero-day vulnerabilities in Kaseya VSA exploited to distribute REvil ransomware

Cybernews: Ransomware gangs exploiting unpatched SimpleHelp remote software, CISA warns

ISMS: From domain admin to least privilege – an ISO 27001 approach for MSPs

Deepwatch RMM security

Huntress: RMMs: A gateway for bulk attacks on MSP customers