What is least privilege?

Key takeaways

• Least privilege is a principle, not a tool. The implementation is in role design, group membership, conditional access policy, and continuous review.
• The biggest enemy of least privilege is privilege creep: access accumulates over time as users change roles, projects complete, and exceptions become permanent.
• For mid-market manufacturers, least privilege gaps usually surface most clearly during assumed-breach simulation, when a foothold reaches systems the user never needed.
• The discipline is in the review cadence, not the initial assignment. Quarterly access reviews for privileged accounts, annual for general workforce, immediate after role changes.
• ARG measures least-privilege adherence during simulation and tracks the trend over engagements.

What is the principle of least privilege, in practice?

The principle is straightforward: give every account, process, and machine only the access it needs to do its job. The practice is harder than the principle.

In practice, least privilege requires:

1. Defined functions for each account. What does this account do. The function is documented; access is scoped to the function.
2. Role-based access design. Common functions grouped into roles; users assigned to roles; access flows from the role, not from individual exceptions.
3. Exception management. Where access exceptions exist, they are documented, time-bounded, and reviewed.
4. Continuous review. Access reviewed at least annually for general accounts, more often for privileged accounts. Reviews focus on whether the access still matches the function.
5. Removal discipline. Access removed promptly when no longer needed: role change, project completion, employment termination, vendor offboarding.

The practical alternative to least privilege is privilege creep: every user has access to everything they have ever needed, plus access they were granted for one-time tasks, plus access inherited from groups they joined for one reason. The compromise blast radius grows linearly with privilege creep; reducing the creep reduces the impact of compromise.

For mid-market manufacturers, the most common starting state is "everyone has read access to most things". Least privilege at this stage is about reducing the access surface that any single compromise touches, not about achieving perfection.

Least privilege for users, services, and machines

The principle applies to three categories of identity, each with its own implementation.

User accounts. Human employees. Least privilege scopes access to job function: AP staff have access to AP systems but not to engineering files; engineering staff have access to CAD and BoM but not to payroll; IT staff have admin rights only for tasks that require them. The implementation is role-based access control with documented role definitions and assigned membership.

Service accounts. Non-human accounts used by applications, scripts, and integrations. Least privilege scopes access to the specific operations the service needs: a backup service account needs read access to the backup targets and write access to the backup destination, not domain admin. Service accounts often violate least privilege because they were created with broad rights "to make it work" during initial deployment and never reviewed.

Machine accounts and processes. Process-level privilege on individual systems. Application processes should not run as administrator unless they need administrator rights for specific tasks. Local accounts should be scoped to local operations only. The implementation is OS-level privilege configuration plus application-level least-privilege design.

A complete least-privilege program addresses all three categories. Most mid-market manufacturers focus on user accounts first; service accounts and machine-level least privilege follow.

Why least privilege fails most often during fast hiring or M&A

Two organizational situations produce the most least-privilege drift:

1. Fast hiring. During growth phases, new employees are onboarded quickly. Default access patterns are broad ("give them what their team has") rather than role-specific. Privilege creep accumulates from day one.
2. M&A integration. Acquired companies bring their own access patterns. Integration usually grants acquired-company users access to the parent environment without restructuring; parent-company users gain access to acquired-company systems for "integration support" that never ends. The combined entity has more permissions than either side had separately.

Other contributing factors:

• Project-based access that becomes permanent. A user joins a temporary project; gets access to project resources; the project ends; the access stays.
• Departing employees without removal. Termination procedures focus on email and laptop; group memberships, application access, and service-account ownership are not always reviewed.
• Role changes without access cleanup. A user moves from engineering to operations; gains operations access; retains engineering access "in case it's needed".
• Exceptions that become routine. "Just for this week" becomes "ongoing"; the exception is never reviewed.

The fix is structural: access reviews on a documented cadence, automated where possible. Without the discipline, the drift accumulates faster than the program can fix.

Examples of overprivileged accounts found in audits

Patterns ARG sees during engagements at mid-market manufacturers:

• Active Directory "Authenticated Users" with broad share permissions. Network shares with ACLs that grant Authenticated Users read access. Any compromised user account reaches the share. Often the result of a 2018 migration that left default permissions in place.
• Service account with domain admin. Backup software, monitoring tool, or integration runs with domain admin because "it needed broad rights during install". The rights were never narrowed.
• AP clerk with engineering file access. A user who joined AP after time in engineering still has membership in engineering groups. The group is the access path.
• Departed employee's account active for months. Off-boarding closed email and revoked the laptop, but did not disable the Active Directory account. The account is still active; its group memberships still grant access.
• Vendor account with rights to multiple environments. Vendor was originally engaged for one specific system; over time, access was added to adjacent systems; the original scope was forgotten.
• Microsoft 365 admin rights granted to "just one person who needed them once". The rights remain. Multiple "just one person" grants accumulate into a long list of effective tenant admins.
• Local admin on most workstations. Workstations were imaged with the user as local admin "because IT was short-staffed at the time"; the configuration was never adjusted.

Each example reduces the security surface the program needs to defend. Each one is fixable through a structured access review.

How to audit and right-size privileges without breaking workflows

The right-sizing project is sequential, not big-bang. A practical sequence:

1. Inventory access. Pull current group memberships, role assignments, and explicit ACLs from the identity provider, file servers, and applications. The output is a data set, not a target state yet.
2. Define target roles. What roles exist (Finance, AP, Engineering, IT, Operations, Executive, etc.). What access each role should have. Documented before changes.
3. Map current state to target. For each user, compare current access to target-role access. The gap is the right-sizing list per user.
4. Review high-risk gaps first. Users whose current access is materially broader than target role: admin rights that should not exist, cross-functional access that accumulated, departed-employee accounts. These get attention before low-risk gaps.
5. Communicate before changing. Users are told their access is being reviewed; they have a window to flag genuine needs the role design missed; changes happen after the window closes.
6. Implement changes in waves. Cohort by cohort or role by role. Each wave's results inform the next wave's adjustments.
7. Establish review cadence. After the right-sizing is complete, ongoing reviews maintain the state. Quarterly for privileged accounts, annual for general workforce.
8. Pair with PAM and conditional access work. Least privilege is most effective when combined with privileged-account hardening and conditional-access policy.

The work usually takes six to twelve months for a 200-person manufacturer. Without right-sizing, the program is starting from privilege creep that has accumulated for years; with right-sizing, the program has a clean baseline to maintain.

Best practices for sustaining least privilege over time

Once the initial right-sizing is done, the program shifts to maintenance.

1. Quarterly access reviews for privileged accounts. Each privileged account's continued access is justified. Drift surfaces and is corrected.
2. Annual access reviews for general accounts. Manager-driven; the manager confirms that each direct report's access still matches the role.
3. Role-change triggered review. When a user changes roles, their access is reviewed and adjusted. The new access is appropriate to the new role; the old role's access is removed.
4. Off-boarding discipline. Termination procedures remove access promptly. Active Directory account disabled, application access revoked, group memberships removed, license released. The procedure is documented and audited.
5. Service account lifecycle management. Each service account has a named owner; the owner is responsible for confirming continued need annually. Dormant service accounts surface and are removed.
6. Vendor access lifecycle. Vendor accounts have defined start and end dates. Time-bounded by default; renewal requires explicit reauthorization.
7. Exception handling. Exceptions to least privilege are documented, time-bounded, and reviewed. An exception that has been in place for two years is no longer an exception; it is the new normal and should be formalized or removed.
8. Continuous testing through assumed-breach simulation. The simulation surfaces where current privileges produce blast radius beyond expectation. Findings drive specific privilege reduction.
9. Map to compliance frameworks. Least privilege is referenced in NIST CSF 2.0, NIST SP 800-171, CIS Controls, and ISO 27001. The evidence supports multiple frameworks simultaneously.

Least privilege FAQs

Is least privilege the same as zero trust?

Related but not identical. Least privilege is a principle about access scoping. Zero trust is a broader architectural model that assumes no implicit trust and authenticates every access decision. Zero trust includes least privilege as one component alongside continuous verification, micro-segmentation, and explicit policy.

How often should access reviews happen?

Quarterly for privileged accounts and high-risk roles. Annual for general workforce. Immediately after role changes, terminations, M&A activity, or material organizational change. Continuous monitoring for high-impact access (admin, finance, OT-adjacent) catches drift between formal reviews.

Does least privilege slow down operations?

Initially yes, slightly. Users accustomed to broad access may need to request specific access they did not need to request before. Mature implementations use just-in-time elevation, role-based access groups, and self-service approval workflows to keep friction low. Done well, least privilege does not slow operations meaningfully after the transition.

What is the difference between least privilege and need-to-know?

Least privilege focuses on the scope of access (what permissions an account has). Need-to-know focuses on information (which data a person can see). The two overlap because access often determines information visibility. Least privilege is the broader principle covering all access; need-to-know is the information-specific variant typically discussed in classified or regulated contexts.

How ARG measures least-privilege adherence during simulation

Least-privilege adherence is measured during assumed-breach simulation in every ARG engagement. The work is operated by James Wall on infrastructure ARG controls.

For each simulated attack chain, ARG records:

• Starting access scope. What access the assumed-breach starting position holds. Granted access plus group memberships plus inherited permissions.
• Lateral reach. What additional access the starting position can reach through privilege escalation, credential extraction, and inherited group membership. The lateral reach measures the actual blast radius of compromising this position.
• Objective accessibility. Whether the engagement's business-impact objectives (wire fraud, IP exfiltration, OT pivot) are reachable from the starting position.

The findings produce specific least-privilege observations: "this AP clerk position has access to engineering file shares because of a 2019 group membership"; "this IT helpdesk position can reach domain admin through cached credentials on a server it should not need to access"; "this vendor account holds rights to seven systems instead of the one it was provisioned for".

Findings consolidate into the monthly operational packet alongside the rest of the engagement. The remediation backlog includes specific privilege-reduction items, prioritized by blast-radius impact. Re-tests in subsequent rounds confirm the closed gaps stay closed.

The output supports insurance underwriting (carriers reward documented access reviews) and CMMC / NIST SP 800-171 compliance for the Access Control family.

For founding clients, least-privilege measurement is part of the standard engagement. The expected outcome is a measurable reduction in blast-radius-per-foothold over the engagement's first year.

Apply as a founding client or see how the engagement works for the full delivery cycle.