· 6 min read

mSecure Told Customers to Consider Changing Passwords and Resetting 2FA, Then Said Almost Nothing Else. Here Is the Triage Order I'd Use for a Vault I Can't Trust.

On November 3, mSeven Software, the developer of the mSecure password manager, emailed current and former customers that it had "recently learned of suspicious activity associated with the mSecure password management application." It recommended that customers "immediately take steps to protect all confidential information," which "may include changing passwords, resetting or re-enrolling two-factor authentication methods, or removing existing passkeys." Ten days later, I have not found a public follow-up that says what systems were involved, when it happened, or whether anyone's vault data was touched. If you run a business out of one password vault, a vague notice like this is the worst kind, because it asks you to do everything without telling you what matters first.

What the notice said, and what it didn't

The email says mSeven launched an investigation, took steps to mitigate the issue, and engaged external cybersecurity experts. That's all.

According to The Hacker News, the email does not name the systems involved, say when the activity happened or whether it has stopped, say how many people received it, or say whether the activity reached vault data or the keys that protect it. It also doesn't say whether the 2FA and passkey advice applies to the accounts stored in mSecure, to your mSecure account itself, or both. As of the evening of November 3, The Hacker News found nothing about it on mSecure's social accounts, and the support forum thread where customers asked whether the email was genuine had no staff reply on its first page when I checked.

mSecure's own security page says your data "is encrypted before it ever leaves your device" and that the account key "is never stored on our servers." If that design held up, a server-side incident shouldn't expose vault contents. But a vendor that believed that would usually say so in the notice. This one didn't, and that silence is the information I have.

Why order matters more than speed

A solo operator's vault might hold a few hundred logins. Forum posters mentioned 800 and nearly 1,000 entries in their own vaults. Nobody rotates 800 passwords in an afternoon, and trying to will get you locked out of something important halfway through. The goal is to rotate the accounts that let an attacker take over the rest of your accounts, then the ones that cost money, and then let the long tail follow.

The triage order I'd use

First, your primary email account. Password reset links for almost everything else go there. Change the password, review the recovery phone and backup email, sign out other sessions, and check forwarding rules and filters for anything you didn't set. If 2FA seeds for it were in the vault, re-enroll 2FA.

Second, your domain registrar and DNS. Whoever controls your domain controls your email, your website and your sign-in links. Rotate, re-enroll 2FA, and turn on registrar lock if it's off.

Third, money: bank, payment processor (Stripe, Paddle, PayPal), and anything that can issue a payout. Check payout destinations for changes before you rotate. That's the change an attacker would make first.

Fourth, code and infrastructure: GitHub, your host, your cloud account, and AI API keys stored as secrets. Rotate tokens and keys too, not just passwords. A stolen API key doesn't care that you changed the password.

Fifth, customer data: your database, CRM, support desk and email marketing tool.

Then everything else, in batches, sorted by how much damage it could do.

The passkey and 2FA part

The email's mention of passkeys and 2FA is the part people will skip, and I'd still deal with it for the top tiers. If your vault stored TOTP seeds next to the passwords, then a stolen vault means stolen 2FA too. Re-enrolling an authenticator creates a new seed and makes the old one useless. For passkeys stored in the vault, remove them from the account and create new ones. For the top three tiers above, I'd move 2FA to a hardware key or an authenticator app that's separate from my password manager, at least until the vendor says what happened.

Should you leave mSecure?

I'm not going to tell you to switch password managers based on one email. I can't verify from public information that any vault data was exposed, and mSeven hasn't said it was. But my rule for any security vendor is simple: if a notice tells me to rotate everything and won't tell me why, I rotate my top tiers that week and give the vendor a deadline. If there's no clear explanation of scope by then, I move. A password manager is the one tool where "we're investigating" isn't enough for long.

If you do move, export to the new manager on a trusted machine, check that the import worked, and only then delete the old vault. Don't leave an unencrypted export file sitting in Downloads.

The honest take

Spend one focused session this weekend on email, domain, money and code, in that order, and re-enroll 2FA on those accounts away from the vault. That covers most of the real takeover risk. The other 790 logins can wait for the vendor's explanation, or for your next quiet week.

Where I could be wrong: this may turn out to be a contained incident that never reached vault data, and the email may be an overly broad, lawyer-shaped notice. If so, you will have spent a few hours rotating your most important credentials, which most of us should do every year anyway. I'm fine with that trade.

Author

Sources

Newsletter

The week, in one email.

The weekly summary of what happened and what it means for people who build alone. No spam, unsubscribe any time.

Form not showing? Subscribe on this page instead.

Related Posts