Lookalike characters are symbols or letters that are visually similar, such as zero and the letter O. They can make secrets harder for humans to read, transcribe, and troubleshoot. Excluding them improves usability in some contexts, but teams must balance that convenience against the character set required by the target application.
Expanded Definition
Lookalike characters are visually similar glyphs that can be mistaken for one another during human reading, copying, or verification. In NHI security, they matter because secrets, API keys, certificate labels, and environment names are often typed, pasted, or audited by people who must distinguish a zero from the letter O, or an uppercase I from a lowercase l.
Usage in the industry is still evolving because some systems intentionally exclude ambiguous characters to improve usability, while others preserve the full character set to maximize entropy or match application constraints. The practical question is not whether lookalike characters are “good” or “bad,” but where they create avoidable operator error. Standards do not settle this as a universal rule, so teams usually define the allowed alphabet based on the downstream system, the recovery workflow, and the risk of transcription mistakes. For control context, see NIST SP 800-53 Rev 5 Security and Privacy Controls, which supports secure handling and human-resistant operational practices.
The most common misapplication is treating every human-facing secret string as if it should use the broadest possible character set, which occurs when teams optimize for theoretical entropy but ignore manual entry and verification errors.
Examples and Use Cases
Implementing lookalike-character restrictions rigorously often introduces a tradeoff between readability and character-set size, requiring organisations to weigh operator accuracy against secret-generation flexibility.
- A temporary recovery code is generated without 0, O, I, and l so help desk staff can read it over the phone with fewer transcription errors.
- A certificate fingerprint or device pairing code uses a restricted alphabet because the code will be copied from a printed sheet during onboarding.
- An internal API token format preserves full entropy, but the display view groups characters into chunks to reduce confusion during troubleshooting.
- A secrets manager policy blocks ambiguous glyphs in manually entered bootstrap credentials while allowing them in machine-only values where humans never transcribe the string.
- A team documenting incident response procedures cross-checks naming conventions against the guidance in the Ultimate Guide to NHIs to reduce confusion during credential recovery.
For broader identity control patterns, organisations often pair this with NIST SP 800-53 Rev 5 Security and Privacy Controls when defining secure generation and handling requirements for operational secrets.
Why It Matters in NHI Security
Lookalike characters can turn a technically valid secret into an operational liability when humans must read, rotate, or recover it under pressure. In NHI environments, this often affects service accounts, bootstrap credentials, break-glass access, and certificate material, where a single transcription mistake can delay remediation or create shadow copies of secrets in chat, email, or ticketing tools.
The risk is amplified by the broader NHI reality described in the Ultimate Guide to NHIs: 79% of organisations have experienced secrets leaks, and 91.6% of secrets remain valid five days after notification, showing how quickly small handling errors can become persistent exposure. If a secret is hard to transcribe, teams are more likely to record it insecurely, delay rotation, or make ad hoc exceptions that weaken governance. This is why lookalike-character decisions belong in secret-design standards, not just in UI preferences.
Organisations typically encounter the consequences only after a failed rotation, a misread recovery code, or an incident response delay, at which point lookalike characters become 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 and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers secure secret generation and usability factors that affect human handling. |
| NIST SP 800-63 | AAL2 | Human entry errors in recovery material can undermine identity assurance processes. |
| NIST CSF 2.0 | PR.AC-1 | Access control processes depend on accurate secret entry and verification. |
Define secret formats that reduce transcription errors without weakening required entropy.
Related resources from NHI Mgmt Group
- How should security teams handle lookalike domains that mimic verification flows?
- What breaks when invisible Unicode characters are not checked in code and AI rules files?
- Why do lookalike domains remain effective even when email authentication is in place?
- Why do lookalike domains still work against trained users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
