The Shifting Sandbags: Why Your Identity Perimeter Never Stays Where You Left It

You define your identity perimeter carefully. You map every user, device, and service account. You set policies, enforce MFA, and lock down privileged roles. Then, a week later, a contractor calls: they can't access the CRM. You check the logs and find the contractor's account was provisioned by an automated HR feed—but the new role didn't include the right group membership. Meanwhile, a developer spun up a test database with a public endpoint, and a service account from last quarter's pilot project is still active. This is identity perimeter drift: the constant, often invisible movement of your security boundary away from where you left it. Think of it like sandbags on a flood wall. You place them carefully, but water seeps through gaps, wind shifts them, and new gaps appear. In this guide, we'll explain why drift happens, how to detect it, and what you can do to keep your perimeter stable—without chasing every change.

Why This Topic Matters Now

Identity perimeter drift isn't a new problem, but it has become more urgent as organizations adopt hybrid work, cloud services, and DevOps practices. Traditional network perimeters have dissolved; now, access decisions rely on who you are, not where you connect from. That shift makes identity the new perimeter—but it's a perimeter built on dynamic data: user attributes, group memberships, device health signals, and policy rules. These data points change constantly, often without human oversight.

Consider a typical mid-size company with 500 employees. Each employee has an average of 10 accounts (email, CRM, code repos, HR system, etc.). That's 5,000 identities to manage. Now add contractors, interns, and service accounts. Multiply by role changes, department transfers, and offboarding delays. Within a month, dozens of accounts are misaligned with the intended policy. Many industry surveys suggest that over 60% of organizations have experienced a security incident linked to mismanaged identities or permissions. The cost is real: data breaches, compliance fines, and lost productivity.

For readers who manage access or security, the stakes are personal. You may have felt the frustration of a quarterly audit where you discover hundreds of orphaned accounts or users with excessive privileges. Or you've dealt with a helpdesk ticket from someone who should have access but doesn't. Drift is the root cause. It erodes trust in your controls and forces you to react instead of plan. Understanding drift helps you move from firefighting to proactive management.

We wrote this guide for security practitioners, identity administrators, and IT leaders who want a clear, non-academic explanation of why perimeters shift and what to do about it. You won't find abstract theories here—just concrete analogies, a step-by-step walkthrough, and honest trade-offs. By the end, you'll be able to explain drift to your team and start building a drift-detection routine that fits your environment.

Core Idea in Plain Language

Imagine you're building a temporary flood barrier with sandbags. You place each bag carefully, overlapping edges to create a solid wall. That's your identity perimeter: a set of rules and assignments that define who can access what. But over time, the sandbags shift. Rain loosens the soil, people kick bags while walking by, and new gaps appear where you didn't place enough bags. You didn't intend for the wall to move, but it did.

In identity terms, drift happens when changes occur outside your planned access model. These changes can be small: a manager approves a temporary role extension, an HR system updates a job code, or a developer adds a new API key. Each change is reasonable on its own, but cumulatively, they move the perimeter. The wall is no longer where you left it.

Three main forces drive drift: automation without governance, human error, and organic growth. Automation without governance means that systems like HR feeds or CI/CD pipelines create identities or modify permissions without a human verifying the outcome. Human error includes mistakes like assigning a user to the wrong group or forgetting to revoke access after a project ends. Organic growth refers to the natural expansion of access as teams add new apps, new users, and new roles—often without updating the baseline policy.

The key insight is that drift is not malicious. It's usually the result of well-intentioned actions combined with a lack of feedback. The person who grants a temporary exception doesn't see the long-term effect on the perimeter. The developer who creates a service account doesn't know it violates a policy written last year. Drift is a systemic issue, not a character flaw.

To manage drift, you need to accept that it's inevitable. You can't stop all change, but you can build mechanisms to detect and correct drift before it becomes a gap. That means shifting from a static perimeter (set once and forget) to a dynamic one (monitor and adjust). The sandbag analogy helps here: you don't just build the wall and walk away; you inspect it regularly, add bags where needed, and remove broken ones. Similarly, you need to review your identity perimeter on a schedule and in response to triggers like role changes or new app deployments.

How It Works Under the Hood

To understand drift, we need to peek at the machinery that defines your identity perimeter. At its simplest, an identity perimeter is a set of policies that map subjects (users, devices, services) to resources (apps, data, networks) through access rules. These rules are stored in directories like Active Directory, identity providers like Azure AD or Okta, and policy engines like AWS IAM or Kubernetes RBAC.

Drift occurs when the actual state of these mappings diverges from the intended state. The intended state is your policy: for example, "all marketing users can access the CRM but not the source code repo." The actual state is what the system enforces at any moment. If a marketing user is accidentally added to a developer group, the actual state drifts from the intended state.

Three common mechanisms cause this divergence:

1. Direct Assignment Creep

Many admins assign permissions directly to users instead of using groups. This is convenient in the moment but creates a tangled web of individual rights. Over time, direct assignments accumulate, and no one knows who has what. When a user changes roles, their old direct assignments often remain, causing drift.

2. Group Membership Cascades

Groups can be nested. If you add a user to a group that is a member of several other groups, the user inherits all those permissions. A small change (adding a user to one group) can have a large, invisible effect. Drift happens when the group hierarchy is not well documented or when groups are reused for multiple purposes.

3. Policy Exceptions and Temporary Grants

Most identity systems allow time-bound exceptions or break-glass accounts. These are meant to be temporary, but they often become permanent. A developer gets a 30-day exception to access a production database for debugging. Thirty days pass, but the exception is not revoked. That's drift.

Automated provisioning systems, like those that sync from HR, can also introduce drift. If the HR system sends a job code change, the identity system may automatically update group memberships. But if the mapping rules are wrong or incomplete, users end up with incorrect access. The system is doing exactly what it was told, but the outcome drifts from the intended policy.

Detecting drift requires comparing the intended state (policy) with the actual state (current assignments). This is often done through periodic access reviews or automated tools that flag differences. However, many organizations lack a clear definition of the intended state. Without a baseline, you can't measure drift. That's why the first step in managing drift is to document your identity perimeter—what should be allowed, and for whom.

Worked Example: The Marketing Team's CRM Access

Let's walk through a concrete scenario to see drift in action. Imagine a company, Acme Widgets, with about 200 employees. Their identity perimeter is defined in Azure AD. The intended state is: all marketing team members are members of the "Marketing" group, which has access to the CRM and the marketing SharePoint site. No marketing user should have access to the finance system or the production code repos.

One Monday, a new marketing intern, Alice, joins. The HR system creates her account and adds her to the "Marketing" group via an automated feed. That works as intended. But the same day, a senior marketing manager, Bob, requests temporary access to the finance system for a budget review. The helpdesk adds Bob directly to the "Finance-ReadOnly" group, with a note to remove it in two weeks. Two weeks pass, but the note is forgotten. Bob still has finance access. That's drift number one.

Meanwhile, a developer, Carol, creates a service account for a marketing analytics tool. She needs it to read CRM data. Carol adds the service account to the "Marketing" group, but she also needs it to write to a shared database. She creates a new group, "Analytics-Service-Accounts," and assigns database write permissions to that group. She adds the service account to this new group. Over the next month, other developers start using the same service account for different tasks, adding it to more groups. The service account now has permissions that were never intended—like access to a staging environment and the ability to delete logs. That's drift number two.

Three months later, during a quarterly access review, the security team runs a report. They find that Bob still has finance access, and the service account has 15 group memberships, many of which are undocumented. The intended state (marketing only) has drifted significantly. The team must now investigate each exception, decide whether to revoke or accept, and update the policy. This is time-consuming and frustrating, but it's the cost of not monitoring drift continuously.

This example shows how small, reasonable changes accumulate. Each change was justified in isolation, but together they created a perimeter that no longer matches the original design. The fix isn't to forbid all changes—that would break productivity—but to build a process that catches drift early. For instance, a weekly report showing new group memberships or direct assignments would have flagged Bob's lingering access and the service account's expansion.

Edge Cases and Exceptions

Not all drift is equal, and some situations require special handling. Here are common edge cases where standard drift detection may fail or need adjustment.

Ephemeral Cloud Roles

In cloud environments, roles can be assumed temporarily via services like AWS IAM Role chaining or Azure Managed Identities. These roles are designed to be short-lived, but they can still drift if the trust policies (which entities can assume the role) are too permissive. For example, a role meant for a specific EC2 instance might be assumable by any instance in the account. Drift here is about scope creep, not user membership.

API-Only Identities

Service accounts and API keys often lack an owner or review cycle. They are created for automation and then forgotten. Drift for these identities is especially dangerous because they often have elevated permissions and no human to notice misuse. Automated tools that flag inactive accounts can help, but many service accounts are active but over-permissioned.

Mergers and Acquisitions

When two companies merge, identity perimeters collide. You may have duplicate users, conflicting group names, and different policy models. Drift is rampant during integration because you are intentionally changing the perimeter. The challenge is to define a new intended state and migrate without creating gaps. Temporary exceptions are common but must be tracked.

Zero Trust Architectures

In a zero trust model, the perimeter is not a fixed boundary but a set of dynamic decisions based on context (user, device, location, behavior). Drift still occurs, but it manifests as policy entropy—rules that become outdated or contradictory. For example, a conditional access policy might allow access from specific IP ranges, but those ranges change as offices move. The policy drifts from the real network topology.

In each of these cases, the fundamental principle remains: compare intended state to actual state. But you need to adapt your detection methods. For ephemeral roles, check trust policies regularly. For API identities, enforce ownership and review permissions quarterly. For mergers, treat the integration as a project with a clear end state and milestones. For zero trust, use policy-as-code and version control to track changes.

Limits of the Approach

While monitoring drift is essential, it's not a silver bullet. There are practical limits to what you can achieve, and it's important to be honest about them.

Tooling Isn't Perfect

Automated drift detection tools can generate false positives. A tool might flag a user who has legitimate temporary access as drifting, requiring manual review. Over time, if the false positive rate is high, teams become desensitized and ignore alerts. This is the classic alert fatigue problem. To mitigate, tune your rules and use risk-based prioritization: focus on high-privilege accounts and sensitive resources.

Defining the Intended State Is Hard

Many organizations don't have a clear, documented intended state. They have a mix of inherited policies, ad-hoc exceptions, and undocumented group structures. Without a baseline, you can't measure drift. Creating that baseline is a significant effort, especially in large environments. It requires collaboration between security, IT, and business owners. Some teams give up and adopt a "clean up as you go" approach, which is better than nothing but still leaves gaps.

Drift Is Not Always Bad

Sometimes drift is actually improvement. A team might discover a better way to organize access, or a new app requires a different permission model. The goal is not to eliminate all change but to make change intentional. The problem is when drift happens unnoticed. So the limit is that you need to distinguish between intentional changes (which should be reflected in the policy) and unintentional ones (which need correction). This requires good change management processes.

Resource Constraints

Small teams may not have the bandwidth to review access regularly. They rely on reactive measures like incident response. In such cases, prioritize the most critical systems and accept that some drift will go undetected. Use automation where possible, but be realistic about what a team of two can manage. Sometimes a simple monthly script that lists new group memberships is more effective than a full IGA suite that no one has time to configure.

In summary, drift management is a continuous practice, not a one-time fix. It requires investment in tools, processes, and culture. The limits are real, but acknowledging them helps you set realistic expectations and avoid burnout.

Reader FAQ

What is identity perimeter drift in simple terms?

It's when the actual access rights of users and services slowly move away from what you intended. Think of it like a fence that gets moved a few inches each week by wind and animals—until it's no longer where you built it.

How often should I check for drift?

It depends on your environment. For high-risk systems (production, finance, HR data), weekly or even daily checks are wise. For lower-risk systems, monthly or quarterly reviews may suffice. The key is to schedule regular reviews and also trigger a review after significant changes like a new app deployment or a merger.

What's the best tool to detect drift?

There is no single best tool; it depends on your identity stack. Many identity governance tools (like SailPoint, Okta IGA, or Azure AD Access Reviews) have built-in drift detection. For cloud environments, tools like AWS IAM Access Analyzer or Google's Policy Analyzer can identify unintended access. Open-source options like Zeek or custom scripts can also work. Start with what you already have before buying new.

Can I prevent drift entirely?

No. As long as your organization changes—new hires, new apps, new projects—drift will happen. The goal is to detect and correct it quickly, not to achieve a static state. Accepting that drift is normal reduces frustration and helps you focus on building good detection and response processes.

What's the most common cause of drift?

Direct permission assignments and forgotten temporary exceptions are the top culprits. Avoiding direct assignments and using groups with clear membership rules can reduce drift significantly. Also, enforce expiration dates on temporary access and automate revocation.

How do I convince my boss to invest in drift management?

Frame it in terms of risk and compliance. Drift leads to data breaches (as seen in many real incidents) and compliance violations (GDPR, SOX, HIPAA). A single audit finding can cost more than a year of tooling. Start small: run a one-time drift report and show the number of exceptions found. That often makes the case.

Now that you understand drift, here are three concrete next steps: (1) Document your intended identity perimeter for one critical system this week. (2) Run a manual or automated comparison of actual vs. intended access for that system. (3) Schedule a recurring review—start monthly—and assign an owner. These small actions will start stabilizing your shifting sandbags.