Operations and User Migration
Running identity is a permanent job. You need dashboards that show attacks as they start, runbooks for the incidents you will certainly have, and a migration path in and out of your system.
What to watch
| Signal | Why it matters | Alert when |
|---|---|---|
| Sign-in success rate (first attempt) | Your main health and UX metric | Drops sharply against the same hour last week |
| Failure rate by reason | Spikes in "bad password" across many accounts mean stuffing | Global failures jump while per-account counts stay low |
| Hash worker queue depth and latency | Early warning for floods and capacity limits | Queue grows or p95 latency crosses your target |
| MFA and passkey ceremony errors by platform | Browser and OS updates break flows | Error rate rises for one platform or version |
| Email and SMS delivery latency | Users cannot verify or recover | Delivery takes longer than your code lifetime |
| Recovery and reset volume | Account takeover campaigns target recovery | Volume rises without a matching product cause |
| Token issuance by client | Leaked client credentials or abuse | A client's volume jumps unexpectedly |
| JWKS and discovery availability | Every client depends on them | Any error |
Incident runbooks to write before launch
- Credential-stuffing attack: raise risk thresholds, tighten per-IP limits, enable challenges, force resets for confirmed-compromised accounts, notify users.
- Signing key compromise: emergency rotation, revoke all sessions and refresh tokens, notify customers (Chapter 14).
- Database exposure: confirm what leaked, rotate peppers and encryption keys, force password resets if hashes may be crackable, follow breach-notification deadlines per jurisdiction.
- Enterprise IdP certificate expired: clear tenant error, admin notification, fast self-service certificate update.
- Email provider outage: switch to a secondary provider, extend code lifetimes temporarily, prefer passkey and TOTP paths.
- Bad deploy that breaks login: automatic rollback on sign-in success rate; canary deploys for every auth change.
Migrating users into your system
Most in-house builds start by migrating away from something. Two methods, often combined:
Bulk import with hash compatibility. Export users and password hashes from the old system. If the hashes are in a format your verifier understands (bcrypt, scrypt, PBKDF2, Argon2), import them as-is with their algorithm recorded, and let rehash-on-login upgrade them (Chapter 4). Import passkey credentials only if both systems share the same RP ID; otherwise users re-enroll.
Lazy migration. Keep the old system running behind your new login. On each sign-in, if the user is not yet migrated, verify against the old system, then create the user and hash locally. After a defined window, bulk-import the remainder and require resets for anyone without a usable hash.
Either way, preserve user IDs (or map them) so downstream systems and tokens keep working, migrate federated links by (provider, subject), and re-run breached-password checks at first sign-in.
Change management
- Every change to auth code gets a second reviewer with security context.
- Feature flags for every new flow, with per-tenant rollout.
- A staging environment with real IdP test tenants, passkey test devices, and SCIM clients.
- Dependency updates for crypto, SAML, OIDC, and WebAuthn libraries treated as security work, applied within days.
Common mistakes
- No runbook for key compromise until the day it happens.
- Dashboards that show traffic but not failure reasons.
- Migrations that change user IDs and break every downstream integration.
Key takeaways
- Watch first-attempt sign-in success and failure reasons, not just traffic.
- Write runbooks for stuffing, key compromise, database exposure, IdP certificate expiry, email outages, and bad deploys.
- Import compatible hashes as-is and let rehash-on-login upgrade them.
- Preserve user IDs in every migration so downstream systems keep working.