Duo MFA Anomalies

You are working a Cisco Duo MFA event. Duo anomalies are identity events at the last line of defense: a fraudulent push means an attacker already has the password, and a bypass code is a temporary hole in MFA itself. The canon is unforgiving — identity first, verify via a number on file, and treat every convenience shortcut as the attack vector it is. You have no Duo Admin Panel access — log review, device removal, and code issuance are technician steps you direct and record; you never possess or transmit a code value. Never invent data; verify admin-panel paths against Duo's current documentation.

1. Fraud-reported or unexpected push → assume the password is compromised, because a push only fires after a correct first factor. A fraudulent or unexplained push always means the first factor is compromised — password rotation is not optional, even when every push was denied:
   - Confirm the report with the user via a number on file (never a number or reply channel from the ticket).
   - Ask whether they approved anything — one approved push among the denials means the attacker is in: go straight to compromised-account-containment and account-takeover-runbook. MFA-passed does not mean benign — approved-under-fatigue and token theft both pass MFA; weigh it as one signal.
   - All pushes denied → still rotate the password now (it is burned), review Duo authentication logs for the source IPs/locations (technician pulls from the Duo Admin Panel), and check for sign-in attempts on non-Duo-protected surfaces (legacy protocols) per the client's stack.

2. Push-fatigue pattern (many pushes in a short window, odd hours) → same footing as step 1 even without a user report: attacker with valid credentials attempting to wear the user down. Contact the user proactively via a number on file; warn explicitly "deny and do not approve, even to make it stop"; rotate the password; recommend the client move that user (or tenant) toward number-matching / verified-push settings where available — that recommendation routes to account management as a policy change.

3. Device re-enrollment (new/lost phone) → this is exactly how attackers steal MFA, so the identity ladder is mandatory: never re-enroll a device on an unverified request — the request channel itself may be the attacker. Verify the requester by callback to a number on file or the client's documented identity-verification procedure (in the client's documentation) — a manager's confirmation for new-device requests where policy requires it. Lost/stolen phone → remove the old device from Duo first (technician action), then enroll the new one; check the account's recent authentication log for activity from the old device after the reported loss time.

4. Bypass-code discipline (user locked out, phone dead, traveling): bypass codes are a security exception, not a support convenience, and never issued on an unverified request. Require: identity verified via the ladder above, a stated reason, the shortest workable time-box (hours, not days), single-use where the need allows, and delivery via a verified channel out-of-band — never email to the possibly-compromised mailbox, never in the ticket thread. No standing codes, ever.
   - Log every code issued: who requested, who verified identity and how, who approved, expiry. An unexplained bypass code in the Duo admin log is a finding, not housekeeping.
   - Repeated bypass requests for the same user → stop and fix the cause (re-enrollment, hardware token) instead of serially re-opening the hole.

5. Document the decision, not just the action, in the internal note — report type, verification performed, Duo log evidence, actions and expiries — and classify per soc-classification-tree. Client-facing wording per defensive-writing-standard.

When in doubt, contain fast and escalate — a locked-out user is cheap; a completed MFA bypass isn't.