Because DNS privileges are often tied to operational tasks, a mover event can leave someone with access that no longer matches their job. If roles are not recertified, access drift becomes normal, and stale permissions stay active long after the original business need has ended.
Why DNS access changes become an access-review problem
DNS is not just a naming service. In many environments it controls records that affect traffic routing, service reachability, mail flow, and incident containment. When someone moves roles, their DNS access must be reviewed because the same privileges that were appropriate for one job can become excessive, out of process, or too broad for the new one.
A mover event is where access drift usually shows up. If a person used to manage records, zones, or resolver settings and then moves into a different function, the old DNS permissions may still let them change production behavior long after the business need has disappeared.
That is why DNS review belongs with recertification, not just account creation. The question is not whether the person can still log in, but whether the specific DNS actions they can perform still match current duties, approval paths, and separation of responsibilities.
What changes when job duties change
Role changes alter the security context around DNS in a few practical ways. A user may no longer need zone edit rights, delegated admin access, or permission to touch records that influence customer-facing services. They may also move from an operational team to a support, engineering, or management role where read-only visibility is enough.
DNS often sits across multiple operational domains, so a stale entitlement can be more powerful than it looks. A permission that seems narrow, such as modifying a record set, can still redirect users, suppress a service, or interfere with validation and recovery workflows if it remains active after the move.
Good review therefore asks two questions at once: what does the role now require, and what production effect could the old DNS access still create? That is the difference between a clean move and a latent privilege problem.
Why stale DNS permissions are risky even when nothing looks broken
Stale DNS access creates a quiet control gap because it is often operationally useful, lightly monitored, and easy to forget during workforce change. The risk is not only unauthorized change, but also accumulated access that bypasses least privilege, complicates accountability, and makes later incident investigation harder.
For identity and access teams, this is the same class of problem as access creep in any high-impact operational system, but DNS can be especially sensitive because changes are immediately externalized into production behavior. An outdated permission may sit idle for months and then become the exact path used for an accidental or malicious change.
Where DNS administrators manage large zones or shared tooling, review becomes even more important because inherited rights can persist through multiple job transitions. The control weakness is not the role move itself, it is the assumption that operational access can safely remain until someone notices a problem.
Risk and Threat Considerations
DNS access that survives a role change can expose an organisation to unauthorized record changes, service redirection, weakened segregation of duties, and delayed detection of misuse. Because DNS affects how users and systems reach services, one stale entitlement can create outsized blast radius compared with the size of the permission.
Failure mechanism: mover events leave behind active DNS privileges, the entitlement review cadence is too slow, or ownership of the access decision is unclear, so access drift becomes normal and the old operational scope stays in place.
Impact: the organisation carries avoidable production-risk exposure, and a former task owner may still be able to change service reachability or support an incident path without current business justification.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Mover events require timely review and removal of stale DNS access. |
| AC-6 — Least Privilege | DNS permissions should shrink to the current job need after a role change. | |
| AC-5 — Separation of Duties | DNS changes can affect production behavior and should not persist outside proper role boundaries. | |
| Recommendation — Recertify and adjust DNS accounts and privileges when roles change. Limit DNS access to the minimum set needed for the new role. Separate DNS change authority from roles that no longer require operational control. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | Access rights must be reviewed and adjusted when duties change. |
| A.8.2 — Privileged access rights | DNS admin rights are privileged and need tighter reassessment after moves. | |
| Recommendation — Review and revoke DNS access rights that no longer match the role. Revalidate privileged DNS access after every role change. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | DNS entitlements are access-control items that should be governed through lifecycle review. |
| Recommendation — Remove or downgrade DNS permissions that are no longer job-required. | ||
Practitioner Guidance
What to verify: Treat DNS access review as a role-to-entitlement check, not a generic user list cleanup. Verify whether the person still needs write access, delegation rights, or elevated resolver and zone administration after the move.
Decision rule: If the DNS permission can alter production routing, service availability, or external name resolution, recertify it immediately at the mover event. If the new role does not require that capability, remove or downgrade it rather than leaving it in place as a convenience.
Common mistake: Teams often review only visible admin accounts and miss delegated or inherited DNS rights. That is where access creep hides, especially in shared operational accounts or cross-functional support models.
Practitioner takeaway: DNS review is about preventing old job scope from turning into permanent operational authority; if the role changed, the DNS entitlement should be explicitly re-justified, not assumed valid.
Related resources from NHI Mgmt Group
- What breaks when API access is not reviewed as roles and service accounts change?
- What happens when an organization keeps outdated access rights in Jira after people change roles or leave?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?