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

Why This Matters for Security Teams

New gTLDs are not just branding decisions. They expand the trust surface that attackers can exploit through lookalike domains, weak delegation controls, misissued certificates, and inconsistent email authentication. Security teams need to govern each namespace as an identity-bearing asset with clear ownership, change control, and evidence of trust decisions across DNS, certificate, and mail systems. That aligns with the trust outcomes described in the NIST Cybersecurity Framework 2.0.

NHI Management Group’s guidance on the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is directly relevant because domain governance behaves like non-human identity governance: it requires ownership, lifecycle tracking, and revocation discipline. That matters most when the domain is used for authentication flows, customer communications, or machine-to-machine trust, where a missed delegation update can outlive the people who approved it.

Security teams often underestimate how quickly trust fragments across registrar records, DNS providers, certificate authorities, and email systems. In practice, many teams discover the problem only after an incident involving spoofing, failed DMARC enforcement, or an unauthorised domain transfer, rather than through deliberate governance.

How It Works in Practice

Effective governance starts by treating the gTLD and every delegated second-level domain as a controlled trust boundary. Assign a business owner, a technical owner, and a security owner, then require all changes to pass through an approval path that covers registrar access, DNS hosting, certificate issuance, and email authentication. That operational model mirrors NHI lifecycle controls because domains, like secrets and service accounts, can be re-used, transferred, or abused long after the original setup.

For practical control, teams should maintain a registry that ties each domain to:

• registered purpose and approved use cases
• delegation chain and administrative contacts
• DNSSEC status, where supported and operationally viable
• certificate issuance policy and monitoring for misissuance
• SPF, DKIM, and DMARC configuration for mail trust

Current guidance suggests using continuous monitoring rather than periodic point-in-time checks, because trust drift is common. A domain may be correctly approved at launch and then quietly lose protections through provider changes, expired certificates, or forgotten subdomain delegations. NHI Management Group’s Top 10 NHI Issues highlights the same governance failure pattern: visibility gaps, weak rotation, and poor ownership are usually what turn an identity asset into an exposure.

One useful benchmark from The State of Non-Human Identity Security is that only 1.5 out of 10 organisations are highly confident in securing NHIs. That confidence gap is a warning sign for domain trust too, because it usually means lifecycle control is fragmented across teams. These controls tend to break down when domains are managed through separate marketing, IT, and legal workflows because no single team can prove end-to-end trust ownership.

Common Variations and Edge Cases

Tighter domain control often increases operational overhead, so organisations must balance speed for launches against the assurance needed for trust-critical namespaces. That tradeoff becomes sharper when a new gTLD supports many branded domains, regional variants, or delegated partner use, because every exception adds another place for drift to enter the trust model.

There is no universal standard for every domain scenario yet. Best practice is evolving, especially for organisations that use domains for identity, payments, or customer login. In those cases, the governance bar should be higher than for purely marketing-oriented domains, and any transfer, registrar change, or nameserver update should require explicit review. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is useful here because auditors will usually ask for evidence of ownership, revocation, and monitoring, not just policy language.

Edge cases also include third-party-managed domains, mergers and acquisitions, and parked defensive registrations. In those environments, control can be technically correct but operationally weak if the organisation cannot prove who can change DNS, who approves certificates, and who receives alerts when trust signals change. Security teams should document those exceptions as explicit risk acceptances, not informal workarounds.

Related resources from NHI Mgmt Group

• How should security teams govern digital trust across human and machine identities?
• How should security teams govern AI trust signals across models, data, and outputs?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?