Summary and recommendation
Keeper user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Keeper is an enterprise password manager built on a zero-knowledge architecture, meaning no administrator - and no Keeper employee - can read vault contents. User and group management lives in the Admin Console at https://keepersecurity.com/console.
Permissions are entirely role-derived: there is no built-in admin user type, and every capability an admin or end user has flows from the enforcement policies attached to their assigned role. Every app that depends on shared credentials is only as accessible as the role and team assignments backing it.
Quick facts
| Admin console path | Admin Console → Users (left sidebar) for user management; Admin Console → Roles for permission management |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full access to Admin Console: manage users, roles, teams, nodes, enforcement policies, provisioning, reporting, and billing. Can transfer vault records from departing users. | Cannot access other users' vault contents directly due to zero-knowledge architecture; cannot decrypt user vault data without an account transfer policy pre-configured. | Business Starter, Business, or Enterprise | Consumes a licensed seat | Admin privileges are granted via a Role with 'Manage Users' and related node permissions enabled. There is no single built-in 'Admin' user type; permissions are role-derived. At least one admin must exist per node. |
| Delegated Administrator | Admin rights scoped to a specific node (sub-unit) of the organization. Can manage users, teams, and roles within their assigned node only. | Cannot manage users or settings outside their assigned node. Cannot access root-level billing or enterprise-wide reporting. | Business or Enterprise | Consumes a licensed seat | Delegated admin capability requires node-based organizational structure. Business Starter does not support delegated administration. |
| Standard User | Access to personal vault and any shared folders/teams they are a member of. Can use Keeper desktop, mobile, and browser extension clients. | Cannot access Admin Console. Cannot manage other users, roles, or enterprise settings. | Business Starter, Business, or Enterprise | Consumes a licensed seat | User capabilities (e.g., ability to export vault, share records outside the organization, use personal vault) are controlled by enforcement policies attached to their role, not by user type itself. |
| Managed Company Admin (MSP context) | MSP-level admins can manage multiple tenant companies, provision licenses, and push policies across managed companies. | Scoped to MSP console; cannot access end-user vaults due to zero-knowledge model. | Enterprise (MSP/Distributor agreement required) | Consumes a seat within the MSP admin allocation | Only available under Keeper's MSP program; not a standard Enterprise feature. |
Permission model
- Model type: role-based
- Description: Keeper uses a role-based access control (RBAC) model. Roles are containers for enforcement policies (restrictions on user behavior) and admin permissions (what admins can manage). Users are assigned to one or more roles. Roles are applied at the node level, and nodes represent organizational units. Enforcement policies control behaviors such as whether users can export records, use two-factor authentication requirements, allow/deny browser extensions, etc.
- Custom roles: Yes
- Custom roles plan: Business and Enterprise (Business Starter has limited role customization)
- Granularity: Granular: ~50+ individual enforcement policy settings per role covering vault behavior, device access, sharing, two-factor authentication, account transfer, and more. Admin permission grants are also per-role and per-node.
How to add users
- Log in to the Keeper Admin Console at https://keepersecurity.com/console
- Navigate to the 'Users' section in the left sidebar
- Click 'Invite Users' or 'Add User'
- Enter the user's email address
- Optionally assign the user to a specific node (organizational unit)
- Optionally assign the user to one or more roles and/or teams at invite time
- Click 'Send Invite' - the user receives an email invitation to create their Keeper account
- User accepts the invitation, sets a master password, and their account becomes active
Required fields: Email address
Watch out for:
- Users are not fully provisioned until they accept the email invitation and complete account setup. They appear as 'Invited' status until then.
- If SSO is enforced for the node, users must authenticate via the configured IdP and may not set a master password.
- Assigning a role at invite time is optional but recommended; users without a role assignment inherit the default node role if one is configured.
- Keeper uses a zero-knowledge model: the admin never has access to the user's master password or vault encryption key.
- Account Transfer Policy must be enabled on a role before a user accepts their invite for vault transfer to work on offboarding; it cannot be retroactively applied to existing accounts without user re-acceptance.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Yes | Admin Console → Users → Import Users (CSV upload). Required CSV columns: Email. Optional columns: Name, Node, Role, Team. |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (SCIM 2.0 supported with Okta, Azure AD/Entra ID, Google Workspace, JumpCloud, and others) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Keeper supports both locking (deactivating) and deleting users. Locking a user prevents login but retains their account and vault data within the enterprise. Deleting a user permanently removes their account. Before deletion, admins should transfer the user's vault records using the Account Transfer feature; once deleted, vault data is unrecoverable due to zero-knowledge encryption.
- Log in to the Keeper Admin Console at https://keepersecurity.com/console
- Navigate to 'Users' in the left sidebar
- Locate the user by name or email
- Click on the user to open their detail panel
- Select 'Lock User' to deactivate (prevents login, retains data) OR select 'Delete User' to permanently remove
- If deleting, first use 'Transfer Account' to move vault records to another admin or designated user (requires Account Transfer Policy to have been pre-enabled on the user's role)
- Confirm the action
| Data impact | Behavior |
|---|---|
| Owned records | Vault records owned solely by the deleted user are permanently lost unless Account Transfer Policy was enabled on their role prior to account creation/acceptance. If enabled, records can be transferred to a designated admin or user before deletion. |
| Shared content | Records shared with teams or other users via shared folders remain accessible to those other members. The deleted user's ownership of those shared records may transfer or the records may remain in the shared folder depending on configuration. |
| Integrations | Any API keys or Keeper Secrets Manager (KSM) application tokens associated with the deleted user's account will be invalidated. Service accounts using the deleted user's credentials will lose access. |
| License freed | Deleting a user frees their licensed seat, which becomes available for reassignment. Locking a user does NOT free the seat - the seat remains consumed until the user is deleted. |
Watch out for:
- Account Transfer Policy must be configured on the user's role BEFORE the user accepts their invitation. It cannot be retroactively applied, meaning vault data for users who joined before the policy was enabled cannot be transferred by admins.
- Locking a user does not free a license seat; only deletion frees the seat.
- Due to zero-knowledge encryption, Keeper support cannot recover vault data for deleted users.
- Shared folder membership is separate from vault ownership; deleting a user removes them from teams and shared folders but does not delete the shared folder contents.
- Admins should revoke any active SSO sessions or device approvals before or immediately after locking/deleting a user.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Business Starter Seat | Basic vault access, limited admin controls, up to 10 users, basic sharing | $2/user/month (billed annually) |
| Business Seat | Full vault access, delegated admin, team management, basic SSO, advanced sharing, 10+ users | $3.75/user/month ($45/user/year, billed annually) |
| Enterprise Seat | All Business features plus SCIM 2.0 provisioning, advanced SSO (Keeper SSO Connect), compliance reporting, SIEM integration, custom enforcement policies, KeeperPAM add-on eligibility | Custom pricing (~$60/user/year for 100+ users; volume discounts available) |
- Where to check usage: Admin Console → Admin (top menu) → Reporting & Alerts → License Usage; or Admin Console → Users to see count of Active, Invited, and Locked users
- How to identify unused seats: In Admin Console → Users, filter by 'Last Login' date to identify users who have not logged in recently. 'Invited' status users who have never accepted their invitation can also be identified and removed to free seats.
- Billing notes: Seats are billed annually. Adding users mid-cycle is prorated. Locking a user does not reduce seat count; only deleting the user frees the seat. Volume discounts apply at 100+, 250+, and 500+ user thresholds. Multi-year discounts available (approximately 20% for 2-year, 30% for 3-year commitments). Enterprise pricing is negotiated directly with Keeper sales.
The cost of manual management
Manual provisioning in Keeper means inviting users one at a time by email, then separately assigning them to nodes, roles, and teams. Bulk imports via CSV are available on Business plans, but role and team assignments still require follow-up steps in the console.
SCIM automation is gated to Enterprise, so Business plan customers carry the full weight of this process indefinitely.
What IT admins are saying
The most consistently reported pain point is the Account Transfer Policy window: it must be enabled on a user's role before that user accepts their invitation.
Admins who miss this step have no path to recover vault data for departed employees - Keeper's zero-knowledge model makes that loss permanent. A secondary frustration is seat billing: locking a user prevents login but does not free a license seat.
Only a full deletion does, and deletion without a pre-configured transfer policy risks losing shared credentials.
Common complaints:
- Account Transfer Policy must be set up before a user accepts their invite; admins who miss this step cannot recover vault data for departed employees, which is a common operational pain point reported by IT administrators.
- Locking a user does not free a license seat, which surprises some admins who expect deactivation to reduce billing.
- The zero-knowledge model, while a security feature, means Keeper support cannot assist with data recovery for deleted or inaccessible accounts, frustrating admins in offboarding scenarios.
- Some administrators report that the node/role structure has a learning curve, particularly for organizations migrating from simpler password managers without hierarchical org structures.
- SCIM provisioning is restricted to Enterprise plan, leaving Business plan customers reliant on manual or CSV-based provisioning for bulk user management.
The decision
Manual management is workable for small, stable teams where offboarding is infrequent and the Account Transfer Policy is configured from day one. Every app whose credentials live in Keeper becomes a recovery risk the moment an offboarding step is missed, because the zero-knowledge architecture makes those mistakes irreversible.
The node and role structure also carries a learning curve for teams migrating from flat-permission password managers. If your headcount or churn rate is growing, the operational ceiling on manual management arrives quickly.
Bottom line
Keeper's manual administration is precise but unforgiving. The zero-knowledge architecture that makes it secure also means every procedural gap - a missed transfer policy, a locked-but-not-deleted user, a role assigned after invite acceptance - has consequences that cannot be undone by support.
Teams that invest in configuring roles, nodes, and transfer policies correctly before onboarding their first user will find the console capable and auditable. Teams that don't will encounter the sharp edges of that architecture at the worst possible moment: during offboarding.
Automate Keeper workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
