The Principle of Least Privilege, Explained Simply
One of the oldest ideas in security. Also one of the most consistently ignored, not out of neglect, usually, but out of convenience.
Least privilege, in one line: a person, system, or process should have access to exactly what it needs to do its job, and nothing more.
It's one of the oldest ideas in information security↗, and one of the most consistently violated, usually not out of carelessness but out of convenience. Granting broad access up front is simply faster than carefully scoping what a new employee or system actually needs.
The principle matters most not during ordinary operations, but in the moment something goes wrong. If an employee's account is compromised through a phishing↗ email, the attacker inherits every permission that account holds, no more, no less.
Least privilege isn't a one-time configuration; it decays as roles change, projects end, and temporary access grants quietly outlive the reason they were granted. A simple quarterly review of who has access to your most sensitive systems catches most of that drift.
If your organization has never done a formal review, start with the single most sensitive system you have and just list everyone with access today. Most teams are surprised by at least one name on that list.