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.
| Path | Example | Where to find who holds it |
|---|---|---|
| In-app impersonation | A “log in as user” button for staff | Your app’s staff roles |
| Internal admin panel | A back office that shows customer records | The panel’s user list and roles |
| Production database | Read replicas, SQL consoles, connection strings | Database roles and cloud access policies |
| Analytics copies | A warehouse or BI tool with customer tables | Warehouse grants and tool seats |
| Logs and error trackers | Request bodies or customer content in events | Tool membership |
| File storage | Buckets holding customer uploads | Cloud access policies |
| Shared credentials | A shared admin login, or a customer’s password in a ticket | Password managers and ticket search |
| Self-approval | Admins who can approve their own access requests | Your 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.
- Take the inventory above and name an owner for each path.
- Remove unused access. Anyone who hasn’t used a path recently loses it now. This is usually the largest, least disruptive cut.
- 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.
- 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.
- Pilot with one team, with a rollback plan. Microsoft’s PIM deployment plan includes both. Watch approval times closely during the pilot.
- Default to narrow sessions. Start with read-only scope and short durations, enforced by your backend. The read-only guide covers what to block.
- Close the side doors. Move database, analytics and log access behind the same approvals, or remove customer content from those systems.
- Wire revocation into offboarding. Removing someone from a team should remove their access everywhere on the same day.
- 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.
| Metric | What it tells you | Healthy direction |
|---|---|---|
| Standing holders per path | How many people can reach customer data without approval | Falls to zero outside documented exceptions |
| Paths with any standing holder | How many side doors remain open | Falls to zero |
| Share of customer-account access through an approved request | Whether people use the path | Rises toward all access |
| Median time from request to approval | Whether the path is fast enough | Stays short enough that nobody bypasses it |
| Requested versus used session length | Whether durations are sized to tasks | Requests shrink toward actual use |
| Self-approved and emergency uses | How often the exception path is used | Low, and every use reviewed |
| Time from offboarding to revocation | Whether removal reaches every path | Same 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
- Microsoft Learn: Microsoft 365 service engineer access control (opens in a new tab)
- NIST SP 800-207: Zero Trust Architecture (opens in a new tab)
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations (opens in a new tab)
- AWS IAM User Guide: Refine permissions in AWS using last accessed information (opens in a new tab)
- Microsoft Learn: Plan a Privileged Identity Management deployment (opens in a new tab)
- Devora: Overview for teams (opens in a new tab)
- Devora: FAQ