Security

ZynoRMM is built on a zero-trust security model. The core principle: no entity — including the hosting infrastructure — can execute sensitive operations on your endpoints without cryptographic proof from an authenticated technician.

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

Threat Model

What a compromised server cannot do

• Execute any sensitive operation on any managed endpoint
• 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 historical audit log contents

What a compromised server can do

• Deny service — refuse to forward legitimate requests (but cannot cause harm)
• See metadata — know that an operation occurred, its type, and timing (but not the contents)
• See which agents exist — agent identifiers are visible (but cannot be used to impersonate or command them)

Trust Model

Tenant Root Certificate Authority

When your organization first sets up ZynoRMM, a cryptographic key ceremony takes place entirely in an administrator's browser. This generates a root certificate authority (CA) that is unique to your tenant. The root CA's private key is encrypted with a high-entropy recovery key, and the administrator downloads the encrypted file and prints the recovery key separately. These two pieces are stored in separate physical locations.

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

Intermediate Authorities

The root CA signs several constrained intermediate CAs, each with a single purpose:

• User CA — can only issue technician certificates
• Script CA — can only approve scripts and upgrades
• Revocation CA — can only issue revocation entries

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

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 (passkey or security key). Only by physically authenticating with their hardware token can a user unwrap the keys needed to perform signing operations — and all signing happens in the browser, never on the server.

Technician Identity

Each technician has a personal certificate signed by the User CA. When a technician authenticates, they also create an ephemeral session certificate (valid for 8 hours) that exists only in browser memory. This session certificate is used to sign individual operations.

The full chain for any operation is:

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

Every link in this chain is verified by the agent before executing any sensitive operation.

Agent Identity

Each agent generates its own identity key using platform hardware security:

• macOS — Apple Keychain (Secure Enclave for supported hardware)
• Windows — encrypted local storage (TPM integration planned)
• Linux — encrypted file with platform-derived key, restricted file permissions

Agent identity keys are used for transport authentication (proving the agent is who it claims to be) — but they do not grant any 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 / Face ID via Secure Enclave (macOS, iOS)
• Android — biometrics via StrongBox or TEE
• Windows — Windows Hello via TPM
• Security keys — YubiKey and other FIDO2 devices (USB/NFC)

Software-only credential providers (like password managers) can be blocked by policy when hardware binding is required. This ensures that a technician's authentication requires physical possession of their device — not just a password.

Multi-Device Support

Technicians can register multiple devices (e.g., a laptop and a 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 doesn't lock you out — you can authenticate from any remaining registered device. A lost device's access can be revoked without affecting other devices.

Operation Security

What requires authorization

Operations are split into two categories: non-sensitive (no signature required) and sensitive (full cryptographic signature chain required).

Non-sensitive operations are read-only telemetry and discovery queries with no sensitive side effects. These can be performed by the bridge directly for monitoring purposes, without a technician signature:

• System information (hostname, OS, CPU, memory, boot time)
• System utilization (CPU/memory/disk usage)
• Hardware inventory (motherboard, CPUs, memory modules, GPUs, disks, network interfaces)
• Installed programs
• System service listing
• Directory listing and file metadata
• Display listing (available monitors)
• Network interface listing
• Network scanning and observation
• DNS resolution
• Ping

Sensitive operations require a full cryptographic signature chain from an authenticated technician:

• File read, write, and delete
• Registry read and write (Windows)
• Process and script execution
• Terminal sessions
• Screen sharing and remote control
• File transfers
• Network tunnels
• Service control (start/stop/restart)
• Agent uninstall

How authorization works

For every sensitive operation, the technician's browser:

1. Constructs a canonical representation of the operation
2. Binds it to the specific 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 entire 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 type of operation

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

Permission Model

Permissions are enforced at two layers:

1. Intermediate CAs — what category of action a user can perform (user management, script signing, revocation) is determined by which intermediate CA keys they hold. This is a hard cryptographic boundary.

2. Certificate extensions — within a technician's certificate, extensions specify which specific operations they 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

All interactive sessions — screen sharing, terminal, file transfer, and network tunnels — use WebRTC with DTLS encryption. Before establishing these connections, the agent and technician perform an additional key exchange to encrypt the WebRTC signaling itself. The bridge relays encrypted signaling but never sees the DTLS fingerprints, ICE candidates (which reveal network topology), or any session data.

Encrypted Request/Response Payloads

For command-response operations (file reads, process execution, etc.), the technician encrypts the request payload using the agent's public key. The agent decrypts, executes, and encrypts the response with a separately derived key. The bridge can see that an operation happened and what type it was, but cannot read the contents of the request or response.

Separate encryption keys are derived for each direction (request vs. response) and each operation, using industry-standard key derivation (HKDF) with distinct labels and random salts.

Audit Trail

The bridge maintains an audit log of all operations. Sensitive fields in the audit log (file paths, commands, output) are encrypted with a tenant-specific audit key — the bridge stores ciphertext it cannot decrypt. Only authorized users can decrypt audit entries for review.

Before forwarding any sensitive operation to an agent, the bridge must produce a signed audit receipt proving it logged the operation. The agent verifies this receipt before executing. This ensures no operation can bypass the audit trail — even the bridge itself must leave evidence.

Pre-Approved Scripts & Updates

Script Library

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

• The script content
• Target constraints (which endpoints or groups it can run on)
• Execution limits (expiry date, maximum execution count)
• Whether it requires a live technician signature to trigger, or can be triggered automatically within its constraints

Agents independently verify the script signature and enforce all constraints before execution.

Software Updates

Software updates are treated as pre-signed scripts that require explicit tenant approval. ZynoRMM publishes a release, but a technician from your organization must review and approve it before it can be deployed to your agents. The vendor cannot push updates to your endpoints directly.

Tamper-Evident Registry

All script approvals, revocations, and update authorizations are recorded in a hash chain — each entry references the previous one, forming a tamper-evident append-only log. Agents validate the chain locally and can detect if entries have been omitted, reordered, or modified.

Revocation

When a technician's access needs to be revoked (e.g., they leave the organization or lose a device), revocation entries are signed by the Revocation CA and distributed to all agents. Agents maintain a local revocation list and check it during every operation verification.

Short-lived session certificates (8-hour TTL) naturally limit the exposure window — even without active revocation, a compromised session key expires within hours.

Enrollment

Deploying the agent is straightforward:

1. Generate an enrollment token in the management console (single-use or limited-use, with optional expiry)
2. Install the agent on the endpoint and provide the token (via MDM, Intune, GPO, or manual entry)
3. The agent connects, submits a certificate signing request, and receives its identity certificate along with all the CA certificates it needs to verify future operations
4. The agent permanently pins the tenant root CA certificate — it will never accept 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 your tenant's root CA.

Cryptographic Primitives

Purpose	Algorithm
Certificate authorities & signing	Ed25519
Agent identity	ECDSA P-256 (hardware-bound)
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

If you discover a security vulnerability in ZynoRMM, please report it responsibly:

• Email: security@zyno.io
• We will acknowledge receipt within 48 hours and provide updates on remediation

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