Phishing
Recognize deceptive requests, verify them through trusted channels, and understand what to report after interacting with a message.
A request designed to borrow trust
Phishing is deceptive communication intended to make someone take an unsafe action. The request might ask for a password, a downloaded file, a payment, or approval of an authentication prompt. Email is a familiar channel, but the same pattern appears in text messages, collaboration tools, social networks, and phone conversations.
The useful question is not simply “Does this look professional?” It is “What action does this message want, and what independent evidence supports the request?” A polished message, familiar display name, or correct job title can make a story convincing without proving who sent it. Phishing is one application of Social engineering.
Follow the request, not the appearance
Imagine a fictional learner receives a message saying their academy account will be suspended in thirty minutes. It links to a sign-in page and asks them to confirm their password. The message uses the academy's colors and mentions a real class.
The learner pauses and opens the academy portal using their existing bookmark. No warning appears there. They contact support through the established directory rather than the telephone number in the message. This changes the verification route: the suspicious message no longer controls both the claim and the channel used to check it.
A suspicious request should be checked through an independently known channel before taking action. Open full-size diagram ↗
The example is illustrative. It does not mean every urgent message is malicious or every missing portal notice proves fraud. It shows how to obtain evidence without relying on details supplied by the requester.
Signals worth examining
Look at the actual sender address, the destination of a link, the requested action, and whether the request fits the normal process. On a small screen, important details may be hidden behind a display name or shortened link. A familiar domain elsewhere in a long address does not necessarily identify the destination's owner.
Attachments and shared-document invitations also deserve context. Were you expecting the file? Does opening it require an unusual installation or a new login? A colleague's genuine account can be compromised, so a recognizable sender is useful context rather than a guarantee.
Spelling errors can be a signal, but their absence is weak reassurance. A well-written message can still request an unsafe action. Conversely, an ordinary typo does not establish malicious intent.
If you already interacted
Distinguish what happened: reading the message, following a link, entering credentials, approving a prompt, opening a file, or transferring money are different events. Report the actual actions promptly through your organization's process, with the message and relevant times. Avoid hiding an incident because the message appeared convincing.
If credentials were entered into a suspected fake page, use an independently trusted route to obtain help and secure the account. An account response may involve more than changing a password, including reviewing active sessions and other access paths. Follow Incident response rather than assuming one action fixes every case.
Build a repeatable habit
Use a fictional message for practice. Underline its requested action, circle the urgency cue, and identify one verification channel you already trust. Explain what you would report and why.
Multifactor authentication can reduce some account risks, but it should accompany a reliable reporting process and thoughtful verification. The goal is to make checking a questionable request normal and easy, rather than expecting people to judge every message perfectly.
References & further reading
Original explanations, with primary references for deeper study.
NIST: An Introduction to Information SecurityCISA: Phishing security tips