Choosing a password manager means trusting a software architecture with a critical keyring. The question is not only “is the app well known?” but also “what happens if the server, device, administrator account, or backup is compromised?”
This framework is for privacy-conscious individuals and SMBs. It helps compare products and prepare vendor questions; it is not a substitute for an independent audit or legal advice.
1. Start with the threat scenario
Before comparing features, describe what you need to prevent:
- vault or backup theft after a server intrusion;
- account recovery by someone who should no longer have access;
- secret leakage through an infected device, browser extension, or clipboard;
- vault loss after theft, failure, or a key person leaving;
- overly broad team sharing with no clear revocation path.
A service can be strong against one risk and weak against another. Record impact, likelihood, people exposed, and the acceptable time to restore operations.
2. Examine architecture and encryption
Ask for a simple diagram of a secret’s journey: creation, encryption, synchronisation, unlock, sharing, backup, and deletion. The provider should explain:
- what is encrypted before leaving the device and what remains readable by the service;
- how the master password or unlock key produces the vault key;
- whether each vault has separate keys and how keys are renewed;
- which metadata remains: service addresses, entry names, devices, logs, or IP addresses;
- how changes and synchronisation are authenticated and protected from tampering.
“End-to-end encryption” and “zero-knowledge” are starting points, not proof. Look for technical documentation, stated limits, and published audits; check their scope and date.
3. Use a comparison grid
Score each criterion from 0 to 3: 0 = absent or undocumented, 1 = partial, 2 = satisfactory, 3 = demonstrated and regularly checked. Missing evidence does not automatically prove a technical weakness, but it should affect the decision.
| Criterion | What to verify | Expected evidence |
|---|---|---|
| Architecture | Client-side encryption, key separation, metadata, and threat model | Dated technical documentation, diagram, explicit limits |
| Cryptography | Suitable algorithms and key derivation, documented parameters, authenticated integrity | Specification, audited code, or an independent report covering the vault |
| Access | MFA, master-password protection, sessions, authorised devices, and revocation | Test in a demo environment and an administration procedure |
| Backups | Export format, encryption, frequency, separation, and tested restoration | Backup/restore procedure and a test result |
| Recovery | Lost device, forgotten master secret, departure, or provider outage | Scenarios, owners, timelines, and dependencies |
| Sharing | Least privilege, groups, expiry, revocation, named accounts, and auditability | Add, remove, and role-change tests |
| Devices | Memory storage, locking, extensions, clipboard, and updates | Control documentation and support policy |
| Governance | Vulnerability disclosure, incidents, subprocessors, retention, and exit | Security policy, alert channels, export, and deletion process |
Do not compensate for a critical weakness with a high average score. Opaque recovery or an unrestoreable backup can be a deal-breaker even when the interface is excellent.
4. Verify copies and recovery
A local solution limits some centralised copies, but it does not protect against device loss. A synchronised solution simplifies continuity, but adds accounts, servers, and flows to protect. In both models:
- define who may create a copy and where it is stored;
- encrypt the copy with a secret separate from the daily account;
- keep at least one copy separate from the primary device and limit access;
- test restoration on a clean device and measure the time required;
- verify that the export is complete, readable, and deleted after the test.
A plan without a test is an assumption. The test should also cover loss of the phone used for MFA and the unavailability of the person who knows the recovery secret.
5. Assess team sharing
For every shared vault or collection, ask who owns access, who approves it, who can export, and who can remove it. Prefer named accounts, role-based groups, and automatic or fast revocation. Permanent shared accounts, non-expiring links, and default administrator rights are warning signs.
Run an offboarding test: remove a fictional user, change a role, replace a shared secret, and check what remains in the logs. Secure sharing should reduce manual copying, not merely move the password into another interface.
6. Do not forget devices
The best vault cannot fix a compromised device. Check session locking, updates, disk encryption, browser-extension permissions, and clipboard handling. On an infected computer or phone, an unlocked secret can be observed before it is stored.
Also ask which operating-system versions are supported, how updates are signed, and how vulnerabilities are announced. For an SMB, these answers belong with endpoint management, MFA, and incident procedures.
7. Questions to ask the vendor
- Which data can the server read if a synchronised vault is uploaded?
- Which metadata is retained, for how long, and by which subprocessors?
- What is the exact scope of the latest audit or penetration test?
- How are keys derived, and how is offline guessing made expensive?
- What happens if the account is locked, MFA is lost, or the provider is unavailable?
- Can I restore an encrypted copy without your service? In which format and with what limits?
- How do I revoke a device, member, or shared access, and what response time is guaranteed?
- How do you report a vulnerability or incident affecting vaults?
- How are data and copies deleted at the end of the contract, and how can deletion be verified?
Answers should be precise and consistent across documentation, contract, and the product you test. Marketing language that avoids metadata or recovery questions is a warning sign.
8. Decide without absolute promises
Choose the solution that matches your threat model, skills, and recovery capacity. Record gaps, compensating controls, and a review date. Reassess after an architecture change, acquisition, incident, or major provider change.
Soclyde fits the case where an organisation wants to generate unique secrets, keep an encrypted vault on its devices, and limit centralised copies. This replaces neither MFA on the protected service, nor backups, nor device security. The right choice is the one whose assumptions your team can understand and verify.
Final checklist
- [ ] The threat model and service limits are written down.
- [ ] Encryption, keys, and metadata are documented.
- [ ] MFA and device revocation have been tested.
- [ ] An encrypted copy exists and restoration time has been measured.
- [ ] Sharing is named, limited, and revocable.
- [ ] Devices, extensions, and updates are covered by a policy.
- [ ] Export, deletion, and the exit plan are realistic.
- [ ] Evidence will be reviewed after changes or at least annually.
