Why We Publish Our Connector Tiers Publicly

*Editor's note (2026-03-28): The connector counts in this post were accurate when published. The canonical connector registry at /api/connectors/certifications now shows 5 GA, 6 Beta, and 58 Experimental connectors. See the registry for current figures.*

Identity security vendors love talking about integrations. "40+ enterprise connectors." "Native support for your entire stack." "Enterprise-grade integrations across cloud, on-prem, and SaaS." What they rarely tell you is which of those connectors are battle-tested in production tenants — and which exist primarily to fill a slide deck.

We decided to do something different. We publish our connector tiers publicly, including the full evidence checklist each connector must pass before we call it GA. This post explains why.

The Problem with Vague Connector Claims

When a vendor lists 40 integrations, buyers have no way to distinguish connectors that have processed billions of events in live production environments from connectors that were written to pass a demo, hooked up to a sandbox once, and never touched again. The connector count becomes a marketing metric, not an engineering signal.

For identity security tools specifically, this matters more than it does for most software categories. If your CrowdStrike connector is experimental and drops events under load, you might miss the lateral movement signal that preceded a breach. If your SailPoint connector is untested against your tenant's entitlement volume, the access review data you're generating for your SOC 2 audit may be incomplete. The stakes of a connector being "sort of working" are not the same as a reporting widget being slightly off.

Buyers discovering that a connector is experimental *after* signing a contract is a bad experience we want to avoid entirely. We'd rather lose a deal to a vendor who has GA coverage for your specific stack than have a customer deploy on expectations we can't meet.

What We Actually Built

Our connector certification system has three tiers:

Tier 1 — GA (General Availability)

A Tier 1 connector has passed all six evidence gates: smoke tests, parser unit tests, real live-tenant validation, load testing against production-scale event volumes, SLA backing in our customer agreements, and complete documentation. All six must be true. A connector is not GA if it has five of six.

Current Tier 1 GA connector count: 0.

We have zero GA connectors today. We are being precise about that. The first live-tenant validations are underway now, and we expect the first promotions to happen in the coming weeks. We are not going to call something GA before it is.

Tier 2 — Beta (14 connectors)

Tier 2 connectors are push-receiver connectors with full parser unit tests. The infrastructure is deployed and receiving events. The parsers have been validated against real event payloads. What they have not done is run against a live customer tenant at production scale. They have not been load tested. They are not SLA-backed.

The 14 Tier 2 Beta connectors today: GCP Audit Logs, AWS CloudTrail, Google Workspace, ServiceNow, Okta System Logs, Entra ID Sign-In Logs, CrowdStrike Identity, Jamf MDM, Ping Identity, Datadog, SailPoint IdentityNow, Delinea Secret Server, Saviynt, and Windows Event Forwarding.

If you are running one of these connectors today, we want to hear from you. Specifically, we want to know your tenant event volumes, edge cases in your payload schemas, and any failures you have hit. That data is what moves a connector from Beta to GA.

Tier 3 — Experimental (43 connectors)

Tier 3 connectors have adapter code and smoke tests. The connector logic exists. It has not been validated against a live tenant. These connectors are visible in the registry and can be configured, but you should treat them as engineering previews.

This is a large number. We built them because the adapter pattern is relatively low-effort once the framework is in place, and having the code written means we can prioritise promotion to Beta based on customer demand. But we are not pretending they are production-ready.

Why We're Publishing This

Three reasons.

First, it is the right thing to do. Buyers of security tools deserve to know the maturity level of the components they are deploying. An identity security platform with experimental connectors deployed in a production environment is not a security improvement — it is a new source of data reliability risk.

Second, it creates accountability. Publishing the tier system publicly means we cannot quietly relabel things. If we call a connector GA, the six evidence gates are documented. If a customer finds a gap, they can point to the published standard.

Third, it accelerates live-tenant validation. The fastest way to get connectors from Beta to GA is to run them against real tenants with real data. Publishing the tier system publicly, and making it easy for early adopters to understand what they are signing up for, makes it easier to find the partners who want to help us get there.

How to Verify It Yourself

The connector manifest is available at `/api/connectors/certifications`. It is a JSON endpoint listing every connector we have built, its current tier, and its evidence checklist — a boolean for each of the six gates.

Before you evaluate IdentityFirst, curl that endpoint:

``` curl https://app.identityfirst.net/api/connectors/certifications ```

You will get back a machine-readable list. Check whether the connectors your environment depends on are Beta or Experimental. If they are not at the tier you need, ask us directly when we expect to promote them — we will give you a straight answer.

What Tier 1 GA Actually Requires

The six evidence gates a connector must pass to reach GA:

1. smoke_tests — Instantiation and basic connectivity verified in CI on every merge.
2. parser_tests — Unit tests covering real-world event payloads including edge cases and malformed input.
3. real_tenant_tested — The connector has run against at least one production customer tenant and the output has been validated by the customer.
4. load_tested — The connector has been tested at the customer's peak event volume without dropping events or degrading parser accuracy.
5. sla_backed — The connector is covered by our standard SLA, including event processing latency and uptime commitments.
6. documented — Complete integration documentation: prerequisites, authentication setup, field mapping reference, known limitations, and troubleshooting guide.

All six must be true. Not five of six. Not "mostly." All six.

The Ask

If you are running one of the 14 Beta connectors in production — or if you want to be the first live-tenant deployment for a connector on the Beta or Experimental list — reach out to us at [support@identityfirst.net](mailto:support@identityfirst.net) or open a conversation through the demo request form.

Early live-tenant partners get several things: direct engineering access during the validation period, influence over the integration roadmap, and preferential pricing locked in before GA.

More importantly, you get a vendor who will tell you exactly where you stand before you sign anything.