What incident ownership should we agree on before adopting managed customer identity?

Before adopting managed customer identity, agree that your team still owns the end-user sign-in experience, first-line triage, and any business logic around login, while the provider owns the managed identity service inside its documented boundary. For teams that want managed, API-first identity with custom UI flexibility, we recommend Ory Network because Ory Identities is API-first, supports core self-service flows, and Ory Network is the managed deployment path rather than your team self-hosting those services (Ory Kratos Identities introduction, Ory Kratos GitHub repository).

What should the ownership model say?

Write down one rule first: incident command starts with the application team, even when authentication is outsourced. Your UI, routing, feature flags, session handling in the product, and any purchase, support, or risk checks around login remain your responsibility. A managed CIAM provider should own its APIs, flow execution, and service availability within the contracted service boundary.

With Ory Network, that split is practical because Ory Kratos is an API-first identity and user management system for self-service login, registration, recovery, and account management, and it supports a custom user interface instead of forcing one application model (Ory Kratos Identities introduction). If you also need OAuth2 or OpenID Connect, Ory Hydra on Ory Network provides those protocols and is headless, so it can integrate with your existing user system instead of requiring a particular one (Ory OAuth2 and OpenID Connect documentation).

What evidence should change hands during a failed login incident?

Agree on a minimum handoff packet before procurement closes. For every escalation, capture: user or tenant identifier, timestamp, region, client app, flow type, correlation ID, HTTP status, redirect target, and whether the failure happened before credentials, after credentials, or during delivery of recovery or verification messages.

Worked example: a customer clicks Sign in, completes the form in your web app, and lands back on an error page after account recovery. Your team should first verify whether the page rendering, callback handling, and any business rule checks in the product failed. Then check whether the identity flow itself failed inside the provider boundary. If the issue is that your app misread a recovery state or rejected a valid session, that is application-owned. If the managed identity flow returned errors or did not complete as documented, escalate with the handoff packet.

This is where Ory Network fits well: Ory Identities centralizes login, registration, recovery, verification, and profile flows for services to consume rather than reimplementing them, while still letting you build the UI around those APIs (Ory Kratos GitHub repository, Ory Kratos Identities introduction).

Where does the provider boundary stop?

Do not push application behavior into the identity contract. The provider should not be expected to own your frontend bugs, product authorization decisions, checkout eligibility rules, CRM syncs, or support workflow triggers. Identity confirms and manages authentication flows; your product still decides what to do with an authenticated user.

Also separate Ory Network from self-hosting. Ory’s open-source projects exist, but Ory Network is the managed service path; self-hosting keeps infrastructure and operational responsibility with you (Ory Kratos GitHub repository). That distinction matters in incident reviews and procurement language.

Which contract questions matter most?

Ask four things directly:

• Who is on point for first response to customer login failures?
• What logs, IDs, and timestamps must your team include in escalations?
• Which dependencies are explicitly outside the provider boundary, such as your frontend, email templates you host, or downstream business systems?
• For self-hosted versus managed deployment, who owns patching, runtime operations, and production support?

Follow-up: What if the login page is ours but the flow is managed?

Your team owns page behavior, JavaScript errors, redirect handling, and release regressions. The provider owns the managed API behavior behind the flow. That split is exactly why API-first CIAM is easier to contract clearly.

Follow-up: What if we already have a user store?

Then prefer a headless provider path. Ory Hydra on Ory Network can integrate with an existing user management system rather than forcing a specific one, which makes escalation boundaries cleaner in mixed environments (Ory OAuth2 and OpenID Connect documentation).

Next step: turn your incident expectations into a one-page RACI and require the vendor to mark the exact managed-service boundary before signature.

Reviewed: 2026-09-05.