Delegation shifts the operational work to a provider, but accountability for domain integrity stays with the organisation. Teams still need to know who can make changes, how access is revoked, and how recovery works if provider access is disrupted. Managed service does not remove the need for identity governance over the people and systems using it.
Why This Matters for Security Teams
Managed DNS delegation is often treated as a vendor-management decision, but accountability for domain integrity, change control, and recovery remains with the organisation. That distinction matters because DNS is both an availability dependency and an identity trust anchor. If registrar access, zone changes, or recovery contacts are not governed, a provider outage or account compromise can still become a domain takeover event. NIST Cybersecurity Framework 2.0 frames this as governance and access control, not just service outsourcing.
NHI Management Group research shows why this topic keeps surfacing in incident reviews: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 20% of organisations have formal offboarding and revocation processes for them. The same governance gap appears in managed DNS, where teams assume the provider owns the risk once the service is delegated.
The practical lesson is that delegation changes operations, not ownership. In practice, many security teams discover that gap only after a registrar lockout, a misdirected zone change, or a recovery failure has already affected production.
How It Works in Practice
Delegation means a provider runs the DNS service or manages specific zones, but the organisation still defines who is authorised to request changes, how those changes are approved, and how access is removed when people or systems leave. That should be treated as identity governance for a critical service, not a support ticket workflow. The same logic appears in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs, where lifecycle control and revocation are central to reducing exposure.
Practically, teams should separate operational delegation from accountability by defining:
- who can request DNS record changes and under what conditions
- which identities hold registrar, provider, and emergency recovery access
- how approval, logging, and change review are enforced
- how access is rotated, revoked, and tested during offboarding or vendor replacement
- what happens if the provider’s control plane is unavailable or the relationship ends
This is where identity governance and domain governance converge. The Top 10 NHI Issues highlights the broader pattern: unmanaged credentials, weak visibility, and poor revocation are recurring causes of control loss. NIST CSF 2.0 and the NIST Cybersecurity Framework 2.0 both support this model by emphasising governance, asset awareness, and access control as continuous responsibilities rather than one-time vendor selections.
These controls tend to break down when registrar ownership, DNS hosting, and domain administration are split across multiple teams and no single party is accountable for emergency recovery.
Common Variations and Edge Cases
Tighter DNS governance often increases operational overhead, requiring organisations to balance faster provider-managed updates against stronger approval and recovery controls. That tradeoff is real, especially for globally distributed services where change speed matters. Current guidance suggests treating the provider as an operator and the organisation as the risk owner, but there is no universal standard for this yet.
Edge cases often appear when DNS is bundled into a broader managed security or cloud contract. In those environments, teams may assume the contract covers registrar custody, emergency contacts, or break-glass access, when it often does not. The same applies when third parties manage subdomains or automation accounts. A managed service can still be vulnerable if the organisation cannot prove who holds the authoritative credentials, how those credentials are rotated, and how access is recovered after a dispute or incident.
For audit and resilience planning, the most useful question is not “who operates DNS?” but “who can still change, restore, or revoke it if the provider fails?” That is the accountability line, and it should be documented in the same way as other identity-critical controls.
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 CSF 2.0 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-03 | Managed DNS still depends on credential rotation and revocation. |
| NIST CSF 2.0 | GV.OV-01 | Delegation is a governance issue that still requires ownership and oversight. |
| NIST CSF 2.0 | PR.AC-1 | Only authorised identities should be able to make DNS changes. |
Inventory DNS admin identities and automate rotation plus offboarding for every authoritative account.
Related resources from NHI Mgmt Group
- What is the difference between managed identities and hardcoded secrets for AI agents?
- What is the difference between human identity governance and AI agent governance?
- What is the difference between workload identity and API keys for AI agents?
- What is the difference between governing human access and governing AI agent access?
