Homoglyph Naming

Expanded Definition

Homoglyph naming is the practice of constructing a software or service name with characters that look nearly identical to trusted ones, often by borrowing letters from another script. In NHI security, that visual deception matters because identifiers, package names, app registrations, and agent labels can all be abused to create trust on sight rather than trust by verification. Definitions vary across vendors on whether the risk belongs to branding fraud, phishing, or identity abuse, but in security operations the concern is the same: a name that passes a casual glance can still conceal a hostile object.

The term is most useful when reviewing inventories of agents, service accounts, OAuth clients, CI/CD components, and API-facing applications. It is a metadata signal, not proof of compromise, yet it often appears alongside weak governance, poor naming discipline, and missing approval workflows. Practitioners commonly tie this back to broader identity hygiene and visibility requirements described in the Ultimate Guide to NHIs, while governance teams can map the issue to asset and identity visibility expectations in NIST Cybersecurity Framework 2.0. The most common misapplication is treating homoglyph naming as a purely cosmetic issue, which occurs when teams do not validate character sets during intake or review.

Examples and Use Cases

Implementing homoglyph detection rigorously often introduces naming friction, requiring organisations to weigh fast self-service registration against stronger review of who is creating machine identities and why.

• A malicious app named with Cyrillic characters is uploaded to a developer portal and visually resembles an internal deployment tool.
• An attacker registers an API client whose name differs from a trusted integration by one homoglyph, hoping operators will approve it during a busy change window.
• A phishing kit impersonates a cloud service account label in logs, making the entry look routine unless a Unicode-aware parser flags it.
• A security team adds homoglyph checks to onboarding controls for agents and service accounts, then correlates suspicious names with other weak signals from the Ultimate Guide to NHIs.
• A governance reviewer compares naming policy against NIST Cybersecurity Framework 2.0 to ensure identity records remain distinguishable across systems and dashboards.

These use cases are most effective when paired with Unicode normalization, approved character allowlists, and human review for high-risk registrations. In mature environments, homoglyph analysis also helps separate innocent localization issues from deliberate impersonation.

Why It Matters in NHI Security

Homoglyph naming matters because NHI ecosystems are already hard to govern at scale, and ambiguity in names makes an already crowded inventory harder to trust. NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts, according to NHI Mgmt Group research in the Ultimate Guide to NHIs. In that environment, a deceptive name can help an attacker hide inside normal administrative activity long enough to obtain tokens, reuse credentials, or pass an approval workflow.

This is not just a naming problem. It intersects with identity governance, secrets handling, and Zero Trust expectations reflected in NIST Cybersecurity Framework 2.0, because the point is to verify machine identity before access is granted. Operators should assume that any visually similar label can be a control bypass attempt until character encoding, ownership, and provenance are confirmed. Organisations typically encounter the operational damage only after a fake service or agent has already been onboarded, at which point homoglyph naming becomes operationally unavoidable to address.