The popular reaction to a consumer dump is always the same. Publish the notice. Tell people to ignore unexpected mail. Point them at a password form. Capcom is doing that now after 11.7 million records tied to CAPCOM ID landed in the open, and the cybersecurity instinct behind it is so baked in that questioning the notice itself feels like arguing against honesty.

You should still tell users. You should still force resets on the accounts you still control. What you should stop doing is treating the announcement as the end of incident response. For attackers, announcement day is when the inbox becomes a login prompt with your logo on it.

CAPCOM ID is a consumer identity system wrapped around games, storefronts, and support. Email is the locator. Password reset is the privileged action. Once 11.7 million locators are public, every “verify your CAPCOM ID” message looks like customer care. Your users have been trained by a decade of real breach mail to click the next one. The fake will arrive in the same hour as the real one, often with better formatting.

The 196 Quiet Resets Are the Incident

Capcom also reported that passwords changed without permission on 196 accounts. That number will get shrugged off next to 11.7 million. Don’t shrug. A dump of email addresses is a targeting list. A silent reset is a completed takeover. One hundred ninety-six is a working exploit against recovery, not a rounding error in a press statement.

Think about the sequence your own shop would run. Legal drafts the notice. Comms wants a clean URL. Identity wants a forced reset. Support wants a script. Meanwhile the addresses are already in other people’s hands. Anyone with a mailbox, a cloned landing page, and a reset form can race you. Some of them will win. The 196 accounts are what winning looks like when the victim still thinks the company is “looking into it.”

This is where a lot of programs go soft. They score the dump as a confidentiality event and the phishing wave as a user-awareness problem. The live failure is account recovery under a known-email condition. If an attacker can change a password without the owner in the loop, your threat-protection stack never got a vote. The session that follows looks legitimate. Your logs show a successful login. Support sees a customer who “just reset.”

Game publishers make an easy case study because the accounts sit next to payment cards, store credit, and years of purchase history. The same pattern shows up in any consumer portal you run: airlines, campuses, utilities, ticketing, municipal payments. Email is public enough to harvest. Reset is powerful enough to matter. If your cyber security review still treats “we notified” as containment, you have written the attacker’s runbook into your IR plan.

Your Cybersecurity Calendar Is Their Phishing Calendar

Phishers do not need a novel lure when you publish the plot. “We had a data incident involving CAPCOM ID. Please reset your password at this link.” That sentence is catnip. It explains why the mail exists. It creates urgency. It names the brand the user already trusts. You cannot unteach that in a footer that says you will never ask for a password.

Users will look for the follow-up. Helpdesk queues will spike. Search results will fill with lookalike domains registered the same afternoon. Inbox filters that might have caught a random “Resident Evil prize” pitch will pass a message that quotes your own incident language. The honest notice does not merely coexist with the fake one. It makes the fake one land.

Watch the clock. The dump leaks. Quiet resets land on the accounts with reused passwords or weak recovery questions. Then the company speaks, and the rest of the list becomes a campaign. If your threat detection only lights up on malware hashes or a noisy brute-force against the login form, you will miss the polite traffic: one reset per mailbox, from residential IPs, using the real “forgot password” endpoint. That traffic is supposed to exist on announcement day. Attackers hide inside the surge you created.

Security teams love to say users should “verify the URL.” Cool. Your users are holding a phone, they just saw your name in the news, and two messages arrived in four minutes. One of them is yours. They will not open a SOC runbook. They will tap the first button that looks like relief. Design for that human, not for the colleague who already lives in a SIEM.

Recovery Is Where You Lose the Account

If your story still starts at the firewall, you are scoring the wrong door. Perimeter gear does not see a password change that used the approved form. Defense in depth for consumer identity means the reset path is harder than the login path, because reset is how an attacker converts a stolen mailbox into a durable session. Login is where customers live. Recovery is where you get owned.

Capcom’s warning is the public half of a private operations problem you can rehearse without their stack, their CDN, or their ticketing tool. The work is ugly and specific. Do it before the next list of yours shows up on a forum.

Harden the reset before you train the click

Run this as a drill with identity, IR, support, and comms in the same room. No product bake-off. No new dashboard. Prove you can deny a stranger a password change even when they already have the email address.

1. Immediate: Inventory every path that can change a password, email, phone, or MFA device: self-service, mobile app, call center, chat, in-game support. If a path can do it, it is in scope. Disable or pin the ones you cannot monitor for 72 hours.
2. Immediate: Force a reset only through a channel you already bound to the user, such as an in-app prompt or a previously registered authenticator. If the only proof you have is “we emailed the dumped address,” you are sending the keys to whoever reads that inbox.
3. Immediate: Rate-limit and step-up recovery. Treat bursts of forgot-password traffic the way you treat credential stuffing. Cap attempts per account and per source. Require a second factor that was not in the dump before the new secret is committed.
4. Immediate: Pre-stage the real notice with a predictable, boring destination: a path on your existing domain, already linked from the logged-in account page. Put the same URL in the status banner, the app, and social. Do not invent a fresh “secure-reset” hostname that a lookalike can twin in DNS.
5. Ongoing security hardening: Log password changes, email changes, and MFA replacements as first-class detections. Alert on volume, on accounts that reset then drain a wallet or change a ship-to address, and on resets that never produce a subsequent owner login from a known device.
6. Ongoing: Give support a hold script that refuses password changes on the call unless the caller completes a step the dump cannot fake. Train them that “I got the breach email” is not identity. Publish that policy in the notice so the real customers expect friction.
7. Ongoing: Keep a takedown and abuse mailbox that actually answers on announcement day. Lookalike domains and cloned pages are a same-day problem. Your IR clock starts when you hit send, not when legal closes the file.

None of that requires a new vendor. It requires you to admit that notification is an authentication ceremony you do in public. If you skip the ceremony design, you are paying for awareness posters while the reset API does the damage.

Frequently Asked Questions

Should we delay the notice so phishers have less cover?

Delaying a legally required notice to “starve” lures usually fails, and it leaves the 196-style takeovers running in the dark. Ship the notice on the obligation clock, but lock recovery and publish one canonical URL first so the message you send is harder to clone than the dump is to abuse.

Is 196 unauthorized resets material when millions of emails leaked?

Yes. Email exposure is targeting. An unauthorized password change is account loss, payment risk, and a trusted session inside your app. Hunt those events as confirmed compromise, then use the count to justify recovery controls you should have had before the list went public.

Does MFA on the game account close this?

MFA helps only if recovery cannot replace it using the dumped email alone. If “forgot password” or a support agent can drop the second factor, you added a prompt, not a control. Bind MFA reset to a device or key the dump did not include.

Sources

• Resident Evil maker Capcom warns of phishing after 11.7 million records exposed