Least privilege

Least privilege limits the blast radius of every account. If an engineer, service account or application holds only the rights its job requires, a stolen password or a careless command can do far less damage. The principle is old and widely accepted; the hard part is applying it continuously as people, systems and permissions change.

Where the definition comes from

The NIST glossary, citing CNSSI 4009, describes least privilege as a principle that a system should restrict the access privileges of users, or processes acting on behalf of users, to the minimum necessary to accomplish assigned tasks. NIST SP 800-53 Rev. 5 turns it into control AC-6, with enhancements that matter for privileged access:

Control	Requirement in brief
AC-6	Allow only the authorised accesses needed for assigned tasks
AC-6(2)	Use non-privileged accounts for non-security functions
AC-6(5)	Restrict privileged accounts to defined personnel or roles
AC-6(7)	Review privileges periodically and remove those not needed
AC-6(9)	Log the execution of privileged functions

How it works

1. Inventory accounts and what they can reach, including nested group memberships and local admin rights.
2. Separate everyday accounts from privileged ones.
3. Scope each role to specific actions on specific resources. AWS’s IAM best practices describe this as defining the actions allowed on specific resources under specific conditions.
4. Add time. Grant elevated rights just in time rather than permanently.
5. Review usage and remove unused rights on a schedule.

Why it matters

When an account is compromised, the attacker inherits every right it holds, so narrow rights mean a narrower incident. They also make audit simpler: fewer privileged accounts means fewer sessions to review and fewer credentials to rotate. NIST SP 800-207 builds least privilege into zero trust: access to each resource should be granted per session with the least privileges needed to complete the task.

Least privilege vs zero standing privileges

Least privilege limits how much access an identity has. Zero standing privileges adds a limit on when: privileged rights do not exist at rest at all and are granted per task. An account can follow least privilege and still hold a narrowly scoped admin role permanently; ZSP removes even that between tasks.

Examples

• A reporting service gets read-only access to two tables instead of the database owner role.
• An engineer asks for read-only database access to investigate an incident rather than full administrator rights.
• A cloud deployment role can update one service but cannot change IAM policies.

How SWOT supports it

SWOT Radar shows, for every host, the local admins, sudo and wheel members and SSH users, following nested AD groups, which is the starting point for removing excess rights. SWOT PAM grants scoped, time-bound access such as read-only database sessions, and SWOT Cloud PAM issues short-lived cloud credentials clamped to the session. See zero standing privileges.