A social engineering method where the attacker places deceptive text in the sender display name or message fields that users see first. The underlying account may be legitimate, but the visible identity claim is crafted to create urgency, confusion, or trust.
Expanded Definition
Display name abuse is a form of deception that exploits the human habit of trusting the first visible identity cue in email, chat, collaboration, and messaging tools. Rather than taking over an account, the attacker manipulates the sender name, subject line, reply-to label, or message preview so the communication appears to come from a colleague, executive, supplier, or internal service desk. That distinction matters: the underlying account can be legitimate, but the visible identity claim is engineered to mislead.
In security operations, this tactic sits alongside impersonation, business email compromise, and brand spoofing, but it is narrower in scope because the abuse is concentrated in the presentation layer. Definitions vary across vendors, and no single standard governs this yet, so teams should treat it as a user-facing identity deception problem rather than a pure email authentication failure. Guidance from NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to identify and protect trusted communication paths, not just credentials. The most common misapplication is assuming DMARC or account lockout alone will prevent it, which occurs when the message is delivered through a legitimate mailbox or approved platform.
Examples and Use Cases
Implementing protections against display name abuse rigorously often introduces review friction, requiring organisations to balance fast internal communication against stricter message validation and user verification steps.
- A finance employee receives a message that appears to be from the CFO, but the display name is spoofed while the sender account is external and unrelated to the organisation.
- A help desk agent sees a ticket message that appears to come from an internal identity team account, but the visible name is copied from a real service mailbox to trigger a rushed password reset.
- A supplier payment request arrives in a collaboration app with the name of a known procurement contact, even though the actual account is newly created and the wording is designed to create urgency.
- An attacker uses a real tenant account in a messaging platform and changes the display name to match an executive, then requests sensitive files or MFA approval.
- Security teams test MITRE ATT&CK-style social engineering patterns internally to measure whether staff trust the visible name before checking the underlying address or account context.
These use cases show why display name abuse is often more effective in fast-moving channels where users skim rather than inspect details. It is especially dangerous in environments that rely on shared inboxes, threaded chat, and mobile notifications, where the visible name may be the only identity cue the user notices.
Why It Matters for Security Teams
Display name abuse matters because it defeats assumptions that identity verification happens automatically at the transport layer. Security teams may have strong email authentication, conditional access, and endpoint controls, yet still experience fraud if users are trained to trust names over verified account context. This is particularly relevant for NHI-adjacent environments where service accounts, automation identities, and agent-driven workflows generate large volumes of routine messages; attackers exploit that noise to hide in plain sight.
Defensive programs should pair technical controls with process design: verified sender indicators, restricted impersonation of executives or support functions, alerting on lookalike display names, and user training that emphasizes checking the full identity context. This aligns with the operational intent of OWASP Agentic AI Top 10 style guidance when automated agents are part of the message path, because an agent can become the target or the amplifier of deceptive instructions. Organisations typically encounter the consequences only after an employee approves a fraudulent action, at which point display name abuse becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST SP 800-63 set the technical controls, and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AT-01 | Awareness and training help users verify identity cues beyond the display name. |
| NIST SP 800-53 Rev 5 | AU-6 | Monitoring and analysis help detect spoofed identity patterns in communications. |
| ISO/IEC 27001:2022 | A.5.16 | Identity management and authentication controls support trusted communication handling. |
| NIST SP 800-63 | IAL2 | Identity assurance concepts are relevant where users mistake presentation for verification. |
| OWASP Non-Human Identity Top 10 | NHI workflows can be abused when agents or service identities are impersonated by name. |
Treat display names as non-assurance signals and verify identity through stronger checks.
