Key facts
- Between August 4 and August 21, 2026, an attacker used a defect in Lenovo's ID registration to sign into roughly 5,000 Dropbox accounts without a password.
- Dropbox has said that every affected account had two-factor authentication turned off, and that files were viewed or downloaded in fewer than a third of the accounts.
- Under Regulation S-P, a client statement in a personal cloud account is still customer information handled on the firm's behalf, and the cloud provider holding it is a service provider.
- An SEC-registered adviser has no later than 30 days from becoming aware of likely unauthorized access to notify affected clients, and only its own documented investigation can conclude that notice is not required.
- NIST's digital identity guidelines have treated text-message codes as a restricted authenticator since 2017; an authenticator app or a hardware security key is the standard to aim for.
- Dropbox Business, Microsoft 365, Google Workspace, and Box all let an administrator require two-factor authentication for every account in the firm.
Between August 4 and August 21, 2026, an attacker signed into roughly 5,000 Dropbox accounts. No password was needed. No access to the victim's inbox was needed. Several of the people who received Dropbox's letter had never heard of the login path that was used against them.
And Dropbox says every one of those accounts had two-factor authentication switched off.
That is the useful part of this story. An attack that made passwords irrelevant was still stopped, completely, by a second factor. For the advisory firms that had it on, there was no letter, no investigation, no notice to clients, and no thirty-day clock. The control that did that is free, takes a few minutes per account, and most cloud tools will let an administrator require it for everyone. This article is about turning it on everywhere client files live, and about why that one setting is worth more under Regulation S-P than most of what a firm pays for.
The numbers on both sides: the incident and the rule
About 5,000 accounts were accessed. Files were viewed or downloaded in fewer than a third of them. The window was seventeen days, August 4 through August 21. Dropbox's letters reached users around August 31, ten days after the window closed.
Now the numbers on the firm's side, from Regulation S-P as amended. Thirty days: the outer limit for notifying each affected client, counted from the day the firm becomes aware that unauthorized access to customer information has occurred or is reasonably likely to have occurred. Seventy-two hours: the deadline the firm's program must be reasonably designed to get from any service provider that holds customer information, counted from when the provider becomes aware of a breach. Two compliance dates: December 3, 2025 for advisers at $1.5 billion or more in assets under management, and June 3, 2026 for every other SEC-registered adviser. This incident arrived three months after that second date. Every SEC-registered adviser is inside the amended rule for it.
One more from the rule. If the firm cannot identify which specific clients' sensitive information was reached, it must notify every individual whose sensitive information sits in the affected system. For a shared client folder, that is the whole book.
And the number that decides whether any of those apply: Dropbox says the share of affected accounts that had two-factor authentication turned on was zero.
What happened: a federated Lenovo ID opened Dropbox sessions
The facts come from Dropbox's statements to reporters, the notification letter as posted by recipients, and Bloomberg's September 1, 2026 reporting. Dropbox has not yet published a public incident notice.
Dropbox allowed sign-in with a Lenovo ID as a federated identity. A defect in Lenovo's registration flow let anyone create a Lenovo ID under an email address they did not control. Dropbox matched that Lenovo ID to the existing Dropbox account with the same email and opened a session. Dropbox told Decrypt that approximately 5,000 accounts were affected, that fewer than a third had files viewed or downloaded, and that affected accounts were "connected through Lenovo ID that did not have Dropbox two-factor authentication enabled." Dropbox has since expired every Lenovo-authenticated session, removed the Lenovo links, and now requires the Dropbox password before a Lenovo ID can be used. Bloomberg reports it has notified regulators.
Why the password did not matter and the second factor did
Most people picture a breach as someone getting hold of a password. This one worked differently. A third party that Dropbox trusted to vouch for identities vouched for the wrong person, and Dropbox believed it. The victim's password was never asked for, so its strength was beside the point. Strong password, weak password, unique password: same result.
A second factor lives on the other side of that trust. It is checked by Dropbox itself, after any sign-in path, against something the account holder physically has. The attacker could borrow an identity from Lenovo. They could not borrow the account holder's phone. That is why the population of affected accounts and the population of accounts without two-factor turned out to be the same population.
The general point is worth stating plainly. Every cloud tool your firm uses accepts sign-ins from paths you did not choose and cannot see: password resets, federated logins, recovery flows, support-desk overrides. A second factor is the one check that sits behind all of them.
What one setting spared those firms
Regulation S-P defines customer information as any record containing nonpublic personal information about a customer that is "handled or maintained by the covered institution or on its behalf." It does not ask whose name is on the account. A client's statement in a personal Dropbox folder is customer information. Dropbox, if it holds that file, is a service provider under the rule. And the rule is explicit that, notwithstanding the use of a service provider, "the obligation to ensure that affected individuals are notified ... rests with the covered institution."
So the thirty days above start on the day someone at the firm reads the Dropbox letter. The trigger is "reasonably likely," not confirmed. The only way to stop the clock is the firm's own reasonable investigation, documented, concluding that the information has not been and is not reasonably likely to be used in a way that causes substantial harm or inconvenience. Dropbox's statement that its logs show no file access is evidence for that investigation. It is not the determination, and a vendor's log line does not close the firm's file.
For a firm with a shared client folder and one account that got the Dropbox letter, that is a month of work: preserving logs, writing to Dropbox for the access record, reasoning through what an attacker with a live session for up to seventeen days could have done with account applications and tax returns, drafting a notice that meets the rule's content requirements, and filing all of it where the next examiner can find it. We wrote about what the vendor's side of that clock looks like last month, and it is not the easy side.
For a firm with two-factor on, none of that happened. Not because the firm was lucky, and not because Dropbox protected it. Because a setting was on.
This is what controls are for. Most of a compliance program is about what to do after something goes wrong. Two-factor is one of the few items on the list that determines whether anything went wrong at all.
Which second factor to choose
Not every second factor is equal, and the difference matters when the thing being protected is a client's identity documents.
An authenticator app on a phone, or a hardware security key, is the standard to aim for. NIST's digital identity guidelines have treated text-message codes as a restricted authenticator since 2017, because a phone number can be moved to an attacker's device without touching the phone itself. Text-message codes are still far better than nothing, and if that is what a tool offers, turn it on today and upgrade later. But when the tool offers an app or a key, choose the app or the key.
Dropbox supports both an authenticator app and security keys. So do Microsoft 365, Google Workspace, and Box. Most custodian portals, CRMs, and planning platforms now do as well. The setting is usually under "security" in the account or admin console, and Dropbox's own help page walks through it in a few screens.
Turning it on across the firm this week
- Start with the tool that just proved the point. If your firm runs Dropbox Business, an administrator can require two-step verification for every team member from the admin console. Turn the requirement on rather than asking people to opt in. An optional control is a control that some accounts will not have.
- Do the same in every other place client files live: Microsoft 365, Google Workspace, Box, ShareFile, the custodian portal, the CRM, the planning software, the e-signature tool. Most of these let an administrator enforce it for the whole firm. Enforce it.
- Ask every person at the firm about personal cloud accounts that have ever held a client file. The account in this incident was, for many recipients, a personal Dropbox account tied to a work or personal email address that nobody at the firm administered. Under Regulation S-P, a client's statement in that account is still customer information handled on the firm's behalf. Either bring the account under two-factor and firm policy, or move the files out and close it.
- While you are in each admin console, look at which outside identity providers the tool will accept for sign-in. This attack did not need a password. It needed a login path nobody at the firm had chosen. If a tool will accept sign-ins from an identity provider your firm does not use, turn that path off where the tool allows it.
- Write the requirement into the firm's information security policy and note the date it was enforced in each system. A control that exists only in the settings is a policy without a record. The annual review, and the next examiner, will want to see when and where.
- If anyone at the firm did receive the Dropbox letter, the thirty days started the day they read it. Preserve the letter and the account's activity log, write to Dropbox for the access record, and get counsel involved this week rather than next.
The practical implication: require the second factor everywhere and write down that you did
It is rare for an incident to sort the affected from the unaffected on a single setting. This one did. Every account the attacker reached was missing the same free control, and Dropbox's own remediation was, in effect, to put a second check behind the path that had been open.
Firms spend real money on vendor reviews, questionnaires, and contract language, and that work matters. But the nine questions worth sending a vendor all assume the firm has done its own part first, and the cheapest part is this one. Turn it on everywhere, require it rather than recommend it, choose the app or the key over the text message, and write down that you did. The firms that did that years ago read about the Dropbox breach the same way everyone else did, as news about someone else.
Questions
What happened in the Dropbox breach of August 2026?
Dropbox accepted sign-ins with a Lenovo ID as a federated identity. A defect in Lenovo's registration flow let anyone create a Lenovo ID under an email address they did not control, and Dropbox matched it to the existing account with that email. About 5,000 accounts were accessed over seventeen days. Dropbox has expired the sessions, removed the links, and now requires the Dropbox password first.
Why did two-factor authentication stop the attack when passwords did not?
The attack never asked for the victim's password; a trusted third party vouched for the wrong person and Dropbox believed it. A second factor is checked by Dropbox itself after any sign-in path, against something the account holder physically has. The attacker could borrow an identity from Lenovo but could not borrow the account holder's phone.
Does a personal Dropbox account holding a client file fall under Regulation S-P?
Yes. Regulation S-P defines customer information as any record containing nonpublic personal information about a customer that is handled or maintained by the covered institution or on its behalf, without regard to whose name is on the account. Dropbox, if it holds that file, is a service provider, and the firm's 30-day clock starts when someone at the firm reads the letter.
Which second factor should an advisory firm use?
An authenticator app on a phone or a hardware security key. NIST has treated text-message codes as a restricted authenticator since 2017 because a phone number can be moved to an attacker's device. Text codes are still far better than nothing; if a tool offers only those, turn them on today and upgrade when the tool allows an app or a key.
What should a firm do if someone received the Dropbox letter?
Treat the day the letter was read as the start of the 30-day Regulation S-P window. Preserve the letter and the account's activity log, write to Dropbox for the access record, begin the firm's own documented investigation, and involve counsel the same week. A vendor's statement that its logs show no file access is evidence for that investigation, not the determination.
Advisor Insights provides general professional information, not individualized investment, legal, cybersecurity, or compliance advice. Your obligations depend on your registrations, your systems, and your contracts, and should be confirmed with counsel. Regulatory descriptions are U.S. federal and current as of September 2026. Incident facts reflect Dropbox's public statements and reporting through September 1, 2026 and may be updated as Dropbox publishes more.
Primary sources
General information from ValaisOS LLC, not legal, compliance, tax, or investment advice. Confirm requirements for your firm with counsel. See Terms of Use.