Password Manager

Category Description

Password manager software enables individuals and teams to securely generate, store, organize, and retrieve credentials and other sensitive data. The core problem it solves is the tension between security (each account should have a unique, strong password) and usability (humans cannot memorize dozens of unique passwords). A password manager resolves this by requiring the user to remember only a single master credential while the software handles secure storage, cross-device synchronization, and autofill of credentials at the point of use. Beyond passwords, the category has expanded to include secure storage of other sensitive items — notes, payment card details, identity documents — and typically provides tools to assess the overall health and exposure of the credential vault.

Example Implementations

Bitwarden
1Password
LastPass
Proton Pass

Target Audience

This spec is scoped to the individual-user tier of the category. The typical user is a non-technical person — or a technically proficient one — who wants to stop reusing passwords across accounts without having to memorize strong, unique ones. Users access the vault from multiple devices (desktop, laptop, mobile browser) and expect seamless synchronization across all of them. The software is used daily, typically at the moment of logging in to a website or application, so low friction at the point of autofill is a core usability expectation.

Core Requirements

Vault item storage — logins: Users must be able to create, read, update, and delete login items in their vault. Each login item must store at minimum a name, username, password, and one or more associated URLs.
Vault item storage — additional types: Users must be able to store at minimum three item types beyond logins: secure notes (free-form encrypted text), payment card details (card number, expiration, CVV, cardholder name), and identity records (name, address, and other personal identity fields).
Custom fields on vault items: Users must be able to add custom fields to any vault item to store arbitrary key-value data (e.g., security questions, account numbers, PINs) beyond the built-in fields.
Strong password generator: Users must be able to generate random passwords with configurable parameters including length and character set (uppercase, lowercase, digits, symbols). The generator must be accessible both standalone and in-context when creating or editing a login item.
Strong passphrase generator: Users must be able to generate random passphrases composed of multiple words, with a configurable word count and word separator character.
Username generator: Users must be able to generate random or random-word-based usernames for use when creating new accounts.
Browser autofill: The application must provide browser extension(s) for at least two major browsers (e.g., Chrome, Firefox, Edge, Safari) that detect login forms on web pages and autofill the username and password from matching vault items. Matching must be based on the URL of the current page against the URLs stored on each login item.
Auto-capture (save prompt): When a user submits a login form in the browser with credentials not already in the vault, the browser extension must prompt the user to save those credentials to the vault. When credentials already in the vault are submitted with different values, the extension must prompt the user to update the stored credentials.
Cross-device vault sync: Vault items created or modified on one device must be available on all other authenticated devices for the same user within a reasonable sync interval (no more than 30 seconds under normal conditions). Sync must work across web, browser extension, and any mobile or desktop clients offered.
Master password authentication: Users must authenticate to their vault using a master password. The master password must never be transmitted to or stored by the server in a recoverable form. All vault encryption and decryption must occur client-side using a key derived from the master password.
End-to-end encryption: All vault data must be encrypted before it leaves the client. The server must store only ciphertext and must not have the ability to decrypt vault contents. The encryption algorithm used must be AES-256 or equivalent strength.
Two-factor authentication (2FA) for vault login: Users must be able to enable a second factor for vault login using at minimum an authenticator app (TOTP/RFC 6238). Once enabled, the second factor must be required on every new device login.
TOTP authenticator code generation: Users must be able to store a TOTP authenticator key (secret seed) on any login item and have the application generate the current time-based one-time code (RFC 6238) for that item. The generated code must update automatically every 30 seconds and must be easily copyable to the clipboard. This feature enables the password manager to serve as an authenticator app for the user's third-party accounts.
Vault item search and filtering: Users must be able to search across all vault items by name, username, URL, and note content. Users must also be able to filter vault items by type (logins, cards, notes, identities).
Folders for organization: Users must be able to create, rename, and delete personal folders and assign vault items to one or more folders. Folder membership must be reflected in the vault item list view.
Password history for a vault item: For any login item, users must be able to view a list of previously saved passwords for that item, including the date each password was last used. This history must be stored automatically whenever a password is changed. Viewing history must not require manually creating a snapshot; restoration of a prior password from history is not required.
Vault health reports — weak passwords: The application must identify and surface vault items that have passwords that are weak (e.g., too short, lacking complexity) and present them in a report view.
Vault health reports — reused passwords: The application must identify and surface vault items that share the same password across multiple entries and present them in a report view.
Data breach exposure check: The application must allow users to check whether their stored passwords or email addresses have appeared in known public data breaches (e.g., via integration with Have I Been Pwned or a comparable breach database). Results must indicate which specific vault items are affected.
Vault data export: Users must be able to export all vault items in at least one portable, human-readable format (e.g., CSV or JSON) for backup or migration purposes. Exports must include all item types, not only logins.
Vault data import: Users must be able to import vault data from at least one common external format (e.g., CSV, or the export format of a major competing password manager). Items must be mapped to the correct item types on import.

Cross-Cutting Requirements

Multi-tenancy: The application must support multiple independent organizations (tenants), each with isolated data.
Authentication: Users must authenticate with email/password at minimum. SSO and OAuth are not required.
Data persistence: All user data must be persisted across sessions in a database.
Web application: The application must be accessible via a web browser. Native desktop or mobile applications are not required.
Concurrent users: The application must support multiple users within the same tenant using the application simultaneously without data corruption or loss.
Responsive design: The web application must be usable on both desktop and mobile browsers. A native mobile app is not required.

Scope Boundaries

Secure credential sharing within an organization is not required. The ability to share vault items with other users via shared collections or vaults is explicitly out of scope for this spec. It represents a distinct tier of the product with significant additional implementation complexity (shared encryption keys, permission models, member management) and is treated as a separate category.
Organization admin console is not required. A dedicated interface for inviting and managing members, assigning roles, and administering shared collections is out of scope for the same reason.
Role-based access to shared collections is not required. Granting and revoking per-user or per-group access to shared credential collections is out of scope.
Encrypted file attachments are not required. Attaching files (e.g., scanned documents) to vault items and storing them in encrypted form is a paid feature in most products.
Emergency access / digital legacy is not required. The ability to designate a trusted contact who can request access to the vault in case of emergency or death is a premium feature in most products.
Single sign-on (SSO) integration is not required. Allowing users to unlock the vault using a corporate identity provider (e.g., Okta, Entra ID, Google Workspace) is an enterprise-tier feature.
SCIM provisioning / directory sync is not required. Automated user provisioning and deprovisioning from an external directory is an enterprise feature.
Event / audit logs are not required. Detailed per-event logs of user or admin actions for compliance and forensics are a paid team/enterprise feature and are also out of scope as an organizational feature.
User groups are not required. The ability to create named groups and assign collection access to groups is an organizational feature and out of scope.
Admin security policy enforcement is not required. Organization-wide enforceable policies (e.g., minimum master password length, required 2FA) are an organizational and enterprise feature and out of scope.
Self-hosting is not required. The option for customers to run the server infrastructure themselves on their own infrastructure is offered by only some products (e.g., Bitwarden) and is not table stakes.
Native desktop applications (Windows, macOS, Linux installable apps) are not required. The web application and browser extensions satisfy the access requirement.
Native mobile applications (iOS, Android) are not required. Responsive web access satisfies the access requirement.
Email alias generation and management is not required. Built-in creation and management of privacy-preserving email aliases (e.g., hide-my-email) is a differentiating feature of some products (e.g., Proton Pass) but is not universal.
Dark web monitoring / real-time breach alerting is not required. Proactive, continuous monitoring that pushes alerts when new breaches are detected is a premium feature; the core breach check requirement above covers the basic on-demand version.
VPN bundling is not required. Bundling a VPN service with the password manager is specific to one product family and not a category expectation.
Secrets manager / developer secrets (API keys, SSH keys, environment variables managed separately from the personal vault) is not required. Developer-facing secrets management is an adjacent product category.
Travel mode (temporarily hiding sensitive vaults when crossing borders) is not required. This is a differentiating feature of one product and not a category expectation.
Passkey storage and autofill is not required. While passkey support is emerging across the category, it is still inconsistently available and is not yet universal table stakes.
Biometric unlock for vault access (fingerprint, Face ID) is not required, as this is dependent on native app or OS-level integration that the web-only requirement does not mandate.
White-labeling or custom branding of the admin interface is not required. This is an enterprise-tier feature.
MSP / multi-account management (managing multiple customer organizations from a single parent account) is not required. This is an enterprise and reseller feature.

Spec Metadata

Version: 1.1
Created: 2026-03-17
Last Updated: 2026-03-17
Status: Draft