Guide

Securing your RMM: MFA, roles and audit logs

By OKSANA DRONOVA · Updated September 29, 2026

Your RMM is the most powerful account your business owns. One login can run a script as SYSTEM on every computer at every client you serve, which is exactly why you bought it, and exactly why attackers go after it. A compromised mailbox hurts one client; a compromised RMM console can hurt all of them in a single evening. This guide is the hardening checklist worth working through for any MSP console, whatever the vendor, ordered roughly by how much risk each step removes.

What real incidents taught the industry

It is worth knowing the history, because every control below maps to something that actually happened.

• 2019, consoles without MFA. Several MSPs had RMM and security-management consoles accessed with stolen or reused passwords. Attackers used the legitimate deployment features to push ransomware to client machines. The fix was not exotic: enforce MFA and stop reusing passwords.
• 2020, SolarWinds Orion. Not an RMM, but an IT management platform whose build process was compromised, so signed updates carried a backdoor to thousands of customers. It showed that trusting the vendor’s update channel is itself a risk to manage.
• July 2021, Kaseya VSA. A ransomware group abused vulnerabilities in on-premises VSA servers to push malicious updates through the RMM to managed endpoints. Around 50–60 MSPs were directly affected and a much larger number of downstream businesses. Lessons: keep self-hosted consoles off the open internet where possible, patch the RMM itself urgently, and have an offline plan.
• February 2024, ConnectWise ScreenConnect. A critical authentication flaw in self-hosted instances was quickly and widely abused after disclosure. Cloud-hosted instances were patched by the vendor; self-hosted ones depended on their owners acting within hours.
• Ongoing, legitimate remote tools misused. Government advisories (including a joint CISA advisory in early 2023) describe phishing campaigns that trick users into running legitimate remote-management software. This is one reason never to send agent links by email.

None of these required anything clever at the MSP. They required a console that was reachable, a login that was weak, or a patch that was late.

1. Enforce MFA, and prefer phishing-resistant methods

Every account, every technician, no exceptions, including the owner and the break-glass account.

1. Turn on the tenant-wide setting that makes MFA mandatory, rather than relying on each user to enable it.
2. Prefer phishing-resistant factors: FIDO2 security keys or passkeys. They are bound to the real site, so a lookalike login page cannot relay them.
3. If keys are not supported, use an authenticator app with number matching. Avoid SMS codes.
4. If the RMM supports single sign-on, connect it to your identity provider and enforce conditional access there.
5. Issue each technician two keys and register both; store the spare securely.

2. Least-privilege roles

Not everyone needs to run scripts across every client.

Scope roles by client organization where the platform allows it, so a contractor on one account sees only that account.

3. Separate admin identities

Your technicians should not read email and browse the web with the same identity that holds super-admin rights in the RMM. Give privileged users a separate admin account for the console, used from a hardened workstation, with no mailbox attached. It is inconvenient for about a week and then it is habit.

4. IP allow-lists where supported

Some platforms let you restrict console logins to specific IP ranges. Where available, limit access to the office and VPN egress addresses you actually use. Where not available, get a similar effect through your identity provider’s conditional access rules. For any self-hosted RMM or remote-support server, keep the management interface off the public internet and put it behind a VPN or zero-trust access gateway.

5. Review the audit log on a schedule

Audit logs only help if someone reads them. A weekly 20-minute review should cover:

• New users, role changes and new API keys
• Changes to MFA, SSO or security settings
• Scripts created or edited, and who ran them against how many devices
• Logins from unusual countries, networks or times
• Mass actions: bulk script runs, policy changes, agent uninstalls
• New integrations or webhooks

Forward logs to a SIEM or at least to storage the RMM admins cannot delete, if the platform supports export.

6. Script signing and approval

Scripts are where RMM power concentrates. Treat the script library like production code.

1. Only senior roles can create or edit scripts; helpdesk roles can run approved ones.
2. Require a second person to review a new script before it is available for mass deployment.
3. Keep scripts in version control and sync them to the RMM, so every change has a history.
4. On Windows, sign PowerShell scripts with a code-signing certificate and set execution policy on endpoints to require signatures where your RMM supports it.

$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert | Select-Object -First 1
Set-AuthenticodeSignature -FilePath .\Clear-TempFiles.ps1 -Certificate $cert `
  -TimestampServer 'http://timestamp.digicert.com'
Get-AuthenticodeSignature .\Clear-TempFiles.ps1 | Select-Object Status, SignerCertificate

5. Alert on any script run against more than a set number of devices at once.

7. Offboarding technicians the same day

Common mistakes

• MFA on everyone except the owner, who “needs quick access”.
• API keys with full rights, created for a one-off integration and never revoked.
• Self-hosted consoles patched on the monthly cycle instead of immediately.
• A shared “tech” login that makes the audit log meaningless.

Where this fits

Security controls vary between platforms, so compare what each supports before you choose: our RMM software category and the NinjaOne, Atera and Syncro reviews cover MFA options, roles and logging. The NinjaOne vs Atera comparison looks at them head to head. When you add new tooling, start from where to get these tools safely, and see how we score security in our methodology.