Unexpected MFA Prompts Checklist for Business Teams
If your phone asks you to approve a business sign-in you did not start, deny the request and contact your company's trusted support channel. Do not approve it to stop the notifications, and do not give a caller an authentication code. An unexpected prompt deserves investigation, but the notification alone does not establish exactly what happened.
This checklist helps employees, office managers, and store supervisors respond without changing security settings or disrupting coworkers. It separates the employee's immediate actions from the investigation that belongs with an authorized administrator.
Start with the sign-in you actually initiated
Ask yourself whether you just opened the business application and deliberately started signing in. A familiar company name or an approximate nearby location is not enough to establish that a request is yours. Microsoft notes that Authenticator locations can be approximate or incorrect.
If you cannot connect the request to your own action, decline it. Do not experiment with approval to discover which application opens. If you were signing in but the request looks wrong, stop and ask support to help you verify the session through a known route.
Keep the authenticator installed and your existing protections enabled. Deleting the app, removing a work account, or disabling multifactor authentication is not an incident-response shortcut. Those changes can complicate legitimate access and recovery.
Handle repeated prompts without engaging the caller
Repeated approval requests can pressure someone into accepting a sign-in. A phone call or message may arrive at the same time, claiming that IT needs an approval to finish maintenance. Treat the combination as a reason to verify independently, not a reason to hurry.
Deny requests you did not initiate, even if they keep arriving.
Do not read out codes, send recovery codes, scan a supplied enrollment QR code, or approve a request on a caller's instructions.
End the unsolicited conversation and contact support through the number or portal already in your company records.
Report the first and latest prompt times, the affected account, and whether any request was accepted.
Microsoft's Authenticator FAQ warns about callers impersonating support and asking for authentication codes. A colleague's name, company logo, or believable maintenance story does not replace independent verification.
Report what happened without sharing secrets
A useful report is short enough to send immediately. You can add details afterward. Keep it in the company's approved support channel rather than a public forum or a group chat that includes customers.
Copyable MFA incident report
Affected work account and application:
First prompt time and time zone:
Most recent prompt time and approximate number of prompts:
Was I deliberately signing in at the time? Yes, no, or unsure:
Did I approve a request or share a code? Yes, no, or unsure:
Related call, message, link, or QR-code request:
Business task affected and safe callback method:
Never include a password, live verification code, recovery code, or authenticator setup secret in this report. If support needs a screenshot, review it for confidential information first and use the approved channel. Recording the time and what you did is more useful than forwarding a screen full of secrets.
For example, an employee could report: “At 9:15 a.m. Eastern I received three requests for my work account while serving a customer. I denied all three and did not share a code. Someone then called claiming to be support.” This is an illustrative report, not a client incident.
Escalate immediately if you already approved
Tell support promptly if you approved a request, entered a number supplied by someone else, or shared a code. Do not wait to see whether anything unusual happens. Be direct about uncertainty too; “I may have approved one” is important information.
Use a known phone number if you suspect your work email or messaging account is affected. Do not follow account-recovery links from the suspicious conversation. Let the authorized responder coordinate containment, recovery, and any required communication.
Microsoft's emergency access-revocation guidance explains that administrators may need to address account access and application sessions. A password change alone should not be treated as proof that every existing session has ended.
If there are signs that email has been accessed, our business email compromise checklist covers the broader response. The unexpected-prompt report remains useful even when the investigation expands.
Give the administrator a clear investigation handoff
The employee's job is to report and avoid approving unknown activity. The administrator's job is to compare that report with available sign-in and security records, assess exposure, and choose appropriate containment. Do not ask an employee to interpret logs or remove authentication methods without guidance.
For Microsoft Entra environments, an organization can enable reporting of suspicious MFA requests. Microsoft documents this in its MFA settings guidance. Whether reporting appears and what happens next depend on the organization's configuration; declining a prompt is not a substitute for contacting support.
Ask the responder to acknowledge ownership and give a safe next step. Record whether the employee may continue working, which account or device needs attention, and how the responder will confirm that access is safe to resume. Avoid promising that denying one request proves the account is secure.
Prepare a simple response routine before the next alert
Give every employee one reporting route they can find without opening the potentially affected account. Include an after-hours escalation route if your business already provides one. A store supervisor and a remote employee should not have to invent a response process during an alert.
Practice the report template with a written scenario, without sending fake approval requests to real accounts. Check that employees can explain the difference between a sign-in they initiated and a request someone else tells them to accept.
Ask your administrator to review authentication options suited to your applications and devices. CISA's small-business MFA guidance favors phishing-resistant MFA and identifies number matching as an improvement for push-based systems. Roll out changes with tested recovery procedures rather than improvising during an incident.
Pair the response routine with unique business passwords and an approved password manager. Our password manager rollout checklist helps teams plan ownership, training, and recovery.
Make the next step clear
Sosa Solutions NYC helps businesses review identity and access security and employee security practices. If your team needs a clearer reporting process or a review of its sign-in protections, discuss those needs through our cybersecurity services page.
Comments