Password manager security features: How to evaluate them

Every password manager vendor claims strong security. Few show you the architecture documentation or the pentest summary that would let you confirm it. The gap between a security page and a verified claim is where due diligence has to start.

Evaluating a password manager's security features means checking encryption architecture, authentication strength, access governance, independent verification, compliance alignment, and operational resilience against evidence, not marketing copy.

This is a security-verification guide, not a buying guide, and part of our broader enterprise password management guide. If you're still comparing vendors on cost, deployment, and DevOps fit, start with the full 10-criteria buying framework; come back here once you have a shortlist and need to confirm the security claims hold up.

Key Takeaways

Verify, don't take the claim at face value: run every vendor's security page against evidence before you sign.
Zero-knowledge and encryption at rest are not the same thing. Ask where keys are generated and held.
MFA strength and session timeout behavior matter more than a features list — test them yourself.
RBAC granularity and real offboarding revocation, beyond an SSO disable, define least privilege in practice.
A current ISO/IEC 27001 certificate, and pentest summary are the baseline proof, not extras.
Map vendor claims to specific GDPR, NIS2, and NIST clauses, not vague "compliant" language.

Why "it has encryption" isn't a security answer

"We use military-level encryption" says nothing about who can decrypt your vault, how a breach would play out, or whether an outside auditor has ever tested the claim. Encryption is table stakes, not a differentiator. What actually determines your risk sits one layer below the marketing line.

The stakes for getting this wrong keep rising. The global average cost of a data breach reached $4.99 million in 2026, a 12% increase and a record high, according to IBM's Cost of a Data Breach Report 2026. Credential-related risk hasn't disappeared either: Verizon's 2026 Data Breach Investigations Report found that vulnerability exploitation climbed to 31% of breaches as the first recorded entry point in 2026, overtaking credential abuse, which fell to 13% in that same first-step count. Tracked at any point across an attack rather than just the opening move, credential abuse still shows up in 39% of breaches, the most common chokepoint in the report.

A verified claim and an unverified one can read identically on a website. "Your data is encrypted with AES-256" is true of a password manager with genuine zero-knowledge architecture and of one where the vendor holds every key and can decrypt records on request. The wording alone gives no indication which one you're buying. That's the gap this framework closes, one pillar at a time.

Every claim on a vendor's security page is checkable. The six pillars below give you a fixed list of what to check and how to check it.

The password manager security verification framework

The password manager security verification framework breaks vendor due diligence into six pillars: encryption architecture, authentication and session security, access governance, independent verification, compliance alignment, and operational resilience. Run the scorecard below against any vendor, current or prospective, before trusting a claim you haven't checked yourself.

Pillar	What to check	How to verify	Pass/fail notes
1. Encryption architecture	Zero-knowledge vs. encryption at rest, key location	Request the architecture documentation; ask where keys are generated	Fail: vendor can decrypt your data on demand
2. Authentication & session security	MFA method strength, passkey support, session timeout	Test auto-lock and re-authentication yourself	Fail: SMS-only MFA, no configurable timeout
3. Access governance	RBAC granularity, offboarding revocation	Simulate an offboarding; check what survives SSO disable	Fail: shared passwords no one can rotate centrally
4. Independent verification	ISO/IEC 27001, pentest cadence	Request the current report and certificate dates	Fail: no report, or a lapsed certificate
5. Compliance alignment	Mapping to GDPR, NIS2, NIST clauses	Ask which article or section a claim maps to	Fail: only "we are compliant," no clause named
6. Operational resilience	Offline access, backups, deployment model	Ask what happens during an outage or lost device	Fail: no documented recovery process

Treat the fourth column as a live worksheet, not a description. Fill in an actual pass or fail for each pillar as you gather evidence, and score anything you can't verify within a reasonable timeframe as a fail by default. A vendor that needs three follow-up emails to answer a documentation request is telling you something about how it will handle an incident, too.

Each pillar gets its own section below, with the specific questions to ask and what a pass or fail looks like in practice.

Pillar 1: Encryption architecture and zero-knowledge design

Zero-knowledge architecture means the provider cannot read your data even under legal compulsion, not that it simply chooses not to look. Encryption at rest is a much weaker claim: the vendor holds the keys and can, in principle, decrypt your vault. Confusing the two is the single most common gap in a vendor's security page.

Encryption at rest vs. zero-knowledge

Encryption at rest protects data from an outsider who steals the database. It does not protect data from the vendor itself, from a subpoena, or from an insider with database access. Zero-knowledge, also described as end-to-end encryption when applied across synced devices, closes that gap: encryption and decryption happen exclusively on the client, and the server stores only ciphertext and encrypted key material it cannot decrypt on its own. Zero-knowledge architecture is the term to look for by name, not "strong encryption."

How to test the claim

The mechanics matter more than the label. Keys should be generated client-side with a cryptographically secure random number generator, derived through a key derivation function (KDF) such as PBKDF2 or Argon2 with a high iteration count, and used to encrypt vault and record data with AES-256. Per-vault or per-record keys, rather than one master key covering the whole organization, limit the blast radius if a single key is ever compromised.

A useful way to test whether a vendor's explanation is real: ask them to walk the chain from master password to plaintext record. In a genuine zero-knowledge design, that chain runs client-side the whole way. The master password derives a master key, the master key decrypts a private key stored, encrypted, on the server, the private key unlocks per-vault keys, and vault keys unlock the individual record keys that decrypt each password or secret. If the explanation skips a step, or the server needs to participate to complete decryption, the architecture isn't zero-knowledge, regardless of what the brochure says.

Verification checklist

Request the architecture or cryptography documentation.
Confirm where encryption keys are generated: client device or server.
Ask whether keys are unique per vault or shared across the organization.
Confirm which KDF is used and its iteration count or memory cost.

Pillar 2: Authentication and session security

NIST SP 800-63B-4 tells verifiers they SHALL allow the use of password managers and autofill functionality (Sec. 3.1.1.2). A vendor whose product fights browser autofill, or whose default policy still forces 90-day password rotation, is working against the current standard, not securing you.

MFA and passkey strength

Multi-factor authentication (MFA) is non-negotiable, but not all MFA is equal. SMS codes are the weakest option and vulnerable to SIM-swap attacks. Time-based one-time passwords (TOTP) are stronger and work offline. Push notifications add convenience but are vulnerable to prompt-bombing unless paired with number matching. Hardware security keys and passkeys, built on the FIDO2 standard, resist phishing by design because the credential is bound to the origin it was created for. Passkey support signals a vendor keeping pace with current standards.

Biometric unlock deserves a closer look, too. Face ID or a fingerprint reader is usually a convenience layer on top of the actual credential, unlocking a device-stored key rather than replacing MFA entirely. That's a reasonable trade-off on a personal device, but confirm what happens on a shared or unmanaged one: does biometric unlock alone grant vault access, or does it still require the underlying authentication step?

Master password and session rules

Master password requirements deserve the same scrutiny. NIST SP 800-63B-4 sets a concrete bar: a 15-character minimum for single-factor passwords, and no periodic rotation requirement absent evidence of compromise. If a vendor's default policy still forces a master password change every 90 days, that policy predates the current standard.

Session timeout and auto-lock behavior decide how long a stolen or unattended device stays exploitable. Don't take the spec sheet's word for it. Open the app, leave it idle for the stated timeout window, and confirm it actually locks. Test what happens after a password reset, too: does every other active session get revoked immediately, or does a stale session on a second device keep working?

Checklist

MFA options offered: TOTP, push with number matching, hardware key, passkey/FIDO2.
Master password policy: length-based, not fixed-interval rotation.
Session timeout and auto-lock: test it yourself, don't just read the spec.
Concurrent session handling after a forced password reset or logout.

Pillar 3: Access governance and least privilege

Role-based access control (RBAC) sounds like a checkbox until you test what happens when someone leaves. Disabling a single sign-on (SSO) account revokes directory-based access. It does nothing to a shared password four people already know, an API key cached in a CI pipeline, or a locally stored token.

How granular RBAC actually gets

Ask how granular RBAC actually gets. Role-level access ("Administrator" versus "Member") is the coarsest option. Group-based access, where permissions attach to a team or department and people inherit them by membership, scales better and matches how role-based access control is meant to work: grant the group access once, then add or remove people from it. Per-folder or per-item access, layered on top of groups, is what lets an admin hand one vendor's credentials to a contractor without opening the whole vault.

SSO disable is not revocation

SSO or AD disable is not access revocation. It's directory disable. A departing employee who shared a login for a vendor portal, a network device, or a legacy application still knows that password until someone changes it. Verifying access governance means asking how the vendor handles that gap: does a shared credential get flagged for rotation on offboarding, or does it just sit there, unrevoked, indefinitely?

The urgency here isn't theoretical. Average eCrime breakout time, the time from initial access to lateral movement, dropped to 29 minutes in 2025, 65% faster than 2024, according to CrowdStrike's 2026 Global Threat Report. An annual access review doesn't catch a credential that should have been revoked in April. Real-time, event-driven revocation does.

Machine identities need the same discipline

Least privilege has to extend to machine identities, not people alone. API keys, service accounts, and CI/CD credentials often sit outside the RBAC model entirely, provisioned once and never reviewed again. Ask whether service accounts get their own scoped roles and rotation policy, separate from interactive user accounts, or whether they're an afterthought bolted onto the same permission system built for humans.

Ask one more question while you're at it: can the vendor answer "who had access to this credential last month," after the fact, from an audit log, without a support ticket? If not, least privilege is a policy statement, not an enforced control.

Pillar 4: Independent verification: audits, certifications, and breach history

Anyone can write "enterprise-grade security" on a landing page. A current, named security certification with a valid date range, a recent penetration test summary, and a documented incident history are the difference between a claim and a claim you can check. If a vendor won't produce any of the three, treat that as an answer.

What a certification actually proves

ISO/IEC 27001 certification confirms a vendor operates a certified information security management system, assessed by an accredited third-party auditor against a recognized international standard, not a self-graded checklist. Check the certificate's issue and expiry dates directly instead of trusting a badge on a website: certifications are typically renewed annually, and a badge with no visible date could be years out of date.

A penetration test summary, ideally from an independent third party or coordinated through a program like HackerOne, shows whether anyone outside the vendor's own team has tried to break in recently, and what they found.

Ask what the certification actually covers, too. A scope statement limited to "corporate IT" or a single product line is weaker evidence than one covering the full production environment that stores your credentials. Some vendors also open their source code to auditing by customers or independent researchers. That's a stronger signal than a certificate alone, though it's uncommon enough that its absence isn't automatically disqualifying.

Breach history is itself a security feature

How a vendor handled its last security incident, if it has had one, is itself a security feature. No documented incident history at all is implausible for any vendor operating at scale. The more useful question is whether the vendor runs a monitoring and disclosure process, or whether "we've never had an incident" is the entire answer.

What to request from the vendor

Current security certification (such as ISO/IEC 27001), with issue and expiry dates.
Most recent penetration test summary and testing cadence (annual, at minimum).

A vendor claiming "GDPR compliant" or "NIS2 ready" without naming a specific article is making a marketing claim, not a legal one. GDPR Article 32 and NIS2 Article 21 each name concrete technical measures. Map a vendor's claims to those clauses directly, and let your legal team confirm what "compliant" means for your specific obligations.

GDPR Article 32(1)(a)-(b) requires controllers and processors to implement "the pseudonymisation and encryption of personal data" and "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services" (GDPR, Art. 32). For a password manager, that maps directly to Pillar 1 (encryption architecture) and Pillar 6 (resilience) above, not to a generic privacy policy.

NIS2 Article 21

NIS2 Article 21(2) gets more specific still. Article 21(2)(h) requires "policies and procedures regarding the use of cryptography and, where appropriate, encryption." Article 21(2)(j) requires "the use of multi-factor authentication or continuous authentication solutions... where appropriate" (NIS2 Directive (EU) 2022/2555, Art. 21). Essential and important entities under NIS2 need a vendor that can point to both clauses by number, not one that says "yes, we support MFA" without saying where it's enforced. NIS2's access and cryptography requirements go deeper into what counts as compliant for European organizations specifically.

NIST and sector-specific rules

NIST SP 800-63B-4, covered under Pillar 2, is the authentication-specific standard behind both frameworks' MFA language. It's worth confirming a vendor's default policy actually reflects it, not an older, stricter rotation rule left over from a previous standard.

Sector-specific rules layer on top of these three. Healthcare organizations add HIPAA's security rule, financial entities in the EU add DORA, and public-sector buyers often carry residency requirements none of the above name directly. None of that changes the underlying question to ask a password manager vendor: which article or clause does its architecture satisfy, and is that mapping documented or just asserted?

Pillar 6: Operational resilience, offline access, backups, and deployment model

Security guarantees don't survive contact with a network outage, a lost device, or a vendor's cloud incident unless the vendor built for it. Offline access, a tested backup and recovery process, and a deployment model that doesn't hand every key to one company's infrastructure are what keep a password manager usable, and secure, when something breaks.

Network outages and offline access

Ask what happens when the network drops mid-session. Some products fail closed, locking users out of every credential until connectivity returns. Others offer a scoped, read-only offline mode for records a user has explicitly marked for local, encrypted caching, syncing everything back the moment the connection returns. Read-only is the safer default: create, edit, and delete should require an active, authenticated connection.

Backup and recovery

Backup and recovery is the second half of resilience. Ask how backups are encrypted, who controls the backup infrastructure, and how a full restore is actually tested, not scheduled. A backup that has never been restored in a drill is a hope, not a plan.

Deployment model and infrastructure resilience

Deployment model decides who controls the keys. A fully cloud-hosted vendor holds the infrastructure, even under a zero-knowledge design, meaning uptime and jurisdiction depend on that vendor's cloud region and incident response. Self-hosted and hybrid deployment put the infrastructure, and the choice of where data physically lives, in the customer's hands, which matters most for organizations with data-residency, air-gap, or sector-specific requirements in healthcare, finance, government, or critical infrastructure.

Ask about failure modes at the infrastructure level, too. Redundant application servers and a properly configured database cluster keep a single hardware failure from taking down access entirely. For organizations running fully isolated or air-gapped networks, confirm the deployment functions with no outbound internet connection on an ongoing basis; an offline installer alone doesn't guarantee that.

How Passwork approaches these six pillars

This framework applies to any vendor, Passwork included. Passwork is a self-hosted, zero-knowledge password and secrets manager built for enterprise and DevOps teams. Here's how it answers each of the six pillars above, with links to the same documentation an external evaluator would request.

Encryption architecture: Passwork uses a zero-knowledge, client-side encryption model. Keys are generated and used on the client. The server stores only ciphertext and encrypted key material, encrypted a second time with an independent server-side AES-256 layer on top. Master keys derive through PBKDF2 with a high iteration count, and vault and record data use AES-256 with unique keys per vault and per record, not one organization-wide key.
Authentication and access governance: Passwork supports TOTP, WebAuthn/passkeys, biometric unlock, SAML SSO, and LDAP/AD sync, alongside configurable session timeouts and failed-login lockout thresholds. RBAC runs through unlimited custom roles and groups, with AD group mapping so directory changes flow into vault access automatically instead of waiting on a ticket. Vault-type policies bind corporate administrators to a vault category itself, not to whoever happened to create it, closing the rogue-personal-vault gap that role-level access alone misses.
Audit logging and independent verification: every vault, folder, password, and admin action lands in an exportable activity log, filterable by user, date, and action type, and can feed a SIEM directly. Passwork is ISO 27001 certified and undergoes annual external penetration testing through HackerOne; Passwork's own audit and certification record is the same kind of document this framework asks every vendor to produce, not a claim to take on faith.
Compliance alignment: Passwork's self-hosted deployment keeps data on customer infrastructure, which simplifies data-residency requirements under GDPR and sector rules, and its policy-bound RBAC plus exportable audit logs map to NIS2 Article 21(2) risk-management measures and ISO/IEC 27001 Annex A controls around access management and logging.
Operational resilience: because Passwork runs on the customer's own infrastructure, including air-gapped networks, uptime and backup strategy stay under the customer's control rather than a vendor's cloud incident timeline. Secure offline mode lets users view specifically marked records without a live connection, read-only, with automatic cache expiration and full activity-log sync on reconnect.

Conclusion

None of the six pillars above are exotic. They're the specific documents, questions, and tests that turn a vendor's security page from a claim into something you've actually checked: where the keys live, how MFA and sessions really behave, whether offboarding reaches shared credentials, and whether a ISO 27001 certificate is current rather than aspirational.

Pick the pillar where your current vendor's answer is weakest, and start your next renewal conversation there.

If you're evaluating a password manager, or auditing the one you already have, try Passwork free and run this framework against a zero-knowledge, self-hosted vault built to answer every one of these questions with evidence.

Frequently asked questions

What's the difference between "encrypted" and "zero-knowledge" in a password manager?

Encryption at rest just means data is scrambled on the vendor's servers; the vendor can still hold the keys. Zero-knowledge means the vendor never has the plaintext or the keys to decrypt it. Only the user's client-side key can unlock the vault, even if the vendor's infrastructure is fully compromised.

Does a password manager need to support passkeys to be considered secure?

Not strictly, but passkey and FIDO2 support signals the vendor is keeping pace with current authentication standards. MFA, ideally not SMS-only, is the non-negotiable baseline. Passkeys are increasingly expected on top of it, especially for phishing-resistant sign-in to the vault itself.

What happens to password manager security if the vendor's cloud service goes down?

If the vendor only supports online access, an outage can lock you out of every credential until service resumes. Look for a documented offline or read-only local mode, a tested backup and recovery process, and a deployment option, self-hosted or hybrid, that keeps you in control if the provider's infrastructure fails.

How often should a password manager's security certifications be re-verified?

Certifications such as ISO/IEC 27001 are typically renewed annually. Ask for the current certificate's issue and expiry dates rather than assuming a badge mentioned on a vendor's website is still active; a lapsed certification is easy to miss without checking directly.

What does GDPR or NIS2 actually require from a password manager's architecture?

GDPR Article 32(1)(a)-(b) requires "the pseudonymisation and encryption of personal data" and the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems. NIS2 Article 21(2)(h) and (j) require documented cryptography policies and multi-factor or continuous authentication. Ask a vendor to map its architecture to these specific clauses, not to answer with a generic "yes, we're compliant."

Is a self-hosted password manager more secure than a cloud-hosted one?

Not automatically, but it changes who controls uptime, data residency, and incident response. A cloud-hosted vendor holds the infrastructure even under a zero-knowledge design, so an outage or breach on their end affects you directly. Self-hosted and hybrid deployment keep the infrastructure, and the physical location of the data, in the customer's hands, which matters most for regulated, air-gapped, or data-residency-sensitive environments.

Password manager security features: How to evaluate them

Key Takeaways

Why "it has encryption" isn't a security answer

The password manager security verification framework