Privilege on Demand (JIT-P v1.0) helps customers reduce standing access by shifting privileged access to just-in-time activation windows. This improves security posture and auditability while keeping authorized users productive.
Problem
Today, many organizations rely on standing elevated access that remains active longer than needed. That increases exposure and audit risk, and creates an ongoing tradeoff between security controls and operational speed.
Solution
Privilege On Demand introduces an activation-based model for eligible entitlements: users request and receive access, then activate it when work begins for a bounded duration, with automatic expiration.
This gives teams stronger least-privilege enforcement, clear activation/expiration events, and less manual cleanup than traditional standing access models.
Who is affected?
Customers using Identity Security Cloud who need tighter control of elevated access
IAM/Security Admins configuring JIT policy and entitlement eligibility
End users activating approved access via Launchpad
Business+ suite customers (Privilege on Demand (JIT-P) packaging)
Action required (customer-facing)
Confirm Privilege on Demand (JIT-P v1.0) is enabled for the tenant/licensing package.
In Admin settings, configure global JIT activation/extension durations.
Mark target entitlements as requestable and configure JIT entitlement assignments.
Validate approval behavior (auto-approve or approval-required) for target access.
Communicate end-user activation flow in Launchpad.
Important dates
Sandbox availability: Starts Jul 6, 2026, End: TBD, estimated Jul 19, 2026 Production rollout: Subject to change based on previous phases, estimated to begin Jul 20, 2026 , estimated completion Aug 21, 2026 Milestones / phases (if any): Production will roll out to low, medium, and then high risk targets
Really interested by this feature as this was a missing piece in the Privileged Access Management perspective.
I hope that both documentation and deployment dates for for both Sandbox and prod will be available soon to investigate further the possibilities of this feature !
Looking forward also for the event on 30/07 : Improving privilege posture in Identity Security Cloud that should demo this feature.
It is being actively worked on for deployment, and at this trajectory, it seems like next week (ideally early next week) we should make some traction on getting it into more customer’s hands.
We have run into some data quality issues, and are quickly working to resolve that before we provide it to any customers.
@Zia_Hotaki FYI trying this out in a demo tenant. On the end user launchpad, it doesn’t seem to show any information about the assigned JIT entitlement. Just a blank row:
it also appears to just show stuck on “Provisioning” status even though the entitlement is on the user in the downstream system (AD group), so I cannot hit extend or deactivate.
I have tried this in Sandbox, and it’s working fine. However, there is something strange with the e-mail templates. The default template uses ${__recipient.name}, but that returns the user name (initials in our case), which looks odd. When I change it to ${__recipient.displayName}, the test mail is displaying the full name correctly, but when the e-mail is triggered by the process itself, the variable doesn’t resolve: Dear $__recipient.displayName,
I have also tried this in our sandbox and I have three questions:
It does not seem like it is possible to see who is eligible to activate an entitlement? I made an access request on a JIT-P entitlement, but the entitlement was not visible on the identity before the user activated the entitlement. Can you confirm whether this is intended behavior?
We lose visibility if we only can see the entitlement on the user when it is activated. How do we keep track of who can activate (and thereby access) entitlements if it’s only displayed under active state, and not visible before activation and after expiry?
Under “Viewing Activations” admin page, is it only possible to see active activations, or is it intended also to see history of activations? For now, the activation disappeared when it expired. It would be good to have the history in this page as well.
Do you have any considerations regarding adding an approval step on the activation request as well as an option? Ie. this is an option in Entra ID.
I have been able to test it on our Sandbox environment.
It is working well in a sense that we can configure the entitlements as JIT entitlements. We can perform the provisioning of the entitlement using the request center. The entitlement is not assigned directly. → What would be nice is to see that there was a request to make that entitlement available for JIT.
Then the use can go to the JIT launchpad and perform the request. Assignment of the entitlement is done. The user can stop the assignment or leave it to be removed at timeout of the JIT.
This all work !!!
It’s really something that was missing to help on elevated, privileged access management as we are trying to assign these less and less in a permanent way.
Nevertheless, the process as it is designed for the moment might be not fully suitable for some customers which are heavily relying on the RBAC and role model strategy.
Currently, we are not allowing any single entitlement requests in order to force our business to use the roles or access profiles as element to request in the request center.
Assignement of the same entitlement through an access profile or a role is setting this entitlement as permanent and doesn’t make it eligible for the JIT.
By allowing the entitlements requests, we are going against the strategy of the RBAC. We would have liked to be able to make entitlements eligible through roles and access profiles also as we consider that somebody could request to use it only because he is currently in a position that requires the usage of it. As most of the time, it is elevated and privileged accesses that would be protected by this mechanism, we strongly believe that we should have more controls on it and make sure it is aligned with the RBAC and compliance processes.
I would propose to have the entitlements listed as JIT to be incorporated in Access Profiles. When these access profiles are assigned either individually or through roles to marked them as “theoretically assigned” or “JIT silent assigned”. Which make them available in the JIT launchpad.
If entitlement still needs to be populated in a permanent way, I would personally request to have two different entitlements for the same access (one for the permanent access, one for the JIT). This makes also better visibility on who gets it in a permanent way vs those that gets them through the JIT.
New Capability
Description
Problem
Solution
Who is affected?
Action required (customer-facing)
Important dates
Resources