You are the single point of failure for every client you manage. That's not a compliment — it's a threat model, and it's the one this stack was designed against. Built as though somebody is already inside: how ZynoRMM decides what to run, how documentation is stored, and where your clients' calls actually go.
This is the distinction that matters, and it is easy to skim past — so it's worth being precise about.
You prove yourself at the door. The system hands back a session, and from then on it trusts whatever arrives carrying that session. A passkey used this way is a very good door — but it's still just a door.
Steal the session, or compromise the server that honors it, and every command after that point is indistinguishable from yours.
There is no session standing in for you. Each command, script and configuration change is individually signed on your own device, with a key that has never left it — and the endpoint checks that signature itself before executing anything.
There's no token to replay, and no server whose "yes" carries any weight. Authority lives in the key, and the key lives in hardware you're holding.
The middle of that diagram is the part an attacker takes. It is also the only part with no authority to give them — our infrastructure can delay or drop your instructions, but it cannot invent one your agents will run.
Every RMM vendor's answer to this is a promise about their own security. That promise is worth something right up until the day it isn't — and on that day it's the only thing between an attacker and your whole book of clients. We would rather you didn't have to take ours.
Think about what's actually in your documentation: network diagrams, recovery procedures, which cabinet the spare keys are in, how to get into the firewall at 3am. An attacker who reads your knowledge base doesn't need to break anything — you've written them a manual.
ZynoKB keeps structured client data in ZynoCMS, the same typed content store the rest of the platform uses — so encryption happens at the field level rather than on the disk underneath. The part that matters is who holds the keys: your technicians do. Sensitive fields decrypt on their device, with a key we were never given.
It's the same instinct as the RMM, applied to storage. Our infrastructure holds ciphertext and nothing that turns it back into plaintext — so the guarantee doesn't rest on our servers never having a bad day.
A phone system hears everything: the medical practice's patients, the law firm's clients, the payment details somebody reads out loud because it was easier than typing them. Whoever runs it inherits all of that.
ZynoTalk is encrypted on every hop we control — from the phone through the carrier handoff — encrypted at rest once it lands, and shared with nobody. Even the AI is ours.
Cryptography handles the vendor-compromise case. The rest is ordinary discipline about scope — who can reach what, with which capability, and how recently they proved it was really them.
The trust model, the key hierarchy and the authorization framework are documented in full. If you have someone who evaluates this properly, point them at it.
We would rather spend the first call on the trust model than on a feature list. Bring your worst scenario — the one that actually keeps you up — and let's walk through what happens.