How to Audit a Password Manager’s Security

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 process for removing unnecessary rights.

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.

Password manager security evaluation grid

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, and authorised devices	Documented controls 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, named accounts, and auditability	Add, rights-removal, 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:

1. define who may create a copy and where it is stored;
2. encrypt the copy with a secret separate from the daily account;
3. keep at least one copy separate from the primary device and limit access;
4. test restoration on a clean device and measure the time required;
5. 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 how unnecessary rights are removed. Check what that removal covers and what the logs let you verify. Prefer named accounts and role-based groups. Permanent shared accounts, non-expiring links, and default administrator rights are warning signs.

Run an offboarding test in a designated environment: remove a fictional user’s rights, change a role, replace a shared secret, and check what the logs let you confirm. 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?
• What happens when a device or member is removed, and which copies or sessions remain accessible?
• 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, device management, and the effects of removing access are documented.
• [ ] An encrypted copy exists and restoration time has been measured.
• [ ] Sharing is named, limited, and has a documented process for removing rights.
• [ ] 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.