14-day RMM trial · No card

Start free

Security architecture

Powerful administration. Deliberate guardrails.

An RMM agent is privileged software. Nizlo is designed around explicit identity, least-privilege technician access, signed and expiring work, encrypted transport, and visible auditability.

Defense in depth

Trust is enforced at more than one layer.

The browser experience, API authorization, durable job protocol, endpoint verification, and deployment architecture each have a defined security responsibility.

Tenant isolation

Tenant ownership is enforced in backend queries and database relationships—not left to browser filtering.

Technician access

Roles and action-specific permissions separate viewing endpoints from remote access, scripts, files, patching, and administration.

MFA and passkeys

TOTP MFA is supported, with WebAuthn/passkey registration and session controls built around the permanent application origin.

Signed device jobs

Privileged work carries a device ID, authorization context, nonce, timestamps, expiration, and server signature.

Immutable operational history

Sensitive actions create tenant-scoped audit records containing actor, target, source, result, and bounded metadata.

Unique device identity

Enrollment exchanges a revocable placement token for installation-specific credentials rather than embedding one universal agent secret.

Concrete data flow

From technician intent to endpoint evidence.

Nizlo does not send raw browser commands directly to an endpoint. The request crosses distinct authorization, persistence, transport, endpoint-verification, and evidence boundaries.

  1. 01

    Technician request

    The browser sends a same-origin request. The API checks the active session, tenant, MFA posture, role, and action-specific permission; the browser is never treated as the security boundary.

  2. 02

    Tenant-bound durable work

    The API validates the target and allow-listed payload, writes durable server state, and creates request and audit context inside the authenticated tenant boundary.

  3. 03

    Outbound agent discovery

    The endpoint maintains authenticated outbound HTTPS and WebSocket connections. A WebSocket message can only wake polling; the full signed job is fetched over the device-authenticated HTTPS channel.

  4. 04

    Endpoint verification

    Before execution, the agent checks its device identity, target, job signature, nonce, issue and expiry times, replay state, and the operation-specific schema and safety rules.

  5. 05

    Bounded result and evidence

    Status and bounded results return over authenticated HTTPS. The service binds them back to the tenant, device, and durable job before exposing lifecycle and audit evidence to an authorized technician.

Privileged action path

Every sensitive action has a verifiable route.

01

Authorize the technician

Validate the session, tenant, MFA state, role, and action-specific permission.

02

Bind and sign the work

Attach the target device, request context, nonce, issue time, expiration, and an allow-listed payload.

03

Verify and record

The agent verifies identity and signature before execution; the platform retains state transitions, result, and audit evidence.

Audit coverage

Ask what is recorded before you install the agent.

Operational history is tenant-scoped and designed to preserve who acted, what object was targeted, when it happened, the request context, and the bounded outcome. Secrets, terminal command text, terminal output, and file contents do not belong in general audit metadata.

  • Sign-in, MFA, passkey, session, and account-security changes
  • Enrollment tokens, endpoint enrollment, archival, restoration, and removal
  • Script, job, service, process, patch, restart, and automation lifecycle
  • Interactive terminal and remote-support session lifecycle
  • Technician, role, permission, policy, retention, and integration changes
  • File-transfer, report-generation, webhook, and notification administration

Development transparency

AI assistance is disclosed. Release evidence still has to stand on its own.

AI-assisted tools are used regularly in Nizlo development, including implementation, tests, documentation, and review. We do not track a defensible percentage of AI-assisted code, so we will not invent one.

Regular AI assistance

AI-assisted tools can contribute suggestions across code, tests, documentation, and review. Human responsibility for what ships does not transfer to the tool.

No made-up percentage

Lines of code are not a reliable measure of authorship or assurance. Without a defensible measurement method, Nizlo will not publish a guessed percentage.

Evidence over provenance

A generated suggestion is not proof that a change is correct. The same lint, strict type checks, automated tests, production builds, database checks, and Windows-agent checks apply before release.

Nizlo remains early-access software. Buyers should evaluate it on authorized noncritical endpoints, inspect the documented security boundaries, and require evidence for the workflows they intend to trust.

Security teams can use the Nizlo RMM security indicators guide to verify expected Windows executables, installation paths, service name, URL protocols, registry keys, and outbound traffic to app.nizlo.com during an authorized investigation.

Responsible disclosure

Report a suspected vulnerability directly.

Email kip@nizlo.com with the affected URL or component, reproducible steps, observed impact, and a safe way to follow up. Do not include customer secrets or personal data in the initial report.

The machine-readable contact is published at /.well-known/security.txt.

Testing boundaries

Use only accounts, tenants, and endpoints you are authorized to test. Do not access or alter another customer's data, disrupt service, use social engineering, or test third-party systems. Stop if you encounter data that is not yours.

Current program scope

Nizlo will review good-faith reports and coordinate follow-up when contact information is provided. Nizlo does not currently offer a paid bug bounty or a broad safe-harbor program, and this page does not authorize testing outside these boundaries.

Security should make operations clearer—not mysterious.

TLS-only production trafficNo shared agent passwordAudited privileged actions