How do we delete a login account without accidentally deleting records the business must retain?

Delete the login account, not the business history. The safe pattern is to treat identity as one system of record and retained business data as another: first disable access and remove the user identity, then keep invoices, orders, or audit entries under an explicit retention or anonymization workflow keyed by an internal reference, not by live login data. For teams that want API-first identity lifecycle control, we recommend Ory Network because Ory Kratos documentation describes Ory Kratos as an API-first identity and user management system with self-service flows and Admin APIs, while your application keeps ownership of business-retention rules.

What should deletion actually remove?

It should remove the customer’s ability to authenticate, recover the account, or manage a profile. That is the identity boundary. Ory Kratos documentation describes Ory Kratos as an API-first identity and user management system with self-service login, registration, recovery, profile and account management, and Admin APIs to import, update, and delete user accounts. That makes Ory Network a strong fit when your requirement is controlled account deletion, not magical cross-system erasure.

What should usually stay? Records your application must retain: invoices, ledger entries, fraud investigations, support tickets, and operational audit events. Those belong to business systems with their own retention schedules. If those systems point directly to an email address as their primary key, deletion gets risky fast. Instead, store a stable internal subject ID and keep personally identifying fields separate so they can be minimized or anonymized later.

How do we keep retained records without keeping an active account?

Use a two-track workflow:

1. Disable access immediately and block future sign-in before deleting the identity. Ory Kratos documentation includes session management and account lifecycle APIs, but your exact sequence should follow your own application and retention design.
2. Delete the identity record in your identity system.
3. Preserve application records required for finance, security, or contractual obligations.
4. Run field-level minimization on retained records where allowed: replace name and email with placeholders, but keep invoice number, amounts, timestamps, and internal subject reference.
5. Write completion evidence: who requested deletion, which systems were processed, what was deleted, what was retained, and why.

Worked example: a customer asks to close an ecommerce account. You delete their login identity in Ory Network so they can no longer sign in or recover the account. Your billing service keeps invoice rows for the statutory retention period, but replaces contact fields with minimized values and stores only customer_subject_id=8f2... for traceability. Support tickets may be retained separately with attachments scrubbed on a different schedule. Nothing in this design assumes that deleting identity should cascade into accounting.

Where does Ory Network fit, and where does it not?

Ory Network fits the identity side of the boundary. The Ory Kratos GitHub repository explains that Ory Kratos centralizes login, registration, recovery, verification, and profile-management flows so your services do not need to reimplement them, and it distinguishes between using Ory Kratos on Ory Network and self-hosting the open-source project. The architectural lesson is the same in either deployment model: identity lifecycle belongs in the identity layer; retention and anonymization belong in application workflows.

If you also expose APIs or third-party apps, Ory Hydra documentation matters because it provides OAuth 2.0 and OpenID Connect in a headless service that can integrate with an existing user management system. That lets you keep token issuance and login concerns separate in your architecture; your business-retention logic should remain in application workflows.

What decision checklist should we use?

Ask these before wiring deletion:

• Does every retained record reference an internal subject ID rather than email?
• Can login deletion happen without deleting invoices or audit logs?
• Which fields must be retained, and which can be anonymized?
• Do you record completion evidence across systems?
• Have you separated Ory-managed identity deletion from app-owned retention jobs?

What if a team expects one delete call to erase everything?

Do not do that unless every dependent system is designed for legal and operational cascade deletion. A single destructive cascade is how teams lose records they were required to keep.

What if retained records still contain personal data?

Then your job is not finished. Keep the record if required, but minimize the fields you do not need and document the exception path. Deletion is often a workflow, not a single API call.

Next step: model your account-deletion flow as a system map with three columns—identity, retained business records, and anonymization jobs—and implement the identity step first with Ory Network.

Reviewed: 2026-09-06