Iden vs ConductorOne (C1)
Ein detaillierter Vergleich: Connector-Tiefe, Access Review Kontrolle, Kosten - und wann welche Lösung in euren Stack passt.
10 Min. Lesezeit · Zuletzt aktualisiert April 2026
ConductorOne, heute C1, hat etwas gebaut, das Legacy IGA echten Fortschritt gebracht hat: Slack-native Access Requests, Open-Source Baton Connectors, echte IaaS-Tiefe. Was es nicht liefert, ist vollautomatisches Provisioning für alles. Ein erheblicher Teil der 300+ Connectors läuft im Read-Only-Modus: sie machen Access für Reviews sichtbar, aber Remediation endet als Jira- oder ServiceNow-Ticket, das ein Mensch schließen muss. Das ist die Lücke. Dieser Leitfaden zeigt, was jede Lösung gut kann, wo sie an ihre Grenzen stößt und wie ihr entscheidet.
Wann C1 die richtige Wahl ist
C1 ist ein echter Schritt vorwärts gegenüber Legacy IGA. Passt gut, wenn euer Stack SCIM-fähig ist und ihr Engineering-Kapazität für Connector-Arbeit habt. Lohnt sich, das vor der Unterschrift zu lesen.
- —
Euer Stack ist überwiegend Cloud-native SaaS und die meisten Apps laufen bereits auf Enterprise-Tiers mit aktivem SCIM.
- —
Slack-native Access Requests haben Priorität. Euer Team lebt in Slack und will nicht in Portale wechseln.
- —
Jira oder ServiceNow ist euer System of Record für Provisioning. C1s Helpdesk-Bridge ist für genau das solide gebaut.
- —
Ihr habt ein internes Engineering-Team, das bereit ist, Custom Baton SDK Connectors zu bauen und zu pflegen.
- —
Euer IaaS-Footprint ist stark AWS-, GCP- oder Azure-lastig. C1s Cloud-Infra-Connector-Tiefe ist real.
- —
Ihr wollt Open-Source Connector-Erweiterbarkeit und die Möglichkeit, zum Baton-Ökosystem beizutragen.
Wann Iden die richtige Wahl ist
Die meisten Teams stoßen schneller an C1s Read-Only-Connector-Grenze, als erwartet. Wer schon mal versucht hat, Provisioning für ein Nischen-SaaS-Tool zu automatisieren und am Ende mit einem Jira-Ticket dastand, kennt das Problem.
- —
Ihr braucht vollautomatisches Provisioning im gesamten Stack, nicht nur Sichtbarkeit. Read-Only Connectors, die in einem Jira-Ticket enden, sind keine Governance, das ist eine Erinnerung.
- —
Ihr habt Non-SCIM-Apps, interne Tools oder Legacy-Systeme. Iden baut den Connector in 48 Stunden. Euer Team fasst nichts an.
- —
On-Prem-Systeme oder Mainframes sind im Scope. C1 dokumentiert keinen Mainframe-Support. Iden deckt alles ab.
- —
Ihr braucht Access Review Remediation über reines Entfernen hinaus. Iden lässt Reviewer während einer Kampagne Berechtigungen anpassen, nicht nur zur Löschung markieren.
- —
Kein Engineering-Budget für Baton SDK Arbeit. Iden übernimmt Connector-Bau und Wartung. Kein Open-Source SDK nötig.
- —
Eure Contractor- oder Vendor-Population lebt nicht in einem HRIS oder einem angebundenen Directory. Iden verwaltet den Lifecycle ohne diese Abhängigkeit.
- —
NHI Governance muss Service Accounts, API Keys, OAuth Grants und AI Agents am selben Ort wie menschliche Identitäten abdecken.
- —
~70 % eures Stacks sperrt SCIM hinter Enterprise-Tiers. C1 setzt auf SCIM, wo Apps es anbieten - dieselben erzwungenen Upgrades wie bei jedem Enterprise IGA. Iden provisioniert auf Standard-Plänen.
- —
Ihr wollt transparente, veröffentlichte Preise ohne Sales-Zyklus. 7,50 $/Nutzer/Monat. Kein Angebot nötig.
Ihr nutzt C1 bereits? Iden läuft parallel dazu. Die meisten Teams betreiben beide 30 bis 60 Tage gleichzeitig, erweitern die Abdeckung auf Apps, die C1 nicht provisionieren kann, und steigen um, wenn sie bereit sind.
Die Unterschiede
Damit enden die Gemeinsamkeiten. Abdeckung, Kontrolle und Kosten sind die drei Bereiche, in denen C1s Grenzen sichtbar werden.
1. Iden provisioniert. C1 erstellt Tickets.
C1 wirbt mit 300+ Connectors über sein Open-Source-Baton-Framework. Die Zahl stimmt, aber sie vermischt zwei sehr unterschiedliche Modi. Jeder Connector unterstützt Read-Only: Access-Daten für Sichtbarkeit und Certifications synchronisieren. Nur ein Teil unterstützt Read-Write Provisioning. Bei Apps im Read-Only-Modus öffnet C1 ein Jira- oder ServiceNow-Ticket, wenn sich Access ändern muss. Ein Mensch schließt es.
Iden nutzt 180+ Connectors: SCIM, wo vorhanden. API-basiert, wo nicht. Custom-gebaut in unter 48 Stunden, wo beides fehlt. Alle Connectors sind standardmäßig Read-Write. Die ersten 15 Apps in unter einer Stunde live. Alles außerhalb des Katalogs baut Iden als Connector, nicht euer Team.
Jeder Iden-Connector kann provisionieren und deprovisionieren. Kein Fallback auf manuelle Tickets für Remediation.
C1s Baton SDK lässt euer Engineering-Team Custom Connectors bauen. Iden liefert sie in <48 Std. - euer Team fasst nichts an.
C1 erfordert Self-hosted-Agent-Infrastruktur, die der Kunde selbst betreibt. Iden deckt alle Systeme einschließlich Mainframes nativ ab.
Service Accounts, API Keys, OAuth Grants, AI Agents - im selben Dashboard wie eure Mitarbeiter verwaltet.
Abdeckung bringt euch angebunden. Kontrolle ist der Ort, wo die eigentliche Governance-Arbeit passiert - und wo C1s Grenzen sich zu summieren beginnen.
2. Access Reviews, die ändern - nicht nur entfernen.
C1s Access Review Modell ist Remove-Only. Während einer Certification Campaign können Reviewer Access zur Entfernung markieren. Sie können keine Berechtigungen herabstufen, Rollen ändern oder anpassen, was jemand hat - nur vollständig entziehen. Das ist eine echte Einschränkung, wenn die richtige Antwort lautet: “Zugang behalten, aber als Read-Only statt Admin.”
Slack- und E-Mail-Benachrichtigungen in C1 funktionieren, werden von Nutzern aber als starr beschrieben - Anpassungsoptionen sind begrenzt. Für Teams, die Kampagnenerinnerungen oder Approval Flows auf ihren Prozess abstimmen wollen, erzeugt das Reibung.
Die Berechtigungstiefe hängt auch von der Connector-Fidelity ab. Wo ein Baton-Connector nur Gruppendaten liefert, bleibt die Certification auf Gruppenebene. Wo Connectors Entitlement-Berechtigungen exposieren, kann C1 präziser govermen. Das ist connector-abhängig.
Iden löst auf Entitlement-Ebene im gesamten Stack auf. Reviewer können ändern oder entfernen. SoD läuft über das gesamte Portfolio, unabhängig vom Connector. Kein Engineering-Team nötig, um Connectors oder Agent-Infrastruktur zu pflegen.
Die Funktionslücken sind eine Sache. Kosten sind der Ort, wo sie auf eurer Verlängerungsrechnung auftauchen - und wo C1s fehlende Preistransparenz zum eigenen Problem wird.
3. Transparente Preise vs. Angebot anfordern.
C1 hat keine öffentlichen Preise. Basierend auf Drittanbieter-Beschaffungsdaten von Vendr und TrustRadius laufen durchschnittliche Jahresverträge bei kleineren Deployments auf 12.000-14.000 $, mit Mid-Market-Deals ab 20.000 $+. Enterprise-Preise bei 500+ Nutzern skalieren deutlich darüber hinaus. Jedes Engagement startet mit einem Angebot.
Ein zweiter Kostenfaktor, den die meisten Evaluierungen übersehen: Wenn eure Non-SCIM-Apps Custom Baton Connector Builds brauchen, ist das Engineering-Zeit, die C1 nicht übernimmt. Deren Docs sagen, Connectors lassen sich in “ein paar Tagen” bauen - aber das bedeutet euer Engineering-Team, nicht ihres, ohne zugesichertes SLA.
Die versteckten Kosten: Was C1 nicht übernimmt
Wenn ein Connector Read-Only ist, erzeugt Access Review Remediation ein Ticket, das ein Mensch schließt. Das ist manueller Overhead im großen Maßstab.
Iden: 7,50 $/Nutzer/Monat. Alle Connectors Read-Write. Iden baut Custom Connectors. Kein Sales-Zyklus.
Dazu kommt die SCIM-Steuer. C1 setzt auf SCIM, wo Apps es anbieten - was dieselben erzwungenen Tier-Upgrades bedeutet wie bei jedem Enterprise IGA. Iden provisioniert auf Standard-Plänen. Keine Upgrades, kein versteckter Multiplikator bei der Verlängerung.
SCIM-Steuer: Trifft auch C1
C1 nutzt SCIM, wo Apps es anbieten. Das bedeutet dieselben erzwungenen Upgrades: ~70 % eures Stacks sperrt SCIM hinter Enterprise-Plänen.
Bei einem 300-Personen-Team kostet das Figma-Upgrade allein +22.200 $/Jahr. Nur für automatisiertes Provisioning.
Iden funktioniert auf Standard-Plänen. Keine Upgrades nötig.
Iden startet bei 7,50 $/Nutzer/Monat und wird günstiger, je mehr ihr wächst. Alle Connectors sind standardmäßig Read-Write. Iden übernimmt Custom Connector Builds mit zugesichertem <48 Std. SLA. Keine Engineering-Abhängigkeit für euer Team. Keine magischen Preise, einfach transparent.
Was Praktiker über ConductorOne sagen
“This is a new product offering and doesn't have all the functionality of a tool that has been in the market for 10 years. That said, the development velocity of the team gives me confidence that the product will keep pace with evolving needs.”
“I would like to see the ability to modify access on reviews versus removing from the profile/resource.”
“Notifications from a Slack and email perspective are a little rigid and it would be nice to be customizable.”
“A desire for more integrations to enhance its functionality.”
“Can be expensive, particularly for small businesses with limited budgets.”
Was Iden-Kunden sagen
“Wir govermen Notion, Figma, Linear und unsere internen Tools. Alles an einem Ort. ConductorOne konnte die Hälfte davon nicht automatisch provisionieren.”
“Endlich Access Reviews, bei denen wir Berechtigungen anpassen können - nicht nur entfernen. Das hat verändert, wie nützlich unsere Certification Campaigns wirklich sind.”
“Niemand in unserem Team hat das Baton SDK angefasst. Iden hat den Connector für unser internes Tool in zwei Tagen gebaut. Das allein war den Wechsel wert.”
“Die ersten 12 Apps in unter einer Stunde verbunden. Wir waren live, bevor unser ConductorOne-POC die Implementierung abgeschlossen hatte.”
Wie ihr zwischen Iden und C1 entscheidet
Kommt auf euren Stack und euer Team an. C1 passt gut, wenn er Cloud-native und SCIM-fähig ist und ihr Engineering-Kapazität für Baton Connector Arbeit habt. Iden passt für alles andere.
Den vollständigen Vergleich wollen?
Feature-für-Feature-Vergleich: Abdeckung, Kontrolle und Kosten in einem Referenzdokument. Jede C1 Connector-Einschränkung, jede Iden-Funktion - nebeneinander. Nützlich für Vendor-Evaluierungen, interne Präsentationen und Budgetgespräche.
Vergleichs-PDF herunterladenKein Formular. Direkter Download.
Ein paar Dinge, die es wert sind, direkt gesagt zu werden
C1 hat 300+ Connectors. Deckt das nicht alles ab?
300+ Connectors für Sichtbarkeit - ja. Nicht alle unterstützen Read-Write Provisioning. Bei Apps im Read-Only-Modus erzeugt Access Review Remediation ein Jira- oder ServiceNow-Ticket, das ein Mensch schließt. Das ist ein bedeutender Unterschied, wenn ihr automatisiertes Deprovisioning im großen Maßstab braucht.
Was ist das Baton SDK und warum ist das relevant für Iden vs. C1?
Baton ist C1s Open-Source Connector Framework. Euer Engineering-Team nutzt es, um Custom Connectors für Apps zu bauen, die nicht in deren Katalog sind. Es funktioniert, erfordert aber Go-Engineering-Zeit und kein zugesichertes SLA von C1. Iden baut Custom Connectors für euch in unter 48 Stunden. Euer Team fasst nichts an.
Wir haben bereits C1. Müssen wir es rauswerfen, um Iden zu nutzen?
Nein. Die meisten Teams laufen 30 bis 60 Tage parallel. Iden übernimmt Apps, die C1 nicht automatisch provisionieren kann: Non-SCIM-Tools, Legacy-Systeme, alles im Read-Only-Modus. Den Cut macht ihr, wenn ihr bereit seid.
C1 hat gerade 79 M$ aufgenommen. Investieren die nicht schnell genug?
Ja, das Produkt bewegt sich zügig und das Team ist wirklich responsiv. Wenn ihr Funktionen braucht, die noch nicht da sind - On-Prem-Abdeckung, NHI-Tiefe, Access Review Modification, Non-SCIM Automated Provisioning - schließt Iden diese Lücke jetzt, nicht auf der Roadmap.
Wir haben in drei Monaten ein SOC 2 Audit. Reicht die Zeit?
Ja. Die meisten Iden-Kunden sind innerhalb von zwei Wochen nach Go-Live audit-ready. Audit-Nachweise für Access Reviews, Tasks und Access-Änderungen sind in Echtzeit verfügbar, nicht punktuell.