TL;DR: ICANN’s 2026 new gTLD round will add another wave of domain namespaces, with more than 1,200 new options introduced in the last expansion and registry operators expected to prove both financial and technical capability, according to DigiCert. Domain identity, DNS, PKI, and email authentication now have to be governed as one trust surface, not separate teams.
At a glance
What this is: This is an analysis of the 2026 ICANN gTLD round and the shift it creates in how organisations govern domain identity, DNS, PKI, and email authentication together.
Why it matters: It matters because IAM and security teams will need to treat domains as part of the identity control plane, not just as web infrastructure or brand assets.
By the numbers:
- The 2012 New gTLD Program introduced more than 1,200 new domain options, including IDNs and names like .futbol and .pizza.
Context
The 2026 ICANN gTLD round is a domain governance issue as much as an internet expansion event. New namespaces change how organisations assert identity online, because the domain becomes part of the trust decision, not just the address people type into a browser.
That matters for security and identity teams because domain trust is only durable when DNS resolution, certificate trust, and email authentication are governed together. When those controls sit in separate operational silos, the organisation inherits inconsistency at the exact point where users and counterparties decide whether to trust a domain.
The article frames the practical challenge correctly: expansion increases flexibility, but it also increases the number of identities, operators, and failure points that need lifecycle governance.
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 does domain expansion increase trust and fraud risk?
A: Because more namespaces create more opportunities for inconsistency between the domain’s registration state, its technical resolution, and the trust signals users rely on. That mismatch makes impersonation, misconfiguration, and operational drift easier to exploit or overlook.
Q: What breaks when DNS, certificates, and email authentication are run separately?
A: Trust becomes fragmented. A domain may resolve normally while certificate governance lags or email authentication is misaligned, which means different parts of the organisation will make different decisions about whether the domain is legitimate.
Q: How do security teams evaluate a registry service provider for a new gTLD?
A: They should assess whether the provider can sustain availability, technical operation, and secure delegation at the namespace level. In practice, that means treating the provider as part of the control environment and not as a purely commercial choice.
Technical breakdown
How new gTLDs change the domain trust surface
A gTLD is the final segment of a domain name, and a new round expands the namespace available to brands, communities, and registries. That expansion matters because the trust decision is no longer limited to whether a domain resolves. It now includes who operates the namespace, how the registry is run, and whether the domain can be authenticated and protected across DNS, PKI, and email channels. In practice, the domain itself becomes an identity object with operational dependencies, not just an internet label.
Practical implication: governance must cover the domain as a lifecycle-managed trust asset, not as a one-time registration.
Why registry service providers sit in the control path
ICANN requires applicants to identify a registry service provider because the registry operator is the technical layer that keeps the TLD available, secure, and resolvable. That makes the provider part of the trust chain, not an external convenience layer. The article also notes that applicants must demonstrate financial and technical capability, which signals that availability and operational resilience are now entry conditions for participation, not optional maturity indicators. For identity teams, that means delegation decisions carry control consequences.
Practical implication: treat registry provider selection as a governance decision tied to resilience, assurance, and operational accountability.
Why DNS, PKI, and email authentication converge at the domain level
Domain identity is increasingly enforced through multiple mechanisms at once. DNS proves where a domain resolves, PKI helps establish cryptographic trust, and email authentication controls whether messages sent from that domain should be accepted as legitimate. If those layers are managed separately, a domain can be technically live but still fail trust validation in channels users rely on every day. The article’s core point is that digital trust now depends on consistent treatment of the whole domain surface.
Practical implication: align domain registration, certificate governance, and email authentication under one operating model.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
New gTLDs turn domain identity into an identity-governance problem, not a naming exercise. The article is right to frame domains as anchors of digital identity, because namespace growth creates more trust decisions, more operators, and more lifecycle events to govern. For security leaders, the issue is not whether a domain exists, but whether the organisation can prove control, authenticity, and continuity across that domain’s full lifecycle. The practitioner conclusion is that domain governance now belongs in the identity programme, not only in web operations.
Domain trust breaks when DNS, PKI, and email authentication are treated as separate control planes. Each layer answers a different trust question, but users and counterparties experience them as one judgment about legitimacy. When those controls are administered independently, the organisation creates policy drift between resolution, cryptographic assurance, and message authentication. The practitioner conclusion is that domain-level trust must be governed holistically or it will fragment at the points that matter most.
Registry service provider selection is part of the control environment, not a procurement footnote. ICANN’s requirement to identify an RSP reflects a basic governance truth: operational capability is inseparable from trust in delegated internet infrastructure. That makes provider assurance, resilience expectations, and lifecycle accountability part of the identity surface for the TLD itself. The practitioner conclusion is that teams should evaluate who operates the namespace with the same seriousness they apply to any other delegated trust boundary.
Domain expansion increases identity blast radius, so governance must shift from asset ownership to operating discipline. More namespaces mean more opportunities for brand expression, but also more chances for misconfiguration, inconsistency, and trust erosion across global environments. The named concept here is domain identity blast radius: the extent to which one poorly governed namespace can affect authentication, trust, and discoverability across channels. The practitioner conclusion is to measure the operational blast radius before approving new namespace strategy.
ICANN’s 2026 round validates that internet identity is now a cross-functional control surface. Financial capability, technical operation, resolution reliability, and authentication integrity are all part of the same governance problem. That does not make the domain team the owner of everything, but it does mean identity, infrastructure, security, and email teams have to coordinate around one trust model. The practitioner conclusion is to assign clear control ownership before expansion forces it.
What this signals
Domain identity blast radius: New gTLDs enlarge the number of places where trust can fail, which means domain governance needs the same lifecycle discipline that teams already apply to other delegated identities. The practical shift is from isolated domain ownership to measurable control over registration, authentication, and recovery.
The 2026 round also shows why internet-facing identity is now a cross-team problem. Security, DNS, certificate, and messaging teams will need shared ownership models if they want domain trust decisions to stay consistent across channels.
For practitioners
- Define domain lifecycle governance Map domain registration, delegation, renewal, certificate coverage, and email authentication to named owners and review cadences so no namespace sits outside accountable control.
- Unify DNS, PKI, and email authentication Establish one operating model for DNS integrity, certificate trust, and domain-based message authentication so policy gaps do not emerge between teams.
- Assess registry provider assurance Require evidence of operational resilience, availability commitments, and security controls from the registry service provider before supporting a new gTLD application.
- Measure domain identity blast radius Inventory which brands, countries, and business units would be affected if a new namespace failed validation, resolution, or authentication controls.
Key takeaways
- New gTLD expansion changes domain governance by increasing the number of identities and operators that security teams have to manage.
- The main risk is fragmentation between DNS, PKI, and email authentication, which weakens trust even when each control seems to work on its own.
- Practitioners should treat new namespace decisions as lifecycle governance problems and assign clear control ownership before expansion forces it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST Zero Trust (SP 800-207), NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Domain trust now depends on controlled delegation and authenticated use across the trust surface. |
| ID.AM-03 — Asset Management | New gTLDs create identity assets that must be inventoried and governed as part of the trust surface. | |
| Recommendation — Apply PR.AA-05 to govern domain-related access and delegation with explicit ownership and review. Inventory every domain and namespace as a managed asset with accountable lifecycle ownership. | ||
| NIST Zero Trust (SP 800-207) | Section 5.4 — Continuous verification | Domain trust requires ongoing verification of DNS, PKI, and authentication state rather than one-time approval. |
| Recommendation — Use continuous verification for domain trust signals instead of relying on initial registration checks. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Device Accounts) | Registry and DNS infrastructure depends on machine identities and delegated technical trust. |
| Recommendation — Apply IA-9 to any service or workload identities that operate domain infrastructure. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article’s governance model depends on clear ownership and lifecycle control for domain operators and providers. |
| Recommendation — Use CIS-5 to assign, review, and revoke domain-related accounts and provider access promptly. | ||
Key terms
- New gTLD: A new generic top-level domain added to the DNS namespace through an ICANN application round. In practice, it is a delegated internet identity surface that must be governed for resolution, authentication, and operational continuity, not just registered as a brand asset.
- 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 Identity: The trust state associated with a domain name across resolution, authentication, and usage. It is broader than ownership, because the domain must be provable, resilient, and consistently validated across channels such as DNS, PKI, and email.
- Domain Identity Blast Radius: The scope of harm that follows when a domain trust failure affects multiple brands, channels, or business units. It is a useful governance lens for new gTLDs because namespace expansion increases the number of places where one weak control can spread confusion or impersonation risk.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org