Short answer: on November 3, 2026, mSeven Software, the maker of mSecure, emailed current and former customers about "suspicious activity" and told them to secure everything stored in the app. Customers also report support replies saying an encrypted database was taken from mSecure Cloud, with no evidence so far that its contents were accessed. The cause, dates and number of affected users have not been published. If you used mSecure, do not wait for those details: replace the credentials that were inside your vault, starting with email and financial accounts, and do it on each service's own site.

This is a developing story. Everything below reflects reporting available on November 5, 2026. mSecure was not tested, and the reportedly stolen data was not seen. Check the sources at the end for updates.

What mSeven has confirmed

Coverage quotes the notice (BleepingComputer, Malwarebytes). The email went out on November 3. In it, mSeven says it "recently learned of suspicious activity associated with the mSecure password management application." The company says it launched an investigation, took steps to mitigate the issue and engaged external cybersecurity experts.

The notice tells customers to immediately protect all confidential information stored in mSecure. The steps it lists "may include changing passwords, resetting or re-enrolling two-factor authentication methods, or removing existing passkeys."

What is reported but not officially published

Customers shared support replies attributed to mSeven. As relayed by BleepingComputer and eSecurityPlanet, they say:

  • an unauthorized actor obtained an encrypted database from mSecure Cloud, holding information on current and former users;
  • the issue concerns users who were syncing with mSecure Cloud;
  • mSeven has "no evidence" the attacker accessed the confidential information inside the database;
  • mSeven has no evidence the app itself is currently unsafe to use.

These come from screenshots and customer posts, not from a public statement by the company. BleepingComputer said it had not received an answer from mSeven when it published. Treat the details as likely but unconfirmed, and note that "no evidence of access" is not the same as "no access."

What nobody has said

Neither the notice nor the reporting reviewed here says:

  • how the attacker got in, or when;
  • which systems were involved;
  • how many users are affected;
  • whether the database reportedly taken includes the vaults themselves, and whether the attacker can read their contents;
  • whether people who never used mSecure Cloud are affected.

mSeven describes mSecure as using AES-256 encryption and a zero-knowledge design in which the company cannot access decrypted vault contents, as BleepingComputer notes. The notice does not say whether those protections were affected, and nothing published settles it. Malwarebytes adds that mSecure's own documentation warns that "someone may already have made a backup of its contents" (that is Malwarebytes's wording), though it does not link that line to this incident.

One more piece of context: heise reports more than 500,000 installs on Google Play and estimates roughly 250,000 users overall. That is the author's estimate, not a company figure.

Why a reset can make sense even if the vault is encrypted

An encrypted copy of a vault is not readable on its own. But an attacker who holds a copy can guess the master password offline. The vendor cannot rate-limit those guesses, and you cannot see them. Strong, unique master passwords make that expensive. Weak ones do not. BleepingComputer points to the 2022 LastPass breach, where stolen encrypted vaults were later tied to cryptocurrency thefts and weak master passwords are believed to have been cracked. That is a different company and a different incident. It shows the mechanism, not what happened at mSeven.

Two consequences follow from this mechanism, and neither depends on facts mSeven has yet to publish:

  • Changing your master password protects the vault from now on, not a copy already taken. A copy stays locked with the old password. What protects you is replacing the credentials that were inside it.
  • Deleting the app alone does not undo anything. The data that matters is on the vendor side and in any copy, not on your phone. Keep your vault until its entries are replaced.

What to do, in order

The notice lists what to change but not an order. The priority order below is this article's own, informed by guidance from Malwarebytes and eSecurityPlanet, who both name email, financial, work and recovery accounts first. Where something is their opinion rather than mSeven's, it says so.

1. Work out what was in the vault

Open the vault and list the entries, or export them to a file you will delete afterwards. Mark each one as email, financial, work, recovery or other. You need this list because the order matters more than speed.

2. Replace credentials by what an attacker could do with them

  1. Primary email and recovery accounts. Anyone who controls your email can reset most other passwords. Change the password, review recovery email and phone numbers, and check active sessions.
  2. Financial accounts. Banks, payment services, anything that can move money.
  3. Work accounts. Cloud consoles, code hosting, VPN, single sign-on. If company credentials were in your vault, tell your IT or security team now (see the team section below).
  4. Everything else, in the order you value it.

Make every change on the service's official site or app, as Malwarebytes and eSecurityPlanet both advise, and never through links in emails or messages. Use a unique password for each account. Expect phishing: reset-warning emails are a convenient lure, including ones that appear to come from mSecure.

3. Handle two-factor secrets without locking yourself out

If you kept authenticator seeds (TOTP secrets) in mSecure, treat them as potentially exposed along with the passwords. Malwarebytes suggests re-enrolling authenticators through each service's security settings. eSecurityPlanet adds that you should keep a working recovery method available. In practice that means saved recovery codes or a second device (this article's suggestion, not theirs), so check this before you remove an old method.

4. Handle passkeys carefully

For each passkey stored in mSecure, first set up another working sign-in method, then remove the old registration at the service, then create a new passkey with a different provider. Do not revoke first.

5. Decide where the new credentials go

Malwarebytes suggests considering a different password manager, at least temporarily, for the replacement credentials. That is its precaution, not a finding about mSecure. mSeven says it has no evidence the app is unsafe to use, so this is your call. If you stay, use a new, long, unique master password.

6. Watch for misuse

After changing a password, check the service's login history or security log for sign-ins you do not recognize, and turn on alerts where the service offers them. Do not assume a quiet inbox means nothing happened.

For teams and companies

If staff stored work credentials in a personal mSecure vault, the exposure is yours even though the account is not:

  1. Ask people to say whether they used mSecure for anything work-related, without blame, so you get honest answers.
  2. Rotate shared and service credentials first: API keys, cloud and database passwords, deployment tokens. The sequence of create, deploy, verify, revoke is covered in how to rotate environment variables after a platform breach, and the first hour for a leaked key is in what to do after a leaked AI API key.
  3. Check access logs at the affected providers for activity from unfamiliar locations or tools.
  4. Ask mSeven in writing which data is affected and what has been contained. eSecurityPlanet recommends this for businesses.
  5. Decide where shared credentials should live. Personal consumer vaults mix work and private secrets and give you no audit trail or revocation. A team secret manager with role-based access and an audit log answers "who could read this?" in an incident. It is still a service you have to trust, so ask the same questions of it.

Switching from legacy vaults to Ennote Security

Consumer password managers rely on downloading encrypted files (blobs) to a user's device. If the central cloud is breached, attackers can take those encrypted files and brute-force them offline at their leisure. This architecture is increasingly risky for enterprise infrastructure.

Ennote eliminates this risk by utilizing a strict Zero-Persistence architecture. Instead of syncing encrypted files that rest on a developer's hard drive or CI/CD runner, Ennote streams secrets directly into the application's volatile runtime memory via a secure gRPC connection. When the process stops, the secret evaporates.

Furthermore, Ennote integrates natively with Kubernetes via the Ennote Smart Agent. Instead of exposing inbound ports or relying on polling, the agent pushes secrets directly to native Kubernetes Secrets and can automatically trigger zero-downtime rolling updates across your pods the moment a credential is rotated.

What to watch for next

The questions that would change the advice are the ones in the unknowns list: whether vault contents were taken and whether they can be read, and how many users are affected. A fuller statement or an independent analysis could narrow the scope. Until then the order above stays sensible, because it is cheap and does not depend on any answer.

Sources

Keep work secrets out of personal vaults. Ennote is a secret manager for passwords, API keys and environment variables, with role-based access, an audit log and Kubernetes sync. Start for free on the Developer plan.