A nightly stock export receives database administrator access because that is the quickest way to make it work. Months later, nobody remembers the reason. The account can still delete tables and change other users' permissions. The export runs successfully, so there is no obvious error on a dashboard asking anyone to investigate.
Least privilege means limiting access to the work that actually needs to happen. A shorter permissions list is not the objective. First establish what the process must do, with which resources and under which conditions. Then determine which consequences of a mistake or compromised account can be prevented.
Describe the operation before choosing the role
The export has a specific job: read stock for the relevant warehouse and write a file to an agreed location. It has no reason to change prices, create users or read personnel records. Even read access needs a boundary: which rows, fields and organisations does the recipient genuinely need?
Hiding an administrative button is ineffective if the same identity can connect directly to the database. Examine the actual access paths. The OWASP authorisation guidance connects least privilege with denial by default and checks on resource access, rather than relying on interface restrictions.
Read-only does not mean harmless. An account might export the entire customer directory or issue queries expensive enough to delay everybody else. Permissions govern allowed actions; workload limits and constraints on data volume address additional risks.
The process owner and an engineer should agree on why a permission is necessary. An activity log cannot decide whether the recipient should receive the complete dataset. If a report only needs aggregated stock, a bounded export may be more appropriate than access to source tables. Reducing authority sometimes starts with changing the interface rather than designing a more complicated role.
Permission to run code can become permission to read data
A dangerous capability does not always have an administrator label. Someone unable to query production directly may be able to modify the program that connects with broad access. They might also launch a job under a more privileged identity. The effective boundary then includes changing and releasing that code.
Review who can assign roles, alter trust settings, replace executable content or manage credentials. For each path, ask whose authority the resulting action will use. A list of directly assigned roles may not reveal the entire chain.
Independent services should not share one account merely for convenience. Separate identities support different permissions and let the company disable one integration without stopping all the others. The AWS IAM recommendations treat temporary credentials and regular permission reviews as distinct parts of this work.
Unused this month is not the same as unnecessary
Activity logs help establish what a process actually did. An ordinary month, however, may not include year-end processing, backup recovery or a rare error path. Removing everything absent from that month's report can cause a failure just when the team has the least time to investigate access rules.
Analysis tools have visibility limits. With AWS last accessed information, the reporting period, tracked actions and attempted access all matter. A missing record is a reason to investigate, not an automatic instruction to remove permission. Successful use does not establish necessity either: a poorly designed process may already rely on excessive access.
Separate routine work from infrequent privileged procedures. A stock export does not need database restoration rights. A distinct recovery procedure can hold those rights with its own owner and verification. A rare need should not become permanent authority for every ordinary run.
Temporary elevation must actually end
An administrator's daily work can be separated from privileged activity. Elevation may require a reason, approval and a limited duration. Microsoft Entra PIM is one implementation of this approach. An expiry time on the request does not, by itself, demonstrate that every application has stopped accepting the previous authority.
After expiry, test an existing session, a new request and credentials created while the elevated role was active. Temporary permission that can quietly leave behind a permanent administrator has limited protective value. The actual termination mechanism depends on the system and should be understood before an incident.
Recovery also needs a controlled emergency path when normal access administration is unavailable. That is not a justification for a shared password in a chat. The exception needs a narrow scope, observable use and subsequent review. Otherwise every urgent task gradually becomes an exception.
Remove access without losing the ability to diagnose failures
Start with one process and its owner. Record its normal result, dependencies and uncommon operations. Test narrower permissions in an appropriate environment, then limit the initial production change. Observation mode can reveal decisions that would have been denied, but does not itself block excessive actions.
Test both outcomes: the export finishes, while writing to another location, changing a table and reading unrelated records are rejected. Include restart, credential replacement and recovery of unfinished work. A test using only an established connection can miss permissions required when a fresh connection is opened.
Support needs the process identity, action, resource and reason for rejection, not a secret or the contents of a protected record. Recovery should restore a specific missing permission after review. Returning to allow-everything at the first inconvenience defeats the exercise.
The result is a working export with a known access boundary, an owner and checks that run when its responsibilities change. Counting deleted permissions is insufficient: the list can become shorter while one remaining path still provides access to everything.