Password Manager vs Secrets Manager: Human Credentials vs Machine Credentials

Production API keys, database passwords and cloud access keys end up in the team password manager because it is already there, everyone can reach it, and it has a sharing button. A password manager and a secrets manager both store credentials encrypted, but they are built for different consumers: a password manager serves a person at a browser or app login, while a secrets manager serves a workload that authenticates with its own identity, reads a secret through an API and should never need a human to copy it. This guide compares the two by consumer, access path, rotation and audit, sets out the threat model and failure modes of each, explains where password manager vendors' machine access features fit, and gives a decision table and a migration path. It is for security architects, platform and DevOps teams and the owners of enterprise password managers. Hardening of each tool is covered in Securing the password manager (enterprise) itself and Securing the secrets manager itself.

Key takeaways

• Decide by consumer, not by sensitivity. If a person types or autofills the credential, it belongs in a password manager. If code, a pipeline or a server uses it, it belongs in a secrets manager, however few people know it exists.
• The access path is the real difference. Password managers are unlocked by a person with a primary password, passkey or SSO; secrets managers authenticate workloads through platform identity, scoped machine accounts or tokens, and deliver secrets through APIs, CLIs and integrations.
• Rotation favours the secrets manager. NIST SP 800-63B says verifiers shall not force periodic password changes on people, while OWASP recommends regular rotation, expiry and dynamic secrets for machines. A shared vault item copied into a CI variable has neither.
• Shared vault items in CI are the classic failure. A credential pasted from a team vault into a pipeline has no owner, no rotation, no record of where it was copied and no way to revoke only that copy.
• Machine access features in password managers are legitimate but scoped. Service accounts, machine accounts and application tokens can feed scripts and pipelines well, provided they are scoped to dedicated vaults or projects, owned, rotated and kept apart from human-shared items.

What each tool is for

Password manager

A password manager stores credentials for people: website and application logins, shared team accounts, recovery codes, and notes. Its strengths are human-facing. NIST SP 800-63B (section 3.1.1.2) requires that verifiers "SHALL allow the use of password managers and autofill functionality" and notes that password managers increase the likelihood of stronger passwords. The NCSC points out that autofill only fills passwords on the correct website, which helps against phishing, and advises turning on two-step verification for the manager itself. Enterprise editions add directory sync, SSO unlock, shared folders, admin policies and event export. See the Password Managers Explained for Everyone Guide.

Secrets manager

A secrets manager stores credentials for workloads: API keys, database credentials, tokens, certificates and encryption material that applications, pipelines and infrastructure read at run time. OWASP's Secrets Management Cheat Sheet frames the job as a lifecycle (creation, rotation, revocation and expiration), recommends dynamic secrets "where possible to reduce the surface area of credential reuse", and says it is "better to limit or remove the human interaction with the actual secrets". The ideal state is that no person ever sees a production secret: the workload authenticates with its own identity and fetches what it needs. See the Secrets Management Guide.

Side-by-side comparison

Threat model, failure modes and a worked scenario for each option

Password manager

Threat model. The attacker targets the person: phishing the primary password or SSO session, stealing an unlocked vault from an infected endpoint, or abusing over-broad sharing. MITRE ATT&CK tracks this as T1555.005 Credentials from Password Stores: Password Managers. The control assumption is that a human is present and can be challenged.

Failure modes. Machine credentials stored as ordinary items and shared with whole teams; the same item copied into scripts, CI variables and configuration files; personal or browser-profile password stores holding service account credentials on work devices; exports left on disk; leavers who saw shared credentials that are never rotated. In the Okta support system breach, credentials for a service account were saved in an employee's personal Google profile in Chrome on a managed laptop, and the response included blocking personal Google profiles on managed devices.

Controls. SSO or passkey unlock with phishing-resistant MFA, admin policies that restrict export and personal vaults, sharing through groups rather than individuals, event export to the SIEM, rotation of shared items when anyone with access leaves, and a rule that workload credentials are not stored as human items. See the Password manager (enterprise) integration security guide.

Decision criteria. Use the password manager when a person logs in interactively: SaaS admin consoles without SSO, shared mailboxes, vendor portals, break-glass credentials kept with split knowledge.

Worked scenario. A finance team shares access to a bank portal that cannot use SSO. The credential lives in a shared folder for the four people who need it, autofill keeps it off sticky notes, the folder's access log shows who used it, and the password changes when one of the four leaves.

Secrets manager

Threat model. The attacker targets the workload and its delivery chain: secrets in source code and files (ATT&CK T1552.001 Credentials In Files), CI/CD variables, build logs, container images, or a stolen machine token that can read more than the workload needs. The control assumption is that no human is in the loop, so identity, scope and expiry must do the work.

Failure modes. A long-lived bootstrap token stored in the pipeline that unlocks every secret (the secret zero problem); policies granted to wide groups of engineers; secrets fetched into environment variables where they leak to logs and child processes; rotation configured but untested so it breaks production and gets switched off; no inventory of which secrets each CI provider holds. After the CircleCI breach, customers were told to rotate every secret stored on the platform, which was only quick for teams that knew what they had stored.

Controls. Workload identity federation instead of stored tokens (GitHub's OIDC integration issues a cloud token "only valid for a single job"), least-privilege policies per workload, managed or dynamic rotation, short leases, audit of every read, and the deployed service fetching its own secrets rather than receiving them through the pipeline, as OWASP recommends. See Environment Variables vs Secrets Manager.

Decision criteria. Use the secrets manager whenever the consumer is code, a pipeline, infrastructure as code, a container platform or an AI agent.

Worked scenario. A deployment pipeline needs a database credential. Instead of a password copied into a CI variable, the pipeline authenticates to the cloud with OIDC, the application fetches a database credential from the secrets manager at start-up using its own workload identity, and the credential is rotated automatically. If the repository is compromised, there is no stored credential to steal.

Machine access features in password manager platforms

A common question is whether you can store API keys in a team password manager. Several vendors now offer separate machine access features that address the workload case. Products are listed alphabetically; listing is not a ranking. Each description comes from the vendor's own documentation as of November 2026.

1Password

1Password service accounts give scripts, CI/CD pipelines and servers access to secrets without a person signing in. Access uses a token "scoped to specific vaults or Environments", the administrator controls which actions the service account can perform, and usage reports show which items it accesses. 1Password recommends service accounts for loading secrets into pipelines instead of a personal account, and documents rotating the token on a schedule or after possible exposure. See the 1Password Security Guide.

Availability: 1Password documents a limit of 100 service accounts, with rate limits and request quotas.

Bitwarden

Bitwarden Secrets Manager is a separate product for machine secrets, built around secrets, projects, machine accounts (non-human users such as applications or pipelines) and access tokens that let a machine account decrypt the secrets assigned to it. The CLI is described as the "primary vehicle for injecting secrets", and an SDK underpins integrations such as GitHub Actions, GitLab CI/CD, Jenkins, Ansible, a Kubernetes Operator and a Terraform provider. Encryption is client-side and the product can be self-hosted. See Bitwarden Security.

Availability: Bitwarden offers Secrets Manager subscriptions for Free, Teams and Enterprise organisations.

Keeper

Keeper Secrets Manager is a component of KeeperPAM for non-human identities and infrastructure secrets. An Application is "a permission boundary that defines which records and folders a workload can access", each client device that authenticates to it has its own unique key, and devices are initialised with one-time access tokens that expire after a set period (24 hours by default). Keeper documents CI/CD integrations including Jenkins and GitHub Actions, and SDKs for common languages. See Keeper Security.

Availability: Keeper suggests sharing no more than 500 records with one Application for performance.

Whichever platform you use, the rule is the same: machine access goes through the dedicated machine feature, scoped to vaults, projects or applications that hold only workload secrets, never through a person's account or a shared human folder. Where the platform supports it, prefer workload identity over a stored token. Detail on token models is in the Akeyless, Doppler and 1Password Machine Access Guide.

Choosing: decision guidance

• Small organisations: a business password manager with a machine access feature can serve both needs at first, provided machine secrets live in dedicated vaults or projects with their own tokens. Move to a cloud or dedicated secrets manager when you need dynamic secrets, workload identity or high request volumes.
• Large organisations: run both, with a published rule for which credential goes where, and an onboarding path from password manager items to the secrets manager when a credential's consumer turns out to be code.
• Privileged human credentials for servers and databases often belong in PAM rather than either tool; see PAM vs PIM and the Privileged Access Management Guide.

How to implement: a phased migration

1. Find machine credentials in human vaults. Use the password manager's admin reporting and event export to list items in shared folders whose names, URLs or fields suggest API keys, tokens, connection strings or service accounts. Interview folder owners.
2. Find copies. Run secret scanning across repositories, CI variables, wikis and chat for those values. See Secrets Scanning vs Secrets Management.
3. Assign owners and consumers. For each credential record the owning team and every workload that uses it.
4. Move one pipeline first. Pilot with a single service: create the secret in the secrets manager, grant read only to that workload's identity, replace the CI variable with federation or a runtime fetch, and confirm deploys succeed.
5. Rotate on move. Issue a new credential when it enters the secrets manager, so every old copy becomes useless. Keep the old credential valid for a short overlap window as the rollback path, then revoke it.
6. Remove the human copy. Delete the vault item or replace it with a note pointing to the secrets manager path and owner.
7. Turn on automated rotation. Use managed rotation where the platform offers it (AWS Secrets Manager, for example, documents managed rotation without a Lambda function for most managed secrets) and test it in non-production first.
8. Write the rule into policy. Add "workload credentials are stored only in the secrets manager" to the secrets management policy and the password manager acceptable use rules.

Detection and measurement

What to monitor:

• Password manager events: exports, mass views or copies of shared items, new shared folders with names that suggest infrastructure, and use of personal vaults on managed devices.
• Secrets manager audit: reads by identities outside the expected workload, reads from unexpected networks, failed authentication bursts, and human identities reading production secrets.
• Machine access tokens: creation, scope changes and age of service account, machine account and application tokens on both platforms.
• Secret scanning alerts in repositories and CI logs that match values held in either store.

See How to measure secret age and rotation coverage.

Common failure patterns

• Shared vault items in CI: a team vault item pasted into pipeline variables in several repositories; when it leaks nobody knows which copy, and rotating it breaks unknown jobs.
• Personal accounts as machine identity: a script signed in to the password manager as an employee, which fails when they leave and grants the script everything they could see.
• Service credentials in browser stores: service account passwords saved in a browser or personal profile on a work device, as in the Okta case above.
• Secrets manager as team vault: engineers granted read on every production path "for debugging", which recreates a shared password vault with an API attached.
• Machine access token as the only secret zero: one long-lived token with access to every project, stored in the CI system it is meant to protect. Scope tokens per workload and prefer federation.
• Rotation without updating consumers: a value changed in the store but not in the target system or the running service, so rotation is disabled after the first outage.

Framework mapping

Practitioner checklist

• Publish a one-line rule: human consumer, password manager; workload consumer, secrets manager; privileged human access to systems, PAM.
• Report on shared password manager items that look like API keys, tokens or connection strings, and assign each an owner.
• Replace every personal account used by a script with a dedicated machine access identity scoped to workload-only vaults or projects.
• Replace stored cloud credentials in CI/CD with OIDC federation where the platform supports it.
• Rotate each credential when it moves into the secrets manager, then remove the human copy.
• Turn on automated or dynamic rotation for database and cloud credentials, tested in non-production first.
• Restrict export and personal vaults in the enterprise password manager and block personal browser profiles on managed devices.
• Send audit events from both tools to the SIEM and alert on human reads of production secrets.
• Rotate shared human items whenever a member of the sharing group leaves.

Standards and references

• NIST: SP 800-63B Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• OWASP: Secrets Management Cheat Sheet
• NCSC: Password managers
• GitHub Docs: OpenID Connect in GitHub Actions
• 1Password: Service accounts
• Bitwarden: Secrets Manager overview
• Keeper: Secrets Manager overview

Related NHI Mgmt Group resources: Secrets Management Guide · Password Manager Buyer's Guide · Secrets Management Buyer's Guide · Environment Variables vs Secrets Manager · Secrets Manager vs KMS vs HSM