# MFA Push Fatigue Remediation Mini-Course A free, reviewable cybersecurity awareness micro-course package for turning MFA push fatigue, suspicious sign-in prompts, and approval pressure into practical training. Use this as source material inside AI Studio by Jericho, or adapt it for your LMS, manager enablement, phishing remediation, MSP/vCISO client delivery, or security awareness refreshers. > Review note: This starter course is not legal advice, a compliance guarantee, or a promise that incidents will be prevented. Review it against your approved identity systems, MFA policy, reporting process, privacy expectations, and learner audience before assigning it. --- ## Course overview **Working title:** Stop, Check, Report: MFA Push Fatigue and Sign-In Prompt Safety **Audience:** Employees, managers, help desk teams, MSP clients, contractors, and high-risk roles that approve sign-ins or receive MFA prompts. **Estimated length:** 6 to 8 minutes **Training goal:** Help learners recognize unexpected MFA prompts, avoid approving sign-ins they did not initiate, and use the approved reporting path without shame or delay. **AI Studio fit:** Create a short lesson, scenario-based quiz, remediation note, captions/transcript, and LMS-ready export package. Adapt the placeholders for your identity provider, help channel, and approved policy language. --- ## Learning objectives By the end of this lesson, learners should be able to: 1. Explain why an unexpected MFA push, code request, or sign-in prompt may signal credential compromise or social engineering. 2. Distinguish between a prompt they initiated and a prompt they should not approve. 3. Use the approved reporting path when MFA prompts, help desk calls, or sign-in notices feel suspicious. 4. Avoid sharing one-time codes, approving prompts under pressure, or ignoring repeated prompts because they are annoying. 5. Know what details to include when reporting: time, device, location if visible, system, message text, caller details, and whether anything was approved. --- ## Lesson copy Multi-factor authentication is designed to add a second check before someone signs in. It helps when the person approving the prompt is the same person trying to access the system. But attackers also know how MFA works. If they get a password through phishing, password reuse, malware, or a leaked credential, they may try to sign in and trigger prompts until the real user clicks approve. This is often called MFA fatigue or push bombing. The attack depends on pressure, distraction, habit, or annoyance. The safest habit is simple: **if you did not start the sign-in, do not approve the prompt.** That includes prompts that appear during a meeting, late at night, while traveling, during a busy shift, or after repeated notifications. It also includes phone calls or messages from someone claiming to be IT, support, a vendor, or a manager who asks you to approve a prompt, read a one-time code, or ignore a security warning. Use the approved reporting channel instead. Reporting quickly helps the security or IT team check whether your password, device, session, account, or application access needs attention. Reporting is not about blame. It is about catching the problem early. A good report includes what happened, when it happened, what system or app was involved, whether you approved anything, and whether someone contacted you. If you accidentally approved a prompt, report that too. Fast, honest reporting gives the team a better chance to respond appropriately. --- ## Scenario 1: The meeting prompt Jordan is in a project meeting when a phone notification appears: "Approve sign-in to [APP NAME]." Jordan is not signing in. A second prompt appears two minutes later. **Best next step:** Do not approve. Take a screenshot if your policy allows it, then report the unexpected prompt through [APPROVED REPORTING CHANNEL]. **Teaching point:** Repeated prompts can be a sign that someone else is trying to use your credentials. Annoyance is part of the pressure. Do not make the prompt go away by approving it. --- ## Scenario 2: The fake support call Riley receives a call from someone who says they are from IT support. The caller says Riley's account is being migrated and asks Riley to read a one-time code aloud to verify identity. **Best next step:** Do not share the code. End the call and contact IT through the approved help channel. **Teaching point:** One-time codes and MFA approvals are security checks, not support scripts. Real support processes should not require you to hand over a code or approve a sign-in you did not start. --- ## Scenario 3: The late-night approval A manager sees an MFA prompt at 11:43 p.m. The location looks unfamiliar. The manager assumes it is probably a background app and clicks approve because they want to sleep. **Best next step:** If a prompt was approved unexpectedly, report it immediately and follow the team's account-safety instructions. **Teaching point:** A mistaken approval is not the end of the story. The key is reporting quickly so security can check sessions, credentials, devices, and access as appropriate. --- ## Knowledge check ### Question 1 You receive an MFA prompt for an app you are not using. What should you do? A. Approve it so the prompt goes away. B. Ignore every prompt forever. C. Do not approve it, then report it through the approved channel. D. Ask a coworker to approve it for you. **Correct answer:** C **Feedback:** If you did not start the sign-in, do not approve the prompt. Reporting helps the team check whether your account or password needs attention. ### Question 2 Someone claiming to be support asks you to read them a one-time code. What is the safest response? A. Read the code if they know your name. B. Share the code only if they sound urgent. C. Do not share the code. Contact support through the approved path. D. Post the code in a team chat so support can see it. **Correct answer:** C **Feedback:** One-time codes are part of the sign-in protection. Do not share them over calls, texts, chats, or email unless your organization has a specific approved process that says otherwise. ### Question 3 You accidentally approved a prompt you did not initiate. What should you do next? A. Hide it because it was probably nothing. B. Report it quickly and explain what happened. C. Change your desktop background. D. Wait until the next annual training. **Correct answer:** B **Feedback:** Fast reporting matters. Include the time, app, device, prompt details, location if visible, and whether anyone contacted you. --- ## Remediation note for simulation follow-up If a learner approved a simulated prompt or shared a code in a test, keep the message practical and respectful: "This scenario was designed to practice a common pressure tactic: approving an MFA prompt or sharing a code when you did not start the sign-in. The safer habit is to stop, check whether you initiated the login, and report anything unexpected through [APPROVED REPORTING CHANNEL]. If this happens with a real prompt, report it quickly, even if you clicked approve by mistake." --- ## LMS packaging guidance Recommended package: - 6 to 8 minute lesson - 3 scenario blocks - 3 question knowledge check - Remediation note for follow-up training - Captions and transcript for video or voiceover delivery - Optional manager discussion prompt - SCORM, xAPI, HTML, or PDF export depending on your LMS Suggested metadata: - **Category:** Security Awareness / Identity Security - **Tags:** MFA, push fatigue, social engineering, account security, phishing remediation - **Refresh trigger:** Identity provider change, MFA policy update, help desk procedure change, phishing simulation result, or repeated suspicious sign-in reports --- ## AI Studio by Jericho prompt Copy this into AI Studio and adapt the placeholders: > Create a 6 to 8 minute cybersecurity awareness micro-course on MFA push fatigue and unexpected sign-in prompt safety. Audience: [AUDIENCE]. Approved identity provider: [IDENTITY PROVIDER]. Approved reporting channel: [REPORTING CHANNEL]. Include lesson copy, three workplace scenarios, three quiz questions with teaching feedback, a remediation note for simulation follow-up, captions/transcript guidance, LMS export notes for [LMS OR FORMAT], and assumptions that require review by security, IT, privacy, legal, or L&D. Use plain language. Do not claim the course guarantees compliance, prevents incidents, or proves secure behavior. --- ## Human review checklist Before publishing, confirm: - The identity provider and prompt examples match your environment. - The reporting path is accurate. - The lesson does not instruct learners to collect information your policy discourages. - Help desk and support language matches approved procedures. - Privacy, legal, compliance, and employee monitoring language is appropriate for your organization. - The quiz feedback is respectful and useful. - Captions, transcript, and export settings match your accessibility and LMS expectations. --- ## CTA Use this starter package as a first useful artifact. Then build the policy-fit, role-fit version in AI Studio by Jericho: https://contentstudio.jerichosecurity.com/campaigns/course-giveaway-mfa-push-fatigue-remediation