Should organisations use generated usernames and plus-addressed email addresses for everyday accounts?

Why This Matters for Security Teams

Generated usernames and plus-addressed email addresses are not just formatting choices. They shape how easily accounts can be correlated, discovered, reused, or targeted across SaaS platforms, support desks, and identity workflows. For teams managing non-human identities and service accounts, identifier design influences auditability, user privacy, and the blast radius of account enumeration. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful baseline for thinking about identifier hygiene, least privilege, and access accountability, even when the account is not human.

The practical question is not whether these identifiers are clever, but whether the receiving service preserves them consistently and whether operations can reliably map them back to ownership without creating a second source of truth. In environments with strong separation requirements, generated identifiers can reduce exposure of real names and limit account correlation. In environments with weak governance, they can make recovery, offboarding, and incident response slower. NHIMG’s DeepSeek breach coverage is a reminder that identity and secret sprawl often becomes visible only after exposure, not during design.

In practice, many security teams discover identifier sprawl only after duplicate accounts, failed recovery, or a support escalation has already exposed the mapping.

How It Works in Practice

Selective use is the safest operating model. Generated usernames work best where the service accepts arbitrary identifiers, the account does not need to be human-readable, and correlation across systems is a concern. Plus-addressed email addresses are useful when the platform treats the local part as an opaque mailbox alias, but many systems either reject the plus sign, strip it, or normalize it inconsistently. That means the control is service-dependent, not universal.

A practical rollout usually combines identifier design with inventory discipline:

• Use generated usernames for externally exposed or shared services where predictable names would reveal role, team, or person identity.
• Use plus-addressed email addresses only after confirming the downstream service preserves the full address during login, password reset, and notifications.
• Store the canonical account-owner mapping in an authoritative system, not in spreadsheets or ticket comments.
• Prevent identifier reuse across services, especially for accounts tied to privileged access, automation, or support tooling.
• Review whether the identifier leaks business structure, contractor status, or environment names.

This matters because account identifiers often become a weak form of secret. When paired with exposed metadata, they can make enumeration and phishing easier. The broader secrets problem documented in The State of Secrets in AppSec shows how quickly weak operational hygiene becomes systemic when teams rely on confidence instead of verification. Current guidance suggests treating identifier choice as part of identity hardening, not just convenience.

These controls tend to break down when service integrations normalize email addresses differently across login, SSO, and notification flows because the original identifier is no longer stable end to end.

Common Variations and Edge Cases

Tighter identifier control often increases operational overhead, requiring organisations to balance privacy and correlation resistance against supportability and troubleshooting speed. That tradeoff is most visible in mixed environments where some services support aliases cleanly and others do not.

For internal low-risk tools, a simple naming convention may be acceptable if the organisation already enforces unique ownership, strong MFA, and clean offboarding. For customer-facing systems, shared admin consoles, and anything that touches secrets or privileged workflows, generated usernames are usually the safer default. Best practice is evolving for agentic and automated accounts, but there is no universal standard for this yet; the important point is that machine-facing identifiers should be stable, unique, and easy to revoke.

Edge cases include delegated mailboxes, contractor accounts, and incident-response accounts. Plus-addressing can help isolate service registrations, but it can also create false confidence if the platform silently canonicalizes addresses or if downstream analytics collapse aliases into one user. If the business depends on precise attribution, the organisation should test the full lifecycle: provisioning, login, password reset, alerting, offboarding, and legal hold. Where that lifecycle cannot be validated, a generated identifier with explicit mapping is usually safer than an email trick that only works in theory.

Related resources from NHI Mgmt Group

• When should organisations use just-in-time access instead of standing privileges for high-risk identities?
• When should organisations use delegated approval instead of waiting for the original reviewer to respond?
• When should organisations revoke access to social media accounts and review permissions?
• Why do non-human identities create more audit risk than human accounts?