Learn how DAC works, where it fits in modern systems, and why it often needs support from stronger models.
Discretionary Access Control (DAC) is one of the early, basic and foundational access control models used in information security systems. It’s simple, flexible, and often familiar to developers and admins because it mirrors the way most operating systems manage file permissions. But what DAC gives in convenience, it can cost in control.
At its core, DAC allows resource owners, usually users or administrators, to grant access to others based on their discretion. That’s where the model gets its name. If you’ve ever right-clicked a folder on your laptop to decide who can read, write, or execute files, you’ve used DAC.
But here’s the thing: in a modern SaaS world driven by speed, compliance, and distributed teams, DAC can fall short. So let’s break it down.
In a DAC model, the owner of an object (like a file, database entry, or system resource) has the authority to control who gets access and what kind. That control includes read, write, or execute
permissions and is typically enforced through Access Control Lists (ACLs).
Think of it as “user-defined access”:
Flexibility for fast-moving teams
DAC is quick to configure and modify. Developers and IT teams appreciate the autonomy to adjust permissions without waiting for centralized approval.
Familiar model
Most teams have used some form of DAC through file systems or collaboration tools. This lowers the learning curve and reduces onboarding time.
Lightweight implementation
There’s no need for complex infrastructure or centralized control systems. DAC is easy to implement in standalone environments or smaller orgs.
Risk of permission sprawl
Because access can be granted by any object owner, permissions can become chaotic. Without governance, it’s easy to lose track of who has access to what.
Weak enforcement of security policies
DAC depends heavily on user behavior. A well-meaning developer might grant access too broadly, exposing sensitive data to the wrong hands.
No centralized oversight
In organizations with high compliance or security standards, DAC lacks the auditability and enforcement needed to satisfy infosec teams.
Let’s break it down with real-world scenarios that show where Discretionary Access Control can make or break a team’s flow.
A product manager needs access to a usage analytics dashboard in order to prepare a quarterly roadmap. The developer who owns the dashboard grants access manually. The PM gets the data they need and delivers the presentation on time. So far, so good.
But after the roadmap cycle ends, the PM moves on to a different product line. The access remains in place. Months later, they still have visibility into sensitive usage patterns for a product they no longer support. This isn’t just a security gap. It can lead to confusion, compliance issues, or even data leaks if the wrong person downloads or shares something unintentionally.
A third-party contractor is brought on to help debug a billing microservice. They’re granted access to that part of the infrastructure to speed up their work. DAC makes that access quick and simple. The developer leading the integration just clicks a few boxes and they’re in.
Fast forward six months. The contractor’s engagement ended long ago, but their access wasn’t revoked. They still have read and write permissions in a production environment. If their credentials were ever compromised, the business would be exposed. Worse yet, no one realizes it because there’s no centralized control or audit trail in place.
In both cases, DAC gave someone the access they needed. But it also failed to take it away when that access was no longer appropriate (see why deprovisioning is important). Without centralized oversight or policy enforcement, access sprawl creeps in. This is how many companies find themselves vulnerable without even realizing it.
What starts as convenience quickly becomes a liability. And in organizations where multiple teams or apps are involved, these risks only multiply.
While DAC gives users control, Mandatory Access Control (MAC) is strict and centralized. In MAC, access is granted based on policies determined by the system or organization, not by individual users. Think of it as a government security clearance model.
For teams that need granular, policy-driven enforcement, MAC is often a better fit. But it comes with overhead and doesn’t play well in environments that prioritize agility.
To solve DAC’s shortcomings without swinging all the way to MAC, many modern platforms combine DAC with Role-Based Access Control (RBAC) or Attribute-Based Access Control (ABAC).
These models provide more nuance and control, which is essential for scaling SaaS and satisfying security audits.
DAC might be familiar, but it’s not built for SaaS at scale. That’s why Frontegg includes built-in support for advanced access control models. It goes far beyond DAC, supporting RBAC, ABAC, and centralized policy enforcement. At the same time, it gives teams the flexibility to adapt when they need it.
With Frontegg:
This is identity management reimagined for distributed teams, complex org structures, and real-world speed.
Frontegg doesn’t just give you another access control system. It gives every stakeholder the ability to contribute without breaking anything.
