No Ticket Needed

Appearance

How to Verify a Suspicious Call or Message from IT

Applies toMicrosoft 365 (Outlook, Microsoft Teams); phone calls, text messages, and in-person requests
11 min read Updated 7 Aug 2026

By , 10+ years in IT support and helpdesk How these guides are checked

Quick Answer

Hang up and call the help desk back on a number you look up yourself — from the intranet, the directory, or a previous ticket email — never one the caller supplies. No legitimate IT process asks you to read out an MFA code, approve a push you did not trigger, or reveal your password.

Checked against Microsoft Learn - end of support and retirement and Google Chrome Releases between 5 Aug 2026 and 12 Sep 2026. Nothing published in that period has been linked to this guide.

Summary ​

The most effective impersonation attack is not a stranger pretending to be a bank — it is someone pretending to be your own help desk. This article explains why internal impersonation works, which requests are never legitimate no matter who is asking, and the one verification habit that defeats all of them.

In this guide

Before You Start ​

  • None required. This article applies to every user, on any device, on any platform.

Instructions ​

1. Understand Why This Attack Works ​

Internal impersonation succeeds on three ingredients, and it helps to name them before you meet them.

  • Urgency. "Your account is flagged for suspicious activity and will be disabled in ten minutes." A deadline stops you from checking, which is the entire point of the deadline.
  • Authority. IT is the one department that legitimately asks people to change settings, install things, and click Approve. An attacker borrowing that authority is asking for something that feels routine.
  • Vocabulary. A good impersonator says "I'm calling from the service desk about your Conditional Access policy," names your actual ticketing system, references a real project, and knows your manager's name. That vocabulary is researched, not proof of employment. Org charts, project names, and internal jargon leak through public directories, job adverts, conference talks, and earlier breaches.

Nothing about this is a comment on how careful you are. These calls succeed on trained, security-conscious people, because the whole design is to make the request feel like part of a normal working day.

2. Know the Requests That Are Never Legitimate ​

This is the shortest path to safety: instead of judging whether a caller sounds genuine, judge what they are asking for. Four requests are always illegitimate, regardless of who is asking, how senior they claim to be, or how urgent it sounds.

  • Reading out an MFA code or one-time passcode. The code exists to prove that you are you. Reading it aloud transfers that proof to whoever is listening. No internal process needs it.
  • Approving a push notification you did not trigger. If you were not typing your password somewhere at that moment, a prompt on your phone means someone else was. Tap Deny, and Report fraud if the app offers it.
  • Installing a remote-access tool the caller directs you to. Genuine support tools are already deployed by your organization or launched from your own ticketing portal. A download link read out over the phone is not a support tool.
  • Giving your password. Nobody in IT needs it. Technicians who need access to your account reset it or use their own administrative accounts — they never ask you to say it, type it while they watch, or enter it into a form they sent you.

Note: A request that arrives before you asked for help is worth extra attention. If you opened a ticket five minutes ago and someone calls about it, that is ordinary. If nobody was expecting to hear from IT and IT calls anyway, verify first.

3. Use the Callback Rule ​

There is one defence that works against every version of this attack, including ones that have not been invented yet: end the conversation and re-establish it on a channel you chose.

  1. End the call, or stop replying to the message. You owe no explanation. "I'm going to call the help desk back on our internal number" is a complete sentence.
  2. Look up the help desk number yourself. Reliable sources are the IT page on your intranet, your ticketing portal, the company directory in Outlook or Microsoft Teams, the asset sticker on your laptop, and the confirmation email from any previous ticket you raised.
  3. Never use a number the caller supplied — spoken on the call, printed in the email signature, listed on the web page they sent, or attached to the caller ID. Every one of those is under the caller's control. Caller ID in particular is trivial to fake, so seeing the real help desk number on your phone screen proves nothing.
  4. Call the number you found and describe what happened: "Someone called claiming to be from the service desk and asked me to approve an MFA prompt. Can you confirm whether that was one of your team?"
  5. For a Microsoft Teams message, start a new chat with the person you look up in the company directory rather than replying in the thread you were messaged in. Replying in the existing thread reaches the impersonator, not the colleague.

Tip: Save your help desk number in your phone contacts today, while nothing is going wrong. The moment you need it is the moment you are least able to search for it calmly.

A real IT department will never be annoyed at being called back to verify. Support teams train people to do exactly this. A technician who reacts to a callback with irritation, pressure, or "there isn't time for that" has told you everything you needed to know — genuine work survives a two-minute pause.

4. Spot Lookalike Accounts in Teams and Email ​

Not every version of this arrives by phone. The written ones carry signals worth learning.

In Microsoft Teams:

  • Look for the External tag next to the sender's name. Teams adds it automatically to anyone outside your organization. An account calling itself "IT Helpdesk" while carrying an External tag is not your IT help desk.
  • Click the sender's name to open their profile card. A genuine colleague has a job title, a department, and a place in the org chart. An impersonator's card is usually near-empty.
  • Watch for display names that describe a function rather than a person — "IT Support", "Service Desk", "Microsoft 365 Admin". Your real technicians have human names.

In Outlook:

  • Read the external-sender banner above the message body if your organization adds one. Some organizations also insert a marker such as EXTERNAL into the subject line.
  • Hover over the sender name to reveal the full address, and read the domain character by character. Lookalike domains swap a letter, add a hyphen, or append a word — a message from [email protected] is not from yourcompany.com.
  • Treat a reply-to address that differs from the sender address as a decision point, not a curiosity.

Note: The hardest case is a message with no External tag and a perfectly correct internal address, sent from a colleague's genuinely compromised account. The tags cannot help you there — the callback rule still can. Verify through a different channel than the one the message arrived on.

5. Treat a Familiar Voice as Unproven ​

Voice cloning now needs only a few seconds of recorded speech, and plenty of people have that much audio in a public webinar, a podcast, a conference recording, or a voicemail greeting. A voice that sounds like your IT manager is no longer evidence that it is your IT manager.

Two practical responses:

  • Agree a verification word. Pick a shared word or short phrase with your immediate team and with anyone who might call you about access, payments, or credentials. When something feels off, ask for it. A cloned voice cannot produce a word that was never spoken online.
  • Ask a question the real person answers instantly and a researcher cannot. "What did we order at the team lunch on Thursday?" beats "What's my employee number?" — the second is on a document somewhere, the first is not.

If the answer does not come, end the call and use the callback rule. This applies equally to a finance request from a familiar executive voice and to a support request.

Deep dive: How to Spot Deepfake Audio and Video Scams.

6. Act Quickly If You Already Complied ​

If you approved something and the feeling arrived a minute later, you are in the most recoverable situation there is. What matters now is speed, and speed comes from acting rather than replaying the conversation. Work through whichever of these apply.

  1. Change your password immediately. Go to https://mysignins.microsoft.com and use Change password. This alone breaks most sessions the attacker holds.
  2. Delete sign-in methods you do not recognize. If you are not certain an entry is yours, remove it anyway — you can add your own phone or authenticator straight back from the same page in under a minute, and leaving an attacker's in place is the far more expensive mistake. Open the Security info page and remove any phone, authenticator, or email entry that is not yours. Attackers add their own so that a password change does not lock them out.
  3. If you installed remote-access software or a session is running: close the session window, disconnect the computer from the network by turning off Wi-Fi and unplugging the network cable, and leave the machine powered on so IT can examine it. Make the next call from your phone, not the affected computer.
  4. Check your recent sign-in activity and mailbox rules. Look for sign-ins from places you have not been, and for forwarding rules you did not create.
  5. Report it to the help desk with specifics. Give them the time, the channel, and the exact action: "At about 2:15 pm I approved an MFA prompt after a phone call from someone claiming to be IT. Please review my account for new sign-in methods, mailbox rules, and app consents, and sign out my active sessions." That sentence lets them start work immediately.

Note: Reporting fast is the whole game, and no support team treats it as a failure. The cases that turn expensive are the ones nobody mentioned for three days.

Deep dive: What to Do If You Clicked a Phishing Link and How to Run a Personal Security Checkup in 15 Minutes.

Troubleshooting ​

INFO

Verifying a caller costs two minutes and never causes harm. Approving a request from someone you could not verify can cost your organization weeks. When the two are weighed against each other, the callback wins every time — which is why help desks teach it rather than resent it.

Symptom / ErrorPotential CauseSolution
Caller knows your ticket number, manager, and internal jargonResearched or previously breached dataDetailed knowledge is not identity. End the call and dial the help desk number from your intranet (Step 3).
Caller ID shows your real help desk numberCaller ID spoofingCaller ID is trivial to fake. Hang up and dial the number yourself rather than trusting the display.
Caller says a callback will delay the fixManufactured urgencyGenuine work survives a two-minute pause. Pressure not to verify is the strongest signal available.
Teams message has no External tagCompromised internal accountTags cannot flag a genuine account in the wrong hands. Verify on a different channel — phone the colleague on their directory number.
You cannot find the help desk number anywhereIntranet page never bookmarkedOpen any previous ticket confirmation email — the reply address and support number are in it. Then save the number in your phone contacts.
A remote-control session is already running on your screenRemote-access tool installedClose the session, turn off Wi-Fi and unplug the network cable, leave the computer on, and call the help desk from your phone.

Last updated:

Frequently asked questions

How do I know if a call from IT is really from IT?
Hang up and call the help desk back on a number you look up yourself — from the intranet, the company directory, or a previous ticket email. Never use a number the caller gives you. A genuine technician expects the callback and is not offended by it.
Is it ever okay to read out my MFA code to IT?
No. There is no legitimate internal process that requires you to read a one-time code aloud or type it at someone else's direction. The code exists to prove you are you, so handing it over hands over your identity.
The caller knew my ticket number and my manager's name. Doesn't that prove they are internal?
No. Ticket numbers, org charts, project names, and internal vocabulary leak through public directories, social media, and earlier breaches. Detailed knowledge is a sign the attacker did homework, not a sign they are a colleague.