Skip to content

Product1 publisher3 min readPublished

Dashlane's new beta blocks the login form until the employee signs into the vault

Dashlane's answer to employees drifting back to typed passwords is a per-domain block inside the browser extension. The work that decides whether it helps happens upstream, when an admin picks which login pages go on the list.

The Product Desk · Product desk

Illustration accompanying Dashlane's new beta blocks the login form until the employee signs into the vault

What happened

  • Dashlane has put Vault Enforcement into open beta for Omnix Enterprise customers who use Chrome or Edge, with the extension deployed by policy and SSO already enabled.
  • An employee who hits a login form on a domain the admin has marked for enforcement sees a warning webcard on the first day.
  • The next day the same form is blocked until that employee signs in to the Dashlane vault.
  • Dashlane says 37% of corporate applications are not managed by single sign-on, leaving more than a third of the app surface on a username and password.

Compiled by The Product DeskSomething wrong?How this is made

Why it matters

  • decision Switching this on forces an admin to produce an accurate inventory of which apps sit outside the identity provider, because the policy is applied domain by domain and a wrong list either blocks a form nobody needed blocked or leaves the drift untouched.
  • constraint Coverage is capped by browser management: an employee who signs in somewhere the policy extension is not installed stays outside the control, so the security promise is really a fleet-management promise.
  • cost Some of the apps most in need of enforcement are the ones whose vendors charge a premium for SSO, so a password manager block becomes the cheap substitute for buying up a licence tier, and the help desk absorbs the difference.
  • precedent Chambers said he hopes other password managers copy the feature, which points at a market where vendors start competing on how hard their tool is for an employee to avoid.

Month one looks fine. Six months later, according to Bradley Chambers, people are back to typing passwords into forms because nothing actually requires them to use the tool IT deployed [13]. Dashlane calls that the adoption gap. Chambers has been an Apple IT admin since 2009 [14].

The part that lands on an admin is the domain list. Enforcement is scoped to specific domains [1], so someone has to work out which company login pages sit outside the identity provider. Dashlane puts that at 37% of corporate applications [5]. In a portfolio of 100 apps, 63 are covered by SSO and 37 are a username and a password typed into a box [15].

Dashlane's telemetry says the autofilled-password traffic concentrates in Salesforce, DocuSign, Adobe, Zoom, GitHub, Dropbox, Box and Atlassian [6]. That is eight apps [20], and the post does not include the sample the telemetry came from. Chambers gives two causes: the SSO tax, where a vendor charges a premium for the login method [7], and legacy passwords that still work on apps that were integrated with SSO years ago [8]. The second one costs nothing but attention to close.

Between the warning card and the dead form there is one day [16]. Admins can put the company logo and the help desk contact on that card [4]. Dashlane clearly expects the help desk to take the day-two calls, so whoever schedules the rollout should staff for them.

The control itself lives in a policy-deployed extension in Chrome or Edge [9]. A login typed in a browser that does not have that extension is not enforced [17], so coverage stops at the edge of the managed browser fleet. The beta also assumes SSO is already enabled and that you can push extensions by policy [9], which means this is a lever for shops that already run an identity provider and browser management.

"It's also an admission that a decade+ of user education hasn't closed the gap, and that at some point you stop asking and start requiring," Chambers wrote [10]. He also wrote that "Good IT security has to be easier than the workaround" [11]. His passkey example is the same problem from the other side: ask a non-technical employee whether their passkey is in iCloud Keychain, their password manager, or on the device itself, and watch the answer [19]. Users who do not understand a control route around it, and "a security control that gets bypassed isn't a control at all" [12].

Two axes sort the work: whether the app is behind SSO, and whether the login happens in a browser you manage. Outside SSO, inside a managed Chrome or Edge is the box Vault Enforcement covers. Outside SSO and outside the managed browser needs device management first. Behind SSO but with live legacy credentials [8] is also an enforcement candidate, because the old password still works. Behind SSO with those credentials killed needs nothing at all. Only one of the four boxes is a toggle in Dashlane's console; the other three are licence negotiations and MDM work.

What to watch

  • Whether Vault Enforcement moves beyond Chrome and Edge, or onto mobile, when the open beta closes.
  • Whether the feature stays on the Omnix Enterprise plan or drops into lower tiers at general availability.
  • Whether a competing password manager ships a domain-level block, which is the copying Chambers said he hopes for.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories