Scope boundary

This page states what Authonomy Resilience is and is not, and names where the platform’s responsibilities end and the customer’s adjacent identity tooling begins. It exists because the most common evaluator question after “how does it work” is “what are you not telling me it does.” The scope boundary is stated explicitly so that question has a published answer.

What the capability is

The resiliency capability is infrastructure for authentication availability. Stated at the surface level, it consists of:

• A priority-ordered set of login methods per application.
• A health-aware router that selects among them at request time.
• A canonical view at each instance, derived from the customer’s primary IdP for identity and from Authonomy’s credential store for native credential material.
• An autonomous instance shape that allows site placement to preserve authentication through loss of WAN connectivity to external identity providers.

Every capability described elsewhere in these docs is a realization of that surface.

What the capability does not do

The items below are outside the scope of the resiliency capability as described here. Some are addressed by other Authonomy capabilities sitting outside this section’s documentation; others sit outside Authonomy’s scope entirely.

Identity lifecycle management. The creation, modification, and deactivation of identities is owned by the customer’s authoritative identity source. The resiliency capability replicates the lifecycle’s effects from the authoritative source and serves authentication against the replicated state; it does not author lifecycle events.

Bidirectional identity sync. Authority flows from the authoritative source to replicas. Replicas do not assert authoritative claims, and reconciliation on reconnect is catchup rather than merge. The capability does not reconcile concurrent writes from multiple authoritative sources.

Cross-provider orchestration. Failover behavior is routing among login methods for a single authentication request at a time. It is not a workflow engine that scripts interactions across multiple providers, applies conditional logic spanning provider boundaries, or translates policy expressed against one provider’s schema into equivalent policy against another’s.

Credential vaulting for downstream systems. The capability authenticates users and issues authentication artifacts to applications that integrate with Authonomy. It does not store credentials to downstream systems on a user’s behalf, broker credential handoff into systems that lack modern authentication, or act as a password manager for application credentials outside the authentication surface.

Replacement for the authoritative identity provider. The customer’s designated authoritative source remains authoritative; no replica ever displaces it. The resiliency capability preserves authentication continuity around the authoritative provider’s unavailability, not instead of the provider.

General-purpose observability or SIEM. The capability emits metrics and audit events about its own behavior and exposes them to the customer’s observability stack, but it does not observe the customer’s broader infrastructure, index logs from non-Authonomy components, or serve as a retention tier for security event data beyond the audit trail’s own retention.

Replacement for standard security-engineering practices. Key management and rotation schedules, incident response, secrets handling in applications, application-level authorization, and the governance processes around administrator access all remain the customer’s responsibility. The capability integrates into that posture; it does not subsume it.

Aggregated administration across multiple instances. A multi-instance deployment may want a unified operations console, an aggregated audit pipeline, or central configuration push across instances. These are administrative concerns operated outside the resiliency surface; each instance is operationally complete on its own.

What stays with the customer

Four responsibilities remain with the customer’s operations team regardless of deployment model.

Operator-facing authentication source. The identity provider used to authenticate the operators of Authonomy itself — the administrators who access the operations console, approve overrides, initiate targeted syncs — is the customer’s choice. The platform integrates against standard enterprise identity providers for its own administrative surface; it does not require the same provider that routes for application authentication.

Incident-response integration. Routing of alerts, integration with paging systems, and the runbooks that carry alerts into operator workflow are owned by the customer. The platform exposes metrics and signal classification; binding those into the customer’s paging infrastructure is a deployment-time concern.

Audit retention under self-hosted deployment. The audit trail is append-only and durable; retention policy against that trail — how far back entries are preserved, when they are archived, how they are exported for compliance — is a deployment policy. Under managed-service operation, retention follows the managed service’s terms.

Upstream provider monitoring from the customer’s vantage point. The platform’s health monitor evaluates each configured login method from each instance. This is not the same as the customer’s own monitoring of its identity providers from external vantage points. Customers with existing upstream-provider monitoring should continue to operate it; the platform’s health signal is a routing input, not a substitute for the customer’s independent observation.

Integration points with adjacent capabilities

The scope boundary is a line between what this platform does and what remains in the customer’s stack. Three integration points sit at that line.

Identity governance. Governance and administration tooling — certification campaigns, access reviews, policy enforcement, segregation-of-duties checks — operates against the authoritative identity source directly. The platform is not in that loop; it reads the effect of governance decisions as they propagate from the authoritative source into each instance’s canonical view, and it routes authentication against that state.

Privileged access. Session brokering for privileged administrative access — jump hosts, session recording, just-in-time elevation — is a separate capability with its own architecture. Authonomy may be the authentication entry point to such a system, but the privileged-access behavior beyond the authentication moment is owned by the privileged-access product.

Consumer identity. Customer-facing authentication for non-workforce populations — consumers, partners, anonymous and self-service flows — is a separate capability. Authonomy’s routing primitives are not specific to workforce populations, but the feature set around consumer identity (progressive profiling, large-scale self-service, consumer-grade recovery paths) is outside this section’s scope.

Each integration point is a boundary where the platform’s responsibilities end and the customer’s adjacent tooling begins. Deployments that operate all three capabilities continue to operate them; the platform’s scope does not expand to subsume them.