Corbado Logo

Corbado Developer Onboarding Audit

Finding: Cross-region replication does not mean regional failover is ready.

Finding

Corbado presents Multi-AZ + Cross-Region Replica as a deployment configuration with near-real-time replication to another AWS region and an RPO of less than one minute. However, the same configuration requires manual failover and has a documented 1–4 hour RTO. Corbado's Geo Failover-Ready configuration is materially different: it maintains a partially deployed secondary application environment that can be activated with minimal manual intervention, with a documented 15–30 minute RTO. The documentation therefore distinguishes between having current replicated data and having an application environment ready to take over, but that distinction can be easy to miss when evaluating disaster recovery primarily through RPO.

Developer Assumption

A team evaluating disaster-recovery options may focus on the <1 minute RPO and the existence of a secondary regional copy when determining whether Cross-Region Replica satisfies its availability requirements. The risk is not that the documentation explicitly promises automatic recovery. The risk is that RPO communicates potential data loss, while RTO communicates service restoration time—and the two represent very different operational guarantees.

Evidence

Corbado disaster recovery configuration

The deployment documentation shows:

Cross-Region Replica

<1 minute RPO

Manual failover

1–4 hour RTO

while Geo Failover-Ready provides:

A partially deployed secondary application environment

Push-button/minimal-intervention activation

15–30 minute RTO

The same page therefore provides direct evidence that replication and failover readiness are separate capabilities.

Production Trigger

The primary region experiences a complete regional failure. The team has current data in another region, but Corbado documents that the Cross-Region Replica configuration still requires manual failover, with a 1–4 hour RTO.

What Can Break in Production

The organization can have a nearly current copy of its data while the application itself remains unavailable.

In other words:

Low RPO ≠ fast recovery.

For an authentication component, that distinction matters because dependent applications may remain unable to authenticate users until the application environment is restored and failover is completed.

Possible Interventions

Make Manual failover prominent wherever Cross-Region Replica is presented.

Put RPO and RTO side by side in the configuration-selection flow.

Explicitly explain that Cross-Region Replica provides replicated data but not a ready-to-activate secondary application environment.

Add a decision rule explaining when Geo Failover-Ready is required.

Explain the operational difference between data replication and application failover readiness.

Business Consequence

A team can satisfy its data-loss requirement while failing to satisfy its service-restoration requirement. For authentication infrastructure, discovering that distinction during a regional outage can mean a significantly longer service interruption than the team expected, affecting every application that depends on the authentication service.

Scope

This finding does not claim that Corbado's Cross-Region Replica configuration is defective. The documented behavior is explicit. The finding is that a low RPO can be mistaken for a strong recovery posture if the operational distinction between replicated data and application failover readiness is not made prominent enough during configuration selection.

Severity: High · Priority: Low

An extended auth outage is severe — every dependent app loses authentication for up to 4 hours. But this only manifests if two things both happen: a team picks Cross-Region Replica specifically, and a full regional failure occurs — a genuinely rare trigger event. High impact, low likelihood of actually firing.

← Back to Audit Library