By treating the old provider as an identity domain that must be closed, not merely deprecated. Remove user and sub-user accounts, revoke API credentials, and confirm that any automation no longer points to the retiring environment. The goal is to ensure the old path cannot still make changes after migration.
How DNS offboarding leaves stale access behind
DNS offboarding goes wrong when the migration is treated as a records change instead of an access change. The retiring provider may still hold logins, API credentials, zone-edit rights, registrar access, or automation hooks that can alter names, redirects, or verification records long after the cutover. Stale access persists when the old control plane is not explicitly closed.
That is why the offboarding checklist has to include both DNS state and account state. If the old service can still authenticate, it can still push changes, and a simple configuration handoff is not enough to remove that authority.
What must be removed, not just deprecated
The core cleanup is to remove every account path that could keep the old provider active. That includes user and sub-user accounts, API keys, tokens, delegated access, and any automation that still points to the retiring environment. NHI Lifecycle Management Guide is useful here because it treats offboarding as lifecycle closure, not a documentation exercise.
In practice, organisations should also check for hidden dependencies: DNS provisioning scripts, Terraform state, CI jobs, monitoring callbacks, registrar integrations, and support accounts used only for emergency changes. Joiner-Mover-Leaver (JML) Guide reinforces the same principle from a broader lifecycle perspective, including revoking the tokens, keys, and agents that outlive the intended ownership period.
For teams managing many zones or brands, the practical test is simple: can the retired provider still make an authoritative change anywhere in the DNS path? If the answer is yes, the offboarding is incomplete even if the live traffic has already moved.
How to confirm the old path is actually closed
The most reliable confirmation is to verify from the outside and the inside. Externally, confirm that authoritative answers now come only from the new provider and that registrar, NS, glue, and delegated records no longer depend on the retired environment. Internally, confirm that credentials tied to the old provider have been disabled, rotated, or deleted, and that no automation can still authenticate against it.
That verification should include a deliberate access review, not just a service check. IAM and IGA Basics is relevant because this problem is ultimately about entitlement removal and access governance, even when the asset being governed is DNS rather than a typical application.
When the old provider supported machine-to-machine changes, the closure step should be treated like credential retirement for any other operational system. RFC 6749: The OAuth 2.0 Authorization Framework is a good reference point for the mechanics of token-based access, and it helps teams remember that a forgotten integration can be just as powerful as a forgotten user account.
Risk and Threat Considerations
Stale DNS access creates a durable control failure because the old provider may retain the ability to edit records, redirect traffic, or reintroduce weak settings after migration. That can lead to accidental breakage, unwanted changes during incident response, or malicious persistence if the retired provider account or token is ever exposed.
Failure mechanism: Organisations decommission the service surface but leave the old identity surface active, so the provider remains capable of making authoritative DNS changes through accounts, API credentials, or automation.
Impact: Attackers or former operators may regain a trusted path into critical naming and routing infrastructure, which can affect availability, control integrity, and downstream service trust.
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 addresses the attack surface, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | DNS offboarding requires revoking and rotating old API credentials and tokens. |
| AC-2 — Account Management | The question is about removing stale provider accounts and sub-accounts after migration. | |
| AC-6 — Least Privilege | Residual DNS access should be reduced to eliminate unnecessary change authority. | |
| Recommendation — Revoke and rotate retired DNS credentials before cutting over ownership. Disable or delete obsolete provider accounts and sub-accounts during offboarding. Remove any remaining DNS write privileges that exceed the new operating model. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Offboarding hinges on removing retained access rights from the retiring provider. |
| Recommendation — Review and withdraw access rights tied to the old DNS environment. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The topic directly concerns leaving stale non-human access behind after service retirement. |
| NHI-02 — Secret Leakage | API keys and tokens left behind can keep the old DNS path live. | |
| NHI-07 — Long-Lived Secrets | Stale DNS access often persists because credentials were never expired or rotated. | |
| Recommendation — Ensure the retired DNS provider is fully deprovisioned, not just disconnected. Locate and remove any DNS secrets that still authenticate to the retired provider. Expire long-lived DNS credentials as part of provider offboarding. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle control is central to removing stale DNS access paths. |
| CIS-6 — Access Control Management | Offboarding depends on removing authorization to change retired DNS systems. | |
| Recommendation — Inventory, disable, or remove obsolete DNS accounts and service access. Revoke access paths that still permit changes to the old DNS platform. | ||
Practitioner Guidance
What to verify: Do not trust a migration ticket alone. Verify that the old provider has no remaining DNS write path, no active sub-accounts, no valid API credentials, and no automation still pointing at the retired environment.
Decision rule: If any retained credential can still change production DNS, treat the environment as not offboarded and keep it in the rotation and revocation scope until the path is closed.
Practitioner takeaway: DNS offboarding is complete only when the old provider is no longer an operational identity, not merely a historical vendor.
Related resources from NHI Mgmt Group
- What should organisations do first to keep offboarding from leaving stale access behind?
- How can organisations reduce the risk of stale API keys and machine tokens?
- How should organisations reduce risk from stale access after role changes or offboarding?
- How should organisations remove endpoint agent software without leaving stale inventory records behind?