Discretionary access control can increase risk because object owners can grant broad permissions to others and those permissions can flow into programs they run. That creates two problems: users may end up with higher access than intended, and malware can inherit the user’s privileges. In practice, DAC trades convenience for weaker governance and a larger attack surface.
Why Discretionary Access Control Raises Risk for Security Teams
discretionary access control sounds flexible because the resource owner decides who gets access, but that same flexibility creates governance gaps. When permissions are delegated informally, access can expand faster than security teams can review it. That matters because privileges are often inherited by the software, scripts, and automation running under a user context, turning a simple over-share into a wider exposure path. NHI Management Group’s guidance on Ultimate Guide to NHIs — Key Challenges and Risks frames this as a control problem, not just a configuration problem.
In practice, DAC also makes accountability harder. Owners may grant access for speed, temporary exceptions become durable, and no one can easily prove whether access matches policy. That is why this model often shows up as a hidden cause of lateral movement, excessive privilege, and unmanaged sharing in real environments. Current guidance from OWASP Non-Human Identity Top 10 and NIST Cybersecurity Framework 2.0 supports tighter permission governance, but it is not a universal standard that DAC can be eliminated everywhere. In practice, many security teams discover the problem only after a user account, shared folder, or application token has already been used to spread access beyond its original intent.
How DAC Becomes a Security Problem in Real Environments
DAC increases risk when owner discretion outruns central oversight. The model assumes the person closest to the asset can judge access appropriately, but that assumption breaks down in shared file systems, SaaS workspaces, cloud buckets, and application-run services where access decisions are made informally and then copied across teams. A user who receives broad access may also run email clients, scripts, admin tools, or browser sessions that can reuse the same entitlements if malware gets execution on that endpoint.
There are three recurring failure modes:
- Access is granted for convenience and never reviewed, so permissions accumulate.
- Owners share access with peers or contractors, creating unclear approval chains.
- Programs inherit the user’s rights, so malicious code can act with the same privileges as the logged-in account.
For governance teams, the practical response is to reduce discretionary grant power, pair RBAC with periodic access review, and use stronger controls for high-value resources. NHI Management Group’s research on 52 NHI Breaches Analysis is a useful reminder that weak credential and privilege governance rarely stays contained to one system. If the environment mixes human-driven sharing with service accounts, scripts, and API tokens, the model breaks down because access inheritance and delegation become too complex for manual control.
Common Cases Where DAC Overhead and Risk Trade Off
Tighter access control often increases operational overhead, requiring organisations to balance speed of delegation against the cost of review and enforcement. That tradeoff is real in engineering teams, research groups, and business units that need fast collaboration. Current guidance suggests DAC can still be acceptable for low-risk, low-sensitivity content, but it is a poor fit for regulated data, production systems, and any environment where a user’s session can trigger automated actions.
One useful way to think about the exception cases is this: the more a user can launch tools, connect integrations, or delegate work to automation, the more DAC behaves like an indirect privilege-escalation mechanism. That is where NHI-oriented controls become relevant, even when the original question is about human access. The practical standard is evolving, but security teams should treat owner-managed sharing as a temporary convenience, not a long-term control boundary.
If a team needs deeper context on why over-privilege becomes systemic, review Top 10 NHI Issues alongside the control baselines in NIST SP 800-53 Rev 5 Security and Privacy Controls. These controls tend to break down when access is highly collaborative and owners can make exceptions faster than the security team can detect and revoke them.
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 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Over-privilege and unmanaged access are central DAC risk amplifiers. |
| NIST CSF 2.0 | PR.AC-4 | DAC risk is fundamentally a weak access-management and permission-governance issue. |
| NIST SP 800-63 | Identity assurance matters when shared permissions and inherited access blur accountability. | |
| NIST Zero Trust (SP 800-207) | PR.AC-4 | Zero Trust reduces trust placed in owner-granted access and inherited privileges. |
| OWASP Agentic AI Top 10 | A1 | Autonomous tools inheriting DAC permissions can turn over-sharing into execution risk. |
Centralise access approvals and periodically recertify permissions against least-privilege need.
Related resources from NHI Mgmt Group
- What is the difference between third-party risk management and access control in supply chain security?
- Why does remote privileged access increase the risk of misuse in distributed environments?
- How should security teams control Azure elevate access in environments with tightly delegated administration?
- Why does standing access increase risk in environments with fluid roles and SaaS sprawl?
