They should not assume a familiar sender makes the content safe. The safest response is to confirm through another channel, such as a phone call or separate message, that the colleague actually sent the item. This matters because attackers often impersonate known contacts after harvesting addresses from social networking sites or public sources. Verification prevents a routine inbox from becoming an entry point.
Why a familiar sender is not enough
A colleague’s name in the From field is not proof that the message is safe. Email display names, reply chains, compromised accounts, and lookalike addresses can all make a malicious link or attachment appear routine. The right default is to treat the item as untrusted until the sender is confirmed through a separate channel.
The key judgement is simple: familiarity lowers suspicion, but it does not remove the need to verify. That matters because many attacks succeed by borrowing trust from an existing relationship rather than inventing a new one.
How to verify before you click or open
Use a second, independent channel that does not rely on the same message thread. A short phone call, chat message, or in-person check is enough to confirm whether the colleague really sent the file or link. If the colleague did not send it, stop there and report the message through your normal security process.
If you do confirm the sender, still inspect the destination before interacting with it. Check for odd domain names, shortened links, unexpected file types, and requests that do not fit the colleague’s normal work pattern. Confirmation of sender identity is necessary, but it does not make every attachment harmless.
What attackers are counting on
These messages work because people are conditioned to trust known contacts and move quickly. Attackers often harvest names and relationships from public sources or social networking sites, then use that information to make a message feel credible. Once a user clicks, the result can be malware delivery, credential capture, or unauthorized access to internal systems.
Attachments can be just as risky as links. A document, archive, or invoice may trigger a malicious payload, redirect to a fake login page, or exploit a weakness in the local application used to open it. The social engineering step is what opens the door; the technical payload is what turns that trust into compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1566 — Phishing | Explains deceptive links and attachments sent through trusted-looking messages. |
| Recommendation — Map suspicious messages to phishing tradecraft and train users to verify via a separate channel. | ||
| CIS Controls v8 | CIS-14 — Security Awareness and Skills Training | Employees need repeatable judgement for spotting and validating suspicious messages. |
| Recommendation — Reinforce verification-before-click behavior through role-based awareness training. | ||
| NIST CSF 2.0 | PR.AT-01 — Awareness and Training Policy Is Established and Maintained | This behavior depends on staff training that normalizes out-of-band verification. |
| Recommendation — Establish training that requires independent confirmation of unexpected links and attachments. | ||
| NIST SP 800-53 Rev 5 | AT-2 — Awareness Training | Users must be trained to verify sender legitimacy before opening content. |
| Recommendation — Train personnel to confirm unexpected messages through a separate communication path. | ||
Practitioner Guidance
What to prioritize: Build the habit of verification before interaction, especially when the message asks for urgency, secrecy, or an unusual action. Those cues are often stronger warning signs than the sender name itself.
What to verify: Confirm the sender through a separate path, then check whether the message content, timing, and requested action match normal colleague behavior. If any one of those elements looks off, treat the item as suspicious even if the sender is real.
Common mistake: Users often assume a reply-thread message is safe because it appears inside an existing conversation. A compromised account can preserve that thread history and still deliver a malicious link or attachment.
Practitioner takeaway: Trust the person only after you have verified the message, not before, because the sender identity is exactly what many phishing campaigns try to mimic.
Related resources from NHI Mgmt Group
- What should employees do after they click a suspicious link or open a phishing attachment?
- What should employees do when they receive a job offer or recruitment message from an unknown sender?
- Why do helpers like raw, html_safe, and link_to become dangerous when they receive user-controlled values?
- What do organisations get wrong when they assume employees are the weakest link?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
