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:
FieldDescription
Step nameOptional label like Security Team Review or Manager Sign-off. Visible to approvers in their queue.
ApproversEligible users or groups for this step. They must already be members of the Signer (any role). Group approvers let anyone in the group approve. Auditors can be members but cannot be approvers.
Required approvalsThe number of distinct approvers that must approve before the step is complete.
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:
FieldDescription
Signatures per approvalHow many signing operations one approval is good for. Leave empty for unlimited. Set to 1 for “approve once per artifact”.
Signing windowHow long the access record is valid after approval. Options: No limit, 1h, 8h, 24h, 7d, 30d.
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

StatusMeaning
PendingApproval workflow is in progress. Waiting on the current step’s approvers.
ActiveAll steps approved, access issued, still within window and signatures remaining.
ExpiredWindow has passed, or the signature count was exhausted.
RevokedAn Administrator revoked the access (or the requester cancelled the request).
RejectedAn approver rejected one of the steps.

​
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

FieldDescription
JustificationShort note recorded on the access record for audit. Required.
Signatures allowedHow many sign operations the access permits. Capped at the policy’s Signatures per approval. Leave empty to fall back to the policy ceiling.
When access beginsDefaults to “now”.
When access expiresCapped at the policy’s Signing window. Leave empty to fall back to the policy ceiling.
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.

​
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.