For decades, groups and birthright access have been the default for managing enterprise data permissions, operationalized through static Active Directory (AD) groups. This approach promised simplicity: central IT granted employees sweeping access based on role, department, or title, which they bundled into broad groups and applied during onboarding. On the surface, it felt efficient. Give people what they’re likely to need and let them get to work.
But simplicity came at a cost. These models were never built for the scale, complexity, regulatory scrutiny, or fine-grained access controls modern enterprises require. Instead, they’ve evolved into sprawling, inflexible frameworks of overprovisioned access, tangled group hierarchies, and audit blind spots. Sensitive data is overexposed. IT is buried in maintenance. Data governance teams can’t answer a basic question: who has access to what — and why?
Using AD groups for data access is similar to trying to hammer in screws – it’s the wrong tool. A simple system, such as requesting access through a ticketing system, results in someone being added to an AD group that has broken data governance and fails compliance requirements. So let’s take a look at the many pain points of AD groups and birthright access – and how to take a better approach.
Before we get into why AD groups and birthright access are failing today’s data teams, let’s define what exactly they are.
Active Directory groups refer to a group of users or systems that exist within a Directory group, such as Microsoft, Okta, or data platform groups (e.g. Snowflake Role). Data teams have traditionally gravitated toward using AD groups in order to easily manage access and permissions to resources in a centralized way.
Birthright access refers to assigning default permissions to new data users based on pre-determined criteria. For instance, someone who just joined a company’s HR department may get birthright access to all HRIS systems and files. Like AD groups, birthright access has traditionally been seen as an easier approach to grant access permissions while largely avoiding manual steps.
If AD groups and birthright access have long been the standard, why are we talking about them?
As we mentioned above, they were built for simple data environments – environments that are becoming less and less practical as organizations embrace advanced analytics, AI, and ML workloads. Not to mention, as the number of users – including AI agents – and the volume of data grow, AD groups and birthright access frameworks are too static to easily adapt.
As a result, the perceived savings in time and effort that initially drove teams to use these approaches are backfiring, creating longer wait times, more effort, and greater risk. Let’s see how:
Think about the last time you went to the airport. You had a ticket, but you still needed to go through security checkpoints, avoid unauthorized areas, and board the right flight. In other words, a ticket did not buy you carte blanche access to the airport.
In a similar vein, today may be creating a group membership to an entire schema of data. But, the user doesn’t need access to all tables, only specific ones for their job. When taking a coarse-grained approach based on groups or memberships, users end up with more access than they need. This violates the principle of least privilege and increases the attack surface for:
It’s no wonder that compliance consistently ranks as a top priority for data leaders: 70% of organizations are subject to 10 or more data regulations, and 33% are subject to 25 or more. But AD groups and birthright access may be undermining compliance efforts.
These approaches necessitate regular scrutiny of user group memberships, rather than actual data access. That’s because users accrue permissions through job changes or project rotations, resulting in “access creep” — the retention of superfluous and obsolete access. This in turn can hinder transparency, cause confusion, and put compliance at risk.
Regulations like GDPR, HIPAA, and SOX require strict controls over who can access what. Organizations must have a firm grasp on what type of data resides across their environments – using data classification frameworks – in order to meet these regulatory standards.
Additionally, data governance teams need a way to identify toxic joins or other scenarios in which sensitivity increases based on context. Birthright access is too broad to account for these instances, and therefore often fails to meet auditability and justification standards.
Sharing a role with another person does not necessarily mean you should share their same access permissions – and that’s a shortcoming for AD groups and birthright access systems.
Think of it this way – your doctor should have access to your health records, but you wouldn’t want any other doctor in the practice to be able to see them without your consent. In the same way, users should only see certain rows of data based on their country or line of business (LOB).
Zero trust is a framework that follows the “never trust, always verify” principle to data access. In other words, you should never assume that a data user or system is authorized and trustworthy – you must explicitly confirm it.
Implementing a zero trust architecture and attribute-based access control (ABAC), which favor dynamic, contextual, and just-in-time access, support this principle. However, birthright or AD group-based systems, which are based on pre-defined criteria, can’t reliably support zero trust standards.
We get it – moving away from a system that’s been in place for years, or even decades, can be daunting. But long-term scalability, innovation, and growth require adjusting legacy processes to fit modern data demands.
I’ve worked with leading enterprises across all industries that have made this change happen – and reaped the benefits from doing so. Here are the most critical shifts I’ve helped them incorporate:
As we mentioned earlier, sharing a role should not necessarily mean sharing permissions. Just-in-time access ensures that you only provision tables/views to a user that has requested and meets security requirements – no more, no less, and no delays.
Immuta’s AI-powered Review Assist feature helps streamline this process by assessing a user’s data access request and providing feedback on whether approving access poses a high, medium, or low risk, including an AI-generated rationale statement. Data stewards can then make faster, more informed decisions, and ensure that the right data gets to the right user.
Access creep and overprovisioned data are both major problems that are easy to miss, particularly when recertification processes require constant manual oversight. Immuta helps eliminate any uncertainty by allowing you to grant time-limited access to users, meaning access is automatically revoked after a set period (e.g., X days/months). This significantly enhances security and reduces the burden of recertification for your team.
Additionally, if a user has not accessed the data within a certain period of time, you can auto-revoke access to ensure that nothing slips through the cracks. This not only mitigates risk, but also helps achieve zero trust principles.
Immuta’s robust policy engine enables a single policy to control data access, for instance, by limiting rows based on a user’s country of residence. This eliminates the need for 195 separate AD groups and policies (one for each country) – an approach that’s not only hard to manage, but is also a burden to monitor and audit.
This capability becomes even more impactful when applying similar restrictions based on account numbers or lines of business.
Whether you’re subject to one compliance regulation or 25 (or more), you need to know who’s accessing what data. It’s not only critical for audits, but it also gives you visibility into how data is being used across the organization. And as AI agents begin to enter the picture and autonomously request data access, the stakes will become even higher.
Immuta gives you the power to understand who is accessing your sensitive data by providing always-on monitoring and reporting capabilities. With unified audit information in hand, you can proactively identify and address anomalous behavior, and revoke permission from users who are no longer accessing the data. This will improve your security posture while reducing overall risk exposure.
Birthright and AD group access are failing your organization, and they’re simply not setting you up for success in today’s data ecosystems. They’re very risky because they assume everyone with a given title or role needs the same data access — leading to overexposure, regulatory risks, and poor security hygiene.
Modern access strategies favor context, least privilege, and automated provisioning. Timebound access and risk-based approvals allow users faster access to data, reducing the complexity of recertification. And continuous monitoring means you always have oversight to ensure data is being used appropriately and efficiently.
See how AI is helping to streamline access decisions.
