Security at OpenRMM
An RMM has administrator access to every machine it manages. That is why each protection on this page is in the public code and can be audited, and why the limitations are written down here too.
The AI proposes. A person decides.
The model reads data that comes from monitored machines, and that data may try to trick it. So no lock depends on what the model decides.
- The AI and MCP run a script only when an administrator released it in advance, bound to its exact content, and have no tool to delete anything. Reboots, installs, deletions, accounts and security settings can never be released.
- Proposed tasks, checks and policies are created disabled. The scheduler only reads active records, and a database constraint prevents enabling a proposal without review.
- The only tool that installs anything is limited to patches a person has approved. There is no tool to approve patches.
- Moving or deleting machines requires approval, with permissions checked again at that moment. To delete, you must type the count.
- Script approval is required by default, for people and for the AI.
What protects what
Access
Ready-made and custom roles checked on every route. Scope by company, site, department or machine for reads, writes and the AI.
Sign-in
SSO through OpenID Connect with MFA required from the provider. TOTP 2FA with single-use codes. The console never accepts a pasted token.
Secrets
Passwords with bcrypt. Agent, session, API and OAuth tokens stored only as SHA-256 hashes. Configuration and 2FA secrets encrypted with AES-256-GCM. Constant-time comparisons.
Audit
An append-only log. Database triggers refuse changes and deletions, the server runs as a user that does not own the table, and a hash chain reveals rewrites.
Limits
10 sign-in attempts per minute, 60 MCP calls and 600 API calls per minute per IP. Request bodies up to 1 MiB.
Releases
Agent binaries signed with Ed25519 and verified before updating, with checksums, an SBOM and CI provenance.
An instance of your own
On Cloud, no customer shares a database or secrets with another.
- Its own namespace, database, secrets, backups and domain.
- A subdomain with TLS and a daily backup.
- The AI model is yours. OpenRMM does not sit between you and the provider.
What we do not do yet
We would rather you know before you buy.
| Limitation | What it means |
|---|---|
| No sandbox for scripts and the terminal | They run with root or SYSTEM privilege, as in most RMMs. That is why approval is required by default; only an administrator can let people who also manage the settings skip it, one device at a time, and that change is audited. |
| Remote video without end-to-end encryption | The native desktop media is trusted at the server's relay. End-to-end encryption is on the roadmap. |
| One server, no high availability | The supported setup is a single server replica. |
| Basic observability | There is a health check and simple metrics, but no tracing or alerts about the platform itself. |
| No Authenticode or Apple Developer ID | The Ed25519 signature does not replace Windows and Apple code signing. |
Report it privately to contact@openrmm.io, without opening a public issue on GitHub. Self-hosted customers with support receive security advisories before disclosure.
contact@openrmm.io
Read the code before you trust it.
Everything is on GitHub under AGPL-3.0, including the locks described on this page.