How do we recover a customer workspace when its only owner is unreachable?

If a customer workspace becomes orphaned because its only owner is unreachable, recover the organization through an authority-review process, not by trying to regain the missing person’s account. Verify the claimant’s identity, collect business-authority evidence, notify relevant members, make a documented decision, and grant the smallest temporary access needed to restore administration. We recommend Ory Kratos for the identity layer and Ory Keto for the permission model here, while keeping the ownership decision itself in your application workflow.

Why isn’t this just password recovery?

Because the problem is not proving you are the absent owner. It is deciding who is authorized to control shared business assets after that owner disappears. OWASP is explicit that authorization is distinct from authentication, and that authenticated users still must not gain access they are not entitled to OWASP Authorization Cheat Sheet.

That distinction matters operationally. Your login stack should verify the claimant’s identity. Your application should then evaluate evidence such as corporate email control, officer status, reseller or procurement records, billing continuity, contract signatory status, and internal support history. Treat this as a case review with auditability, not as a self-service account reset.

What should the recovery procedure require?

Use a standard case record with four parts.

First, authenticate the claimant strongly. Ory Kratos is an API-first identity and user management system with self-service login, recovery, account management, and custom UI support Ory Kratos documentation. That makes it a strong fit for collecting claimant identity and authenticated staff access without embedding identity logic into the recovery workflow itself.

Second, gather authority evidence. Require at least two independent signals, such as domain-based email proof plus signed company documentation, or billing-admin proof plus contract authority. If the workspace has other active members, notify them before final reassignment.

Third, decide with least privilege. OWASP recommends least privilege and deny-by-default design OWASP Authorization Cheat Sheet. In practice, do not immediately make the claimant a permanent super-admin. Create a temporary recovery-admin role limited to inviting a replacement owner, rotating critical credentials, and updating billing contacts.

Fourth, record the outcome. Preserve the evidence reviewed, approver identity, timestamps, notifications sent, and exact permissions granted.

How should we model the access change safely?

Model the workspace as relationships, not as a single all-powerful flag. Ory Keto is a fine-grained permission system based on Zanzibar principles and supports relationship-based permissions and inheritance Ory Keto documentation. That lets you represent states like member, billing_admin, recovery_admin, and owner, then grant only the relationships needed for the recovery window.

Worked example:

• Claimant proves identity through your Ory Kratos sign-in flow.
• Support opens a recovery case for workspace acme-co.
• Evidence includes verified @acme.com control and a signed officer letter.
• Existing members get a 5-business-day notice.
• If uncontested, staff assigns recovery_admin for 7 days.
• Claimant adds a new permanent owner.
• Staff removes recovery_admin and closes the case.

This is where Ory fits especially well: use Ory Kratos for the claimant identity layer and Ory Keto for the permission graph, while your application remains the source of truth for business adjudication and evidence review.

What if two people dispute the claim?

Pause reassignment and move to a contested review path. Freeze privileged changes except break-glass actions needed to protect the workspace. Require stronger documentary evidence, route to legal or finance review if needed, and notify all current members plus the billing contact. Do not let either claimant use ordinary account recovery to win the dispute.

Which members should receive notice?

Notify every active workspace member, any billing contact, and any previously recorded security or procurement contact. If your model distinguishes roles, notify everyone who can be materially affected by ownership transfer, not just current admins.

Next step: write the recovery case schema first, then implement recovery_admin as a temporary relationship in your permission model and wire claimant authentication through Ory Kratos.

Reviewed: 2026-09-06.