Alles, was Security-Teams, Einkauf und Partner über tidiam wissen müssen: Grundlagen, Funktionen, Connectors, Sicherheit und Compliance, plus FAQ. Read-only, ehrlich, ohne Marketing-Theater.
tidiam gibt Security-Teams und CISOs ein klares, auditierbares Bild ihrer Identitäten über mehrere Identity Provider hinweg und erzeugt audit-fertige Reports.
tidiam verbindet Ihre Verzeichnisse und Identity-Quellen read-only, wertet Benutzer, Gruppen, Berechtigungen und Policies aus und macht Risiko und Compliance auf einen Blick sichtbar, kontinuierlich statt einmal im Jahr.
Statt manueller Exports und Tabellen liefert tidiam einen laufenden Überblick und Reports, die auf NIS2, ISO/IEC 27001:2022 und CIS Controls gemappt sind.
Alle Identitäten aus mehreren Providern in einer Tabelle: Quelle, Status, Risiko, letzter Login.
Statt sich durch mehrere Admin-Portale zu klicken, sehen Sie alle Benutzer, Gruppen und Service Principals an einem Ort, mit Quelle, Status, Risiko-Hinweisen und letztem Sign-In. So fallen verwaiste Konten, Duplikate und überprivilegierte Identitäten sofort auf.
Der Health Score fasst den IAM-Zustand zusammen und zeigt, wo Handlungsbedarf besteht.
Das Dashboard gibt einen schnellen Überblick: Gesamtzustand, Trend über die Zeit und die Bereiche mit dem größten Handlungsbedarf. Der Score ist als Orientierung gedacht, nicht als Blackbox-Note, jedes Finding ist nachvollziehbar und mit einer Empfehlung hinterlegt.
Die genaue Berechnung wird hier bewusst nicht offengelegt; entscheidend ist, dass Sie jederzeit sehen, was den Zustand beeinflusst und wie Sie ihn verbessern.
Priorisierte Findings nach Kategorie und Schweregrad, jeweils mit Handlungsempfehlung.
Findings werden nach Schweregrad (kritisch, hoch, mittel, niedrig) und Kategorie gruppiert, etwa privilegierte Konten, fehlende MFA, verwaiste oder inaktive Konten und Lücken in Conditional Access. Jedes Finding ist verständlich beschrieben und mit einer konkreten Empfehlung versehen.
tidiam mappt Findings auf den Identity-relevanten Teil von NIS2, ISO/IEC 27001:2022 und dem BSI IT-Grundschutz (Edition 2023); CIS Controls dienen als Referenz.
tidiam deckt den IAM-Anteil dieser Frameworks ab, nicht das gesamte Framework. Abgedeckt sind Bereiche rund um Zugriff, Berechtigungen, privilegierte Konten und MFA.
NIS2: Zugriffskontrolle und Identitätsmanagement.
ISO/IEC 27001:2022: relevante Annex-A-Controls zu Identity & Access.
CIS Controls: Account- und Access-Management.
Was außerhalb von IAM liegt, ist not in scope und wird ehrlich so dargestellt.
Audit-fertige Reports in mehreren Typen, reproduzierbar als Snapshot, in DE und EN.
Executive: Überblick für Management und Auditoren.
Technical: Details für das IAM-Team.
Audit Evidence: Nachweise für Prüfer.
Identity Profile: Sicht auf einzelne Identitäten.
Reports basieren auf einem Snapshot und sind damit reproduzierbar. Verfügbar auf Deutsch und Englisch. Reports können mit Klassifizierungsstufen (z. B. Intern, Vertraulich) gekennzeichnet werden.
Geführte Kampagnen, in denen Verantwortliche Zugriffe bestätigen oder entziehen.
Ein Access Review ist eine Rezertifizierung: Verantwortliche bestätigen pro Konto oder Objekt, ob der Zugriff bleibt oder entzogen wird. Kampagnen starten Sie über vorgefertigte Prüfumfänge: privilegierte Konten, externe Gäste, Objekte ohne Owner, Objekte mit Owner oder alle Befunde einer Kategorie. Reviewer sehen die relevanten Zugriffe im Kontext und entscheiden pro Eintrag. Jede Entscheidung ist dokumentiert, das Ergebnis dient als Nachweis für Prüfer, Kunden und Versicherer. Verfügbar ab Professional.
Bewusst akzeptierte Risiken werden dokumentiert statt versteckt, mit Begründung, Ablaufdatum und eigenem Report-Kapitel.
Nicht jedes Finding ist ein Fehler. Ein Notfallkonto ohne MFA oder ein Dienstkonto mit statischem Secret für ein Altsystem kann gewollt sein. Administratoren stufen ein einzelnes Objekt oder einen ganzen Prüfpunkt als akzeptiertes Risiko ein, mit Pflichtbegründung und einem Ablaufdatum von höchstens zwölf Monaten.
Akzeptiert heißt nicht behoben: das Finding zählt nicht mehr in Health Score und Prioritäten, der Datenabgleich beobachtet das Objekt weiter, und nach dem Ablaufdatum wird es automatisch wieder offen. Jeder Report führt akzeptierte Risiken in einem eigenen Kapitel mit Begründung und Gültigkeit auf und nennt den Score ohne Akzeptanzen daneben. Jede Akzeptanz, jeder Widerruf und jeder Ablauf steht im Change Trail. In allen Plänen enthalten.
Ob eine einzelne Person so entscheiden darf, ist eine Frage der Organisation. Das Vier-Augen-Prinzip lässt sich deshalb einschalten: die Akzeptanz wirkt erst, wenn eine zweite Person mit Administratorrechten sie freigibt. Bis dahin bleibt das Finding offen und zählt normal. Wer den Antrag gestellt hat, gibt ihn nicht selbst frei, kann ihn aber zurückziehen. Die Begründung muss eine sein: Platzhaltertext wird abgewiesen. Vierzehn Tage vor dem Ablauf erinnert eine Mail an die Wiedervorlage.
Read-only über Microsoft Graph mit Least-Privilege-Scopes.
tidiam liest Benutzer, Gruppen, Service Principals, App-Registrierungen, Rollen und Conditional-Access-Policies über Microsoft Graph mit Application-Permissions, ausschließlich lesend. Zwei Wege: eine App-Registrierung in Ihrem Tenant (Client-Secret wird verschlüsselt gespeichert) oder der Admin-Consent für die tidiam-Connector-App (kein Secret verlässt Ihren Tenant). Die Berechtigungen:
Directory.Read.All (Benutzer, Gruppen, Service Principals, App-Registrierungen, Rollen, Gäste)
AuditLog.Read.All (MFA-Registrierung, letzte Anmeldung; Anmeldeaktivität braucht Entra ID P1)
SecurityEvents.Read.All (optional, Microsoft Secure Score)
Alle vier sind Leserechte. Zurückgeschrieben wird nichts. Optional liest tidiam auch die Azure-Rollen auf Ihren Subscriptions und Ressourcen und woran Managed Identities hängen; dafür vergeben Sie derselben App die Azure-Rolle Leser (Reader). Der Entra ID Quick Check im Browser ist der einzige Weg mit delegierten Rechten; der Connector der Plattform arbeitet immer mit Application-Permissions.
On-Prem AD wird über einen schlanken read-only Agent angebunden.
Für On-Prem Active Directory installieren Sie einen schlanken Agenten im Netzwerk, der ausschließlich liest: Benutzer, Gruppen, Organisationseinheiten und Gruppenrichtlinien. Der Agent benötigt ein Dienstkonto mit Leserechten und schreibt nichts zurück.
Okta über die Admin-API, Keycloak direkt über die Admin-REST-API oder über den read-only Agent.
Okta wird read-only über die Admin-API angebunden (Benutzer, Gruppen, App-Zuweisungen), über eine OAuth-Service-App mit reinen Lese-Scopes. Keycloak-Realms (Benutzer, Rollen, Clients) liest tidiam über einen Service-Account mit view-Rollen, wahlweise direkt über die Admin-REST-API per HTTPS oder über den read-only Agent aus Ihrem Netzwerk. Im Agent-Modus bleiben die Keycloak-Zugangsdaten beim Agent. Auch hier: nur lesen, nichts zurückschreiben.
Beide direkt per API aus der Cloud, ohne Agent und ausschließlich lesend. AWS IAM ist verfügbar, Google Workspace folgt in Kürze.
AWS IAM: Ein Connector entspricht einem AWS-Konto und liest IAM-Benutzer, Rollen, Policies, Zugangsschlüssel und das Root-Konto. Dafür legen Sie in Ihrem AWS-Konto eine rein lesende Rolle an, mit einem Klick über einen CloudFormation-Link oder selbst mit den JSON-Policies. tidiam darf diese Rolle nur aus dem eigenen AWS-Konto und nur mit einer External ID übernehmen, die tidiam für Ihren Connector vergibt; ein Schlüssel von Ihnen liegt bei tidiam nicht, und wenn Sie den Stack löschen, ist der Zugang beendet. Das Lesen von CloudTrail-Ereignissen ist optional und ergänzt nur, wer eine Änderung vorgenommen hat.
Google Workspace (in Kürze): Ein Connector entspricht einer Workspace-Organisation und liest Benutzer, Gruppen, Admin-Rollen und die Bestätigung in zwei Schritten. tidiam greift über das Google Admin SDK mit einem Dienstkonto zu, das per domänenweiter Delegation ausschließlich lesende Scopes erhält; der Audit-Log-Scope ist optional und ergänzt nur, wer eine Änderung vorgenommen hat.
Beide Connectors arbeiten direkt per API, ohne Agent und ohne Schreibrechte: tidiam verändert weder das AWS-Konto noch die Workspace-Organisation.
Was nicht gelesen wird: Von AWS weder IAM Identity Center noch AWS Organizations (ein Connector gilt für genau ein Konto) noch IAM Access Analyzer. Von Google Workspace keine Tokens von Drittanbieter-Apps, keine App-Passwörter und keine Gruppeneinstellungen, weil Google sie nur mit Schreib-Scopes herausgibt und tidiam keine anfordert; Dienstkonten erscheinen noch nicht als Identitäten.
Über alle Connectors hinweg arbeitet tidiam ausschließlich lesend, per API und über den On-Prem-Agenten. tidiam verändert keine Konten, Gruppen oder Policies in Ihren Quellsystemen. Remediation bleibt in Ihrer Hand; tidiam zeigt nur, was zu tun ist.
Verarbeitung in Deutschland auf zertifizierter Infrastruktur.
Ihre IAM-Daten werden in Deutschland gespeichert und verarbeitet, auf ISO-27001-zertifizierter Infrastruktur (Rechenzentrum Falkenstein). Damit bleibt die volle Datenhoheit in der EU. Die Liste der Subprozessoren ist auf unserer Trust-Seite veröffentlicht.
Verschlüsselung, Least Privilege und Read-only-Zugriffe als Fundament.
Read-only: kein Schreibzugriff auf Quellsysteme.
Least privilege: nur minimal nötige Leseberechtigungen.
Verschlüsselung: Daten verschlüsselt in Transit und at Rest.
Credential-Schutz: rein lesende App-Zugänge, verschlüsselt gespeichert; On-Prem-Zugangsdaten bleiben beim Agent in Ihrem Netzwerk.
Implementierungsdetails werden aus Sicherheitsgründen nicht öffentlich beschrieben; weitere Auskunft für Prüfer geben wir im Rahmen der Anbieterprüfung auf Anfrage.
Nur Fakten: was bereits gilt und was in Vorbereitung ist.
Die genutzte Infrastruktur ist ISO 27001 zertifiziert. Für tidiam selbst läuft die Vorbereitung auf eine eigene ISO-27001-Zertifizierung. Wir behaupten keine Zertifikate, die nicht vorliegen; sobald sich der Status ändert, wird er hier aktualisiert.
Vier Stufen, die sich vor allem über Connector-Anzahl und Funktionen unterscheiden.
Es gibt Essentials, Professional, Business und Enterprise. Der Hauptunterschied liegt in der Anzahl der Connectors und Identities sowie Funktionen wie Compliance-Frameworks, Access Reviews und Support. Aktuelle Preise und der genaue Funktionsumfang stehen auf der Pricing-Seite.
Ein Konto mit Leseberechtigung in der jeweiligen Quelle.
Für On-Prem (AD, Keycloak): Netzwerkzugang für den read-only Agenten.
Für AWS: eine rein lesende Rolle, per CloudFormation-Link angelegt; für Google Workspace (in Kürze): ein Dienstkonto mit domänenweiter Delegation und nur lesenden Scopes.
Eine Person, die Findings reviewen und Verantwortliche zuordnen kann.
tidiam prüft Identitäten und Berechtigungen über mehrere Verzeichnisse hinweg, täglich und ausschließlich lesend, und erzeugt daraus audit-fertige Reports.
Wie unterscheidet sich tidiam von einem klassischen IAM/IGA-Tool?
tidiam ersetzt kein IdP und provisioniert keine Konten. Es bewertet den Zustand, deckt Risiken auf und liefert Compliance-Nachweise.
Ersetzt tidiam Entra ID oder Okta?
Nein. tidiam liest aus diesen Systemen und bewertet sie, es ersetzt sie nicht.
Wie viele Prüfungen laufen?
125 Checks prüfen die tatsächliche Konfiguration, täglich statt punktuell; 8 weitere für Google Workspace folgen in Kürze. Jedes Finding ist priorisiert, hat eine Fix-Empfehlung und ist auf NIS2, ISO/IEC 27001:2022 und den BSI IT-Grundschutz gemappt; CIS Controls dienen als Referenz.
Kann ich tidiam testen?
Ja, auf zwei Wegen: Die interaktive Demo mit Beispieldaten fordern Sie auf der Demo-Seite an. Mit Ihrem eigenen Entra-ID-Tenant starten Sie nach der Registrierung eine kostenlose Probe über 30 Tage, ohne einen Tarif zu buchen.
An wen wende ich mich bei Fragen?
An unser Team unter hello@tidiam.com oder über die Kontakt-Seite. Wir antworten in der Regel innerhalb von 24 Stunden an Werktagen.
Daten & Sicherheit
Welche Daten liest tidiam?
Benutzer, Gruppen, Service Principals, Berechtigungen und Policies, ausschließlich lesend.
Schreibt tidiam etwas zurück?
Nein. tidiam ist über alle Connectors hinweg read-only.
Wo liegen meine Daten?
Ausschließlich in Deutschland, auf ISO-27001-zertifizierter Infrastruktur.
Wer kann auf meine Daten zugreifen?
Nur berechtigte Personen Ihrer Organisation. Details stehen in der Datenschutz-Erklärung.
Wie werden Secrets behandelt?
Zugangsdaten sind rein lesende App-Zugänge und werden verschlüsselt gespeichert; On-Prem-Zugangsdaten bleiben beim Agent in Ihrem Netzwerk. Implementierungsdetails sind nicht öffentlich.
Compliance
Hilft tidiam beim NIS2- oder ISO-27001-Audit?
Ja, für den IAM-Teil: Findings sind auf NIS2, ISO 27001:2022 und den BSI IT-Grundschutz gemappt und als Nachweis exportierbar.
Ist tidiam selbst zertifiziert?
Die Infrastruktur ist ISO 27001 zertifiziert. Die eigene ISO-27001-Zertifizierung von tidiam ist in Vorbereitung.
Deckt tidiam das ganze Framework ab?
Nein, nur den Teil, der Identitäten und Zugriffe betrifft. Alles Übrige weist der Report ausdrücklich als nicht abgedeckt aus.
Was, wenn ein Finding so gewollt ist?
Dann stufen Administratoren es als akzeptiertes Risiko ein, mit Pflichtbegründung und einem Ablaufdatum von höchstens zwölf Monaten. Es zählt dann nicht mehr in Health Score und Prioritäten, der Abgleich beobachtet das Objekt weiter, und nach Ablauf ist es automatisch wieder offen. Jeder Report führt akzeptierte Risiken in einem eigenen Kapitel und nennt den Score ohne Akzeptanzen daneben. In allen Plänen enthalten.
Setup
Wie lange dauert die Einrichtung?
Cloud-Quellen sind in Minuten verbunden; der erste Report ist oft am selben Tag fertig.
Welche Berechtigungen braucht der Connector?
Nur Leseberechtigungen (Least Privilege). Für Entra ID z. B. read-only Microsoft-Graph-Scopes.
Brauche ich einen Agenten für AD?
Ja, für On-Prem AD und Keycloak gibt es einen schlanken read-only Agenten. Cloud-Quellen laufen ohne Agent über API.
Können Findings in unser Ticketsystem?
Ja, per Klick als Ticket in Jira, ServiceNow, TOPdesk oder Zendesk. Der Ticketstatus wird zurückgemeldet. Das Finding selbst schließt erst, wenn die nächste Prüfung die Änderung im Verzeichnis sieht, nicht schon beim Schließen des Tickets. Ab Professional ist die Integration im Tarif enthalten, für Essentials als Add-on buchbar.
Reports
Welche Report-Formate gibt es?
Executive, Technical, Audit Evidence und Identity Profile, als PDF in DE und EN.
Sind Reports für Auditoren reproduzierbar?
Ja, Reports basieren auf einem Snapshot und lassen sich für denselben Stand erneut nachvollziehen.
Gibt es Reports auf Deutsch und Englisch?
Ja, beide Sprachen werden unterstützt.
Pläne
Wie viele Connectors sind pro Plan enthalten?
Essentials 1, Professional 10, Business 20, Enterprise unbegrenzt. Ein Konnektor ist eine verbundene Quelle, also ein Entra-Tenant, ein AWS-Konto oder ein Verzeichnis, in Kürze auch eine Google-Workspace-Organisation.
Wie wechsle ich den Plan?
Ein Upgrade ist jederzeit möglich; die Laufzeit beträgt 12 oder 24 Monate mit jährlicher Abrechnung.
Was zählt als Identität?
Jedes Konto in einem angebundenen Verzeichnis: Menschen ebenso wie Service-Accounts, Admin-Konten, Gäste und technische Nutzer. Gezählt wird, was die Konnektoren beim Abgleich tatsächlich lesen. Die aktuelle Zahl sehen Sie im Dashboard.
Grenzen & Roadmap
Was kann tidiam noch nicht?
tidiam provisioniert keine Konten.
Welche Connectors fehlen aktuell?
Verfügbar sind Entra ID, Active Directory, Okta, Keycloak und AWS IAM; Google Workspace folgt in Kürze. Fehlt Ihnen eine Quelle, sagen Sie es uns.
Noch Fragen oder Preise vergleichen? Wir helfen weiter.