This feels like another half-baked feature that was not thought out as well as it should have been.
I don’t understand why the decision was made for the end or expiration time to be in force from the moment the request is submitted instead of from the moment final approval is granted and provisioning happens. This is not an intuitive design. I have IAM admins and management who have asked me why this works this way, as there is nothing we can do to change it.
Also, given the decision was made for the clock to start ticking at request time, I would think that you would let us submit temporary access in advance to get around this limitation, but nope, we can’t do that either and can only submit temporary access within the limits that we set on the role.
What this means from an IAM admin/engineering perspective, is we have users who are submitting requests and being approved and having access provisioned and then immediately deprovisioned who then reach out to us as to why they don’t have the access.
Again, not a well thought out implementation of this feature, which has the potential to be very useful, but not in its current state.
Hi @jennifer_mitchell, is there any way I can track the progress on that feature? that feature is much wanted from our perspective. Or are there any ETA?
From what I understood another feature related to JIT is eligibility i.e they’re already “pre-approved” so they can use the tool similar to Microsoft PIM. You PIM out your access when you need it since you have the eligibility to, I would love to know when you’re planning on realesing this!
I agree with the concern raised here. Right now, the expiration timer starts as soon as a request is submitted, not when it’s finally approved and provisioned. This causes problems because any delay in approvals cuts into the temporary access window.
We’ve seen cases where access is approved, provisioned, and then immediately removed, which confuses users and creates extra support work. It makes temporary access much less useful.
A better approach would be to either start the timer at provisioning or allow requests to be scheduled in advance. Without one of these options, the feature doesn’t deliver the value it should