Scope 1 – New Problems, New Approaches: From Job Functions to Use Cases

After working closely with over 100 organizations—from Fortune 500 enterprises to small startups—and spending hundreds of hours in discussions with customers and prospects at Axiom, we’ve developed a structured approach that simplifies least privilege implementation. This experience has shaped our 3 Scopes Approach—a phased roadmap designed to minimize friction and maximize adoption across any organization. By dividing roles and responsibilities into three clear scopes—Core Access, On-Demand Access, and Just-in-Time Access—this method ensures smoother, more efficient, and more successful least privilege rollouts.

This is the first article “Scope 1 – New Problems, New Approaches: From Job Functions to Use Cases” of a 3-part series “3 Scopes to Success: A Phased Paved Road Approach to Least Privilege Rollout” that will guide you through each phase of the 3 Scopes Approach and provide practical steps to implement lasting least privilege within your organization.

Why Not Use RBAC and Simple Job Function Roles?

Traditional Role-Based Access Control (RBAC) defines access by static job roles. For example, a “Database Administrator” gets full access to databases, regardless of how often they need it. The problem? This approach doesn’t account for the dynamic nature of modern operations, where almost all access can be considered privileged.

When users need to update customer records or scale a system, they often require admin-level access. RBAC blurs the lines between regular and admin privileges, leading to overly broad roles that are hard to manage.

Here’s a use case for you: “I’m just trying to do my job!” said the developer to their amazing security team, after realizing they need full admin access just to update a minor config in their source control. In the end, what makes an admin role privileged is the ability to execute specific administrative tasks and use cases!

Here’s a snapshot of what the typical RBAC approach looks like:

Example Traditional RBAC Table

System or DataJob Function/RolePrivileges
Production DatabaseDatabase AdministratorFull access to create, update, delete, and read customer records
Data WarehouseData ScientistRead access to datasets, execute models
CI/CD PipelineDevOps EngineerFull access to deploy code, manage pipelines, run tests
Financial RecordsFinance AnalystRead and update access to generate reports, manage financial records
Support Ticketing SystemSupport EngineerFull access to view and resolve support tickets
Reporting DashboardBusiness AnalystRead access to generate business intelligence reports

Why This Approach Fails

While RBAC worked well in simpler environments, it falls short in today’s complex systems:

  • Static Job Roles: Access is tied to broad job functions, forcing security teams to constantly create new roles for every minor variation.
  • Excessive Privileges: Users get more access than they need, increasing the risk of misuse or breaches.
  • Lack of Flexibility: Users often need temporary access for specific tasks, but RBAC doesn’t easily support this.

For example, a support engineer needing temporary access to a database to troubleshoot an issue would either get full access (risky) or no access (unproductive). It’s a lose-lose situation.

The Transition to a Use-Case Approach

Here’s where the use-case approach shines. Instead of granting access based on job functions, it’s task-driven. Access is given dynamically based on what users need to do, how often they need it, and the sensitivity of the data involved. This reduces risk, aligns with modern workflows, and provides more flexibility.

ABAC? Not Quite.

Sound familiar? Did someone say ABAC? Well, kind of—but not exactly. The use-case approach shares some similarities with Attribute-Based Access Control (ABAC), but without the headache. ABAC tries to control access with a ton of confusing attributes—”Department,” “Favorite Color,” or “Is Unicorn?” (okay, maybe not that last one)—leaving security teams scratching their heads, wondering why a policy isn’t working.

The use-case approach keeps things straightforward: no cryptic attributes, just concrete tasks. Instead of managing access by layering multiple attributes that might not even make sense to the user, you focus directly on what needs to get done—reading, writing, modifying, or deleting—and grant access accordingly.

Use-Case Approach Table

System or DataUse CaseAccess Level (Read, Modify, Create, Delete, Admin)Teams/Users
Production DatabaseMonitor real-time database performanceReadEngineering, DevOps
Data WarehouseRun experiments, model trainingRead, ExecuteData Scientists, ML Engineers
CI/CD PipelineDeploy code, manage build pipelinesModify, ExecuteDevOps Engineers, Developers
Financial RecordsGenerate reports, review transactionsRead, ModifyFinance, Auditors
Support Ticketing SystemResolve customer tickets, update recordsModify, CreateSupport Engineers
Reporting DashboardGenerate and analyze business reportsReadBusiness Analysts, Data Analysts

Why the Use-Case Approach Works

The use-case approach offers clear advantages over RBAC:

  • Task-Specific Access: Access is tailored to the actual tasks a user performs, minimizing unnecessary privileges.
  • Minimized Risk: By granting access based on need rather than role, users don’t get excessive permissions.
  • Flexibility: Access can be adjusted dynamically. Temporary or one-time access for specific tasks? Easy.
  • Alignment with Operations: Use cases mirror real-world workflows, allowing access that matches how work is done, not based on predefined job functions.

From RBAC to Use-Case Mapping

Transitioning from RBAC to use-case-driven access starts with an Access Matrix. This matrix helps assess the sensitivity, frequency, and specific use cases for different systems and data. With this foundation, you can leave behind static roles and begin granting access based on real-world tasks.

Scope Matrix Example

System or DataRisk/SensitivityFrequencyUse Cases
Production DatabaseHigh – Potential for data loss or security breachDaily – Continuous monitoringMonitor performance, troubleshoot issues
Data WarehouseHigh – Exposure of proprietary dataWeekly or Monthly – Data science activitiesRun experiments, train models
CI/CD PipelineMedium – Misconfiguration could disrupt deploymentsDaily – Development and deploymentDeploy code, manage pipelines
Financial RecordsCritical – Breach could result in legal consequencesMonthly or Quarterly – Financial auditsGenerate reports, review transactions
Support Ticketing SystemMedium – Customer data must be kept privateDaily – Resolving support ticketsView, update, resolve support tickets
Reporting DashboardLow – Data is typically aggregated/anonymizedDaily – Regular reportingGenerate and analyze business reports

What’s Coming Next in This Series?

In the next two articles, we’ll dive deeper into how to break down access into these manageable scopes and implement them strategically to minimize friction and maximize security.

  • Article 2: Scopes, Scopes Everywhere! Building 3 Scopes for Effective Rollout
    In this article, we’ll guide you through the 3 ScopesJust-in-Time Access, Core Access, and Just-In-Time Access—and show how organizing access this way makes least privilege rollouts smoother and more efficient. You’ll learn how to reduce user friction while achieving measurable security improvements.
  • Article 3: Hit Them Where It Doesn’t Hurt: Cherry-Pick the Right Rollout Plan
    The final article will focus on the strategy behind rolling out least privilege. We’ll show you how to start with low-stakes users and gradually move toward higher-risk roles, ensuring a smooth phased rollout. Real-world success stories will demonstrate how this approach leads to lasting security wins with minimal disruption.

Most Popular

This website uses cookies. By continuing to browse this site, you agree to this use.