After a data breach: what passkeys stop, what they don't, and what to check in your login

Passkeys don't prevent server breaches. What they do prevent is the next step: attackers using leaked email addresses and names to take over accounts through phishing and credential stuffing. A passkey can't be typed into a fake site or reused across services, and because the service keeps only public keys, a leaked database contains nothing an attacker can log in with. This post covers what to check in your login after breach news, and how to add passkeys to the login you already have.

The warning from Japan's National Cybersecurity Office

On October 9, 2026, the National Cybersecurity Office in Japan's Cabinet Secretariat published a notice titled "Response in light of incidents involving data leaks through unauthorized access" (in Japanese). It says the office has confirmed multiple cases in which attackers broke into the systems of organizations that handle large amounts of personal data, through exploited web vulnerabilities, compromises in the supply chain, and weak data management, and stole data including personal information.

The notice says that systems exposed to the internet should be protected on the assumption that they could be attacked at any time. Among its recommendations, the ones that concern logins are:

• Introduce multi-factor authentication (MFA)
• Prohibit easily guessed passwords
• Detect abnormal authentication attempts from outside
• Do not store passwords or credentials in plaintext
• Delete information promptly once it is no longer needed (keep less data)

Most of the notice is about keeping attackers out in the first place: patching, managing contractors, encryption and access control. The rest of this post focuses on the part that concerns your users' accounts.

What comes after a leak

Even when only email addresses and names may have leaked, the story doesn't end there. A list of real email addresses feeds two kinds of attack:

• Phishing. Attackers send emails that look like breach apologies or identity checks, lead people to a fake login page, and collect their passwords and one-time codes. Because the messages reach real customers under a real company's name, they are hard to tell apart.
• Credential stuffing. Attackers take email and password pairs leaked from other services and try them against your login. If a user reused a password, the attacker gets in even though nothing is wrong with your systems.

Both end in account takeover. The leak doesn't have to be yours: if your users' addresses are in someone else's breach, your login becomes a target.

What passkeys stop, and what they don't

Passkeys are sign-ins based on WebAuthn, the standard from the FIDO Alliance and the W3C. At registration, the user's device creates a key pair and gives the service only the public key. At sign-in, the device signs a challenge from the service with the private key, and the service checks the signature with the public key. Each key is created for the service's domain (the RP ID), and the browser only signs with a key that matches the domain of the page it's on.

The last two rows are where rollouts differ. If you add passkeys but keep passwords and a weak recovery flow untouched, attackers simply move there.

What to check in your login after breach news

Whether or not you add passkeys, start by checking your current login.

Rate limiting and monitoring

Credential stuffing tries a few passwords across many accounts, so per-account lockouts miss most of it. Count failures per IP address, per account and across the whole service, and make sure a sudden rise gets noticed. This is what the notice means by detecting abnormal authentication attempts. Locking accounts immediately also gives attackers a way to lock real users out, so combine limits with delays or extra checks.

Alerts for new devices

Email users when someone signs in from a new device or browser, when their email address or password changes, and when a new sign-in method is added. It's a low-effort way to help people notice a takeover early.

The limits of one-time codes

SMS and app-based one-time codes are stronger than a password alone, but they don't survive a fake site that relays what the user types to the real site in real time. A code typed into a phishing page works just as well for the attacker. Having MFA is not the same as being phishing-resistant.

Recovery flows

Password resets, email address changes and identity checks at your support desk are the back doors of your login. A reset that needs only access to the inbox falls as soon as the email account does. Notify users after a reset, ask again before sensitive changes, and decide what your support team checks before helping someone back in.

Stored credentials

Check that passwords aren't stored in plaintext or in a reversible form, that your hashing is current, and that old credentials and unused accounts are gone. Data you don't keep can't leak.

Adding passkeys to an existing login

The practical path is to add passkeys next to your current login rather than replacing it. Users have many kinds of devices and browsers, and not all of them will be ready on day one.

1. Offer passkeys on the sign-in page. Keep the email and password fields, and add "Sign in with a passkey". With autofill (conditional UI), passkeys show up in the username field's suggestions and the page barely changes.
2. Invite users to register right after they sign in. Right after a password sign-in is also right after you've verified the user. Tell them they can sign in with a fingerprint or face next time, and let them register on the spot.
3. Keep a fallback. Leave passwords or email sign-in in place for a while for devices that can't use passkeys and for people who lose their device. Then set a date after which users who have a passkey stop using their password.
4. Decide on recovery first. Before launch, decide how you'll verify and re-register someone who lost their device. Skip this and your support inbox fills with "I can't sign in."

See Adding passkeys to an existing login and Designing passkey account recovery for more on each step.

Doing this with SealGate

SealGate is an API and browser SDK for adding passkeys to an existing login. Following the steps above, it fits in like this:

• Registration and sign-in. In the browser, call the SDK's sg.register() and sg.login(). Your server adds your API key to the JSON the SDK sends and relays it to SealGate. When sign-in succeeds, you issue your own session. To add a passkey for a signed-in user, pass signed_in: true after checking your own server session.
• Autofill. sg.login({}, { mediation: 'conditional' }) shows passkeys in the username field's suggestions.
• What's stored. SealGate keeps the user ID you assign (external_id), a display name, passkey public keys and authentication records. It does not hold names or passwords. We recommend an external_id that doesn't identify the person, rather than an email address.
• Recovery. You verify the user's identity on your side, then call POST /v1/recovery/start to issue a recovery token valid for 15 minutes so they can register again. SealGate does not verify identity.
• Suspected takeover. POST /v1/users/{external_id}/revoke revokes all of that user's passkeys at once.
• Monitoring and alerts. Registrations and sign-ins are recorded in the audit log and can be delivered as webhooks (register.completed, login.failed and others), so you can tell users when a passkey is added or notice a spike in failures.
• Password coexistence deadline. Set a deadline in the app settings, and after it passes the sign-in response returns password_allowed: false. Use it to stop accepting passwords from users who already have a passkey.

The API and code samples are in the docs. For pricing, see the pricing section.

FAQ

Will passkeys prevent data breaches?

No. Passkeys are a way to sign in. Keeping attackers out of servers and away from data is the job of patching and access control. Passkeys protect against the account takeover that uses leaked data afterward.

Do we need to act if only email addresses leaked?

Yes. A list of valid email addresses is both a phishing mailing list and a list of accounts to try in credential stuffing. Check your rate limiting, monitoring and new-device alerts.

Isn't MFA enough?

One-time codes sent by SMS or generated in an app can be relayed from a fake site. If you need resistance to phishing, consider adding passkeys, whose signatures are bound to your domain.

Related

• What passkeys are and how to add them to your service (SHANNON, in Japanese)
• The cost of adding passkey authentication (SHANNON, in Japanese)
• Data breaches and account takeover (SHANNON, in Japanese)

Sources

• Response in light of incidents involving data leaks through unauthorized access (National Cybersecurity Office, Cabinet Secretariat of Japan, October 9, 2026; in Japanese)
• Web Authentication: An API for accessing Public Key Credentials Level 3 (W3C)
• Passkeys (FIDO Alliance)