ZynoRMM Security Model

This technical reference describes the security model behind ZynoRMM. For technician setup and access workflows, see Technicians and Access.

ZynoRMM uses a zero-trust security model: no entity, including the hosting infrastructure, can execute sensitive endpoint operations without cryptographic proof from an authenticated technician.

This is a cryptographic enforcement boundary, not a policy check that could be bypassed. Even if an attacker gained full control of the ZynoRMM bridge server, they could not run commands on managed endpoints, read file contents, access screen sessions, or push unauthorized updates.

Threat model

What a compromised server cannot do

• Execute sensitive operations on managed endpoints
• Read the contents of file transfers, terminal sessions, commands, or screen sessions
• Forge or replay technician commands
• Impersonate a technician or escalate permissions
• Push software updates to agents
• Uninstall or decommission agents
• Read encrypted audit-log fields, including sensitive filesystem paths, commands, and output

What a compromised server can do

• Deny service — refuse to forward legitimate requests, without being able to cause endpoint actions
• Read bridge-collected telemetry — system and utilization information, hardware and installed-program inventory, service and display lists, network diagnostic observations, and disk device or mount paths reported as inventory
• See audit metadata — know that an operation occurred, its type, status, and timing, but not encrypted sensitive fields
• See which agents exist — agent identifiers are visible, but cannot be used to impersonate or command an agent

Trust model

Tenant root certificate authority

When an organization first sets up ZynoRMM, a cryptographic key ceremony takes place entirely in an administrator's browser. This creates a tenant-specific root certificate authority (CA). The root CA's private key is encrypted with a high-entropy recovery key; the administrator downloads the encrypted file and prints the recovery key separately, then stores those two pieces in separate physical locations.

The root CA private key never exists on a server. It is generated in the browser, used to sign intermediate authorities, encrypted, and erased from memory.

Intermediate authorities

The root CA signs constrained intermediate CAs, each with one purpose:

• User CA — issues technician certificates only
• Script CA — approves scripts and upgrades only
• Revocation CA — issues revocation entries only

These are cryptographic boundaries, not policy checks. A user who holds the User CA key cannot sign scripts; that requires a separate key.

Intermediate CA private keys are stored encrypted on the server, but the server cannot decrypt them. Each authorized user's private keys are wrapped with a symmetric key derived from their hardware-backed WebAuthn credential, such as a passkey or security key. A user must authenticate with that hardware token to unwrap the keys used for signing, and signing happens in the browser rather than on the server.

Technician identity

Each technician has a personal certificate signed by the User CA. When a technician authenticates, they create an ephemeral session certificate, valid for eight hours, that exists only in browser memory. This session certificate signs individual operations.

The certificate chain for an operation is:

Tenant Root CA (offline, never on a server)
 -> User CA (intermediate, unwrapped with WebAuthn)
 -> Technician Certificate (per person, with permissions)
 -> Session Certificate (8-hour TTL, in-memory only)
 -> Per-Operation Signature

The agent verifies every link in this chain before executing a sensitive operation.

Agent identity

Each agent generates its own identity key using platform security:

• macOS — Apple Keychain, with Secure Enclave support where available
• Windows — protected local storage, with TPM backing where available
• Linux — encrypted file with a platform-derived key and restricted file permissions

Agent identity keys are used for transport authentication — proving the agent is the one it claims to be — but they do not grant the ability to execute operations. Operations require technician signatures.

Hardware-backed authentication

Technician authentication is built on WebAuthn with hardware-bound credentials. Supported authenticators include:

• Apple — Touch ID or Face ID through the Secure Enclave
• Android — biometrics through StrongBox or a trusted execution environment
• Windows — Windows Hello through the TPM
• Security keys — YubiKey and other FIDO2 devices over USB or NFC

Policy can block software-only credential providers, such as password managers, when hardware binding is required. This requires physical possession of a technician's device, not only a password.

Multi-device support

Technicians can register multiple devices, such as a laptop and phone. Each device's WebAuthn credential derives a different encryption key, so the intermediate CA keys are independently wrapped for each device. Losing one device does not lock out a technician who has another registered device; the lost device's access can be revoked without affecting the remaining devices.

Operation security

What requires authorization

Operations fall into two categories: non-sensitive, which do not require a technician signature, and sensitive, which require the full cryptographic signature chain from an authenticated technician.

Non-sensitive operations are read-only telemetry and discovery queries with no sensitive side effects. The bridge can perform these directly for monitoring:

• System information, including hostname, OS, CPU, memory, and boot time
• System utilization, including CPU, memory, and disk usage
• Hardware inventory, including motherboard, CPUs, memory modules, GPUs, disks, and network interfaces
• Installed programs
• System-service listing
• Display listing
• Network scanning and observation
• DNS resolution
• Ping

Sensitive operations require the full signature chain:

• File read, write, and delete
• Filesystem browsing and per-entry path metadata through an authorized file-transfer session
• Windows registry read and write
• Process and script execution
• Terminal sessions
• Screen sharing and remote control
• Screenshot capture
• File transfers
• Network tunnels
• Service control, including start, stop, and restart
• Agent uninstall

How authorization works

For every sensitive operation, the technician's browser:

1. Creates a canonical representation of the operation.
2. Binds it to the target agent, preventing cross-endpoint replay.
3. Binds it to the tenant, preventing cross-tenant replay.
4. Includes a timestamp, replay nonce, and sequence number.
5. Signs the complete structure with the session key.

The agent independently verifies:

1. The full certificate chain from the operation signature back to the pinned tenant root CA.
2. The signature over the canonical payload.
3. That the operation is addressed to this specific agent.
4. That the timestamp is within an acceptable window.
5. That the replay nonce has not been seen before.
6. That the technician's certificate has not been revoked.
7. That the technician has permission for this operation type.

If any check fails, the agent rejects the operation. There is no override mechanism.

Permission model

Permissions are enforced at two layers:

1. Intermediate CAs determine which action category a user can perform, such as user management, script signing, or revocation. This is a cryptographic boundary.
2. Certificate extensions specify which operations a technician can perform and on which endpoints or groups. These are set when the certificate is issued and are immutable.

Encryption

End-to-end encrypted sessions

Interactive sessions — screen sharing, terminal, file transfer, and network tunnels — use WebRTC with DTLS encryption. Before a connection is established, the agent and technician use an additional key exchange to encrypt WebRTC signaling. The bridge relays encrypted signaling but never sees the DTLS fingerprints, ICE candidates that reveal network topology, or session data.

Encrypted request and response payloads

For command-response operations, such as file reads, process execution, and screenshot capture, the technician encrypts the request payload with ECIES: an ephemeral X25519 key exchange with the agent's published DH key, followed by AES-256-GCM encryption. The agent decrypts, executes, and encrypts the response with a separately derived key. The bridge can see that an operation occurred and its type, but cannot read its contents.

Separate encryption keys are derived for each direction and operation with HKDF-SHA256, distinct labels (zyno-req-enc and zyno-resp-enc), and random salts. Each operation uses a fresh ephemeral key exchange; keys are never reused.

Audit trail

The bridge maintains an audit log of all operations. It can read ordinary audit metadata, such as operation type, status, and timing. Sensitive audit-log fields, such as filesystem paths, commands, and output, are encrypted with a tenant-specific audit key; the bridge stores ciphertext it cannot decrypt. Only authorized users can decrypt those fields for review.

Before forwarding a sensitive operation to an agent, the bridge must produce a signed audit receipt proving it recorded the operation. The agent verifies this receipt before executing, so every operation leaves evidence in the audit trail.

Scripts and updates

Script library

Technicians can pre-sign scripts for repeated use across endpoints. Each signed script includes:

• The script content
• Target constraints, such as endpoints or groups
• An expiry date
• Whether it requires a live technician signature to trigger or can run automatically within its constraints

Pre-stored scripts are recorded in a tamper-evident registry and can execute across multiple endpoints without being re-signed.

Ad-hoc scripts

Technicians can also execute scripts without pre-storing them. An ad-hoc script is signed in real time with the technician's Script CA key and includes replay protection:

• createdAtMs timestamp — signed and verified by the agent to be within five minutes of the current time
• Mandatory expiry — the SDK defaults to five minutes, and the agent rejects expired scripts
• Full signature chain — author certificate → Script CA → tenant root CA

An attacker who captures an ad-hoc script in transit cannot replay it after the five-minute window. Because createdAtMs is signed, it cannot be changed without invalidating the signature.

Software updates

Software updates are pre-signed scripts that require explicit tenant approval. ZynoRMM can publish a release, but a technician in the organization must review and approve it before it can be deployed to that organization's agents. The vendor cannot push updates to endpoints directly.

Tamper-evident registry

Script approvals, revocations, and update authorizations are recorded in a hash chain: every entry references the previous entry, forming a tamper-evident append-only log. Agents validate the chain locally and can detect entries that were omitted, reordered, or modified.

Revocation

When a technician's access needs to be revoked, for example because they leave the organization or lose a device, the Revocation CA signs revocation entries and distributes them to agents. Agents maintain a local revocation list and check it during every operation verification.

Short-lived session certificates limit exposure even without active revocation: a compromised session key expires within eight hours.

Enrollment

To deploy the agent:

1. Generate an enrollment token in the management console. It can be single-use or limited-use, with an optional expiry.
2. Install the agent and provide the token through MDM, Intune, GPO, or manual entry.
3. The agent connects, submits a certificate-signing request, and receives its identity certificate and the CA certificates it needs to verify future operations.
4. The agent permanently pins the tenant root CA certificate and never accepts a different root, even if the server is compromised.

No manual approval step is needed: a valid enrollment token is the authorization. Once enrolled, the agent trusts only operations that chain back to the tenant root CA.

Cryptographic primitives

Purpose	Algorithm
Certificate authorities and signing	Ed25519
Agent identity	ECDSA P-256, hardware-backed where available
Key exchange	X25519 ECDH
Symmetric encryption	AES-256-GCM
Key derivation	HKDF-SHA256
Replay prevention	128-bit random nonces
Memory safety	Keys zeroized from memory after use
Timing safety	Constant-time comparisons for signatures and MACs

Reporting vulnerabilities

To report a ZynoRMM security vulnerability, email security@zyno.io. We will acknowledge receipt within 48 hours and provide remediation updates.

Please do not disclose a vulnerability publicly until a fix has been released.

Related

• Technicians and Access
• Enroll Managed Endpoints
• Scripts and Agent Updates
• Passkeys