Enhancement: General Availability Release of Re-authenticated Approvals

Description

:bangbang: We are pleased to announce the GA release of re-authenticated approvals, an important security layer in the access request approval flow that is critical to organizations in regulated industries and has applications for other types of sensitive access as well.

With this functionality, customers can require access request approvals for any sensitive or regulated items to prompt the approver to re-authenticate via their SSO solution before completing the approval. The intent of this extra step is to verify the approver’s identity to ensure the access granted to the target user is appropriately authorized.

The Value

Organizations that operate in highly regulated environments, such as the bio-pharma industry, are often subject to security requirements around the granting of certain access. A common requirement is an electronic signature on the authorization of that access for a user.

Identity Security Cloud can prompt the approver to re-authenticate at the time of approval to meet regulatory e-signature requirements. ISC then audits the action, including the required details about who authorized the access, when it occurred, a business justification, and confirmation that it was authenticated, all serving as evidence of proper authorization.

Who is affected?

We are rolling this feature out globally for all customers!

Note: This feature must be enabled for it to be applied to your tenant. If this use case does not apply to any part of your business, you can simply leave it disabled and it will change nothing for any of your users. If you want to begin using the feature, see the How To Activate section below.

How To Activate

Once this feature is released to your tenant, you still must enable it before any changes will be evident in your tenant.

  1. The first requirement for enabling is that your tenant must be configured with an SSO Identity Provider. This feature relies on your identity provider to perform the reauthentication when prompted.
  2. The second step is to use the Set Access Request Config API endpoint to set the reauthorizationEnabled flag to true.

How to Use

When the feature is fully enabled, a new tab will appear in the Edit pages for any access item, called Reauthentication. For any access item that requires this layer of security, select the box to Require Approval Reauthentication.

Approvers who are SSO-authenticated users will be prompted to reauthenticate through your SSO when approving a grant-access request for those items. Reauthentication is not required for deny decisions, approval reassignments, or revocation request approvals.

Please refer to our [admin] and [user] product documentation for more details and for step-level instructions for both admins and approvers.

Important Dates

This will be rolled out on the following schedule:

Sandbox: Monday, July 28, 2025.

Production: Week of August 4, 2025.

Calendar

:bangbang: By RSVP’ing to this event you will be reminded of this release prior.

2 Likes

Hi @jennifer_mitchell,

Thank you and team for continuing to strengthen security and compliance in access approvals!

To summarize how this works: once enabled, reauthorizationEnabled via Set Access Request Config API endpoint to enforce an additional identity verification step during access approval for sensitive or regulated items; when approvers attempt to approve access to such items, they’ll be prompted to re-authenticate via their SSO provider. This ensures that the person granting access is still who they say they are, right at the moment of approval; not just when they first logged in.

Will the reauthentication be triggered for deny decisions, or reassignments in access request?

I appreciate that the feature integrates cleanly into existing tenants SSO configuration, but will the feature be extended to e-Signature applications like DocuSign?

Would there be a different audit log/event for the approval after reauthentication?

Thank you,
Amar Sheriff

Thanks @TheOneAMSheriff!

No. Because the requirement for authenticating the approver is about the granting of access, decisions that result in no access being granted (deny) or that precede the actual approval decision (as reassignment does) do not require reauth.

We have no plans for that at this time. In fact, for many of our customers interested in this feature, the intent was to replace the need for extensions into apps like that.

The audit data around a reauth approval is, for the most part, captured in the Request Access Approved event - containing the approver, approver comments, date-time of approval, and a reauthorizationSignature attribute which is the token ID sent from the SSO system. For the more complete story, that event can be coupled with the Access Force Auth Passed event which contains the same token under the attribute name requestSignatureId as evidence of the source of that ID. And in fact, there are a total of 5 events that appear in the log at that same point (within seconds) that describe the whole sequence:

  • Send Saml Request Passed
  • Receive Saml Assertion Passed
  • Access Force Auth Passed
  • Add Workitem Complete Comments Passed
  • Request Access Approved
1 Like