Account lifecycle and deletion

This guide covers the lifecycle of an account — the console owner that registered SenseCrypt and manages billing, tenants, and administrators. It explains the self-service delete flow, the grace window, and what happens when deletion becomes permanent.

An account is not a tenant. The account is the billing entity and console owner; a tenant is the isolation boundary (its own issuer, keys, and directory). An account can own many tenants. Deleting the account tears down every tenant it owns. Deleting a single tenant is a different operation and does not close your account. This page is about account deletion — see Multi-tenancy for the account-vs-tenant distinction.

Who can delete an account

Only the account owner can start or undo a deletion. A delegated administrator who holds billing:manage can reach the rest of the billing surface, but the delete and reactivate endpoints additionally require the owner — a non-owner gets 403.

To confirm intent, the delete request requires you to type the account's own email address back. A mismatch is rejected before anything changes.

POST /v1/admin/billing/account/delete
Content-Type: application/json

{ "confirm_email": "owner@example.com" }

You can only self-delete from a healthy billing state — an active or trialing account. An account that is past due must resolve the outstanding payment first; deletion is refused from that state (otherwise reactivating would silently reset the non-payment timeline without paying).

The 30-day grace window

A delete does not erase anything immediately. It is a soft delete: the account moves to a pending_deletion status and a 30-day grace window starts. The account stays recoverable by the owner until that window expires, at which point a background sweeper performs the permanent purge (described below).

What the delete request does right away, before the grace window even starts counting:

• End-user access is cut immediately. Every end-user device key and every refresh-token family across all the account's tenants is revoked at the moment you request deletion — not 30 days later. A held device key or refresh token cannot be used to drive a face ceremony, rotate a key, or hit /me during the grace window. Deletion is a hard "cut access now" signal.
• End-user sign-in is blocked at the issuer. While the account is pending_deletion, every end-user protocol request (/v1/idp/*) to any of its tenants is refused with 403 (service_suspended). Discovery, authorize, token — all closed for the duration.
• Billing stops. No further charges accrue.

The owner's admin console session is deliberately left intact — you need it to reactivate.

The 423 account_deleting block on the console

During the grace window the admin console is mostly frozen. Any authenticated call to /v1/admin/* returns:

423 Locked
{ "code": "account_deleting", "message": "Account is scheduled for deletion" }

This is intentional: while an account is on its way out, you should not be able to create apps, add users, rotate keys, or otherwise change configuration. Only a small allowlist stays reachable so the owner can see the deletion banner, change their mind, and manage payment:

If you are building tooling against the admin API, treat 423 account_deleting as "the account is winding down; only billing and reactivation are available."

Reactivating within the grace window

The owner can undo the deletion any time before the grace expires:

POST /v1/admin/billing/account/reactivate

Reactivation lifts the pending_deletion status and returns the account to the state it would have been in:

• trialing if the original trial is still running (a saved card does not end the trial),
• active if a card is on file,
• past_due otherwise (no live trial, no card) — you land back on the pay-to-continue path.

Once the status is no longer pending_deletion, the 423 block lifts and the full console is reachable again, and the issuer stops refusing end-user auth.

Reactivation restores billing and console state — it does NOT restore end-user credentials. The device keys and refresh-token families that were revoked at delete time stay revoked. Because deletion is a hard cut, your end users must re-enroll and sign in again after a reactivation. Configuration (apps, tenants, groups, users) is untouched and comes back as it was; only the live credential material is gone.

Permanent deletion (purge)

If the grace window expires without a reactivation, a background sweeper permanently purges the account. This is irreversible. The same purge path also runs when a suspended, past-due account exhausts its own (separate, longer) non-payment countdown.

The purge does three things that matter for your data:

1. Crypto-shred of signing-key material. For every tenant on the account, KMS-custody signing keys are scheduled for deletion in AWS KMS, and the software-custody key envelopes are destroyed along with the rows that wrap them. Once the wrapping key material is gone, the sealed private keys are unrecoverable — the data is cryptographically shredded, not merely unlinked.
2. Stripe customer deletion. The account's Stripe customer record is deleted, ending the billing relationship.
3. Full data erasure by cascade. The account row is deleted, and every child record cascades with it — all tenants, applications, users, groups, resource servers, sessions, and keys across the whole account. Nothing tenant-scoped survives the account purge.

A final "your account has been deleted" email is sent to the owner's address (captured before the row is removed).

KMS keys are scheduled for deletion with a pending window (7–30 days, deployment-configured) rather than destroyed instantly — this is the AWS-mandated safety window during which a scheduled key deletion could, in principle, be cancelled by an operator with KMS access. The database records themselves are gone at purge time.

How this differs from tenant deletion

Deleting a tenant removes one issuer and its directory but leaves the account (and any sibling tenants) fully intact and billable. Deleting the account is the operation described here: it revokes access everywhere, blocks the console behind 423, runs a 30-day grace, and — if not undone — crypto-shreds keys and cascades away every tenant the account owned. Operators offboarding a single tenant (for right-to-erasure of just that tenant's users, say) should use the tenant-level path, not account deletion.

Related

• Multi-tenancy — accounts vs. tenants, and why the tenant is the isolation boundary.
• Refresh tokens and sessions — eager revocation on lifecycle events.
• Security — signing-key custody (software envelope vs. KMS) and crypto-shred.
• Error codes — account_deleting, service_suspended, payment_required.