<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">

Struggling to implement least privilege in your organization? Join StrongDM featuring Forrester for this upcoming webinar. Register now!

3 Reasons Why Least Privilege Has Failed

StrongDM manages and audits access to infrastructure.
  • Role-based, attribute-based, & just-in-time access to infrastructure
  • Connect any person or service to any infrastructure, anywhere
  • Logging like you've never seen

The Principle of Least Privilege. It’s the idea that every person or thing in your environment should only be granted the baseline access and permissions required to do their jobs. 

Logically, that makes sense. Why would you provide permissions or access beyond what an individual needs' Especially when the outcome can be catastrophic. In fact, 61% of all breaches involve using credentials to gain access to sensitive systems—so of course you’d want to limit the access to those systems.

Furthermore, an analysis of real-world access management and permission usage across 225 companies, ranging from small startups to large enterprises shows:

  • 85% of credentials with privileges have not been used in the last 90 days
  • Nearly 1 in 3 users with access to systems have not used that access in the last 90 days
  • 15% of resources available have not been accessed in the last 90 days.

The problem? The ability to audit, track, and understand how permissions are being used (or if they’re used at all) has been non-existent. Until now. The findings are clear: organizations need visibility into privileged access and its usage to fully understand and address their total attack surface.

Breaking Down Access: Users, Resources, & Privileges


This blog post breaks down access across three dimensions: users, resources, and privileges. Each is defined below, and helps to paint the broader picture—that the gaps in visibility into permission usage creates a significant attack surface for virtually every organization.

Reason 1: Unused Privileges


Privileges are a critical source of risk for every organization. Every user or identity that has elevated privileges can be a target for credential theft, credential stuffing, or ransomware, among others. It’s no wonder that credentials are involved in nearly two-thirds of all breaches.

Even worse, the analysis shows that 85% of credentials with privileges have not been used in the last 90 days. These are privileges that are available, unused, and ripe for the picking for bad actors. And this raises an obvious question: if the privileges have not been used in the last 90 days, are they even needed? Deprovisioning unused credentials with privileges is a substantial opportunity for security teams to reduce their overall attack surface.

The principle of least privilege requires that credentials have the bare minimum privileges possible to be productive—and yet 85% of privileges go unused. Not having visibility into privileges use across the entire stack has prevented security teams from taking remedial actions, and enabling them to truly take a least privilege approach. It’s virtually impossible for security teams and admins to know which permissions are actually needed, and this type of visibility provides a data-driven approach to managing permissions based on real-world usage.

Reason 2: Over Provisioning


It’s not just privileges that go unused. In many cases, the complexity of provisioning access on an identity-based level results in users being over provisioned, and having access they may not need.

In fact, the analysis shows that nearly 1 in 3 users have access to systems that they have not used in the last 90 days. The heterogeneous nature of modern technology stacks has made it extremely difficult for security teams to track which credentials are being used, what systems are being accessed, and by whom. This lack of visibility has resulted in access to systems living in perpetuity, but not being used, and creating unnecessary risk.

Users having unnecessary access is the antithesis of least privilege, and presents a tangible opportunity for security teams to audit access usage across teams, and deprovision access that exists, but is not being used.

Reason 3: Unused Resources


Getting visibility into access and usage extends beyond reducing risk. In this case, the analysis has shown that 15% of resources available have not been accessed in the last 90 days.

Resources includes everything in your stack—databases, servers, cloud resources. These unused resources are not just a security risk, they may also be systems that can be deprovisioned or moved to a cheaper service to free up budget for other uses. Similar to unused privileges, the question at hand is, “If these resources haven’t been touched in 90 days, do we still need them?”

In the case of the principle of least privilege, it’s not only credentials to be concerned about, it’s the systems that can be accessed by those credentials. Getting visibility into system usage gives security teams an opportunity to reduce their overall risk, while also reducing costs by identifying unused resources.

The Impact of Visibility on Least Privilege


The principle of least privilege is not a flawed methodology. It’s just a methodology that has been impossible to embrace due to the inherent challenges by modern technology. 

The challenge of getting visibility into access, privilege, and resource usage across your entire tech stack is daunting. But the benefits of doing so can be immense:

  • Lower risk by removing unnecessary privileges
  • Reduced attack surface by right-sizing user access
  • Cost savings and reduced attack surface by deprecating unused resources

Your ultimate goal when implementing least privilege should be to effectively get to zero: zero unused privileges, zero over provisioning, and zero unused resources. 

You should also aspire to have zero credentials exposed either to the end-user or the end-user system. This ensures that even where credentials may be over provisioned or have unnecessary access, the human element of risk is removed.

Getting to Least Privilege: StrongDM


When it comes to access management, least privilege is a critical stepping stone on your journey towards achieving zero standing privileges and dynamic access. But historically, it’s been extremely difficult to get the visibility you need in order to implement least privilege as it was meant to be realized.

That’s where StrongDM comes in. StrongDM provides the visibility you need to not only implement least privilege, but also enable you to progress on the Secure Access Maturity Model, a model designed to help you go from identity-based access to dynamic access management.

These changes don’t happen overnight. Achieving true dynamic access is a journey, and being able to reduce risk, limit access to sensitive systems, and understand systems not being used, is an important milestone. StrongDM can help you get there.

See StrongDM in action, book a demo.

About the Author

, Senior Marketing Director, has held marketing leadership roles for Silicon Valley technology companies specializing in database, data management, and data analytics solutions. As head of content marketing at Splunk, Dominic contributed to boosting the company’s market visibility and its growth from a $100M to a $1.3B company. He brings relentless creativity to the task of connecting people with technical products to improve their lives. Dominic holds a B.S. degree in Public Relations from the University of Texas at Austin. To contact Dominic, visit him on LinkedIn.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

Vault Sprawl: How To Manage Multiple Secret Vaults
Addressing Vault Sprawl: How To Manage Multiple Secret Vaults
Secret vaults ensure that sensitive and privileged credentials are well protected, rotated, and only used–or checked out–when necessary. This makes them a critical and foundational tool for credential protection in modern infrastructures.
Augmenting Legacy PAM with StrongDM: Getting to Dynamic Access
We constantly hear about the gender gap in technology. Whether it’s the shortage of female founders and CEOs, claims of discrimination, or the comparatively small number of women in computer science majors, it seems that the issue has become a regular feature story in the news cycle. Disagreement over how to respond abounds on social media, in editorials, and not infrequently within tech companies themselves.
Service Accounts: Definition, Best Practices, Security, and More
Service Accounts: Definition, Best Practices, Security, and More
Is your organization overwhelmed by rampant service account sprawl? Rest assured, you can regain control. Modern Privileged Account Management (PAM) tools and practices empower you to overcome the challenges of unchecked service accounts. The information in this article will help you understand the meaning of service accounts, so you can manage your organization’s service accounts more effectively and mitigate their risks. Robust security is attainable for all your privileged accounts.
PAM Pricing Simplified: Your Cost and ROI Explained
PAM Pricing Simplified: Your Cost and ROI Explained
The cost of a privileged access management (PAM) solution goes beyond the licensing fees. While it’s tempting to look only at the initial costs, evaluating privileged access management pricing includes examining other factors to determine whether the solution will provide a real Return on Investment (ROI) or cause more problems than it solves.
Privilege Elevation and Delegation Management (PEDM) Explained
Privilege Elevation and Delegation Management (PEDM) Explained
In this article, we’ll explore Privileged Elevation and Delegation Management (PEDM). You’ll learn how PEDM works and how it mitigates the risks associated with poorly managed privileged accounts. By the end of this article, you’ll understand why PEDM is an important security strategy and how businesses can use PEDM to manage privileged access and prevent cyberattacks.