Learn / Security
The RMM security checklist.
An RMM platform can run code on every machine you manage, which makes it one of the most consequential security decisions an IT team makes. These are the questions worth asking every vendor you evaluate, including us, with why each one matters and what a good answer sounds like.
Checklist 01
How are agent commands and updates protected?
The channel from the platform to the agent is the crown jewel: whoever can send commands owns the fleet.
Ask
Are commands to the agent signed?
A good answer: every command carries a digital signature the agent verifies before acting, so possession of the network path is not enough to drive a device.
Ask
Are agent updates signed and version-checked?
The update channel is how an attacker turns one compromise into every device. Updates should be signed, version-checked, and refused when the check fails.
Ask
What does the agent refuse?
Ask what happens to an unsigned or malformed command. The honest answer names a refusal path and where the refusal is logged, not just a happy path.
Checklist 02
How is my data separated from other tenants?
On a multi-tenant platform, your real boundary is the vendor's isolation architecture, not your own diligence.
Ask
Separate databases or filtered tables?
A database per tenant is a structural boundary. Shared tables filtered by a tenant column depend on every single query being written correctly, forever.
Ask
How is technician access scoped?
Inside your tenant, can you limit a technician by role and by customer? Can client portal users see only their own organization?
Ask
Who at the vendor can see my data?
Ask which vendor staff can reach tenant data, under what controls, and whether that access is itself logged and reviewable.
Checklist 03
How are stored credentials protected?
An RMM stores the passwords that open your customers' infrastructure. Treat its credential handling as you would a password manager's.
Ask
How are secrets encrypted, and where is the key?
A specific cipher named without hesitation, and an encryption key held outside the database, so a database copy alone does not expose the vault.
Ask
Is every credential reveal audited?
Viewing a stored password should create a permanent record naming who revealed it and which record, visible to you, not only to the vendor.
Ask
What leaves in exports and integrations?
Ask which exports include secrets and which strip them, and what data any AI or third-party feature sends outside the platform.
Checklist 04
Who acted, and what does the log show?
When something goes wrong, the difference between an incident and a catastrophe is whether you can reconstruct who did what.
Ask
Is a second factor enforced for staff?
Not merely available: enforced for password sign-ins, with lockouts and scan detection behind it, and single sign-on that leans on your identity provider.
Ask
Are remote sessions authenticated end to end?
A remote control relay should refuse a session without a valid, signed ticket. Ask what a stolen session token alone would get an attacker.
Ask
Can I review the audit trail myself?
Administrative actions, commands, reveals and sessions, tied to named people, and readable by you without filing a support ticket.
Checklist 05
What will they put in writing?
Every vendor sounds secure in a demo. The differentiator is what they will state in writing, including the gaps. Ask which third-party attestations and independent security tests they have completed, and how you would report a vulnerability to them. Then ask the question that sorts vendors fastest: what do you not claim yet? A vendor who answers that one specifically, in writing, is telling you how they will behave after an incident. A vendor who cannot is telling you the same thing.
Good to know
Common questions about RMM security.
Because an RMM agent runs with high privileges on every machine you manage, the platform is a single point of compromise for entire fleets. RMM products have been used to push ransomware to every downstream customer at once, so the vendor's engineering deserves the same scrutiny as your own.
A digital signature on each command that the agent verifies before acting. It means a command is honored because it is cryptographically proven to come from the platform, not merely because it arrived over the network. Without it, anyone who reaches the transport or the queue can drive your fleet.
Ask how the separation is built, not whether it exists. A separate database per tenant is a stronger boundary than shared tables filtered by a tenant column, because one missing filter in shared tables exposes another tenant's data.
No. Certifications attest to process, and young products often have strong engineering before they have reports. The disqualifying signal is a vendor who is vague, or who claims more than they can show. Concrete answers plus written honesty about gaps beats a logo wall.
At minimum: who signed in and from where, every administrative action, every credential reveal, every command sent to an agent and every remote session, each tied to a named person. If technicians share accounts or actions are unattributed, the trail is decoration.
Our answers
How Revolutionary RMM answers this checklist.
Our security page answers every question above in the product's own terms: signed commands and signed, version-checked agent updates, a separate PostgreSQL database and database role per workspace, AES-256-GCM encryption with the key held outside the database, audited credential reveals, enforced two-factor sign-in for staff passwords, and an authenticated, signed ticket for every remote session.
It also states plainly what we do not claim yet, because that is the standard this checklist asks of every vendor. Bring the whole list to the demo call and ask us each question directly.
Put us on the same list.
Bring this checklist and your security questionnaire. We will answer each item in the product, in plain terms.
