New gTLDs in 2026 raise the stakes for domain identity

At a glance

What this is: This is a DigiCert analysis of the 2026 gTLD application round and the way domain names now sit at the centre of digital identity, trust, and operational scale.

Why it matters: It matters because expanded domain fleets increase the number of identities, dependencies, and failure points IAM, security, and infrastructure teams must govern together.

👉 Read DigiCert's analysis of the 2026 new gTLD round and digital trust

Context

The next gTLD round is really a governance story about domain identity at scale. As more namespaces are added, organisations have to treat the domain itself as an identity surface that must be resolvable, authenticated, and protected across DNS, PKI, and email authentication.

That shift matters for IAM and security teams because domain control is no longer just a branding or infrastructure issue. It affects trust boundaries, operational ownership, and the ability to prove that a domain and the services behind it are legitimately managed over time.

Key questions

Q: How should security teams govern new gTLDs as part of digital trust?

A: Security teams should treat each domain as a governed identity asset, not a standalone technical asset. That means assigning ownership, tracking delegation, coordinating DNS and certificate control, and aligning email authentication settings under one operational model. The goal is to prove who controls the namespace and how trust is maintained across its lifecycle.

Q: Why do new gTLDs increase identity governance complexity?

A: New gTLDs increase complexity because each additional namespace adds delegation, provider dependency, and trust verification work. The challenge is not only scale, but coordination across DNS, PKI, and messaging controls. If those layers are owned separately, organisations lose visibility into where trust is established, where it is weakened, and who can restore it.

Q: What breaks when domain governance is split across different teams?

A: When domain governance is split, teams can make isolated changes that undermine the larger trust model. A domain may resolve correctly while certificates, email authentication, or ownership records drift out of sync. That creates gaps that are hard to audit and slower to recover, especially during misdelegation or spoofing events.

Q: Who should be accountable for domain trust controls and delegation?

A: Accountability should sit with a named business owner and a named technical owner, supported by security and infrastructure governance. The organisation must be able to show who approved the domain, who operates it, and who can change it. That clarity matters because trust failures at the domain layer often cross team boundaries.

Technical breakdown

How new gTLDs change the domain identity surface

A gTLD is the top-level suffix in a domain name, such as .com or .org, but the operational effect goes beyond naming. Each new namespace creates another set of registries, delegation paths, DNS records, and trust relationships that must be maintained consistently. The 2012 expansion showed how quickly this surface can grow, and the 2026 round continues that pattern with updated evaluation and delegation requirements. From an identity perspective, the domain becomes part of the trust fabric because it anchors how users, services, and email systems recognise legitimacy.

Practical implication: track domain inventory, ownership, and delegation state as part of identity governance rather than treating DNS as a separate operations silo.

Why registry service providers matter to secure delegation

Registry service providers operate the technical infrastructure behind top-level domains, including DNS resolution and domain registration systems. ICANN’s evaluation requirement is designed to confirm that applicants can rely on a provider with the capacity to support availability and security at scale. That creates a control point before delegation, not after a problem appears. For practitioners, the important issue is not whether a registry is public or private, but whether the party running the domain layer can sustain resilience, authentication integrity, and administrative control across the full lifecycle.

Practical implication: add registry-provider assurance to third-party risk and lifecycle governance reviews before any new domain is delegated.

Why DNS, PKI, and email authentication now need one trust model

Domain infrastructure no longer behaves like a single control plane. DNS makes the domain resolvable, PKI makes services cryptographically trustworthy, and email authentication reduces impersonation risk. When those layers are managed separately, gaps appear between name ownership, certificate issuance, and message authentication. That is where brand abuse, spoofing, and trust drift begin. The architectural point is simple: the domain is now an identity anchor, so its controls have to be aligned across discovery, verification, and communication channels instead of being owned by disconnected teams.

Practical implication: align DNS change control, certificate governance, and email authentication policy under one domain trust model.

NHI Mgmt Group analysis

New gTLD expansion turns the domain into an identity governance object. The article frames domain names as more than addressability, and that is the correct security lens. Once a domain becomes an anchor for trust, discoverability, and brand representation, it starts behaving like a governed identity asset rather than a static technical label. The implication is that IAM, security architecture, and digital trust teams need a shared operating model for domain ownership.

Domain-level trust fails when DNS, PKI, and email authentication are managed as separate controls. This article points directly at convergence, and that is where many programmes are still lagging. A domain can be resolvable yet unauthenticated, or authenticated in one channel and exposed in another. The implication is that trust policy must be evaluated across the domain lifecycle, not only within one control family.

Registry assurance is a third-party identity control, not just a procurement check. ICANN’s requirement for a registry service provider shows that the delegatee matters as much as the delegation. If the provider running the namespace cannot sustain availability and security, the organisation’s domain trust story is already weakened. The implication is that supplier review must cover operational identity dependency, not only commercial terms.

Brand identity and infrastructure identity are converging at the domain layer. The article makes clear that new namespaces create both opportunity and complexity, which is the right framing for governance teams. More domains mean more identities to secure, more lifecycle events to manage, and more opportunities for inconsistency between what the organisation owns and what it can actually control. The implication is that domain governance now belongs inside broader identity risk management.

Identity governance for domains should be measured by controllability, not volume alone. A larger gTLD universe is not automatically a problem if ownership, delegation, verification, and recovery are all disciplined. The real issue is whether teams can prove who controls the namespace, who can change it, and how quickly trust can be restored after misuse. The implication is that domain programmes need audit-ready control evidence, not just domain counts.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, which shows how slowly identity-related trust issues are often remediated in practice.
• For a broader control baseline, Top 10 NHI Issues is the next step for teams aligning identity governance with operational trust.

What this signals

Domain trust will increasingly be judged by lifecycle discipline, not by namespace size. As organisations consider new gTLDs, the practical question is whether they can still prove ownership, delegation, and recovery across a growing domain portfolio. The teams that already struggle with visibility will feel that pressure first, because expansion magnifies governance gaps faster than it creates new business value.

The strongest programmes will treat domain management as part of identity operations, with ownership, review, and rollback paths defined before expansion happens. That puts DNS, certificates, and email authentication into the same control conversation as access reviews and third-party risk, which is where they belong.

Identity control at the domain layer now needs the same evidence standard as NHI governance. If an organisation cannot show who changed a domain, who approved it, and what trust dependencies it affects, it cannot claim mature control. That is the same audit logic security teams already apply to secrets and service accounts.

For practitioners

• Inventory domains as identity assets Map every owned, delegated, parked, and legacy domain to a business owner, technical owner, and trust dependency profile. Include DNS, certificate, and email-authentication responsibilities in the same register so domain control is visible end to end.
• Add registry-provider assurance to third-party reviews Treat registry service providers like critical identity infrastructure suppliers. Verify availability commitments, operational resilience, and administrative controls before new gTLD delegation or renewal decisions are approved.
• Unify DNS, PKI, and email authentication governance Put domain change control, certificate lifecycle management, and DMARC, SPF, and DKIM ownership into one operating workflow. That reduces the chance that one control is updated while the others drift out of alignment.
• Define recovery ownership for domain trust events Pre-assign incident roles for hijack, spoofing, misdelegation, and certificate abuse scenarios. The team that owns the domain must be able to prove restoration steps, approval paths, and escalation contacts before an event occurs.

Key takeaways

• New gTLDs expand the domain identity surface, which means DNS governance now has direct security and trust implications.
• The main risk is control fragmentation, where DNS, PKI, and email authentication drift apart and weaken domain legitimacy.
• Practitioners should govern domains as identity assets with clear ownership, lifecycle control, and recovery accountability.

Key terms

• Generic Top-Level Domain: A generic top-level domain is the suffix at the end of a domain name, such as .com or .org. In governance terms, it is part of the trust surface because it affects delegation, brand representation, discoverability, and the operational controls needed to manage the namespace safely.
• Registry Service Provider: A registry service provider operates the technical infrastructure behind a top-level domain, including DNS resolution and registration systems. It is a critical dependency because the provider's resilience, control processes, and security posture directly affect whether the namespace can be trusted and operated reliably.
• Domain Trust Model: A domain trust model is the set of controls that keep a domain resolvable, authenticated, and resistant to misuse. It spans DNS, certificate management, and email authentication, and it matters because users and systems often interpret domain legitimacy as proof of organisational legitimacy.
• Digital Trust: Digital trust is the confidence that a domain, service, or communication channel is genuinely controlled by the organisation it claims to represent. In practice, it depends on technical proof, governance ownership, and the ability to detect and recover from misuse across the domain lifecycle.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: The next wave of new gTLDs is coming in 2026. Read the original.