CIAM Observability: The Metrics Nobody Tracks

Auth0 keeps your authentication logs for one day on Starter, five days on Essentials, ten on Professional, and thirty days on Enterprise. Okta holds System Log events for 90 days. Microsoft Entra ID keeps sign-in logs for 30 days on P1 and P2, seven on the free tier.

IBM's 2026 Cost of a Data Breach Report puts the mean time to identify a breach at 183 days. Every retention window above closes before the average organization knows it has a problem.

That is the observability gap in customer identity, and it is only the most obvious part of it. The deeper problem is that most teams cannot answer basic questions about their own login: how many people start a signup and finish it, what fraction of passkey prompts convert, whether provisioning stopped working last Tuesday. I argued in The Identity Tax that teams should instrument the funnel before they renegotiate the vendor bill. This is how.

Why identity ends up under-instrumented

Identity is bought, not built. The vendor owns the flow, so the vendor owns the telemetry, and the buyer inherits whatever dashboard ships in the box. That dashboard is designed to make the product look healthy, not to make your funnel legible.

Three consequences follow.

The metrics are vendor-shaped. You get monthly active users because that is what you are billed on. You do not get signup-start-to-complete, because nobody bills on abandonment.

The data expires. Retention is a pricing lever, not a security decision. The tier that gives you thirty days of logs is the tier that costs more.

Nothing fails loudly. Identity plumbing degrades to silence rather than to an error, which is the exact failure pattern I wrote about in The Silent Failure Problem. A broken SCIM connection does not page anyone. It simply stops provisioning users, and the first report comes from a customer six weeks later.

The three metric families

Identity telemetry splits cleanly into three groups with three different owners. Funnel metrics belong to product and growth. Security metrics belong to detection. Operational metrics belong to whoever gets paged. Most teams instrument one of the three.

Funnel metrics: where users fall out

The registration and login funnel is a conversion funnel, and it deserves the same rigor as checkout. Instrument these:

• Signup start to complete. One number, measured per acquisition channel and per device class. Mobile web is usually the worst cohort and usually the biggest.
• Drop at the password field. Separate the field from the form. The password step is normally the single largest loss in the sequence, and you cannot argue for passwordless without the number.
• Passkey prompt to enrollment. Count prompts shown, prompts dismissed, ceremonies started, ceremonies completed. Enrollment counted against total users hides a rollout that is failing at the prompt.
• Passkey login success rate by platform. Enrollment is not usage. I broke down that gap in the passkey success rate analysis, and the pattern holds: healthy enrollment coexisting with poor authentication rates points at a platform or synchronization problem, not a user problem.
• MFA challenge completion. Broken out by factor. SMS, TOTP, push, and passkey fail at very different rates.
• Time to first login. From invitation sent to first successful session, per tenant. In B2B this is the number that predicts whether an account onboards or stalls.
• Recovery entry rate. The share of login attempts that end in a reset. It is a product metric and a security metric at the same time.

Security metrics: what attack looks like in the numbers

Detection teams already watch authentication, usually through a SIEM, usually with rules written for workforce identity. Customer identity needs its own set.

• Authentication success rate by method. A sudden drop in password success with steady volume is credential stuffing. A sudden rise is worse.
• Recovery volume as an attack indicator. Account takeover attempts route around the login. Recovery flows are the most attacked surface in customer identity, and a volume spike in resets is often the first visible signal of a campaign.
• Failed-then-succeeded sequences per identifier. The classic stuffing signature, and cheap to compute.
• Impossible travel and device novelty rates. Track the rate, not just the events. The rate tells you whether your risk engine is drifting.
• Step-up trigger rate and step-up abandonment. An adaptive authentication policy that fires on 30 percent of sessions is not adaptive, it is a tax. One that fires on 0.1 percent is probably not firing at all.
• Session revocation latency. From the decision to revoke to the moment the session actually stops working. If you have adopted continuous access evaluation, this is the metric that proves it works.
• Token lifetime distribution in production. Configured lifetime and observed lifetime are different things once refresh is in play. Measure what sessions actually live, not what the policy says.

Operational metrics: the silent failure detectors

This is the family nobody builds, and it is where the expensive outages live. The design rule is simple: alarm on the absence of events, not only on their presence.

SCIM reconciliation. SCIM provisioning breaks quietly. A bearer token expires, an attribute mapping changes on the customer side, an IdP admin rotates a secret, and the sync simply stops. No error reaches you, because there is no request to fail. Three alerts cover it:

1. Zero SCIM events from a tenant that normally produces them, over a window sized to that tenant's history. Seven days is a reasonable default for an active enterprise account.
2. A nightly diff between the IdP's user set and your local membership table, alarming when the difference exceeds a threshold rather than on any difference at all.
3. Deprovisioning latency, measured as the gap between an IdP deactivation and the local state change. This is the number a security questionnaire will ask you for, and the number a regulator will ask about after an incident.

SSO connection health per tenant. Certificate expiry dates on every SAML connection, counted down in days, plus last-successful-login per connection. An enterprise customer whose IdP certificate expires on a Saturday will discover it before you do unless you watch the dates.

Webhook and log-stream delivery. If your vendor pushes events to you, the delivery pipeline is itself a silent failure candidate. Watch the success rate and the queue age.

Email and SMS deliverability for auth messages. A verification email that lands in spam looks exactly like a user who changed their mind. Split the funnel metric by delivery status or you will misread it.

The retention problem, and the fix

Go back to the numbers at the top. You will need identity logs from before you knew there was an incident, and the average investigation starts months after the fact. No CIAM vendor's default retention covers that gap.

The fix is to stream events off the platform on the day you turn the platform on. Every major vendor supports it: Okta has Log Streaming and the System Log API, Auth0 has log streams to external providers, Entra exports to a Log Analytics workspace or an event hub. The destination matters less than the decision to make your own store the system of record.

Three rules for the pipeline:

• Keep raw events, not aggregates. You cannot re-derive a query you did not anticipate from a rolled-up counter.
• Normalize once, at ingest. Identity events from three sources use three schemas. Pick a shape and map into it, or every later query becomes an archaeology project.
• Set retention by evidence value. Authentication events are worth keeping longer than user-agent detail. Personal data in logs is still personal data, and GDPR minimization applies to your observability store exactly as it applies to your user table.

A starter dashboard you can build this quarter

Seven panels, each with an alert condition. This is the smallest version that is genuinely useful.

Panel	Source	Alerts when
Signup completion rate	App events plus vendor logs	Drops more than 10 percent week over week for any device class
Password-step drop	App events	Trends up for two consecutive weeks
Passkey prompt conversion	App events	Falls below your rollout target for a platform
Auth success rate by method	Vendor logs	Any method deviates from its own 30-day baseline
Recovery volume	Vendor logs	Exceeds baseline by 3x in an hour
SCIM events per tenant	Vendor logs	Zero events for 7 days from an active tenant
SSO certificate countdown	Connection config	Any connection is within 30 days of expiry

None of this requires a new tool. It requires deciding that identity telemetry belongs to you rather than to your vendor.

What to ask a vendor before you sign

Observability is a procurement question, and it is easier to answer before the contract than after. When you build a shortlist, and the fast-growing CIAM providers reshaping identity in 2026 are worth having on it alongside the incumbents, put these five questions to every name:

1. What is log retention on the tier we are actually buying, in days?
2. Is log streaming available on that tier, or is it gated to enterprise?
3. What is the event schema, and is it documented and versioned?
4. Do provisioning failures emit an event, or do they fail silently?
5. Can we export historical logs at contract termination, and in what format?

Question four separates the products that were designed to be operated from the products that were designed to be demoed. The honest answer from most vendors is that a stalled SCIM sync produces nothing at all, which is exactly why you build the zero-event alarm yourself.

Frequently asked questions

What are the most important CIAM metrics to track first?

Start with three: signup start-to-complete rate, authentication success rate by method, and SCIM events per tenant with a zero-event alarm. The first tells you what the login is costing you in lost users, the second is your earliest credential-attack signal, and the third catches the failure mode that produces angry enterprise customers.

How long should identity logs be retained?

Longer than any vendor default. With a mean time to identify a breach of roughly six months, a 30-day window means the evidence is gone before the investigation starts. Stream events to your own store and set retention against your regulatory obligations and your incident-response needs, not against your vendor's pricing tiers.

How do you detect a broken SCIM connection?

By alarming on silence. A failed sync usually generates no error, so the detector has to be the absence of expected events: no SCIM activity from an active tenant over a window sized to that tenant's normal volume. Pair it with a nightly reconciliation diff against the IdP and a deprovisioning-latency measure.

Is a spike in password resets a security signal?

Frequently, yes. Account recovery is the most attacked flow in customer identity because it routes around a hardened login. A sharp rise in reset requests, especially concentrated on accounts that share an attribute, is often the first observable phase of a takeover campaign.

Does CIAM observability need a separate tool?

No. It needs a destination and a schema. Most teams already run a SIEM or a logging platform, and identity events can go there. What is usually missing is not tooling but a decision about who owns the metrics and which absences count as alerts.

What is the difference between CIAM observability and IAM monitoring?

Scale and intent. Workforce IAM monitoring watches a known population for misuse. Customer identity watches an anonymous, hostile, and much larger population, where the funnel is a revenue surface as well as an attack surface. The security metrics overlap. The conversion metrics have no workforce equivalent.