Skip to main content
A Signer with an approval policy makes signing a two-party operation: someone asks, someone else says yes, and the request becomes an active access window with limits on how much and how long. This page covers everything that happens inside a Signer’s Approvals tab. Concretely, approvals govern three things:
  1. The policy: who has to approve, in what order, and how strict the per-access limits are.
  2. The path to access: either an Administrator pre-approves an access window for a specific member, or an Operator requests one and approvers sign off.
  3. The active access record: once approved, it’s the row in the Approvals table with its own expiry, signature count, and revoke button.
Signers without an approval policy don’t use this flow. Members with sign rights sign directly and you’ll still see a full audit trail under the Signer’s Activity tab.

​
When you want an approval policy

Production releases

Two security leads must sign off before a release artifact is signed.

Separation of duties

Developers request to sign; managers approve. Audit shows both actors.

Compliance

SOC 2, PCI-DSS, or internal SDLC frameworks that require documented approval.

Bounded CI access

Pre-approve a CI identity for “10 signings within the next hour” instead of standing access.

​
How an approval flow works

Each step runs in order. Once the last step’s required approvals are reached, Infisical issues an active access record bounded by the policy’s per-approval limits. The Operator can then sign through the PKCS#11 module or the Sign API. Administrators can also pre-approve signing directly when the approval flow isn’t a fit, for example during an incident response where waiting on approvers would block recovery.

​
Configure the approval policy

Open the Signer’s Approvals tab and click the pencil icon on the Approval Policy panel. The editor is a 2-step sheet.
1

Approvers

Define one or more approval steps. To turn the policy off entirely, delete every step. The Signer reverts to direct signing.For each step:Add more steps to run multiple sign-offs in sequence. For example: Step 1 Team Lead Review (1 approval), then Step 2 Security (2 approvals).Required-approval validation:
  • A step must have at least one approver.
  • Required approvals must be ≥ 1.
2

Approval limits

Per-approval caps that apply to every access record this policy issues:You can combine both. For example: maxSignings=10 with signing window=1h issues access good for at most 10 sign calls within one hour of approval, whichever comes first.
Press Save policy. The new policy applies to new requests; existing active access keeps its original terms until it expires or is revoked.

​
Access lifecycle

Every approved request becomes an active access record. On the Approvals tab it’s a row in the Requests table with its own status, expiry, and signature counter.

​
Statuses you’ll see

​
Approval paths

There are two ways someone gets active access on a Signer: Administrators pre-approve signing directly for someone else, or members open a request to sign that runs through the approval policy.
An Administrator gives a specific member access up-front. No approval workflow runs. The access is created Active immediately and the recipient can sign right away.
1

Click Pre-approve signing

From the Signer’s Approvals tab, click Pre-approve signing.
2

Pick the recipient

Select the user or machine identity that should receive access. The list includes every Signer member except Auditors (including users reachable via a group).
3

Set the access terms

Per-access values cannot exceed the policy ceilings. Requesting maxSignings=10 against a policy that allows 3 returns a 400 with a clear message. Omitting a field that the policy caps simply clamps to the ceiling, never silently unlimited.
4

Issue the access

Press Pre-approve. The recipient can sign immediately.
Typical use: pre-approving a CI machine identity for “10 signings within the next hour” right before a release pipeline runs.

​
Approving or rejecting

If you’re an eligible approver for the current step of a pending request, an Approve or Reject action is visible on the request row.
1

Open the request

Click the row on the Signer’s Approvals tab. Full details: requester, recipient, justification, requested signings, requested window, and which step is currently pending.
2

Review

Verify who’s asking, for how many signings, for how long, and why.
3

Decide

  • Approve counts toward the current step’s required approvals. When the last step’s count is reached, the access record is created.
  • Reject terminates the workflow. No access is created. The requester can submit a new request.
You can never approve your own signing request, even if you are listed as an approver for the current step. This is always enforced and cannot be disabled. (Pre-approving signing for yourself is allowed. It is an administrator action, not an approval of your own request.)

​
Revoking access

Administrators can revoke an active access record (or cancel a pending request) at any time. Hover the row on the Approvals tab; an X icon appears. Confirm in the dialog and:
  • Pending request cancels the workflow. No approver can act on it after that.
  • Active access is immediately revoked. Subsequent sign calls return 403 with a clear message.
In-flight sign calls already in progress complete normally; revocation is checked at request entry, not mid-operation. The row stays visible in Revoked status so the audit trail is preserved.

​
FAQ

The policy has more than one step and yours wasn’t the final step. Open the request to see which step is currently pending; the access record is issued only after the last step’s required approvals are reached.
Three possibilities:
  1. The Signer has no approval policy, so signing is direct and no request is needed.
  2. You already have active access. Sign directly under it.
  3. You don’t have sign permission. Check that your role on this Signer is Operator or Administrator (not Auditor).
Have an Administrator pre-approve access for that identity in advance with appropriate per-approval limits. The CI identity then signs under the access record directly without going through the review workflow.
No. Access records are immutable once issued. If you need more time or more signatures, submit a new request (or have an Admin pre-approve a new one) and revoke the old one if you want to be tidy.
Expired is automatic: the window ended or the signature count was reached. Revoked is explicit: an Administrator (or the requester via cancel) ended the access before its natural expiry. Either way, signing under it is no longer possible. The status difference shows up in the audit log.
Pending requests run under the policy that was active when they were submitted. Edits affect only new requests. To force a refresh, revoke the pending request and have the requester submit again.

​
What’s next

Signers

Manage the Signer itself: members, certificate, lifecycle.

PKCS#11 Module

Have the module auto-open signing requests on denied calls.