Security and trust
RMM security, stated plainly.
A remote management platform can run code on every machine you manage. You deserve a concrete account of how it is built, and an equally plain account of what we have not earned the right to claim yet.
Last reviewed September 2026.
Controls in the platform
How Revolutionary RMM is built.
Each control below is in the product today. Ask us to show any of them on the demo call.
01 / ISOLATION
A database per MSP workspace
Each MSP workspace has its own PostgreSQL database and its own database role. One workspace's data does not sit in another's tables.
02 / ACCESS
Roles and customer scope
Inside a workspace, what a technician can see and do follows their role and the customers assigned to them. Client portal access is set per customer organization.
03 / SIGN-IN
Two-factor sign-in for staff
Staff who sign in with a password must complete a second factor. Single sign-on relies on your identity provider's checks. Sign-in protection adds lockouts, address blocking, scan detection and an allow list.
04 / CREDENTIALS
Encrypted secrets, audited reveals
Stored credentials and connection secrets are encrypted with AES-256-GCM, with the key held outside the database. Revealing a credential creates an audit event naming who revealed it and which record.
05 / AGENT
Signed commands and updates
Commands sent to the agent carry a digital signature that the agent checks before it acts. Agent updates are signed and version-checked, and they wait while a remote session is active.
06 / REMOTE
Authenticated remote sessions
The remote control relay requires an authenticated, signed ticket. A session without a valid signature is refused.
Records
Know who acted. See what changed.
AUDIT RECORDS
What is recorded
Administrative actions, credential reveals and AI-assisted workflows create audit records you can review. Rotated local administrator passwords are revealed through the same audited path.
DATA HANDLING
Where things live and what leaves
The platform runs on infrastructure we operate. Documentation exports leave secrets out; a personal vault export includes its passwords, because that is its purpose. AI features send the context you submit to the model provider configured with your workspace's own key.
What we do not claim yet. We do not hold a SOC 2 report. We have not completed an independent penetration test. We do not carry cyber or professional liability insurance. We do not offer contractual service level agreements, and there is no contractual response time. Support itself is 24/7: you can reach us at any hour and the founding team answers, so you get someone who built the product. That is not a staffed operations center on a shift rota with follow-the-sun handover, and we will not describe it as one. Revolutionary IT, the separate MSP that is our first design partner, has run 24/7 coverage for longer, and that is a different company rather than a commitment from us. Agent updates are signed separately, as described above.
If your procurement process needs an attestation report today, we are not the right fit yet, and we will tell you so on the first call. If you evaluate on the engineering, this page is the starting point.
In progress
What we are writing down next.
Not in the product today: a written data governance statement (where your data is stored, who processes it, how long it is kept, how it is deleted, and how you get it back if you leave), documented recovery objectives proven by regular timed restore tests, and a completed launch readiness review rechecked by someone who did not do the work.
Report a security issue
Found a vulnerability? Tell us directly.
Send the details through our contact form and mark the message as a security report. Include the affected page or component, the steps to reproduce it, and what you observed. Please do not access other customers' data or disrupt the service while testing, and give us a reasonable time to fix the issue before you share it publicly. A person reads every report.
Questions
Good to know.
On infrastructure we operate, with a separate PostgreSQL database and role for each MSP workspace. Inside a workspace, customer records follow roles and assigned customers. A written data governance statement is in development.
Each reveal creates an audit event that names the person and the record. Secrets are encrypted with AES-256-GCM, and the key is kept outside the database.
Commands carry a digital signature that the agent checks before acting, and agent updates are signed and version-checked. Who can send a command is controlled separately, by roles and customer scope.
Yes, for staff who sign in with a password. If you use single sign-on, the second factor is enforced by your identity provider.
Yes. AI features send the context they work on to the model provider configured with your workspace's own key, and AI-assisted workflows are recorded in the audit trail.
Yes. We would rather answer it early and plainly than discover a mismatch after you have moved devices. The list above of what we do not claim is a good place to start.
Limits, checked daily
Not in the product today.
Each line below is a gap recorded against this capability in the product's own feature record. A line leaves this page by itself on the next daily run once that record says the gap is closed, so the list cannot fall behind what we ship. The rest of this page is written by hand.
- A second factor can be an authenticator app or a passkey; signing in through your own identity provider or directory is not available yet.
- A workspace's data is removed on request, and there is no self-serve export of everything it holds yet.
Bring your security questions to the demo call.
We will show the controls on this page in the product and answer your questionnaire in plain terms.
