DACL modification is the act of changing a Discretionary Access Control List on an object. In Windows and similar access-control models, the DACL contains access control entries that grant or deny permissions to users, groups, or service accounts, so modifying it changes who can read, write, execute, or take ownership of the object.
What DACL modification means in access control
DACL modification changes the discretionary access rules on an object, which means the permissions enforced by the operating system can be altered at the object level. In Windows-style security models, that is not just a metadata change, it directly changes who can access the object and what they can do with it.
This matters because the DACL is the enforcement point for discretionary permissions. If the list is changed incorrectly, a user, group, or service account may gain access that was never intended, or lose access that a dependent process requires.
How DACLs shape read, write, execute, and ownership rights
A DACL is made up of access control entries that allow or deny specific rights. Those rights can include read, write, execute, delete, and in some cases the ability to change ownership or alter permissions again. The practical effect is that DACL changes can either narrow or expand the authority attached to an object.
Because permissions are evaluated against the ACEs in the DACL, order and specificity matter. An apparently small edit can have a broad effect when inheritance, group membership, or deny entries are involved. That is why DACL changes often have consequences beyond the single object being edited.
Why DACL modification is security-sensitive
DACL modification is security-sensitive because it can be used to create unauthorized access, weaken segregation of duties, or grant persistence to a compromised account. If an attacker can change a DACL on a file, registry key, service, or directory object, they may be able to keep access even after credentials are reset.
It is also sensitive in routine administration because permission drift is easy to create and hard to notice. Over time, inherited permissions, delegated administration, and manual fixes can leave objects with broader access than policy intended.
In practice, DACL changes are most risky when they affect privileged objects, security tooling, or resources that control other permissions. Those cases can turn a local access change into a wider administrative compromise.
Common sources of DACL drift and misuse
DACL drift usually comes from manual edits, inherited permissions that are not reviewed, application installers that over-grant access, or scripts that copy permissions without understanding the object context. A service account may also be given rights that were meant to be temporary and then left in place.
Misuse is often subtle. For example, granting write access where read-only was intended, or allowing a broad group to change a DACL, can create an indirect privilege path later. The issue is not only who has access now, but who can rewrite the rules later.
That is why DACL modification should be treated as a control event, not just an administrative convenience. The security outcome depends on the target object, the principal receiving access, and whether the change can be propagated or inherited elsewhere.
Risk and Threat Considerations
DACL changes can create immediate overexposure or durable persistence if an attacker, misconfigured script, or over-privileged admin rewrites access on a sensitive object. The most dangerous cases are those where changing the DACL also enables follow-on changes, such as taking ownership or modifying permissions again.
Failure mechanism: An adversary or mistaken administrator alters the ACEs on an object so that the intended control boundaries no longer apply, allowing unauthorized read, write, execution, or permission rewriting.
Impact: Sensitive data, system components, or administrative objects may become accessible to the wrong principal, and the altered permissions may survive beyond password resets or partial remediation.
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 NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | DACL changes directly alter who receives access rights on an object. |
| AC-3 — Access Enforcement | A DACL is the object-level mechanism that enforces discretionary access decisions. | |
| AU-2 — Event Logging | Permission changes are a security-relevant administrative event that should be recorded. | |
| Recommendation — Restrict permission-changing rights to the smallest set of authorized administrators. Ensure object ACLs enforce approved allow and deny decisions consistently. Log object permission modifications and review them for unexpected changes. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | DACL modification changes access authorization for users, groups, and services. |
| Recommendation — Align object permission changes with approved access-control policy and ownership. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control requires managing and reviewing object permissions and authority. |
| Recommendation — Define and review who may modify object permissions under formal access rules. | ||
Practitioner Guidance
What to watch for: Treat DACL modification as a high-value audit event on critical assets, especially when it affects privileged folders, registry keys, services, or objects that govern other access decisions. Unexpected permission changes often matter more than the original access granted.
Governance implication: Use clear ownership for who may change object permissions, and distinguish between routine operational access and the separate authority to rewrite the access rules themselves. That distinction is what prevents permission creep from becoming permanent.
Practitioner takeaway: If a DACL can be changed, the ability to change the DACL is itself a privilege that should be tightly scoped and reviewed.
Related resources from NHI Mgmt Group
- What breaks when an AI agent moves from bug analysis to code modification?
- Who is accountable when a high-risk AI system needs reassessment after a substantial modification?
- What should organisations do after discovering critical mobile app vulnerabilities such as APK modification, UI hijacking, or runtime tampering exposure?
- What breaks when a deployer makes a substantial AI system modification?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org