Crypto Policies and Quorum Approvals
Two policy modules you bind to vaults and keys: crypto policies constrain how a key may be used, quorum policies require several administrators to approve sensitive key and vault operations.
Access policies decide who may use a key at runtime (see Access Policies). The two modules on this page govern the keys themselves:
| Module | Answers | Enforced |
|---|---|---|
| Crypto policy | Which algorithms, key sizes, operations and PQC posture are allowed, and how old a key may get | Synchronously, at key creation and on encrypt, decrypt, sign and verify calls through the Cockpit key API |
| Quorum policy (M-of-N) | How many administrators must approve a sensitive operation before it runs | On key deletion, vault deletion and vault rotation |
Both are created under Administration and bound to a vault or a key from its Policy Bindings card. A key-level binding overrides the vault's; keys without their own binding inherit the vault's policy.
Crypto policies
A crypto policy is a set of constraints evaluated when a key is created and on every encrypt, decrypt, sign and verify call made through the Cockpit key API. An operation that violates the policy is refused, and the decision is written to the audit log.
| Setting | Effect |
|---|---|
| Allowed algorithms | Only the listed key algorithms may be used |
| Minimum RSA size | RSA keys below this size are refused |
| Allowed EC curves | Only the listed elliptic curves may be used |
| Allowed operations | Restrict the key to some of encrypt, decrypt, sign and verify |
| PQC posture | Classical (no requirement), Hybrid (reject pure-classical keys) or PQC only (require post-quantum keys) |
| Maximum key age + require rotation | Refuse use of keys older than the set number of days, forcing rotation |
Decrypt requests that Microsoft 365 sends to a DKE service are governed by the service's access policy, not by crypto policies. A crypto policy on the vault still applies when keys are created: Microsoft 365 DKE requires RSA-2048, so a policy that sets a minimum RSA size above 2048 or a Hybrid or PQC-only posture will block the creation of DKE keys in that vault.
Quorum policies (M-of-N four-eyes control)
A quorum policy requires M approvals from a set of N approvers before a gated operation runs. It is DuoKey's dual-control (four-eyes) mechanism.
| Setting | Description |
|---|---|
| Threshold M | Number of distinct approvals required |
| Approvers (the N set) | Individual users, roles or organisational units |
| Gated operations | delete and rotate. Leaving the list empty gates both. Other operation names are rejected, because only these are enforced today. |
| Approval TTL | How long a request stays open, default 86,400 seconds (24 hours) |
| Requester may count toward quorum | Off by default: the person who asks cannot approve their own request |
| Policy enabled | Disable a policy without deleting it |
What is gated
| Resource | Operation |
|---|---|
| Key | Delete |
| Vault | Delete |
| Vault | Rotate |
Releasing an escrowed S/MIME private key also requires the approvals of a quorum policy; without one, recovery is refused. See the S/MIME documentation.
How an approval works
Request
An administrator starts a gated operation, for example deleting a key. Instead of running it, the Cockpit opens an approval request and the API answers 202 Accepted with quorum_required: true and a request_id.
Vote
Approvers open Administration → Quorum Approval Requests. Only members of the request's approver set can vote, each only once, and they can approve or reject with a comment.
Execute
Once M approvals are recorded, the administrator runs the operation again. It executes and the approval is consumed, so it cannot be replayed.
Expire
A request that does not reach M approvals before its TTL expires and must be opened again.
Request statuses: pending, approved, rejected, expired, consumed.
Two-person key deletion: threshold 2, approvers = role KeyCustodian, gated operation delete, TTL 24 hours, requester may not approve. Bind it to the vault holding your DKE keys: no single administrator can delete a DKE key, and therefore no single administrator can make DKE-protected documents unreadable.
API
| Endpoint | Purpose |
|---|---|
GET / POST /api/crypto-policies | List or create crypto policies |
GET / PUT / PATCH / DELETE /api/crypto-policies/{id} | Read, update, enable/disable or delete a crypto policy |
GET /api/crypto-policies/{id}/audit | Change history of a crypto policy |
GET / POST /api/quorum-policies | List or create quorum policies |
GET / PUT / PATCH / DELETE /api/quorum-policies/{id} | Read, update, enable/disable or delete a quorum policy |
GET /api/quorum/requests | List approval requests |
GET /api/quorum/requests/{id} | Request detail with its votes |
POST /api/quorum/requests/{id}/approve | Approve a request |
POST /api/quorum/requests/{id}/reject | Reject a request |
Managing these policies needs the CryptoPolicies.* and QuorumPolicies.* permissions, and the Crypto Policies and Quorum Policies features enabled for the tenant.