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

PAM Was Dead. StrongDM Just Brought it Back to Life. ✨  An important message from StrongDM's CEO!

Close icon
Search bar icon

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

, Technical Marketing Expert, 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

PAM Was Dead. StrongDM Just Brought it Back to Life.
PAM Was Dead. StrongDM Just Brought it Back to Life.
In essence, legacy PAM solutions over-index on access. StrongDM uses the principles of Zero Trust to evaluate and govern every action, no matter how minor - where each command, query, or configuration change is evaluated in real-time against dynamic policies that adapt to the context of the user, the sensitivity of the action, and the prevailing threat landscape.
Privileged Access in the Age of Cloud Authentication & Ephemeral Credentials
Privileged Access in the Age of Cloud Authentication & Ephemeral Credentials
The way that people work continues to evolve, and as a result, so do the ways that they must authenticate into their organization’s resources and systems. Where once you simply had to be hardwired into the local office network, now you must expand your perimeter to include remote and hybrid workforces, on-prem and cloud environments, and take into account a growing list of factors that impact how and where people access critical company resources.
9 Privileged Access Management Best Practices
9 Privileged Access Management Best Practices
Understanding the pillars of access control and following best practices for PAM gives you a roadmap to an implementation that is secure and comprehensive with no security gaps. This article contains nine essential privileged access management best practices recommended by our skilled and experienced identity and access management (IAM) experts.
Vendor Access Management (VAM) Explained
Vendor Access Management (VAM) Explained
Vendor Access Management (VAM) is the systematic control and oversight of vendor access to an organization's systems, applications, and data. It involves processes such as onboarding and offboarding vendors, utilizing solutions for Just-in-Time access, ensuring security, and streamlining workflows to minimize operational inefficiencies.
How to Meet NYDFS Section 500.7 Amendment Requirements
How to Meet NYDFS Section 500.7 Amendment Requirements
The New York Department of Financial Services (“NYDFS”) Cybersecurity Regulation is a set of comprehensive cybersecurity requirements that apply to financial institutions operating in New York. The goal of the regulation is to ensure that the cybersecurity programs of financial institutions have robust safeguards in place to protect customer data and the financial sector.