Emergency Succession for Solo Founders: Limited Authority, Break-Glass Access, and Recovery Handoff

Solo-founder companies often reduce continuity to "my partner knows the master password for the password manager." This creates two opposing risks: the founder may simply be on a ten-hour flight, yet the successor can permanently transfer funds and delete databases; when the founder is genuinely hospitalized, the backup email address, hardware key, or cloud account may still require the founder's approval. Documentation can tell people what to do, but it cannot answer who receives which authority under what conditions, or how to prove that all temporary privileges have disappeared after the founder recovers.

Agent Delegation Contracts govern machine subtasks, while Human Handoffs for Coding Agents preserve the context of a single coding task. This article governs only the operational continuity of a human succeeding the founder: payments, domains, cloud resources, customer notifications, and security response remain executed by their respective systems, while the succession control plane issues only limited authorization and preserves evidence of acceptance.

Publish an Immutable continuityCharter.v1

The founder and governance witnesses jointly sign founder.continuityCharter.v1. It specifies business service tiers, maximum tolerable downtime, the successor and alternate, activation evidence, confirmation quorum, cooling-off period, the scope and limits of each capability, prohibited actions, lease duration, renewal method, notification recipients, recovery owner, and charter expiration date. Bank transfers, equity, production deployments, data exports, and public statements cannot be grouped under a vague admin privilege.

schema: founder.continuityCharter.v1
charterId: company-continuity@5
successor: person:ops-primary
quorum: 2-of-3
activationDelayHours: 12
leaseHours: 24
capabilities:
  - service: cloud-production
    verbs: [restart, scale-within-limit, read-incident]
    deny: [delete-account, rotate-root, export-customer-data]
  - service: billing
    verbs: [view-failures, retry-approved-invoice]
    amountLimit: USD1000

NIST SP 800-34 Rev.1 places business impact analysis, recovery strategies, plan testing, and maintenance within the same continuity lifecycle. Small teams should likewise determine which functions must recover within four hours and which can remain unavailable for 72 hours, rather than copying all of the founder's privileges by default. The charter references each service's runbook digest, contacts, dependencies, and latest drill receipt. Any change to this material creates a new generation; old signatures cannot authorize new capabilities.

Credentials are not written into the charter. NIST SP 800-63B establishes explicit requirements for authenticator lifecycles, recovery, and binding. Actual capabilities should be issued by systems that support distinct principals, short-lived credentials, and revocation. Legacy services that cannot provide granular permissions use an escrowed break-glass package: encrypted material is split among separate custodians, reconstruction requires quorum, and an out-of-band alert fires immediately. The OWASP Secrets Management Cheat Sheet emphasizes least privilege, rotation, expiration, and complete auditing. Secrets Management can implement the routine lifecycle; a continuity process must not use an "emergency" to make shared root credentials normal practice.

Activation Has Exactly One Acceptance Point

The state moves from NORMAL to UNREACHABLE_SUSPECTED, then to ACTIVATION_PENDING after multichannel contact attempts and the evidence waiting period are complete. Insufficient evidence produces DISPUTED; unreachable witnesses produce QUORUM_BLOCKED. The successor cannot interpret either state as approval. The only acceptance point occurs when the quorum issues successorActivation.v1 for the same charter digest and activation nonce. The control plane uses CAS to advance the state to ACTIVE_LIMITED and issue the initial capability leases. Chat messages, calendar timeouts, possession of a recovery code, and successful login do not constitute acceptance.

Each lease is bound to the activation, principal, device/authenticator, service, verbs, monetary or resource limits, expiration time, and revocation generation. High-risk actions require separate independent approval. The successor is prohibited from expanding their own privileges, modifying the charter, replacing witnesses, or extending the overall duration. Every operation with side effects must also persist successorEffect.v1 first, using a stable effect ID to bind the activation, business object, operation semantics, payload digest, provider idempotency scope, and PREPARED state.

Before making the external call, the executor uses CAS to confirm simultaneously that the activation remains ACTIVE_LIMITED, the lease has not expired and matches the scope, the revocation generation has not changed, and the effect remains PREPARED, then advances it to DISPATCHING. At the same authoritative gate, recovery revocation increments the revocation generation and closes the dispatch watermark, so only revocation or dispatch can succeed. A call timeout or lost response enters UNKNOWN_EFFECT; blindly retrying with a different effect ID is prohibited. First use the provider operation ID, idempotency key, or a consistent query to obtain a receipt, then reconcile the result. If a provider does not support idempotency or conditional preconditions, acceptance into DISPATCHING crosses the point of no return. The recovery process can only wait for a definitive result or isolate the operation manually; it cannot claim that the operation has been revoked. All control-plane events are written to an independent audit destination. Cloud Control-Plane Audit Integrity provides gap and tampering detection; the process cannot rely solely on the same cloud account that the successor is authorized to delete.

When the founder recovers, the process first enters RECOVERY_PENDING. After strong authentication and witness confirmation, it increments the revocation generation, stops new leases, and waits for in-flight actions to reach known outcomes. The state then becomes HANDOFF_RECONCILING: bills, deployments, customer commitments, tickets, and credentials are reconciled individually. The successor and founder must sign the same effect ledger before the process can enter CLOSED. Disputes and unknown external effects remain in RECOVERY_EXCEPTION; records cannot be deleted merely to close the incident. The append-only evidence and preservation techniques in Generative AI Incident Evidence Preservation apply equally to security incidents during human succession.

Drills Must Exercise Real Failure Conditions

In addition to quarterly tabletop exercises, conduct a limited recovery in an isolated account at least once a year. Inject simultaneous unavailability of the founder's phone and email, one witness refusing to sign, replay of an old charter, clock skew, loss of a hardware key, partial failure of the lease service, revocation of the successor's device, an unknown response from the cloud control plane, a scale-up request one millisecond before the recovery CAS, and a malicious successor attempting to increase their own privileges. The system must isolate unknown actions in a verification queue and prove that the race between revocation and dispatch has exactly one winner.

The acceptance gate requires every Tier-0 service to have an owner, RTO, current runbook, and drill receipt from the past 12 months. The difference between the charter and actual capabilities must be 0, successful undeclared verbs must be 0, quorum bypasses must be 0, and accepted replays from old generations must be 0. Activation p95 must not exceed 25% of the predefined RTO, successful new calls after lease expiration or revocation must be 0, audit-event attribution must be 100%, and unresolved Tier-0 effects after recovery reconciliation must be 0. Any unauthorized action immediately fails the drill; speed cannot compensate for authorization defects.

For rollout, first let the system generate only capability inventories and discrepancy reports without accessing real credentials. In the next phase, connect only read-only status pages and repeatable service restarts, then expand incrementally to operations with explicit limits. Each cohort retains the original manual contact tree and existing recovery paths, while an activation-generation switch can pause new leases. On false activation, an audit gap, or delayed privilege revocation, immediately roll back to NORMAL/MANUAL_ONLY, increment the revocation generation, and rotate exposed material. Retire the old succession process only after two consecutive drills pass both the activation and recovery gates.