Just-in-time access (JIT access) means a person gets a permission only when a task needs it, for a limited time, and loses it automatically afterwards. Microsoft’s identity documentation (opens in a new tab) describes it as a model in which users “receive temporary permissions to perform privileged tasks”, with access granted only when they need it.
Most guides to just-in-time access are about infrastructure: admin roles, servers and databases. This one applies the same idea to support access to customer accounts, the moment a support engineer opens a customer’s account inside your SaaS product. The parts are the same: a request with a reason, an approval, a time box, a narrow scope, automatic revocation and a record.
What is just-in-time access?
JIT access is the opposite of standing access, a permission someone holds all the time whether or not they’re using it. With JIT, nobody holds the privilege by default. It’s granted for one task and removed by the system when the window closes.
CISA’s Zero Trust Maturity Model (opens in a new tab) shows the progression well. At its lowest stage, an organization grants permanent access and reviews it periodically. At the next, access expires. At the advanced stage, access is need-based and session-based. At the optimal stage, automation authorizes “just-in-time and just-enough access” tailored to individual actions and resources.
Two related terms come up often:
- Just-enough access limits what someone can do during the grant, not just when they have it.
- Zero standing access is the end state where nobody holds privileged access by default. Microsoft uses the term for its own service personnel (opens in a new tab), who have no standing privileged access to Microsoft 365 production or to customer data.
Why apply JIT to support access to customer accounts?
Support access to a customer account is privileged access, even if nobody calls it that. The person can see the customer’s data and act with their permissions. A “log in as any user” button available to every support agent is standing access to every customer’s data.
Microsoft applies JIT to exactly this case (opens in a new tab). An engineer who needs customer content requests it through a system called Lockbox. A second person, who can’t be the requester, approves it. Lockbox revokes access when the elevation period ends. Microsoft says the most common reason (opens in a new tab) engineers need that access is a customer support request that requires troubleshooting. Before approving, Lockbox also checks (opens in a new tab) that the requested time is within a maximum, that there’s a business justification and that the resource is within the engineer’s work scope.
You don’t need Microsoft’s scale to copy that shape.
The six parts of JIT access to a customer account
| Part | Question it answers | Weak version | Strong version |
|---|---|---|---|
| Request | Who wants which account, and why? | A Slack message | A named customer, a scope, a duration and a ticket reference |
| Approval | Who agreed? | Implied by job title | A recorded decision, ideally by someone other than the requester |
| Time box | For how long? | Until someone remembers | The shortest useful window, plus an idle timeout |
| Scope | What may they do? | Everything the customer can do | Read-only by default, enforced by the backend |
| Revocation | How does it end? | Manual logout | Automatic and server-side, even with no tab open |
| Record | What can you show later? | Nothing, or chat history | Request, decision, session timing and how it ended |
A few notes on getting each one right:
- Make the reason useful. “Ticket 4821: export button missing for this user” helps an approver and a later reviewer. “Debugging” doesn’t. Treat the reason as required in your team policy, even if a tool lets you leave it blank.
- Approval by the requester isn’t independent review. It can be acceptable for a small team, but record it as what it is.
- Read-only must be enforced on the server. A hidden edit button doesn’t stop an API call. The read-only impersonation guide covers the operation inventory.
- Records come in two kinds. The access record explains why the session existed. Your application’s audit events explain what happened inside it. The impersonation audit log guide shows how to link them.
How is JIT for customer accounts different from PAM?
Privileged access management (PAM) tools such as Microsoft Entra Privileged Identity Management (opens in a new tab) grant elevated roles on directory and cloud resources. They offer time-bound assignments, approval to activate a role, justification, notifications and access reviews. They answer questions like “may this engineer hold the database admin role for an hour?”
Customer-account JIT answers a different question: may this agent see this customer’s account, as that customer, inside our product?
| Infrastructure PAM | JIT for customer accounts | |
|---|---|---|
| What’s granted | A role on servers, databases, cloud or directory resources | A session inside your app as one customer user |
| Whose identity applies | The engineer’s own, elevated | Two identities: the staff actor and the customer subject |
| Who enforces limits | The cloud or directory’s access controls | Your application backend and its tenant checks |
| What “read-only” means | Read-only IAM actions | API endpoints that don’t change state or trigger side effects |
| Who revokes the credential | The PAM tool or the cloud provider | Your application, which issued the session |
Choose a PAM tool when engineers need elevated rights on infrastructure, for example production database access or a cloud admin role.
Choose customer-account JIT when support needs to see a product exactly as a specific customer sees it. Many teams need both, for different jobs.
Where does your team sit? A maturity table
Levels 1 to 4 adapt CISA’s four stages (opens in a new tab), from permanent to just-in-time access, to support access. Level 0 is added for shared credentials.
| Level | What support access looks like | Main risk |
|---|---|---|
| 0. Shared credentials | A shared admin login, or the customer’s password | No way to tell who did what |
| 1. Standing access | Every agent can open any account, reviewed occasionally | Every account is exposed all the time |
| 2. Expiring access | Access granted on request, but broad and long-lived | Wide scope and windows nobody checks |
| 3. Session-based JIT | One customer, one reason, approved, time-boxed, scoped, ended automatically and recorded | Approval quality depends on people |
| 4. Automated JIT | Policy decides routine cases, people review the exceptions | Policy rules need ongoing review |
Most teams with an in-house “log in as user” feature sit at level 1. Moving to level 3 is mostly process plus a few backend changes. Level 4 is worth considering only once level 3 runs smoothly. The build vs buy guide helps decide who should own that work.
How Devora applies JIT to customer accounts
Devora is JIT access for customer accounts. It isn’t a PAM product, and it doesn’t manage servers, databases or cloud roles. Here’s how its workflow maps to the six parts:
- Request. A team member picks a customer from search results (opens in a new tab) your app supplies, then requests a scope, a duration and a reason.
- Approval. An approver or admin in your organization reviews each request. Admins can approve their own requests (opens in a new tab) unless you turn that off. Self-approval is recorded separately from approval by another admin.
- Time box. The requester picks 15 minutes to 2 days, with 15 minutes pre-selected. Sessions also end after an idle timeout (opens in a new tab), 15 minutes by default.
- Scope. Read or write scope, endpoint rules, and a backend guard that enforces them (opens in a new tab) on the routes you protect.
- Revocation. When a session ends, Devora sends your backend a signed termination request (opens in a new tab), retried on failure and sent even with no tab open. Removing a staff member ends their active sessions and revokes their pending and approved requests.
- Record. Devora’s security page lists what it records: requests, decisions, reasons, scope, timing, self-approval, revocation and termination events.
Your application still owns authentication, issuing and revoking its own credential, tenant authorization and business audit events. Devora has no staff-to-customer assignment feature. If agents should only open assigned customers, that check belongs in your app, as the assigned-customer guide explains.
Start with the smallest change that removes standing access
You don’t have to reach level 4 to get most of the benefit. Removing the always-on “log in as” button, and replacing it with a short, recorded, read-only session per ticket, closes the largest gap. If a staging fixture or a denial log can answer the ticket, use that instead.
If you want the request, approval, time box and record handled for you, create a Devora account and try one staging session against the six parts above.
Sources
- Microsoft Learn: What is Privileged Identity Management? (opens in a new tab)
- CISA: Zero Trust Maturity Model, Version 2.0 (April 2023) (opens in a new tab)
- Microsoft Learn: Microsoft 365 service engineer access control (opens in a new tab)
- Microsoft Learn: Customer Lockbox requests (opens in a new tab)
- Devora: Overview for teams (opens in a new tab)
- Devora: FAQ
- Devora: Scope and security (opens in a new tab)
- Devora: Session lifecycle and cleanup (opens in a new tab)
- Devora: Security