Moving an encrypted service into a company server room changes who operates it. It does not, by itself, answer who can read a document. That distinction matters when an organisation wants control of its infrastructure without quietly giving its administrators control of every employee’s files.
A historical product offered two deployment choices
The AVLab review of UseCrypt Safe, published on 7 January 2019, described a hosted service and an installation on customer infrastructure. Its comparison placed encrypted files on different servers while retaining local client participation. This is evidence about the product described in that review, not a current price list, availability statement or assessment of today’s Messenger.
A separate primary source documents a commercial setting for the technology. In its 28 March 2019 announcement of data-protection services, Netia identified UseCrypt software and HVKM as the basis of Netia Data Safe. It described separate client-side and server-side key components. The announcement establishes what Netia presented at that date. It does not prove the present configuration of a customer’s deployment.
Draw the people into the diagram
Consider a hypothetical company choosing between a managed installation and operating its own server. A useful trust map names the person who can change server configuration, the team that distributes client updates and the employee who can open a document. Those capabilities may belong to different people. A single rectangle labelled “private cloud” conceals that difference.
Start with one operation: opening an existing file. Mark the encrypted object, the client-held material, the participating service and the component that renders readable content. Then ask which administrator can change each component. This exercise is an analytical checklist, not a reconstruction of an undocumented UseCrypt protocol.
There is a practical reason to separate those questions. An administrator might be unable to decrypt a stored object using a server backup alone, yet still be responsible for delivering software to a client. The first property does not settle the second. An assessment must identify which authority it has examined and which authority remains outside the test.
Operational ownership brings operational duties
Running a service internally also gives someone responsibility for patching, monitoring and restoring it. That work does not disappear because the documents are encrypted. Nor should a recovery procedure create an undocumented route around the promised access boundary.
For the hypothetical deployment, write down who can restart the participating service and what happens when that person is unavailable. Use synthetic documents to rehearse a change of administrator. Check both successful authorised access and the rejection of an account that should no longer participate. Keep the outcome separate from any claim about resistance to a malicious client update, unless that was actually tested.
Keep the historical evidence useful
The existing Safe and HVKM source guide provides a place to read the historical material in context. It should not be collapsed into a promise that one deployment location is always safer than another. Different organisations can reasonably choose different operating models, but their reasons should be visible.
A serious review ends with an accountable map: who runs the service, who controls the endpoint and which observed operation requires their participation. The server’s address is one fact on that map. It is not the whole security argument.
