Dashlane Locked User Accounts After a Brute-Force Attack on Its New-Device-Token Flow

The Dashlane lockout is the protection working as designed; the news is that attackers are now specifically targeting the device-enrollment plumbing — the same recovery-and-onboarding layer that Signal users were phished through two days earlier.

PARIS, FRANCE — On May 31, 2026, password manager Dashlane confirmed that an external party launched a brute-force attack against the token check on its new-device-registration flow, and that the company's automatic protections responded by suspending the affected accounts. Users first realized something was wrong when they received an official Dashlane email saying their account had been temporarily suspended for security reasons, and that someone had attempted to register a new device and failed to enter the correct token after several tries. Dashlane has not publicly quantified how many accounts were targeted; it has said the suspended accounts have been unsuspended and that there is no evidence of compromise of its internal systems.

The incident was reported on June 1, 2026 by Help Net Security and The Register, with Dashlane's own statement reiterated to affected users on social media and via the company's status page. The status was marked resolved on May 31 and changed to monitoring on June 1.

What Happened

Dashlane's automatic protection logic suspended a set of user accounts on May 31, 2026 after detecting repeated failed token entries against the new-device-registration flow — the step a Dashlane user goes through to authorize a new device on their account. The first public signal was an email sent to affected users that read: "Your account has been temporarily suspended for security reasons as someone has attempted to register a new device and didn't enter the correct token after several tries." The message instructed recipients to contact customer support to restore access. Dashlane opened its investigation at 15:19 UTC after users began reporting both the suspension emails and login problems.

Later the same day, Dashlane confirmed that the lockouts were not a malfunction. The company said certain user accounts had been targeted in a brute-force attack by an external party, and that the suspensions were the expected behavior of its built-in security measures. Dashlane has reiterated, on its status page and in direct replies to users on social media, that there is no evidence its systems have been compromised. The company marked the incident resolved on May 31, then moved the status to monitoring on June 1.

The Attack Targeted the Enrollment Layer, Not the Vault

What is notable about this incident is what the attackers chose to attack. They did not target master passwords, and they did not attempt to crack vault data. They targeted the new-device-registration flow — the step that exists so a legitimate user can add a phone, a laptop, or a browser to their account. That flow protects access to the rest of Dashlane by requiring a short token before a new device is trusted. Brute-forcing that token check is an attempt to slip a new attacker-controlled device into an existing account without ever needing the master password. The lockout email Dashlane sent describes exactly that scenario in the operator's own words: someone tried to register a new device and missed the token several times. The account-suspension behavior is the design intent — the system noticing the abuse and refusing to let it continue.

The Lockout Email Is the Protection, Not the Problem

Several users initially assumed the suspension emails were themselves a phishing attempt, which is a reasonable instinct in 2026 but, in this case, wrong. The Register reported that the messages contained no suspicious links or attachments and were sent from a real Dashlane domain; the only friction in the user experience was that the emails arrived before Dashlane publicly explained what was happening, and that the messages used an older Dashlane logo. The honest read is that Dashlane's automated protection fired faster than its public communications did. For anyone who received one of these emails, the verification pattern is the same as for any unexpected security notice from a service that holds high-value credentials: do not click links in the email; instead, open the Dashlane app or navigate to dashlane.com directly, sign in, and check device and notification history from there. If the lockout is real, the support flow on the official site is the way through it.

This Pairs With the Signal Recovery-Key Phishing Wave

Read in isolation, the Dashlane lockout is a single-vendor story with a clean ending. Read against the rest of the week, it is part of a clearer pattern: attackers are targeting the recovery and enrollment plumbing of the apps people trust most. Two days earlier, The CyberSignal covered a Signal recovery-key phishing wave that went after the new online-backup feature — an attack on the recovery construct, not the messaging itself. The Dashlane incident is the same shape on a different surface: an attack on the device-enrollment construct, not the master password. Both target the layer that exists so legitimate users can recover or extend access to an account, which is precisely the layer that, when compromised, gives an attacker durable presence without ever needing the user's primary secret. The defender's mental model has to widen accordingly: it is no longer just the password and the second factor that need protection — it is the entire onboarding and recovery surface around them.

Scope and Impact

Dashlane has not disclosed how many accounts were targeted, how many lockout emails were sent, or where the attempts originated. The Register reported that some users in affected forums said they had separately received unauthorized-login-attempt notifications from locations including Korea and Russia, but Dashlane has not corroborated those reports or attributed the brute-force activity to any specific actor or geography. The company has also not stated whether any new-device registrations actually succeeded against any account before the protections fired, and "no evidence of compromise of Dashlane's systems" is a statement about Dashlane's infrastructure, not a universal guarantee about every individual account.

The wider context for this attack pattern is the one The CyberSignal has tracked through the spring: credential and identity surfaces continue to be where the most determined operators are spending their time. The Verizon DBIR 2026 reported that vulnerability exploitation has just overtaken credential theft as the number-one initial-access method, but credential and identity attacks did not go away — they are evolving toward the auxiliary flows around the password: device enrollment, recovery, and token issuance. Recent campaigns illustrate the shift, including the Tycoon2FA OAuth device-code variant that uses Microsoft's own login page against M365 users and the FBI's Kali365 alert on device-code phishing for Microsoft 365 token theft. The Dashlane incident is the same pattern attacking a different vendor's enrollment plumbing.

Several specifics remain unconfirmed at the time of writing. Dashlane has not characterized the attacker's success rate or the volume of accounts attempted; it has not detailed how attackers were generating or sourcing the candidate device-registration tokens; and it has not described any planned changes to the token format, attempt-rate limiting, or device-enrollment flow itself. The month's other identity-adjacent incidents — including the breaches at Radiology Associates, Docketwise, and Oncology Institute — reinforce that personal-data exposure is at a level that makes credential-and-identity follow-on attacks easier, not harder. Treat the absence of disclosed scope as a reason to be modestly cautious rather than reassured.

Response and Attribution

For Dashlane users who received a suspension email, the immediate step is to verify the message is legitimate before doing anything else. Do not click links in the email. Open the Dashlane app or type dashlane.com into the browser directly and sign in there; from inside the account, check the device list and the security and notification history for any device you do not recognize. If access is still blocked, use the support channel linked from the official site to restore it. After regaining access, review every linked device and remove any you do not recognize, change the master password as a hygienic precaution, and confirm the second factor on your account is still the one you set up. If you reuse any Dashlane-protected credentials elsewhere — you should not, but if you do — rotate them.

For CISOs at organizations that have Dashlane in the environment as the sanctioned password manager, the action list is twofold. First, brief affected employees through your own internal communications channel rather than relying on them to interpret the suspension email correctly; make explicit that the lockout is Dashlane's protection working and that the verification path is to open the app or go to dashlane.com directly. Second, take this as the prompt to audit which password managers are in enterprise use across your organization — sanctioned and shadow — and to confirm that the new-device-enrollment flows in each are using phishing-resistant factors where the product supports them. Where the product supports passkeys or FIDO2 for device enrollment, prefer those over short numeric tokens.

For product and identity teams more broadly, the most useful posture shift the Dashlane incident invites is to treat device-enrollment-token flows as a documented attack surface in their own right. That means rate-limiting attempts per device-token attempt window, alerting on bursts of failed token entries against a single account, expanding the token entropy where it can be expanded without breaking usability, and — over the longer term — replacing short numeric one-time tokens for device registration with FIDO2 or passkey-bound enrollment. The Signal recovery-key phishing wave on online backups from earlier in the week is the same architectural lesson on a different product: the auxiliary flows around the primary credential are now the front line. Dashlane has not named a threat actor for the brute-force activity, and no public reporting has tied it to a known campaign; treat that as a gap to monitor rather than as an absence of intent.

The CyberSignal Analysis

Signal 01 — The Lockout Is the Protection Working

The instinct to read "password manager locks users out" as a failure is understandable but inverted. The Dashlane lockout is the system catching abuse mid-attempt and refusing to complete an action it could not verify was legitimate. The alternative — a lockout that did not happen — is the failure mode: a brute-forced device-registration token succeeds, an attacker-controlled device is silently added to a real user's account, and the user only finds out when the vault is drained. The lesson for vendors is to invest in protections that produce visible, sometimes inconvenient outcomes, and to communicate them in the moment so users can tell the protection apart from a phishing email. The lesson for users is to read the inconvenient security email before forwarding it as suspected phishing.

Signal 02 — The Enrollment Surface Is the New Front

Most discussion of password-manager security focuses on the vault and the master password — the obvious crown jewels. The Dashlane incident is a reminder that the enrollment and recovery flows around the vault are an equally consequential surface, and one that has historically received less hardening. A new-device-registration flow is, by design, a way to extend trusted access to a new endpoint; an attacker who can brute-force the token check is attempting to use that legitimate primitive against the account it was built to serve. The defensive implication is structural: every flow that exists so a user can recover access, add a device, or enroll a new factor is a candidate target, and each one needs the same rate limiting, the same anomaly detection, and the same factor-strength expectations as the primary login itself.

Signal 03 — Pair This With Signal, and Recovery Plumbing Is the Story

The Dashlane attack does not stand alone, and it should not be read alone. Two days earlier, a phishing wave went after Signal users by targeting the recovery-key flow on the new online-backup feature — not the messaging itself, but the layer that lets users get back into the app after a device change. The Dashlane attack is the same playbook against a different vendor's onboarding plumbing. Across both incidents, the through-line is that attackers are no longer just chasing passwords and codes; they are chasing the constructs that exist to help legitimate users recover, extend, or migrate access. For defenders, the practical re-baselining is to audit every such construct in their stack — recovery codes, backup keys, device-enrollment tokens, account-migration flows — with the assumption that someone has already decided to attack it.

Sources