Secure approvals: Why re-authentication (MFA) matters for critical decisions

[#1]

In many Jira Cloud instances, approvals are used for highly sensitive business decisions— financial sign-offs, compliance approvals, production changes, or access-related requests. While Jira Cloud does a great job securing user access at login time, one question often comes up in discussions with administrators:

How can we be sure that the person approving an issue is really the intended decision-maker at the moment the decision is made?

This becomes especially relevant in everyday situations: shared workstations, long-running browser sessions, or simply forgetting to lock a screen. In these cases, a valid Jira session alone may not be sufficient protection for critical approvals.

To address this concern, I recently introduced a new feature called Re-Authentication in my app Group Sign-Off / Multi-Approval for Jira Cloud: you can find it on the Atlassian Marketplace.

The idea is straightforward: even if a user is already logged in to Jira, submitting an approval can require an additional confirmation step. This ensures that the decision is intentional and actively performed by the correct person—right at the moment it matters.

To remain independent of Atlassian login mechanisms and any configured SSO setup, the app uses user-specific app secrets as an additional layer of security for approvals. These secrets are managed per user and are only required when submitting an approval decision, not during normal issue interaction. This approach adds protection without interfering with existing authentication or identity providers.

However, securing who makes a decision is only one side of the story. In many regulated or audit-relevant environments, another question is just as important:

Why was this decision made?

For that reason, the app also supports an optional justification step as part of the approval. While re-authentication acts as a pre-decision safeguard, justification works as a post-decision documentation step. Approvers can be required to provide a short explanation when approving or declining an issue, ensuring that the reasoning behind a decision is captured and traceable later on.

From a practical standpoint, this combination provides a balanced approach. Approvals gain an additional level of assurance while remaining easy to use. Administrators can decide which group sign-off or multi-approval custom fields require re-authentication before a decision, a justification afterward, or both, simply by enabling the corresponding options. For routine approvals, neither may be necessary. For high-impact or compliance-driven decisions, using both can significantly increase confidence in the outcome and the audit trail.

As Jira is increasingly used to support business-critical processes, I believe it’s worth rethinking how approvals are protected and documented — not just who is allowed to approve, but how securely and transparently those decisions can be attributed and explained.

I’d be very interested to hear how other Jira admins approach approval security and documentation today. Do you rely solely on login sessions, or do you already require additional confirmation or reasoning for critical decisions?

— Frank Polscheit
Developer of Group Sign-Off / Multi-Approval for Jira Cloud

[Aaron Morris]

Regarding re-authentication:

I think it's important to distinguish between electronic approvals and electronic signatures, where electronic approvals might be more "lightweight" than electronic signatures. Having this distinction enables you to implement interim approval steps in your workflows without the burden of authentication mechanisms. Then you can save the electronic signatures (with an authentication mechanism) for the very end of the workflow.

For example, you might have a regular electronic approval to pre-approve a defect fix, and then apply a full electronic signature when closing the completed defect record. Part of the final signature is attesting to the validity of the interim approval steps. If the defect record says that I pre-approved it...but I didn't...I certainly wouldn't sign the defect upon closure.

This creates a nice balance that is 100% audit-ready to regulators. (I'm speaking from the perspective of the life sciences industry.)

All apps in the Atlassian Marketplace that are compatible with 21 CFR Part 11 require a re-authentication mechanism when creating an electronic signature. If they don't, then they are not compliant with the regulation.

Regarding justification:

This is interesting and new to me. When would an approval justification be required for audit-readiness? In my experience, the company policies and procedures describe the context and definition of the required approvals. And I believe that's what auditors expect.

In fact, some companies even prohibit approval comments, with the concern that someone might provide an electronic approval that violates the policy-defined approval meaning. (Using the approval comments field as a "policy escape".)  Have you seen anyone use the approval justification that way?