One account, one account per session or a VM per person?
How you keep one person's session apart from another's decides your security, your bill and your operations. There are three honest options.
By the Onscryn team · November 1, 2026 · 8 min read
The moment two people need the same Windows software at the same time, you have chosen an isolation model, whether you meant to or not. The default, when nobody decides, is the weakest one. It is worth deciding on purpose.
Three honest options
The first model is one shared account. Everyone signs into the same Windows user on the same machine. It is the simplest to set up and the cheapest to run. It is also the least separated: people can see each other's windows, files and history, and you cannot tell who did what.
The second is a separate Windows account for each session on a shared host. Each person gets their own profile, their own files and their own running programs, while the underlying machine and the licence for Windows are shared. This is how multi-user Windows servers have worked for decades, and it is a strong, efficient middle path.
The third is a virtual machine per person. Each person has a whole computer to themselves. It is the strongest separation you can get without separate hardware, and the one with the most to run: every machine has to be built, patched, backed up and paid for.
What each one protects you from
A shared account protects you from nothing. It exists because it is convenient. If the people involved are a trusted team and the data is low stakes, that may be fine, and you should say so honestly rather than pretending otherwise.
A separate account per session protects one person's files, settings and running programs from another's, and gives you an identity to attach actions to. It does not give each person their own kernel, so it relies on Windows account isolation holding. For most business software that is the standard model and it is well understood.
A virtual machine adds a boundary at the hypervisor, which is a smaller and more heavily scrutinised surface. If you are handling data where that distinction matters to a regulator or a client, it is the model to reach for.
The cost nobody mentions: cleanliness
There is a second question behind isolation: what is left behind when a session ends? Profiles accumulate. Temporary files linger. Someone's cached credentials outlast their session. A model that creates a fresh account for each session and removes it afterwards, or scrubs it before reuse, answers that question by design. One that does not leaves the answer to chance.
How to choose
- What is the worst thing that could leak, and who would care?
- Do you need to show an auditor or client a specific boundary?
- How many people, at what times? Capacity changes the economics sharply.
- Who will build and patch the machines, and what does an hour of their time cost?
Most teams land on the middle option and move one application or one group of users to a stronger one when the risk calls for it. That is a sensible path. The mistake is not choosing a weaker model. The mistake is not knowing which one you chose.