If your team stores shared logins in mSecure, you now have to decide how much to rotate without knowing what was exposed. The vendor has told customers to act, but has not said what went wrong. That puts the scoping burden on you, and the safe default is to treat the vault as potentially exposed until proven otherwise.
What happened
According to The Register, mSeven Software emailed mSecure customers on 3 November. The company said it had recently learned of suspicious activity linked to the password management application, launched an investigation, took steps to mitigate the issue and brought in external cybersecurity experts.
The email recommends that customers immediately protect all confidential information stored in the app. That may include changing passwords, resetting or re-enrolling two-factor authentication methods, or removing existing passkeys. The Hacker News also covered the notice.
The Register reports that the company has not explained what the activity involved, when it happened or whether attackers reached customer data. mSeven had not answered the outlet’s questions at publication. Customers have pressed for detail on the support forum and on Reddit, and some with 500 or 800 stored passwords asked whether every credential needs changing, or only those tied to mSecure itself.
Why it matters
A password manager concentrates risk by design. One incident can touch every account a user has stored, so the vendor’s communication matters as much as its engineering. A notice that says to take steps but names no scope forces customers to assume the worst case.
The advice itself is a signal. Telling users to reset 2FA and passkeys, not just passwords, suggests the company is worried about more than a single credential type. That is inference, not a stated finding, and it may also reflect plain caution. Either way, customers cannot tell which.
The episode also fits a pattern we have covered, where a single vendor holds data that many organisations depend on. See our pieces on the Trigger.dev breach and secret rotation and on Bullhorn and vendor concentration.
What it means for you
Start by finding out who in your organisation uses mSecure, including individuals on personal licences who keep work logins in it. Shadow usage is where these notices get missed.
Then rank credentials by blast radius rather than trying to reset everything at once. A practical order:
- The mSecure account itself: change the master password and re-enrol its 2FA and passkeys.
- Admin consoles, cloud providers, email, source control and identity providers.
- Financial, payroll and customer-data systems.
- Everything else, staged over days, starting with accounts that lack 2FA.
Check sign-in logs on your most sensitive systems for unfamiliar activity, and revoke sessions and API tokens stored in the vault. Budget staff hours for this: hundreds of entries per person is a multi-day task.
Press mSeven in writing for the scope, the timeline and whether vault contents were accessed. If answers stay vague, that is a data point for your vendor review. For longer term resilience, ask any credential vendor about breach notification commitments, and keep an exportable inventory of what is stored so a future reset is faster. Our enterprise coverage tracks similar vendor risk stories.
What to watch
- Whether mSeven publishes what the suspicious activity was, when it occurred and whether customer data was accessed.
- Any updated guidance that narrows the reset to specific credentials or confirms a wider scope.
- Findings from the external investigators the company engaged.
- Customer churn signals on the support forum and Reddit, and whether other vendors tighten their own disclosure language.
