Zero standing privileges for customer accounts: removing support's permanent access

Zero standing privileges means no one holds permanent access to customer data. Inventory standing access, remove it in stages and track the metrics.

Zero standing privileges means nobody holds privileged access by default. Access exists only while an approved, time-limited task needs it, then disappears. For customer accounts, that means no support agent, engineer or admin can open a customer’s data today without a fresh, recorded approval.

Microsoft describes its own version (opens in a new tab), zero standing access, as service personnel having no standing privileged access to Microsoft 365 production or to customer data. Anyone who needs it submits a justified request and gets approval first.

Most teams agree with the goal. The hard part is getting there. The just-in-time access guide covers how approved access works, and the break-glass guide covers emergencies. This one covers the program in between: finding the standing access you have, removing it in stages, and proving it stays gone.

What are zero standing privileges?

Zero standing privileges (ZSP) is an operating state where the number of people holding permanent privileged access to a resource is zero. Zero standing access (ZSA) is the same idea under another name. Standing access is the opposite: a permission someone holds all the time, whether or not they’re using it.

NIST’s zero trust architecture (opens in a new tab) expresses the principle behind it. Access to each resource is granted per session, with the least privilege needed for the task, and access to one resource doesn’t automatically grant access to another. Applied to support, that means access per customer, per task, not to “all customers” for as long as someone holds a role.

Zero standing access doesn’t mean support can never see customer data. It means nobody can see it in advance.

Why shouldn’t support have permanent access to customer data?

Permanent access turns every support account into a key to every customer. A few consequences follow:

  • Exposure grows with headcount. Ten agents with a “log in as user” button means ten people who can open any account, at any hour, for any reason.
  • A stolen staff account reaches everyone. Phishing one agent is enough to reach every customer’s data.
  • Offboarding gaps stay open. A role change or departure has to be remembered in every tool that grants access.
  • Reviews find problems late. NIST SP 800-53 control AC-6(7) (opens in a new tab) asks organizations to review assigned privileges on a schedule and remove those whose need can’t be revalidated. With standing access, that review is the only thing removing access. With zero standing access, the system removes it when each task ends.

How do you measure standing access to customer accounts?

Measure standing access by listing every path to customer data and counting who can use each one today without a per-task approval. Most teams find more paths than they expected.

PathExampleWhere to find who holds it
In-app impersonationA “log in as user” button for staffYour app’s staff roles
Internal admin panelA back office that shows customer recordsThe panel’s user list and roles
Production databaseRead replicas, SQL consoles, connection stringsDatabase roles and cloud access policies
Analytics copiesA warehouse or BI tool with customer tablesWarehouse grants and tool seats
Logs and error trackersRequest bodies or customer content in eventsTool membership
File storageBuckets holding customer uploadsCloud access policies
Shared credentialsA shared admin login, or a customer’s password in a ticketPassword managers and ticket search
Self-approvalAdmins who can approve their own access requestsYour access tool’s settings

For each row, record the number of people, when each last used the access, and an owner. That gives you a baseline: standing holders per path. Use last-used data to find the easy wins. AWS, for instance, provides last accessed information (opens in a new tab) so you can identify unused permissions and remove them.

Self-approval deserves its own line. An admin who can approve their own requests is recorded each time, but can still reach any customer whenever they choose. Count them, even if you decide to keep the setting.

How do you move from standing access to approved access?

Move in stages, and build the approved path before you remove the old one. If you remove the button first, people rebuild standing access through shared logins and database consoles.

  1. Take the inventory above and name an owner for each path.
  2. Remove unused access. Anyone who hasn’t used a path recently loses it now. This is usually the largest, least disruptive cut.
  3. Stand up the request path. One customer, one reason, an approval, a time limit and a record. The just-in-time guide covers the parts.
  4. Make people eligible, not active. Microsoft Entra PIM separates (opens in a new tab) eligible assignments, which someone activates when needed, from active ones, and recommends keeping zero permanently active assignments apart from emergency access accounts. Apply the same split to customer accounts: agents may request access, but hold none.
  5. Pilot with one team, with a rollback plan. Microsoft’s PIM deployment plan includes both. Watch approval times closely during the pilot.
  6. Default to narrow sessions. Start with read-only scope and short durations, enforced by your backend. The read-only guide covers what to block.
  7. Close the side doors. Move database, analytics and log access behind the same approvals, or remove customer content from those systems.
  8. Wire revocation into offboarding. Removing someone from a team should remove their access everywhere on the same day.
  9. Document the exceptions. Keep a short list of break-glass holders and service accounts, each with an owner and a review date.

Which metrics show zero standing access is working?

Track a few numbers monthly. They show whether standing access is shrinking and whether the approved path is fast enough that nobody routes around it. Set your own targets. The direction is what matters.

MetricWhat it tells youHealthy direction
Standing holders per pathHow many people can reach customer data without approvalFalls to zero outside documented exceptions
Paths with any standing holderHow many side doors remain openFalls to zero
Share of customer-account access through an approved requestWhether people use the pathRises toward all access
Median time from request to approvalWhether the path is fast enoughStays short enough that nobody bypasses it
Requested versus used session lengthWhether durations are sized to tasksRequests shrink toward actual use
Self-approved and emergency usesHow often the exception path is usedLow, and every use reviewed
Time from offboarding to revocationWhether removal reaches every pathSame day

A rising approval time is an early warning. If it climbs, expect shared credentials to come back.

What exceptions should zero standing access allow?

Allow as few as you can, and make every one visible. Even Microsoft’s guidance keeps a documented exception (opens in a new tab): two emergency access accounts permanently assigned the Global Administrator role, limited to break-glass scenarios.

Typical exceptions for customer accounts:

  • Break-glass access for incidents when the approval path can’t respond in time. Keep it short-lived, alerted and reviewed, as the break-glass guide describes.
  • Service accounts for jobs that process customer data. Scope them to the job, keep them out of human hands and log their use.
  • Self-approval on small teams with a single admin. Record it as self-approved and review it.

Anything else on the list should have an owner, a reason and an end date.

How does Devora fit?

Devora removes the standing in-app path to customer accounts. Members can search for a customer and request access, but they can’t open the account until an approver or admin in your organization approves the request, as Devora’s overview for teams (opens in a new tab) describes. The requester picks a duration from 15 minutes to 2 days, and the session ends automatically. Removing a member ends their active sessions and revokes their pending and approved requests.

Three limits matter for a zero standing access program:

  • Self-approval is on by default. Admins can approve their own requests (opens in a new tab) unless you turn it off under Settings → General. Count those admins in your inventory.
  • There’s no staff-to-customer assignment. Any member can request any customer your search returns. If agents should only reach assigned customers, check that in your app, as the assigned-customer guide explains.
  • It covers one path. Devora governs access to customer accounts inside your application. Databases, analytics copies, logs and cloud consoles need their own controls.

Start with the inventory table. It usually shows which path to close first. When you’re ready to replace the in-app path, create a Devora account and try one staging session, then measure your standing holders again.

Sources

Quick answers

Common questions, answered clearly.

Direct answers to the questions teams usually ask when evaluating this approach.

What does zero standing privileges mean?

Zero standing privileges means nobody holds privileged access by default. Access is granted for a specific task after a request and approval, for a limited time, and removed automatically when the time ends. Microsoft calls its version zero standing access.

Is zero standing access the same as just-in-time access?

They work together. Zero standing access is the goal: nobody holds access in advance. Just-in-time access is the mechanism that grants temporary access when a task needs it. Without a working just-in-time path, people tend to rebuild standing access through shared accounts or side doors.

Does zero standing access mean support can never see customer data?

No. Support can still see a customer's account when a ticket needs it. The difference is that each access is requested, approved, time-limited and recorded, instead of being available to everyone with a support role at any time.

How do you measure standing access to customer accounts?

List every path to customer data, such as an in-app login-as feature, admin panels, production databases, analytics copies and logs. For each path, count the people who can use it today without a per-task approval. That count, per path, is your baseline, and the goal is zero outside documented exceptions.

Does admin self-approval count as standing access?

In practice it is close to it. An admin who can approve their own requests can reach any customer whenever they choose, even though each use leaves a record. Count those admins separately, keep the group small, and turn self-approval off once you have a second approver available.

Put it into practice

Give your team context.Keep control of access.

Bring approvals, scoped sessions, and access history into your support workflow.