A Dashlane business plan holds the shared logins, secure notes and secrets of a whole organisation, so the admin policies, SSO configuration, recovery settings and API credentials around it decide how well that vault is protected. This guide explains how to run a Dashlane professional plan securely, using Dashlane's own security page, Help Center and CLI documentation as the source for every product detail (checked 8 November 2026). It covers the encryption model, Confidential SSO and SCIM provisioning, admin and Group Manager roles, admin-assisted account recovery, the Policies tab, sharing controls, the public API and CLI keys, the Activity Log and a hardening baseline. It is for identity teams, security engineers and IT administrators who own a Dashlane tenant. These are customer-side settings in a shared responsibility model: Dashlane runs the service, and you decide how it is configured. For the wider discipline see the Secrets Management Guide.
This is an independent guide from NHI Mgmt Group, based on Dashlane's public documentation as of November 2026. It is not sponsored or reviewed by Dashlane. Product features change, so confirm settings against Dashlane's current documentation.
Key takeaways
- Policies apply to everyone, admins included. Dashlane states that changes on the Policies tab affect all members, so test each one with a pilot group before switching it on for the plan.
- Choose Confidential SSO deliberately. It is the setup path for new plans (self-hosted SSO closed to new setups after October 2025), and a plan cannot move from Confidential back to self-hosted.
- Admins keep a Master Password. Even with SSO on, admins sign in with a Master Password, and admin recovery needs a second admin, so keep at least two named admins at all times.
- Treat API and CLI keys as privileged credentials. Public API keys stay valid until revoked and CLI keys can last up to 12 months, so store them in a vault Secret, record an owner and rotate them on a schedule.
- Turn on Additional activity logs early. Vault item and sharing events are recorded only from the day the policy is enabled, and the Activity Log keeps 15 months, so stream it to your SIEM for longer retention.
How identity and access work in Dashlane
Dashlane describes its design as zero-knowledge: vaults are encrypted and decrypted on members' devices, and only members hold the keys. Its security page lists AES-256 in CBC mode with HMAC for confidentiality and integrity, and Argon2d for password stretching with 3 iterations, 32 MB of memory and 2 threads. When a member signs in on a new device, that device generates its own 40-byte device key, which needs explicit verification and is kept separate from the vault encryption key. The practical point for administrators is that authentication (who the member is) and the keys that open the vault are handled as separate steps.
Sign-in models
| Model | How members sign in | What Dashlane documents | Admin considerations |
|---|---|---|---|
| Master Password | Member's Master Password, plus 2FA on new devices when the Enforce 2FA policy is on | Cryptography policy can enforce a key derivation function for the plan | Pair with Enforce 2FA and admin-assisted recovery so members are not locked out |
| Confidential SSO | Work credentials through a SAML 2.0 identity provider; the encryption service runs in secure enclaves (AWS Nitro Enclaves) | Requires Password Management or Credential Protection; Okta, Entra ID, JumpCloud, PingID, AD FS, Google Workspace and Duo listed | Set up before inviting members so they never create a Master Password; admins still use a Master Password |
| Self-hosted SSO (existing plans) | SAML through an encryption service the customer runs in Azure or AWS | No new setups after October 2025; existing configurations continue | Keep the encryption service patched and its hosting account locked down; plan a move to Confidential when convenient |
Decision guidance: for a new deployment, Dashlane recommends Confidential SSO for its simpler setup, and it is the only option now offered. Small teams without an identity provider can run on Master Passwords with Enforce 2FA, Cryptography and admin-assisted recovery. Larger organisations with an identity provider gain central joiner and leaver control through SSO and SCIM. If you rely on Microsoft Conditional Access for mobile devices, check the mobile Conditional Access note on Dashlane's SSO setup page (as of November 2026) and enforce mobile access requirements through your device management controls.
SSO configuration details
- Where: Admin Console, Integrations, Single sign-on. You add the Entity ID and Assertion Consumer Service URL to a SAML application in your identity provider, then upload its metadata.
- Domains: verify every domain you own on the Domain Management page. Dashlane documents a TXT record for verification.
- Entity ID: from extension version 6.2551 (January 2026) a unique Entity ID lets one identity provider manage several Dashlane domains. Earlier setups can migrate through Integrations, Single sign-on, Edit, Migrate, then replace the Entity ID in the identity provider.
- Certificates: when you renew the SAML signing certificate, the metadata you paste back must contain only one certificate. Delete the inactive certificate first, test the connection, then ask a member to test a login.
- Conversion: once SSO is enabled, non-admin Master Password members are moved to SSO at their next login. Admins usually cannot test SSO with their own admin accounts, so keep a test member account.
- Email changes: an email change in the identity provider is not carried into Dashlane automatically, so add it to your change process.
See the SAML Security Guide for identity provider side controls.
Provisioning with SCIM
Confidential SCIM provisioning is documented for Entra ID (Azure), Okta, JumpCloud and PingID. Google Workspace uses SAML group sync, and Duo syncs through its connected identity provider. Where SCIM is not available, just-in-time provisioning creates the account at first SSO login once the user is assigned to the Dashlane SAML application. Dashlane notes that groups created inside Dashlane are separate from SCIM groups, so pick one source of truth for each group. See the SCIM Provisioning Guide.
Admin roles and privileged access
The Admin Console is available only to admins. Dashlane documents these roles and functions on a professional plan.
| Role | Powers documented by Dashlane | Hardening note |
|---|---|---|
| Admin | Full Admin Console: members and groups, policies, integrations (SSO, SCIM, SIEM, extension deployment), Developer Access, Activity Log, account recovery approvals, 2FA recovery codes, promotion of members to admin or Group Manager | Two or three named people; each with a strong Master Password and 2FA |
| Group Manager | Delegated management of groups | Use for team leads who organise sharing groups, instead of granting admin |
| Billing contact | Subscription only: invoices, payment method, seats and upgrades | Give finance this function rather than admin |
| Member | Own vault plus items shared with them | The default for everyone else |
Protecting admin accounts
Because admins continue to use a Master Password under SSO, the admin account is the one place where a long, unique passphrase and strong second factor matter most. Dashlane advises keeping at least two admins in case one forgets their Master Password, and if the only admin resets their account they must contact Dashlane support to regain access. Record admins in your privileged access inventory and review the list each quarter. See SaaS Admin Account Protection.
Admin-assisted account recovery
Admin-assisted recovery is on for the plan by default; each member acknowledges a message to activate it for their account. When a member forgets their Master Password, they request recovery, and an admin accepts or rejects it under Activity Log, Account Recovery Requests. Dashlane describes the process as zero-knowledge: the admin never sees the member's data or Master Password, and the member sets a new Master Password and reauthorises their devices afterwards. Several documented rules shape how you govern it:
- Verify identity first: Dashlane recommends confirming the member's account email before approving. Add an out-of-band check, such as a call to the member's manager.
- Timing rule: an admin can approve only if they became an admin before the member's most recent successful login.
- No self-approval: admins cannot approve their own requests, so admin recovery needs a second admin.
- Pending requests stay open: requests remain until acted on, and the feature cannot be switched off while one is pending, so review the queue regularly.
- SSO members: members who sign in with SSO recover through their identity provider password instead.
Members can also hold an account recovery key, or use biometric recovery on mobile. If an admin generates 2FA recovery codes for a member who lost their authenticator, treat that as a sensitive event and log the reason.
Integrations, API tokens and service accounts
Dashlane exposes two machine access paths, both under Integrations, Developer Access, and both created only by admins.
| Credential | Access | Lifetime | Handling |
|---|---|---|---|
| Public API key (bearer token) | Read-only: Members, Members Device, Password Health and Team Status endpoints; vault data is out of scope | Valid until revoked | Shown once; save it in a vault Secret immediately; issue one key per connected tool; revoke and reissue if exposure is suspected |
| CLI key (DASH_EDWSA_ prefix) | Team commands in the Dashlane CLI, with scopes chosen at creation | Expiry set by the admin, up to 12 months | Supplied through the DASHLANE_ENROLLED_TEAM_DEVICE_KEYS environment variable; choose the narrowest scopes and shortest practical expiry |
Practical controls for these keys:
- Inventory: list every key, its name, owner, purpose and creation date in your secrets register. Keep this record yourself as part of change control, so every key has an accountable person.
- One key per integration: Dashlane recommends generating a new API key for each new third-party tool, which keeps revocation targeted.
- Store safely: keep keys in a managed secret store or a Dashlane Secret, never in scripts, tickets or chat. Inject the CLI variable at runtime on the host that pulls logs.
- Rotate: set a rotation interval for API keys (for example every 6 or 12 months) and when an admin or integration owner leaves; CLI keys rotate naturally at expiry.
- Revoke: remove unused keys from the Developer Access page or the CLI.
The SIEM and Splunk integrations, the identity provider SAML application and the SCIM token are also machine trust paths. Review them with the same owner and rotation discipline. See the API Key Management Guide.
Logging and detection
The Activity Log has two tabs, Activity and Account Recovery Requests. It covers company account changes, member and device activity, member and group management, Collections, billing, account recovery, 2FA, SSO, extension deployment, SCIM provisioning, the Splunk integration, the public API, the CLI and shared links with non-Dashlane users. Activity is kept for 15 months and can be filtered and exported as CSV. On plans with Spaces, logging covers actions on Business Space items.
Turn on Additional activity logs in Policies (not on the Standard plan) to add vault item events (add, edit, delete, copy or reveal), sharing events, autofill and Password Health events. These start from the day the policy is enabled. For longer retention and correlation, stream logs to your SIEM through the documented integrations, or pull them with dcli t logs on a schedule, using --start set to the last pull time and writing JSON lines to a file your SIEM agent watches. Sensitive event types such as copy events appear only when sensitive action logging is enabled.
| Event to alert on | Why it matters | Suggested response |
|---|---|---|
| Member promoted to admin or Group Manager | Expands control of the plan or of sharing groups | Confirm against an approved change |
| Policy turned off (Enforce 2FA, Allow Export on, sharing outside company on) | Changes the baseline for every member | Page the plan owner; revert if unapproved |
| SSO or SCIM configuration edited | Changes who can sign in and how accounts are created | Verify with the identity team the same day |
| Public API or CLI key created or revoked | New machine access to plan data | Match to a ticket and secrets register entry |
| Account recovery request approved, or 2FA recovery codes generated | Changes how a member gets into their vault | Confirm the member requested it through a second channel |
| Shared link created for a non-Dashlane user | Data leaving the plan boundary | Check the item, recipient and expiry |
Metrics that show it is working: percentage of members on SSO or with 2FA enforced; number of admins (target two or three); API and CLI keys with an owner and rotation date (target 100 percent); days since last access review; Password Health score trend from the Insights Dashboard; median time to act on recovery requests.
Hardening baseline
Most of these settings are on the Policies tab. Plan names follow Dashlane's documentation, and some policies depend on plan tier.
| Setting | Recommended value | Notes from Dashlane docs |
|---|---|---|
| Enforce 2-factor authentication | On | Applies to Master Password users on new devices |
| Cryptography | Enforce the plan's chosen key derivation function | Lets admins enforce a KDF instead of member choice |
| Allow Export | Off (the default) | Turn on for named cases only |
| Automatically log out members if inactive | 15 or 30 minutes | Options 15, 30 or 60 minutes; not on Standard |
| Auto-lock on exit | On | iOS and Android |
| Additional activity logs | On | Not on Standard; no backfill |
| Restrict Dashlane access to verified domains | On where Credential Protection is in use | Requires at least one verified domain |
| Move company items to Business Space | On, with Business Space domains defined | Members cannot move company items out; exports limited to Personal Space |
| Revoke access to company items for removed users | On | Removes Business Space logins at offboarding |
| Allow sharing outside the company | Off (the default) | Link sharing also stays off while this is off |
| Turn off autofill on listed sites | Add high-risk admin portals or internal IPs as needed | Not on Standard; members log out and in to apply |
Rollout order
- Prepare: verify domains, name two or three admins, set billing contacts, and decide SSO or Master Password.
- Configure SSO and SCIM before invitations so members never create a Master Password, then test with a member test account.
- Pilot policies (Enforce 2FA, Cryptography, inactivity logout, Business Space) with a small group, collect feedback for one to two weeks, then apply to the plan. Roll back by toggling the policy off; review the Activity Log entry.
- Turn on logging (Additional activity logs, SIEM stream or scheduled CLI pull) before migrating shared credentials, so history starts early.
- Migrate shared credentials into groups and Collections owned by named teams.
- Operate: quarterly review of admins, groups, keys and outside sharing.
Apply Dashlane app and extension updates promptly and follow the vendor's security notices through the Dashlane security page. For a non-technical rollout plan for staff, see the Password Manager Setup Guide.
Framework mapping
| Control area | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| SSO, 2FA and Master Password policy | PR.AA-01, PR.AA-02 | IA-2, IA-5 | 6 | A.5.17, A.8.5 |
| Admin roles and least privilege | PR.AA-05 | AC-2, AC-6 | 5, 6 | A.5.15, A.8.2 |
| Vault encryption and export control | PR.DS-01 | SC-28 | 3 | A.8.24 |
| Activity Log and SIEM | PR.PS-04, DE.CM-03 | AU-2, AU-6, AU-11 | 8 | A.8.15, A.8.16 |
Common misconfigurations
- A single admin: one admin means no one can approve that admin's recovery request. Keep at least two, as Dashlane advises.
- Inviting members before SSO: members then create Master Passwords that must be converted later. Configure SSO first for new plans.
- Additional activity logs turned on late: vault and sharing events start only from the enable date, so an investigation may find no history. Enable it on day one.
- Keys without owners: an API key created for a reporting tool and left in a script for years. Store it in a Secret, record an owner and rotate it.
- Outside sharing switched on for convenience: turning on sharing outside the company also allows link sharing for non-Dashlane users. Keep it off, or review links in the Activity Log weekly.
- Recovery approved on email alone: approving a recovery request without a second check. Add a manager or helpdesk call-back step.
- Identity provider email changes not carried over: a renamed user ends up with a mismatched account. Include Dashlane in the rename runbook.
Practitioner checklist
- Verify all company domains and configure Confidential SSO and SCIM before inviting members.
- Keep two or three named admins with strong Master Passwords and 2FA; use Group Manager and billing contact for delegated tasks.
- Turn on Enforce 2FA, Cryptography, inactivity logout and Additional activity logs after a pilot.
- Keep Allow Export and sharing outside the company off unless a documented exception exists.
- Define Business Space domains and revoke company items for removed users.
- Add an out-of-band identity check to every account recovery approval.
- Inventory public API and CLI keys with owners, scopes and rotation dates; store them in a vault Secret.
- Stream Activity Log events to your SIEM and alert on admin, policy, SSO and key changes.
- Review admins, groups, keys and shared links every quarter.
Standards and references
- Dashlane: Security
- Dashlane Help Center: Admin Console Policies
- Dashlane Help Center: Set Up SSO and SCIM
- Dashlane Help Center: Admin-Assisted Account Recovery
- Dashlane Help Center: Dashlane Public API
- Dashlane Help Center: Explore the Activity Log
- Dashlane CLI: Business Commands
- NIST: SP 800-63B Digital Identity Guidelines, Authentication
Related NHI Mgmt Group resources: Secrets Management Guide · Password Manager Setup Guide · SAML Security Guide · SCIM Provisioning Guide · SaaS Admin Account Protection