An enterprise password manager concentrates the organisation's remaining passwords in one service, and its admin console, recovery mechanism and integrations decide who can get at them. End-to-end encryption protects vault contents from the provider, but the customer still controls who administers the tenant, how lost vaults are recovered, how the directory and identity provider are trusted, which policies apply to exports and devices, and how leavers are handled. Those customer-side settings are where most of the day-to-day risk sits. This guide is for IAM teams, security engineers and the administrators of a workforce password manager. It covers admin roles, recovery, identity integration, the platform's own non-human identities, policies, logging, offboarding and the lifecycle. It is vendor-neutral: confirm exact setting names in your vendor's documentation. For choosing a product, see the Password Manager Buyer's Guide; for rolling it out to users, see the Password Manager Setup Guide.
Key takeaways
- Administrators manage policy, not passwords. The NCSC says administrators should not be able to view or use individual passwords, shared groups being the exception; design roles so that stays true.
- Account recovery is the most powerful feature. Whoever can trigger recovery can often reach a user's vault, so restrict it, require approval and log every use.
- Identity integration moves trust. When vault unlock or provisioning depends on your identity provider or a directory connector, those systems and their keys become part of the vault's security boundary.
- Exports are unprotected files. Disable or tightly restrict export, and audit it.
- Leavers who administered shared items require password changes. The NCSC advises changing every password a departing administrator could see or use.
What the platform holds and can do
Most enterprise password managers share an architecture: client-side encrypted vaults synchronised through a cloud or self-hosted service, an admin console for policy, and integrations with the directory and identity provider. The table describes common components; your product may name or combine them differently.
| Component | What it holds or can do | If an attacker controls it | Primary control |
|---|---|---|---|
| Admin console | Policies, users, groups, shared folder ownership, recovery, reports | Weakens policy, adds themselves to shared folders, triggers recovery | SSO plus MFA, role separation, admin from privileged access workstations |
| Account recovery mechanism | Admin-assisted recovery keys or escrow, or user recovery codes | Access to a user's vault after a reset | Restricted recovery role, approval, alerting, user notification |
| Identity provider unlock (where used) | Vault unlock tied to an SSO sign-in, sometimes with a key service | An identity provider compromise becomes vault access | Phishing-resistant MFA on the identity provider, protected key service |
| Directory or SCIM connector | Provisioning token or connector host with directory read and vault admin rights | Adds users to groups with shared folder access, or blocks deprovisioning | Scoped token, hardened connector host, alerts on group changes |
| Shared folders and collections | Team and service credentials | Broad access through one membership change | Named owners, least privilege, access logging |
| Automation and API access | Tokens for reporting, provisioning or scripted secret retrieval | Bulk reading of shared items | Scoped tokens, expiry, IP restriction |
Stealing credentials from password managers is ATT&CK technique T1555.005 Password Managers. Most of the controls below reduce how far one compromised account, device or integration can reach.
Admin roles and console access
| Role | Can do | Should not do |
|---|---|---|
| Owner or super administrator | Tenant settings, identity integration, other admin roles | Be used day to day; hold more than two or three seats (our suggestion) |
| Policy administrator | Password, MFA, export, device and sharing policies | Manage recovery or shared folder membership |
| User administrator or help desk | Invite, suspend and reinvite users; view status | Perform account recovery without approval |
| Recovery approver | Approve or perform admin-assisted recovery | Approve recovery of their own account or another administrator's without a second person |
| Auditor or reporting | Read event logs and security reports | Change anything |
- Authentication: require MFA on every vault, and phishing-resistant MFA for administrators. The NCSC says MFA should be used on all cloud-synchronised password managers and wherever the manager protects privileged or sensitive accounts. See the Passwordless and Passkeys Guide.
- Separate admin identities: administrators should use a separate admin account or role elevation, not their everyday vault user, where the product supports it. Administer from privileged access workstations. See the Privileged Access Workstations Guide.
- Audit admin access: the NCSC says administrator access should be audited. Send admin events to your SIEM (see logging below).
- Break-glass: keep one owner account outside SSO, with its credentials in a sealed offline process, so an identity provider outage does not lock you out of the tenant. See the Break-Glass Account Guide.
- Review: review admin role assignments every quarter (our recommendation) and on every leaver or role change.
Account recovery
The NCSC treats recovery as optional: weigh the risk of recovery against the cost of a lost vault, understand exactly how recovery works and who can perform it, and note that recovery could be exploited, especially if the provider handles it. It also says nobody, including the provider, should be able to access passwords without the correct decryption key.
- Decide per population: for most staff, admin-assisted recovery prevents lost business credentials. For administrators and holders of highly sensitive items, consider recovery codes held by the user only, or a two-person recovery.
- Restrict who recovers: grant recovery rights to a small named group, not to all help desk staff.
- Verify the requester: recovery requests are a social engineering target. Use the same identity verification you use for MFA resets. See the Passkey account recovery guide for verification patterns.
- Notify and alert: tell the user when their account is recovered and alert the security team on every recovery of an administrator or shared folder owner.
- Re-enrol devices: after recovery, require the user to re-approve devices and rotate their most sensitive items if compromise is suspected.
Identity integration and the platform's own identities
| Identity or secret | Needs | Avoid | Credential pattern |
|---|---|---|---|
| SCIM provisioning token | Create, update and suspend users and groups | No expiry; stored in a shared admin note | Rotated on a schedule; alert on group changes not sourced from the directory |
| Directory connector host (where used) | Read users and groups, call the vault admin API | Running on a general-purpose server or under a personal admin account | Dedicated hardened host, service identity, connector secret in a protected store |
| Identity provider trust (SAML or OIDC) | Sign users in, sometimes unlock vaults | Stale signing certificates, broad app assignment | Signed assertions, assignment to a defined group, alerts on trust changes |
| Key service for SSO unlock (self-hosted options) | Release or derive vault keys after SSO | Hosting on shared infrastructure | Treat as tier 0, restricted admin, monitored |
| Reporting and automation API tokens | Read events or manage users | Tokens that can read vault items when they only need events | One token per integration, minimum scope, expiry |
- Directory integration rules: the NCSC says users should see only their own credentials, integration should use a well-understood open specification, and it must not interfere with the directory's other functions.
- Group-to-folder mapping: if directory groups grant shared folder access, a change to a directory group is a change to who can read those passwords. Alert on membership changes to those groups.
- Inventory them: record each token and connector with owner, scope and expiry. See the SCIM Provisioning Guide and the Service Account Security Guide.
- Keep machine secrets elsewhere: credentials used by applications and pipelines belong in a secrets manager, not in human vaults. See the Secrets Management Guide.
Policies that protect the tenant
| Policy | Suggested setting | Why |
|---|---|---|
| MFA on vault access | Required for all; phishing-resistant for administrators | NCSC: MFA on all cloud-sync managers and where privileged accounts are protected |
| Master password | Length-based policy in line with your password standard, no forced periodic change | NCSC: users must remember it; avoid burdensome rules that push workarounds |
| Export | Disabled for most users; allowed for a named group with audit | NCSC: exported files are unprotected; let administrators disable or audit export |
| Personal vaults | Separate or disabled for work accounts | NCSC: work and home passwords strictly separate; verify cross-vault access is not possible |
| Autofill | Fill only for the exact saved site; user action before fill | NCSC: never offer all stored credentials to any website the user visits |
| Devices and clients | Managed or approved devices only for administrators; supported client versions | Limits where vault data is decrypted |
| Sharing | Shared folders with named owners; hide-password or use-only where available | NCSC: log who accessed a shared password and when, with an authorised person controlling access |
For general password rules, see the Password Security Guide.
Logging, offboarding and the platform's own audit trail
The NCSC lists the events to capture: vault access, passwords viewed or used, new device enrolment, master password resets and failed unlock attempts. Add the admin-side events below.
| Event to capture | Why it matters | Alert? |
|---|---|---|
| Admin role granted, owner added, SSO or identity trust changed | Tenant takeover or persistence (T1078) | Always |
| Account recovery performed | Possible vault access by someone else | Always for administrators and shared folder owners |
| Policy weakened (MFA, export, autofill, devices) | Lowers protection for everyone | Always, with approver |
| Vault export | Unprotected copy of credentials | Always |
| Shared folder membership or permission change | Widened access to team credentials | For folders marked sensitive |
| Many failed unlocks, or new device from an unusual location | Guessing or account takeover (T1555.005) | Against baseline |
| Provisioning token or connector credential changed | Added credentials (T1098.001) | Always |
- Export logs elsewhere: stream events to a SIEM or archive that password manager administrators cannot change, in line with NIST SP 800-53 AU-9(2) and AC-6(9). The CISA and FBI Secure by Demand guide asks SaaS providers to keep security logs available for at least six months at no additional charge. See the Log Management and Retention Guide.
- Offboarding: suspend through SCIM on the leaver's last day, transfer ownership of their shared folders, and use the account overview to find shared items they could reach. When an administrator leaves or changes role, the NCSC advises changing every password they could see or use. We recommend applying the same rule to shared folder members; prioritise privileged and external-facing accounts.
Lifecycle: buy, deploy, run, retire
| Stage | Security actions |
|---|---|
| Buy | Use the NCSC enterprise criteria and the Secure by Demand questions (SSO, MFA by default, logs in the base product, vulnerability disclosure policy, SBOM). See the Password Manager Buyer's Guide. |
| Deploy | Configure owners, break-glass, admin roles, recovery design, policies and log export before inviting users; connect SCIM with a scoped token; pilot with IT first. |
| Run | Quarterly reviews of admins, recovery approvers, tokens and shared folder owners; client version coverage; apply vendor security updates promptly and follow the vendor's security advisories. |
| Respond | If the tenant, an admin account or a connector is suspected compromised, follow the Password Manager Vault Breach Response Playbook: revoke sessions, rotate tokens, review recoveries, exports and policy changes, and rotate exposed credentials by priority. |
| Retire or migrate | Plan migration so exports are created on a managed device, imported promptly and securely deleted; revoke SCIM tokens, connectors and identity provider trusts; confirm data deletion in writing. |
Roll back a policy change that blocks users, such as restricting devices, by widening it for a named pilot group first rather than switching the policy off for everyone.
Detection and measurement
- Number of owners and super administrators (target two or three, our suggestion), all with phishing-resistant MFA.
- Percentage of users with MFA enforced on the vault (target 100%).
- Account recoveries per month, and the share with a recorded approver and verified requester (target 100%).
- Vault exports outside the named export group (target zero).
- Time from leaver event to vault suspension, measured from SCIM logs.
- Shared folders with no current owner (target zero).
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ATT&CK threat addressed |
|---|---|---|---|
| Admin roles and privileged accounts | AC-2, AC-6, AC-6(5) | PR.AA-05 | T1078 Valid Accounts |
| Vault authentication and recovery | IA-5 | PR.AA-01 | T1555.005 Password Managers |
| Provisioning and connector credentials | IA-5, SC-12 | PR.AA-01 | T1098.001 Additional Cloud Credentials |
| Encryption and export control | SC-28, AC-4 | PR.DS-01 | T1555.005 Password Managers |
| Audit log protection | AU-9, AU-9(2), AC-6(9) | PR.PS-04 | T1685 Disable or Modify Tools |
| Provider risk | SA-9 | GV.SC-07 | T1199 Trusted Relationship |
Common failure patterns
- Too many owners: every IT team member gets the top role during rollout and keeps it.
- Help desk recovery without verification: a phone call is enough to trigger admin-assisted recovery of someone else's vault.
- Export left on: users can export everything to a plain file that ends up in downloads folders and backups.
- Directory groups that silently grant folders: a routine directory group change gives a new team access to sensitive shared credentials.
- Stale SCIM token: the provisioning token has no expiry and sits in an admin's notes.
- Leavers without rotation: an administrator leaves and the shared passwords they could see are never changed.
Practitioner checklist
- Limit owners to two or three, separate policy, user, recovery and audit roles, and keep one tested break-glass owner outside SSO.
- Require MFA on every vault and phishing-resistant MFA for administrators.
- Restrict account recovery to named approvers, verify requesters and notify users on every recovery.
- Scope and rotate SCIM tokens, harden any directory connector host and alert on group-to-folder changes.
- Disable export except for a named, audited group.
- Enforce exact-site autofill, separated personal vaults and approved devices for administrators.
- Stream vault and admin events to a SIEM that password manager administrators cannot change.
- Suspend leavers through SCIM, transfer folder ownership and rotate passwords departing administrators could see.
- Plan migration and retirement so exports are short-lived and data deletion is confirmed.
Standards and references
- NCSC: Password manager buyer's guide
- NCSC: Risk manage administration using tiers
- CISA and FBI: Secure by Demand Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: T1555.005 Password Managers
Related NHI Mgmt Group resources: Password Manager Buyer's Guide · Password Manager Setup Guide · Password Security Guide · Securing the PAM Vault Itself