Security by design, not by checklist
Why we build access control, encryption and audit into the architecture from the first commit, and what that looks like in practice.
It is tempting to treat security as a phase: build the product, then harden it. We think that order is backwards. By the time you go looking for the gaps, the architecture has already decided where they are. So at Vexaro, the security properties come first and the features are shaped to fit them, not the other way around.
No implicit trust, by default
Nothing in Vexaro is trusted because of where it sits on the network. Every session needs the host's on-screen consent or its unattended password, each device keeps its own rules on who may connect and with which rights, and unattended access can be limited to an allowlist of Vexaro IDs. That is what makes the rest tractable: when every session passes the same checks on the host's terms, you can reason about who can reach what without drawing a map of the network.
Encryption you don't have to opt into
Direct sessions are end-to-end encrypted: the encryption boundary is the two machines, not our infrastructure. When a network forces a relayed connection, traffic stays encrypted in transit through Vexaro-operated relays. Either way there is no toggle to turn on; encryption is how a session works.
Least privilege and a real audit trail
- Roles grant the narrowest access that does the job, and each device keeps its own rules on who may connect unattended and with which rights.
- Administrative actions, sessions, and access events are recorded in an audit log that, on paid plans, you can export and review on your own terms.
- Session recording, which an administrator turns on for the whole organization on the Team plan and above, gives you an account of what happened during a connection, not only a record that one occurred.
A claim that access is controlled is only worth as much as your ability to check it afterward, which is why the log is a first-class part of the product rather than an export bolted on later.
Where we are today
Security by design is ongoing work, and we are in early access. We will not claim certifications we have not earned or print a customer count to look bigger than we are. What we will do is state plainly what is true today, build toward recognized international certification, and publish our status as we reach each milestone. If you are running a vendor review, our team can walk you through the current security overview and the supporting detail.
A security claim is only worth as much as the audit log that can check it.
Designing for security from the first commit is not glamorous and it rarely shows up in a demo. But it is the difference between a product that is secure because someone remembered to check, and one that is secure because it could not easily be otherwise. That is the version we want to run, and the version we want you to run too.