Around 5,000 Dropbox accounts were accessed using Lenovo IDs that had apparently not been properly verified. The incident highlights an aspect of cloud security that is often overlooked in public debate. This is not about a conventional security vulnerability, but about whose judgement a service relies on when it accepts a login.
Dropbox allows users to sign in with a password or through accounts held with other providers, including Google, Apple and Lenovo. These providers act as authentication services. Users who sign in this way authenticate with the third-party provider. The email address serves as the link between the two services.
Anyone could create a Lenovo ID simply by entering an email address. Lenovo did not, however, check whether the person creating the account actually had access to that mailbox. Anyone who knew or guessed the email address associated with another person’s Dropbox account could therefore create a new Lenovo ID and use it to sign in to Dropbox. Dropbox accepted this as sufficient proof of identity, provided two-factor authentication (2FA) was not enabled for the account. This is how an attacker gained access to the affected accounts.
Table of Contents
A successful login says little about someone’s identity
When users sign in to a digital service, another provider often verifies their identity. The application then receives only confirmation that the user has been successfully authenticated. This creates a chain of trust: the application relies on the authentication service, which in turn depends on the reliability of the accounts and evidence it uses.
That is what makes this case significant. No Dropbox password was guessed or stolen. All it took was a Lenovo ID that anyone could create. Dropbox accepted the resulting confirmation without questioning how reliable it was. In other words, a successful login did not answer the crucial question in this case: was the person signing in really who they claimed to be?
This is a significant security risk
An incident like this is serious even for a personal account. When companies store business data in the cloud, trade secrets, personal data, internal communications, and information from customers and partners are at stake.
Few organisations would accept a Lenovo ID for access to their own corporate network. Yet when the same data is accessed through a cloud service, organisations often apply different standards and rely on the provider’s authentication mechanisms.
At a minimum, a service must authenticate employees exclusively through their organisation’s authentication service. It must be possible to disable all other sign-in methods.
Before approving a service such as Dropbox, organisations must therefore establish which identity sources it accepts and how those sources verify identities. They must also check whether additional authentication factors can be made mandatory, who can change these settings, and how access rights are revoked when employees change roles or leave the organisation. These checks remain necessary, regardless of the provider’s size or how well known it is.
Why authentication services should be open source
The same applies to external identity services such as Microsoft Entra ID and Okta. They are often central components of modern IT architectures, but may in turn trust systems that are unknown to the organisations using them. With some caveats, this also applies to directory services operated in-house, such as Active Directory. Without access to the source code, it is impossible to fully verify whether a system contains deliberate or unintended mechanisms for bypassing authentication requirements. Where a service runs does not, by itself, answer that question.
This is why the authentication service itself must be open source and capable of being operated independently. Only when the source code is accessible can organisations examine which bypass mechanisms exist, which dependencies a service has, and which sign-in methods it actually accepts. This also makes independent audits possible. Depending on the solution, organisations retain greater control over how the service is operated and developed.
The German Federal Office for Information Security (BSI) rightly points out that using free and open-source software does not, by itself, guarantee a secure system. Open-source software must still be maintained and operated securely. However, the BSI also notes that open-source software offers significant strategic advantages in managing security. That is where its value lies: open source provides a key foundation for a high level of security.
Digital sovereignty starts with access
Digital sovereignty is often associated with where data is stored or which cloud infrastructure an organisation chooses. Yet it begins with digital identity. An organisation must be able to understand and control who verifies identities, which systems trust one another, and who can change or revoke those relationships. Without that control, it remains unclear on what basis access to the organisation’s data is granted.
By using a cloud service, a company transfers part of its IT operations to an external provider. Responsibility for its data and for access to that data remains with the company.
The Dropbox-Lenovo case is therefore more than an isolated security incident. It illustrates why the sign-in methods used by cloud services matter: one system accepts another system’s assertion and uses it to decide who can access data. The organisation using the service may have no control over that decision.
The key question is: who decides who can access our data, and can we verify that decision?
Source reference: This article is based on the German-language heise report titled “Ich mach mir eine Lenovo-ID und hol mir Deine Dropbox-Dateien,” published on September 2, 2026: https://www.heise.de/news/Fremde-Dropbox-Konten-ueber-Lenovo-ID-zugaenglich-11437565.html.
