Discretionary Access Control

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.

How DAC works

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”:

• A developer creates a resource
• That dev chooses who can access it
• The system respects the user’s decision

Pros of DAC

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.

Cons of DAC

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.

DAC in action

Let’s break it down with real-world scenarios that show where Discretionary Access Control can make or break a team’s flow.

Example one: A product manager’s data access lingers

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.

Example two: Contractors with persistent permissions

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.

The common thread

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.

DAC vs. Mandatory Access Control (MAC)

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.

Where role-based and attribute-based access control come in

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).

• RBAC assigns permissions based on roles (e.g., admin, editor, viewer). It adds structure to who can do what.
• ABAC goes deeper, granting access based on user attributes (like department, location, or project team) and resource context.

These models provide more nuance and control, which is essential for scaling SaaS and satisfying security audits.

Why this matters at Frontegg

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:

• Developers stop being the gatekeepers of access. They integrate once and get out of the way
• Infosec gets policy-level enforcement with full visibility and compliance controls
• Product and customer success teams can grant access and manage permissions through intuitive tools, without pinging devs for help
  

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.