An employee receives a sign-in approval request while making coffee. Then another arrives. The dangerous ambiguity is simple: are they fixing a broken login, ignoring a nuisance, or helping someone else enter the account?
A useful response plan removes the need to guess under pressure.
Give the employee one clear action
If a person did not initiate a sign-in, they should not approve its prompt or share a verification code to make the notifications stop. They should report it through an established company channel.
MITRE describes MFA request generation as a technique that can pressure users into accepting an authentication request. That is a reason to investigate an unexpected prompt, not proof that an attacker already has access.
Avoid asking the user to copy a code into a ticket or send it to a technician. The reporting workflow should preserve the event without turning support into another route for collecting authentication secrets.
Ask questions that establish the event
The first responder needs the account, approximate time, application shown, whether any request was approved, and whether the person was trying to sign in elsewhere. Record the answers without blaming the employee.
A hypothetical user may have approved one prompt before noticing the pattern. The response should make that fact easy to disclose. A punitive conversation encourages incomplete timelines precisely when the team needs accuracy.
Use the identity provider's authorized logs to review the event. A remembered location label on a phone is not a complete attribution, and an IP address alone does not identify the person behind it.
Separate attempted access from successful access
Build the timeline around the events the system actually records: failed attempts, completed authentication, new sessions, changes to authentication methods, and sensitive activity after sign-in.
If unauthorized access is suspected, follow the organization's account containment procedure. That can include restricting access, reviewing registered methods, and revoking applicable sessions. The right sequence depends on the service and the urgency.
Do not tell a user that changing the password guarantees every existing session has ended. Session response requires its own verification.
Fix the workflow that made the event confusing
After immediate review, ask whether the account's authentication method invites repeated approval requests and whether a stronger method is available. Check who can enroll a replacement device or authorize a recovery.
A tabletop can be as short as asking the help desk: “What do we do when an employee reports ten prompts they did not start?” Compare the answers across shifts.
For rollout planning, use the phishing-resistant MFA coverage review. The best outcome is not merely a blocked prompt; it is a response that people recognize, trust, and can follow quickly.