AC-6: Least Privilege

What this control requires

AC-06 requires organizations to limit every user and process to the minimum access needed to perform assigned tasks. This is the principle of least privilege, and it applies across people, automated processes, and system-level accounts. Rather than granting broad permissions and hoping nothing goes wrong, least privilege demands that each identity starts with zero standing access and receives only what a specific role requires.

In practice, this means organizations must define granular roles, assign permissions based on documented job functions, and enforce those boundaries through technical controls. Least privilege extends beyond initial account provisioning. It also covers the development, implementation, and operation of systems, requiring that even privileged processes run at the lowest privilege level necessary to complete their function.

Specifically, the control sits within the Access Control family of the NIST SP 800-53 framework. Organizations meeting MODERATE or HIGH baselines must implement AC-06 and demonstrate that access authorizations are actively managed and enforced rather than assumed.

Why it matters

Excessive permissions are one of the most common root causes of data breaches and insider threats. When users or processes hold more access than their role requires, a single compromised credential or a single dishonest employee can expose data across the entire organization. The damage scales with the breadth of access, turning what should be a contained incident into an enterprise-wide crisis.

The consequences extend beyond direct data loss. Regulatory penalties, legal liability, and reputational harm compound when investigations reveal that access controls were either misconfigured or never verified. Organizations that fail to enforce least privilege often discover the gap only after an incident forces a forensic review.

Morgan Stanley Smith Barney and Galen Marsh

Between June 2011 and December 2014, Galen Marsh, a financial advisor at Morgan Stanley Smith Barney’s (MSSB) Manhattan office, used the firm’s internal web portals to download client data far beyond his own book of business. Marsh’s legitimate access was scoped to clients he personally advised.

However, two internal MSSB portals contained authorization modules that had not functioned effectively for more than 10 years. These modules were supposed to enforce access boundaries between advisor groups and branch offices but did not actually restrict queries.

In practice, Marsh exploited this gap to download personal and financial information on over 700,000 MSSB clients across unrelated branches and regions, including names, addresses, account numbers, balances, and holdings. Portions of the stolen data were posted online and offered for sale before MSSB discovered the exposure.

Where AC-06 specifically broke down was that authorization boundaries meant to restrict Marsh to his own clients had been non-functional for a decade without detection or correction. Least privilege requires that access be limited to what is necessary for each role, not just at provisioning but continuously, with mechanisms verified to be enforcing those boundaries. Marsh pleaded guilty in December 2015 and was sentenced to three years’ probation and $600,000 in restitution.

The consequences extended to regulatory action. The SEC separately fined Morgan Stanley $1 million under Regulation S-P for failing to adopt written policies and procedures reasonably designed to safeguard customer records.

What attackers exploit

• Stale or unreviewed permissions that accumulate as employees change roles, leaving dormant access paths open across departments
• Overly broad service accounts configured with administrative privileges for convenience during setup and never scoped down afterward
• Shared credentials or group accounts that make it impossible to trace actions to a specific individual or enforce role-based boundaries
• Lack of periodic access certification, allowing privilege drift to go undetected for months or years
• Unrestricted lateral movement within flat networks where compromising one system grants access to many others

How to implement

Implementing least privilege sounds straightforward in theory, but most organizations struggle with it because access decisions are scattered across dozens of systems, each with its own permission model. The real difficulty is not writing a policy but ensuring that the policy is actually enforced, verified, and maintained across every system and identity in the environment.

For your organization

The first step is building a complete inventory of all user accounts, service accounts, and system-level identities. Map each identity to its role and the specific data or systems it needs to access. This mapping becomes the foundation for every access decision.

In practice, this means implementing role-based access control (RBAC) as the primary mechanism for assigning permissions. Define roles based on job functions, not on individuals. Each role should carry the narrowest set of permissions that still allows the function to be performed.

Where this often breaks down is with privileged accounts. System administrators, database administrators, and network engineers need elevated access, but that access should live in separate privileged accounts distinct from daily-use credentials. Enforce multi-factor authentication on all privileged sessions and log every action taken under elevated privileges.

The result of unreviewed permissions is privilege drift, which is why a formal access control review cycle is essential. Quarterly reviews are a common cadence, but high-risk systems may warrant monthly certification. During each review, managers must confirm that every permission assigned to their team members is still required for current duties.

Take provisioning and deprovisioning as an example of where automation pays off. When an employee changes roles, automated workflows should revoke old permissions and assign new ones based on the updated role. When an employee departs, all access should be disabled within hours, not days.

For your vendors

Third-party access introduces the same least privilege risks but with less visibility and control. Vendors, contractors, and managed service providers often receive broader access than their engagement requires because scoping third-party permissions takes coordination between procurement, security, and the business unit managing the relationship.

In practice, this means defining explicit access requirements for every third-party engagement before granting any credentials. Document what data the vendor needs to access, which systems are in scope, and what actions the vendor is authorized to perform. Formalize this scope in the contract and enforce it through technical controls, not just policy language.

Specifically, provision dedicated accounts for each vendor with permissions limited to the agreed scope. Never allow vendors to use shared internal accounts or inherit permissions from an internal role. Apply time-bound access wherever possible, configuring accounts to expire at the end of the engagement period and requiring re-authorization for extensions.

But scoping access at the start is not enough without ongoing verification. Log all third-party sessions and flag any access that falls outside the defined scope. Establish automated alerts for anomalous behavior, such as a vendor account querying data from systems or regions outside their authorized boundary.

The result is that periodic access reviews of all active vendor accounts become essential. Confirm that each vendor still requires the access they hold, that the engagement is still active, and that the permissions match the current scope of work. Vendors whose engagements have ended should have all access revoked immediately.

Evidence examples

Cross-framework mapping

Related controls

• AC-02 Account Management. Governs the lifecycle of accounts that AC-06 constrains, ensuring accounts are created, modified, and removed in alignment with least privilege assignments.
• AC-03 Access Enforcement. Provides the technical mechanisms that enforce the permission boundaries defined under AC-06.
• AC-05 Separation of Duties. Complements least privilege by ensuring that no single individual holds enough access to complete a high-risk process without oversight.
• AC-16 Security and Privacy Attributes. Supports least privilege by associating security attributes with subjects and objects, enabling more granular access decisions.
• CM-05 Access Restrictions for Change. Restricts who can modify system configurations, directly reinforcing least privilege for change management functions.
• CM-11 User-installed Software. Limits the ability of users to install software, preventing privilege escalation through unauthorized applications.
• PL-02 System Security and Privacy Plans. Documents the intended access control posture, including least privilege requirements, for each system.
• PM-12 Insider Threat Program. Addresses the organizational detection and response capabilities that catch failures in least privilege enforcement.
• SA-08 Security and Privacy Engineering Principles. Embeds least privilege into system design from the architecture phase rather than retrofitting it after deployment.
• SA-15 Development Process, Standards, and Tools. Ensures that development environments and toolchains also follow least privilege, preventing developers from holding excessive production access.

Frequently asked questions

What is NIST SP 800-53 AC-06?

AC-06 is the least privilege control within NIST SP 800-53, requiring organizations to grant users and processes only the minimum access necessary to perform assigned tasks. It applies to all system identities, including human users, automated processes, and service accounts. The control mandates that organizations define roles, enforce access boundaries through technical controls, and verify that those boundaries remain effective over time.

AC-06 is required for both MODERATE and HIGH baselines under NIST SP 800-53 Revision 5.

What happens if AC-06 is not implemented?

Failure to implement AC-06 exposes the organization to privilege abuse, credential theft, and uncontrolled lateral movement across systems. The Morgan Stanley Smith Barney breach demonstrated this risk directly. Authorization modules that were supposed to restrict advisor access went unenforced for more than 10 years, allowing a single financial advisor to download data on over 700,000 client accounts outside his authorized scope.

Without least privilege, a compromised or malicious account can access data and systems far beyond what any single role should reach, turning a localized incident into an organization-wide breach.

How do you audit AC-06?

Auditing AC-06 starts with verifying that documented access control policies define least privilege requirements for every role and system. Collect current access authorization records and compare assigned permissions against role definitions to identify any privilege drift. Review system configuration settings to confirm that RBAC policies, group memberships, and service account permissions match documented baselines.

Examine audit logs for evidence that privileged actions are recorded and reviewed. Confirm that periodic access reviews have been conducted, with documentation showing that unnecessary permissions were identified and revoked. For third-party accounts, verify that vendor access is scoped to contractual requirements and that deprovisioning occurs when engagements end.

What is the difference between least privilege and zero trust?

Least privilege is a specific access control principle that limits each identity to the minimum permissions required for its assigned function. Zero trust is a broader security architecture that assumes no identity or network location is inherently trusted and requires continuous verification for every access request. AC-06 focuses on permission scoping, ensuring that roles carry only necessary privileges.

Zero trust encompasses least privilege but extends further by requiring authentication and authorization at every access point, applying micro-segmentation, and continuously evaluating trust based on context such as device posture, location, and behavior. Implementing AC-06 is a foundational step toward a zero trust architecture, but zero trust adds layers of verification that go beyond permission assignment alone.