The principle of least privilege is one of those controls that almost every organisation acknowledges and almost none fully implement.
The concept is straightforward: every user account, service account, and application should only hold the permissions it genuinely needs to perform its function. No standing admin rights for day-to-day tasks. No service accounts with domain-level access because it was easier to configure that way. No developer with direct write access to a production database three years after they stopped needing it.
What we consistently find on internal engagements is that the initial configuration is often reasonable. The problem is what accumulates over time. Temporary access that was never revoked. Emergency permissions granted during an incident and forgotten. Role assignments that made sense when someone joined a team and were never reviewed when they moved on. That drift is called privilege creep, and it quietly expands your attack surface without any single decision feeling significant at the time.
The practical impact is this: a compromised credential in a well-scoped environment is a contained problem. The same credential in an environment with unchecked privilege creep becomes a path to lateral movement, data access, and potentially domain compromise.
If your organisation has not done a formal access rights review recently, that is worth prioritising. It does not require specialist tooling to start - a structured audit of who has what, cross-referenced against what they actually need, will surface more than most teams expect.