Least privilege means every person, administrator and service account has only the access its job requires. Just-in-time (JIT) access adds a time dimension: elevated rights are granted on request, for a short window, and removed automatically afterwards. In practice that comes down to designing roles around real job functions, reviewing access regularly, removing standing admin rights, granting elevation with approval and time limits, trimming cloud permissions using usage data, controlling service accounts and keeping a few well-protected break-glass accounts. This post walks through each of those.

What is least privilege?

Least privilege is an old principle and a familiar control. NIST SP 800-53 covers it as control AC-6, and CIS Controls v8 addresses it across Control 5 (Account Management) and Control 6 (Access Control Management). The goal is simple: when an account is stolen or misused, or its owner makes a mistake, the damage is limited to what that account could reach.

It remains one of the most common gaps we see. Earlier this month, NSA and CISA published a joint advisory on the top ten cybersecurity misconfigurations their red and blue teams find in large organizations. Improper separation of user and administrator privilege was second on the list, covering excessive account privileges, elevated service account permissions and the non-essential use of elevated accounts.

What is just-in-time access?

Just-in-time access replaces permanent (standing) privileges with temporary ones. An administrator's everyday account has no elevated rights. When they need to change a firewall rule or restart a production service, they request the role, it's granted for a set period, and it expires on its own.

Standing access Just-in-time access
When rights exist All the time Only during an approved window
Exposure if the account is compromised Full privileges, any time Nothing elevated, unless a session is active
Approval Once, at provisioning Per request, by policy
Audit trail Who has access Who used access, when and why

The end state some teams aim for is zero standing privilege, where no human account holds admin rights by default. Few mid-sized organizations get all the way there, but every standing privilege you remove shrinks the target.

How do you design roles for least privilege?

Good roles make least privilege sustainable. Bad ones push people toward "just give them admin."

  • Start from job functions, not individuals. Define roles around what a team does, such as accounts payable, help desk or database operations, and not around what a specific person happened to accumulate.
  • Assign permissions to groups, never directly to users. Direct grants are easy to miss in reviews and tend to survive role changes.
  • Build from usage data. Look at what current role holders actually use before deciding what the role should include.
  • Separate conflicting duties. The person who creates a vendor shouldn't be the person who approves its payments. The engineer who writes a change shouldn't be the only one who approves it for production.
  • Split birthright and requestable access. Everyone in a role gets a baseline automatically. Anything beyond that is requested, approved and time-limited.
  • Keep the role count manageable. Hundreds of near-identical roles are as hard to govern as none. Handle one-off needs as time-bound exceptions.

CIS Controls v8 Safeguard 6.8, Define and Maintain Role-Based Access Control, sits in Implementation Group 3. Don't let that put you off. Rough roles for your main job functions help at any size.

How should access reviews work?

Access reviews catch the privilege creep that builds up as people change jobs, projects end and exceptions pile up. Reviews often fail because they turn into rubber stamps. A few changes make them worth doing:

  1. Send reviews to the people who know. Resource owners understand who should access their system better than line managers do.
  2. Show useful context. Include the role, the last time the access was used and whether it's privileged.
  3. Revoke by default. If a reviewer doesn't confirm access by the deadline, remove it.
  4. Review privileged access more often. Quarterly for admin and production access is a reasonable default, with standard access reviewed at least annually.
  5. Fix the mover process. People who change roles often keep their old access. Trigger a review whenever someone's job, department or manager changes.

Keep the evidence. Auditors will ask, and it also shows whether your reviews actually remove anything.

How do you remove standing admin rights?

This is usually the step with the biggest risk reduction. Do it in phases so you don't break things.

On endpoints

Remove local administrator rights from everyday user accounts. Replace them with a self-service software catalog and, where needed, an elevation mechanism for specific approved tasks. Make sure each machine's built-in local administrator account has a unique, randomized password, so one recovered password can't be reused across the fleet.

On servers and infrastructure

Give administrators separate admin accounts that are never used for email or web browsing. CIS Safeguard 5.4 calls for exactly this. Admin rights should sit on those accounts only, and ideally only when activated.

In your directory and identity platforms

Count the members of your most powerful groups, such as domain-level and tenant-level administrator roles. In many environments that number is far higher than anyone expects. Reduce it to the smallest workable set, move everyone else to scoped roles and make the remaining high-privilege roles eligible for JIT activation instead of permanently assigned.

How does JIT elevation work in practice?

A workable JIT flow for a mid-sized organization looks like this:

  1. Request. The admin requests a specific role on a specific scope and gives a reason, ideally a ticket or change number.
  2. Approve. Policy decides who approves. Lower-risk roles can auto-approve with logging. High-impact roles need a peer or manager.
  3. Reauthenticate. Require MFA at activation, even if the user already signed in with MFA.
  4. Time-box. Grant the role for the shortest practical window, commonly one to eight hours, with a short default.
  5. Expire automatically. Removal shouldn't depend on anyone remembering.
  6. Log and review. Record the request, the approval and what was done during the session, and sample those records regularly.

Many identity and cloud platforms support time-bound role assignments natively. Where they don't, time-limited group membership or role bindings with an expiry condition achieve much the same result.

How do you apply least privilege in cloud IAM?

Cloud permissions sprawl faster than on-premises ones. Broad built-in roles, wildcard policies and old experiments leave identities with far more access than they use.

Your cloud provider records when identities, roles and permissions were last used. Use that data for an unused permissions analysis:

  • Unused identities. Disable users, roles and access keys with no activity in the last 90 days, after checking with their owners.
  • Unused permissions. Compare what each role is granted with what it has actually used, then remove the difference. Some providers can generate a starting policy from recorded activity.
  • Wildcards. Replace * actions and resources with specific ones, starting with production.
  • Broad built-in roles. Swap owner- or administrator-level assignments for narrower roles scoped to the resources people actually manage.

Put organization-level guardrails in place that no account can override, such as blocking changes to audit logging or restricting which regions can be used. Keep routine human access to production minimal and let deployment pipelines make changes instead.

How should you manage service accounts?

Service accounts often hold wide privileges, rarely change their passwords and have no clear owner. They deserve the same discipline as human admins.

  • Inventory them. CIS Safeguard 5.5 asks for an inventory with an owner, purpose and review date for each account, reviewed at least quarterly.
  • Scope them. A backup job needs backup rights, not domain-wide administrator rights.
  • Block interactive sign-in. A service account should never be used to log on to a desktop.
  • Protect the credentials. Use long, random, rotated passwords. Weak service account passwords are a known target for offline cracking techniques such as Kerberoasting. Where the platform supports managed identities or automatically rotated service credentials, use them instead of static secrets.
  • Watch their behavior. Alert when a service account signs in from a host it doesn't normally use.

In the cloud, prefer workload identities with short-lived tokens over long-lived access keys stored in code or configuration files.

What are break-glass accounts and how do you protect them?

Break-glass accounts are emergency accounts for when normal administration fails. That might be an identity provider outage, broken federation or an access policy that locks every admin out. Least privilege and JIT don't remove the need for them, but they need careful handling.

  • Keep two, not one, so a single lost credential doesn't leave you stuck.
  • Make them cloud-only or local, so they don't depend on the systems they're meant to recover.
  • Use long random passwords and hardware-based MFA, stored securely with access split between people where practical.
  • Exclude them only from the specific policies that could lock them out, and document why.
  • Alert on every sign-in, without exception.
  • Test them on a schedule, and rotate credentials after every use.

Frequently asked questions

Is least privilege the same as zero standing privilege?

No. Least privilege limits what an account can do. Zero standing privilege also limits when it can do it, by removing admin rights until they're requested. JIT access is how you get from the first to the second.

How long should a JIT session last?

As short as the task allows. One to four hours covers most routine administration, with longer windows reserved for planned maintenance. If people constantly request extensions, the default is too short or the role is too narrow.

Won't removing admin rights overwhelm the help desk?

It can at first. Reduce the load by building a self-service software catalog before removing rights and by rolling out in waves. Track the requests that come in, then fix the common ones with better tooling or role changes.

How often should we review access?

Quarterly for privileged and production access, and at least annually for everything else. Also trigger a review whenever someone changes roles.

Next steps

  • Count your standing administrators across the directory, cloud and key SaaS platforms.
  • Move admin rights onto separate accounts and make the highest roles JIT-eligible.
  • Run an unused permissions analysis on your production cloud accounts.
  • Inventory service accounts, assign owners and remove interactive sign-in.
  • Set up two break-glass accounts with alerting, and test them.