Skip to content

The CAB

The Change Advisory Board (CAB) is the group of people who authorize high-impact changes in your tenant. The setup wizard puts the principle plainly: “Churchill won’t act on a single root.” Registering an application, or re-baselining a binary that changed, never goes through on one person’s say-so. That includes the organization owner. These changes take effect only when the board signs off.

Until a CAB exists and its genesis baseline is sealed, the governance side of the dashboard stays gated: you cannot register a protected application. Standing the board up is the owner’s first job on a new tenant. See the setup ceremony.

  • Chair: the organization owner chairs the CAB and runs the setup ceremony. At setup, the chair chooses whether to also hold a voting seat. Either way, the chair facilitates the board. The chair is also the recovery contact: when an operator’s sign-in locks after three failed attempts, the console tells them to contact the CAB chair.
  • Members: two or more people, each holding their own signing passkey. There is no upper limit on board size. Members cast the approvals. The quorum and veto rules below are about them.

A member’s signing credential is a WebAuthn passkey. The member creates it on their own device from their invitation email. The chair provides identity only: a name, a work email, and a role. The chair never creates or handles anyone’s key. There is no public key to paste, and no key material ever travels to the chair or to Churchill. Churchill records only the public key and its fingerprint.

An approval is a receipt: a passkey assertion over a challenge the control plane builds for that specific change. The member’s device asks them to confirm with their passkey. A receipt binds one member to one change, so it cannot be replayed onto another change.

One consequence is worth naming: a passkey lives on the member’s device or platform authenticator. If a member loses their passkey, they cannot sign, and the CAB must re-admit them with a fresh invitation.

The passkey a member creates from their invitation doubles as their dashboard sign-in credential. The invite page states this while the key is created: “This passkey is also your dashboard sign-in.” A member can therefore open the console, review a pending change in full, and approve it from the same account. See joining the CAB.

The two capabilities stay separate underneath. Console access and board membership are different grants: disabling a member’s console access leaves their board seat and signing key untouched, and removing their board seat leaves their console access untouched.

  • The genesis baseline: once, at setup. Sealing it locks the member registry as the root that every future change is voted against.
  • Application registrations: registering a new protected application ends by submitting it as a change request for the board.
  • Change-control requests: when a protected binary diverges from its approved baseline, the board decides the re-baseline or its rejection. See Change control.

Routine operator actions, such as reading the fleet, reviewing evidence, or replaying a recording, do not go to the board. They land on the audit chain instead.

Situation Rule
Genesis baseline Unanimous. Every member must approve. There is no threshold to lower.
Ongoing changes Quorum: M of N signed receipts. The current requirement shows in the CAB page header, for example quorum 2 of 3.
Any rejection Veto. A single rejection terminates the change. There is no override.
No decision in 7 days The change request expires.

For the signing mechanics, how a member casts a receipt, and what quorum looks like on a live change request, see Approvals.

  • CAB page (in the Governance sidebar group): the working surface. It lists change requests with stage tiles and filters, opens each request’s detail with its receipts and signing panel, shows the quorum requirement in the header, and carries the CAB members card with the roster and its roundtable ring: the chair at the top, members and outstanding invitations around it, seats and quorum in the middle.
  • Settings, policy tab: the CAB governance card shows whether the board is configured, the quorum required, the active member count, and the roster. Owners also see the sealed setup receipt here, with copy and JSON export.
  • Profile: if your operator account is linked to a CAB key, your signing key (fingerprint, algorithm, enrollment date) and a count of changes awaiting your approval.

The roster is not frozen after setup. The owner manages it from the CAB members card on the CAB page:

  • Invite member… sends an invitation email immediately. The owner enters a name, work email, and optional role. The invited member confirms their identity and creates their own passkey from the emailed link, exactly as at genesis. As the card puts it: “New members are admitted by passkey only.”
  • Rename changes a member’s display label across the dashboard. The signing key, its fingerprint, and receipts already on the audit chain are unchanged.
  • Remove deactivates a member’s signing key. It is typed-confirm gated: the owner types the member’s email to confirm. Receipts the member already cast remain on the audit chain. The chair’s own seat cannot be removed.
  • A pending invitations list tracks outstanding invites with state pills (invited, expired, revoked, not sent) and per-row Resend and Withdraw buttons.

Removing a member below the change quorum is allowed but warned: the card states “This drops the board below its change quorum”, and approvals will stall until another member is admitted.

One rule is permanent: removed keys stay dead. Churchill refuses to register a key that has ever been removed. A member who leaves and later returns starts over with a fresh invitation and a new passkey.