GUIDE

The two-person
rule.

Two authorised people, acting together, or the operation does not proceed. Borrowed from contexts where the cost of a single mistake was total.

Origins

The two-person rule is best known from nuclear weapons handling, where no individual may be alone with a weapon or able to complete an arming sequence unaided. Related forms appear in cryptographic key ceremonies, secure facility access, and the handling of controlled substances.

What distinguishes it from ordinary approval workflows is strictness. It is not that a second person signs off afterwards, or that an action is reviewed and can be undone. It is that the action is structurally impossible for one person to complete. Where the control is implemented well, there is no override, no emergency bypass, and no administrator who can proceed alone.

Translating it to infrastructure

The literal form does not transfer — you cannot require two engineers to turn keys simultaneously — but the property that matters does. The question to ask of any critical operation is whether a single credential, session, or person is sufficient to complete it.

For most teams the honest answer is yes, in more places than expected. Root credentials, cloud organisation-level permissions, the CI system's deploy token, the DNS registrar login, and the on-call engineer's standing production access are each usually enough on their own to cause severe, hard-to-reverse damage.

Root and organisation-owner accounts in your cloud provider.
DNS and registrar control — frequently the single most damaging account and the least protected.
Signing keys for releases, mobile apps, or firmware.
Backup deletion and retention settings, which an attacker will target before doing anything visible.
The identity provider itself — whoever administers SSO can usually become anyone.

Where it is worth the cost, and where it is not

Strict two-person control is genuinely expensive. It requires two people to be reachable, it slows incident response, and if implemented without a realistic fallback it will eventually block legitimate emergency work — at which point people build an undocumented bypass and you are worse off than before.

The practical approach for most engineering organisations is to reserve strict two-person control for a very small number of operations whose blast radius is existential, and use ordinary threshold approval for the wider set of high-risk-but-recoverable actions. Deleting all backups warrants the strict form. Locking the production database for twenty minutes does not.

TeamSigner supports both, because both are the same mechanism with a different threshold. What it does provide in either case is that approvals are signatures held on separate physical devices, so compromising one laptop or one session is not sufficient regardless of the number you require.

Common questions

How is this different from requiring an approval in a ticketing system?

A ticket approval records that someone clicked approve, and anyone with sufficient access to that system can produce the same record. A two-person rule implemented with device-held keys requires two separate physical devices to participate, which cannot be faked from a single compromised account.

What happens if one of the two people leaves the company?

Membership and thresholds are configuration. Remove the member and the remaining team continues to meet the threshold, provided you sized it with turnover in mind. Sizing a threshold at exactly your headcount is a common mistake.