Privacy and Data Policies

Corbado Observe measures authentication with a minimum of personal data. It works with pseudonymous identifiers, does not capture credentials and lets you set retention per purpose with data policies. This page summarizes the built-in protections, the purposes Observe supports and how to align retention with your privacy requirements.

Observe protects data at capture with pseudonymous user IDs, no passwords or field values, removed passkey signatures, masked URL query values and no stored IP addresses. A data policy per session sets how long journeys keep the pseudonymous user link: the default security and reliability policy and an extended journey analysis policy based on your users' privacy choices. After the link is removed, journeys are kept without it. Aggregated KPIs such as funnels and trends contain no user reference. You set how long each purpose keeps the user link.

1. Built-in protections

Pseudonymous identifiers: Observe links journeys to the user reference your integration sends. Configured Autocapture integrations hash the identifier in the browser, so email addresses and phone numbers are not sent to Corbado. With custom events, send a pseudonymous value such as a keyed hash and compute the same value in your own systems to join the data.
No credentials or field values: Observe does not capture passwords, one-time codes or other input values. The web SDK records how a field was used, for example focus, paste, autofill and changes in length. It does not read the clipboard.
Protected passkey telemetry: Autocapture removes user names, display names, assertion signatures and PRF outputs from WebAuthn telemetry. Credential and authenticator metadata such as AAGUID, transports and backup state remain available for analysis. For custom events, the web SDK provides the same sanitization functions.
Masked URL queries: the web SDK replaces query values in reported page URLs with * and does not report URL fragments. Paths are reported as they are, so keep personal data out of them. See data handling for allowlisting.
No IP addresses in the data model: Observe does not store client IP addresses or derive locations from them. Dimensions such as country come from tags your integration sets.
First-party storage: SDK storage is scoped to your origin and project. The device identity is a random value. Observe stores no advertising identifiers and does no cross-site tracking.
Aggregated KPIs without user reference: time series, funnels and trends contain no user reference.

If your policy requires that Corbado never receives client IP addresses, route event delivery through your own proxy and remove them there. The SDKs send to a configurable API base URL. Forward the browser’s Origin header unchanged so origin checks continue to work.

2. Purposes and retention

Authentication telemetry serves several purposes, each with its own retention needs:

Purpose	Typical questions	Data needed
Authentication security and reliability	Did a release or platform update break a login method? Are bots, credential stuffing or account enumeration hitting the login?	Recent journeys with a pseudonymous user reference for investigation
Extended journey analysis	How do returning users adopt passkeys? How do methods perform for the same users over months?	Journeys linked to a pseudonymous user reference over a longer period
Aggregated reporting	How do success rates, funnels and methods develop?	No user reference

Data policies let you keep each type of data for as long as its purpose requires. A common setup bases the default policy on the legitimate interest in secure and reliable authentication (Art. 6(1)(f) GDPR) and selects an extended policy based on the user’s privacy choices. As the controller, you decide the legal basis and describe it in your privacy notice.

3. Data policies

A data policy has a numeric code and three retention periods, each counted in days from capture:

Setting	When the period ends
Tracking data	Raw events, batches, tags, user references and device information of the session are deleted
User link	The pseudonymous user reference is removed from flows and subflows. The journeys stay available for analysis
Flows	Flows and the records derived from them are deleted

A period of 0 keeps the data without a time limit. Aggregated KPIs contain no user reference, so removing the user link does not change them. Code 0 is the project default and applies to every session that has not selected another policy. Configure policies in the management console under Observe → Settings → Data policies. A code keeps its meaning once created, because stored sessions reference it. You can rename a policy and adjust its periods at any time.

Example configuration

Code	Name	Applies when	User link
`0`	Security and reliability	By default	For the period your security and reliability purposes require
`1`	Extended journey analysis	The user’s privacy choices allow extended analysis	For your analysis period

When the user link of a journey is removed, the journey continues to count in KPIs, funnels and trends. Patterns identified in recent journeys, such as a bot signature or a recurring error sequence, can still be applied to it.

4. Select a policy per session

Your integration selects the policy for each session. Create the policy in the management console before your integration selects its code.

Web SDK
Autocapture
iOS and Android

Available from web SDK 0.16.6. Pass the code at initialization and update it when the user’s privacy choices change:

import { init } from "@corbado/observe";

const tracker = init({
  projectId: "<ProjectID>",
  apiBaseUrl: "<APIBaseURL>",
  dataPolicy: 0,
});

// After the user's privacy choices change
tracker.setDataPolicy(1);

The SDK stores the selected code per project in the browser and sends it with every batch, across page loads and new sessions. Call setDataPolicy() again whenever the choice changes, including a return to 0.

The iOS and Android SDKs select the policy the same way as the web SDK. Pass the code when initializing the tracker and call setDataPolicy() when the user’s privacy choices change. The SDK stores the selected code in the app and sends it with every batch.

Observe applies the most recent code it receives for a session to the whole session, including events recorded before the change.

5. Processing, hosting and access

Roles: you are the controller. Corbado processes Observe data on your behalf under a data processing agreement. Contact us for the agreement and the technical and organisational measures. The list of subprocessors is in the Corbado Trust Center.
Hosting: Observe runs on Corbado’s public cloud by default. Dedicated instances in a chosen region are available for enterprise deployments. See projects, environments and hosting.
Transport: SDKs and API clients communicate with Observe over HTTPS.
Access: API keys carry operation-specific permissions, can be restricted to IP addresses and expire. See API authentication.

Certifications, encryption and access control are summarized in security and compliance.

6. Requests from individual users

Export or delete the Observe data of a user by the user reference your integration sends. Deletion covers the data stored by Observe. Copies you have loaded into your own systems follow your own deletion process. See user data export and deletion.

Compatibility & constraints

What Observe collects, storage and hosting.

Data access

API, exports and security of data outside the console.

Overview

Get started

Custom events

Developer tools

Data access

Security & compliance

Custom events reference

Privacy and Data Policies

1. Built-in protections

2. Purposes and retention

3. Data policies

Example configuration

4. Select a policy per session

5. Processing, hosting and access

6. Requests from individual users

Compatibility & constraints

Data access

​1. Built-in protections

​2. Purposes and retention

​3. Data policies

​Example configuration

​4. Select a policy per session

​5. Processing, hosting and access

​6. Requests from individual users

Compatibility & constraints

Data access

1. Built-in protections

2. Purposes and retention

3. Data policies

Example configuration

4. Select a policy per session

5. Processing, hosting and access

6. Requests from individual users