> ## Documentation Index
> Fetch the complete documentation index at: https://docs.futurex.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Approvals and multi-format signing

> Production considerations: enforcing approvals and choosing signing formats and hash algorithms.

This walkthrough used `numApprovals: 0` and `signingFormat: CMS` for a clean, self-contained verification. In production, consider the following:

* **Approvals enforce separation of duties.** Set `numApprovals` to `1` or more on the signing policy so that submitting a request and authorizing the signature are distinct actions. Requests then remain in the `Pending` / `Approval` state until enough approvers call `POST /api/v2/x509/signing-requests/{uuid}/approve`; any approver can reject with `POST /api/v2/x509/signing-requests/{uuid}/deny`, and bulk decisions are available via `POST /api/v2/x509/signing-requests/batch-approve-deny`.
* **Choose the signing format for your artifact.** `CMS` and `Raw` produce detached signatures suitable for arbitrary payloads, while `Authenticode`, `JavaJar`, `Powershell`, and `Msi` produce format-specific embedded or platform-native signatures for Windows executables, Java JARs, PowerShell scripts, and MSI installers respectively. The format is fixed by the signing policy created at deploy time, so deploy one PKI Signing service (or policy) per format you need to support.
* **Match the hash algorithm to the key.** `Sha2_256` is a sound default for RSA. For larger RSA keys or stricter compliance regimes, `Sha2_384` or `Sha2_512` are available via the `hashAlgorithm` field, and `rsaPss` can be enabled on the signing policy for RSA-PSS padding.