Just-in-Time Access: Schluss mit Standing Privilege - für Menschen und Maschinen

Stellen Sie sich vor, jeder Mitarbeiter trägt rund um die Uhr einen Generalschlüssel für das gesamte Bürogebäude - auch wenn er nur einmal pro Woche in den Serverraum muss. Genau das ist Standing Privilege: dauerhafter, immer aktiver Zugriff, der weit über das hinausgeht, was für die tägliche Arbeit tatsächlich benötigt wird. Und genau das ist das größte ungelöste Risiko in den meisten Identity-Stacks heute.

Laut dem Verizon Data Breach Investigations Report 2025 ist Credential Abuse der häufigste initiale Angriffsvektor - und die meisten kompromittierten Credentials trugen weit mehr Zugriffsrechte, als der Angreifer für den Schaden benötigte. Das Problem ist nicht, dass Passwörter gestohlen werden. Das Problem ist, was Angreifer damit tun können, wenn sie erst einmal drin sind.

Just-in-Time Access (JIT) ist die Antwort darauf. Nicht als theoretisches Konzept, sondern als operativer Kontrollmechanismus, der Standing Privilege durch zeitlich begrenzte, aufgabenspezifische Berechtigungen ersetzt - für Menschen und Maschinen gleichermaßen.

Just-in-Time-Zugriff in der Praxis

Kurz gezeigt: Zeitlich begrenzter, feingranularer Zugriff, der sich nach Ablauf automatisch wieder entzieht.

---

Warum Standing Privilege so gefährlich ist

Gartner warnt, dass viele Unternehmen nach wie vor auf breite, persistente Privileged Access setzen, was zu "unnötig erhöhtem Risiko" führt - und dass selbst klassische PAM-Tools das Risiko durch Standing Privilege nicht beseitigen, solange das Zugriffsmodell nicht grundlegend geändert wird.

Das Problem entsteht schleichend. Zugriff wird beim Onboarding vergeben, gelegentlich bei Rollenwechseln angepasst und selten wirklich entzogen - bis etwas schiefläuft. Rollen akkumulieren Berechtigungen, weil es einfacher ist, Rechte hinzuzufügen als zu entfernen. Periodische Access Reviews fangen einen Teil davon ab, aber der Großteil bleibt bestehen.

Die Konsequenzen sind konkret:

• Lateral Movement: Hat ein Angreifer gültige Credentials, bestimmen Standing Privileges, wie weit er sich im Netzwerk bewegen kann. IBM beziffert die durchschnittlichen Kosten eines Data Breach 2025 auf 4,4 Millionen US-Dollar - Privilege Escalation ist dabei einer der zentralen Treiber.
• Role Bloat: Rollen sammeln über Zeit immer mehr Berechtigungen an. Unit-42-Forschung zeigt, dass 99 % aller Cloud-User, Rollen und Service Accounts über mehr Berechtigungen verfügen, als sie tatsächlich benötigen.
• Dormant Accounts: Accounts, die niemand mehr aktiv nutzt, aber weiterhin Zugriff haben, sind ein offenes Einfallstor.

Die Identity Defined Security Alliance stellte fest, dass 84 % der Unternehmen im vergangenen Jahr einen identitätsbezogenen Breach erlebt haben - und 96 % gaben an, diesen mit besseren identitätsfokussierten Sicherheitsmaßnahmen hätten verhindern oder minimieren können.

Was JIT Access wirklich bedeutet

Just-in-Time Access ist kein Produkt-Feature, sondern ein Governance-Prinzip: Zugriff wird nur dann gewährt, wenn er gebraucht wird, nur für die Dauer der Aufgabe, und automatisch entzogen, wenn die Aufgabe abgeschlossen ist.

Das Ziel ist Zero Standing Privilege (ZSP): ein Zustand, in dem keine Identität dauerhaft erhöhte Rechte hält. BeyondTrust schätzt, dass ein JIT-Zugriffsmodell privilegierte Bedrohungsfenster und Angriffsflächen um mehr als 90 % reduzieren kann.

Der typische JIT-Workflow sieht so aus:

Entscheidend: JIT ist kein Ersatz für Governance, sondern ein Teil davon. Der Timer allein schafft keine Sicherheit. Sicherheit entsteht, wenn Genehmigung, Provisionierung, Entzug und Audit über den gesamten Zugriffspfad hinweg greifen.

Das blinde Fleck: Nicht-menschliche Identitäten

Hier liegt das eigentliche Problem vieler JIT-Programme: Sie denken nur an Menschen.

Laut dem Non-Human Identity Security Report 2024 erkennen 88,5 % der Unternehmen an, dass ihre NHI-Governance-Praktiken hinter dem Stand ihrer menschlichen IAM-Maßnahmen zurückbleiben oder bestenfalls gleichauf sind. Dabei sind nicht-menschliche Identitäten - Service Accounts, API Keys, OAuth Tokens, CI/CD-Pipeline-Identitäten, AI Agents - in den meisten Umgebungen längst in der Überzahl.

In den meisten Unternehmen übersteigen Machine Identities die Anzahl menschlicher Nutzer um den Faktor 10:1 oder mehr. Und sie werden mit Standing Privilege betrieben, die niemand regelmäßig überprüft.

Das Muster ist bekannt: Service Accounts erhalten beim Setup übermäßige Berechtigungen, weil es einfacher ist als die Mindestberechtigungen zu ermitteln. Diese Berechtigungen werden nie reduziert. Der Account läuft 24/7 mit Admin-Rechten. Niemand bemerkt es - bis ein Angreifer ihn übernimmt.

JIT für nicht-menschliche Identitäten funktioniert nach demselben Prinzip: Wenn eine Deployment-Pipeline erhöhte Berechtigungen benötigt, stellt sie eine Anfrage über einen Approval-Workflow, erhält temporäre Credentials, führt das Deployment durch - und verliert die erhöhten Rechte automatisch, wenn die Aufgabe abgeschlossen ist. Kein Standing Privilege, kein dauerhafter Blast Radius.

JIT in der Praxis: Was wirklich funktioniert

Theorie ist einfach. Die Umsetzung scheitert oft an drei Stellen:

1. Fehlende Inventarisierung Man kann keinen JIT-Workflow für Accounts aufbauen, die man nicht kennt. Der erste Schritt ist immer: alle privilegierten Accounts inventarisieren - menschliche und nicht-menschliche. Directories, Datenbanken, Cloud-Ressourcen, CI/CD-Pipelines, Konfigurationsdateien. Alles.

2. Zu grobe Policies JIT funktioniert nur, wenn Policies granular genug sind. Eine Policy, die nur zwischen "Admin" und "Kein Admin" unterscheidet, ist kein JIT - das ist nur ein langsamerer Weg zum gleichen Standing Privilege. Policies müssen nach Ressource, Risikostufe, Kontext und Dauer differenzieren.

3. Unvollständiger Entzug JIT scheitert, wenn eine temporäre Berechtigung nicht vollständig aus allen nachgelagerten Systemen, gecachten Sessions oder vererbten Rollen verschwindet. Revocation muss nachweisbar über jedes System hinweg funktionieren, das das Privilege akzeptiert hat.

Warum Coverage der entscheidende Faktor ist

Hier liegt der blinde Fleck der meisten JIT-Implementierungen: Sie decken nur einen Teil des Stacks ab.

Viele Tools implementieren JIT für die SCIM-fähigen Apps - und lassen den Rest des Stacks unberührt. Das bedeutet: GitHub, Jira, Notion, Figma, Slack, Linear und Dutzende weitere Tools, die täglich genutzt werden, laufen weiterhin mit Standing Privilege. Der Audit Trail endet dort, wo die SCIM-Integration aufhört.

Das ist kein JIT. Das ist eine Illusion von Kontrolle.

Echte Zero-Standing-Privilege-Governance erfordert Coverage über den gesamten Stack - unabhängig davon, ob eine App SCIM unterstützt, eine API anbietet oder weder noch. Und sie erfordert granulare Kontrolle: nicht nur auf App-Ebene, sondern auf Channel-, Repository- und Projektebene.

Genau hier setzt Iden an. Als IGA-Plattform mit universeller App-Coverage - SCIM, API oder keines von beidem - stellt Iden sicher, dass JIT-Policies und Access-Governance nicht an der Grenze Ihres SCIM-Setups enden. Kein SCIM-Tax, kein Enterprise-Plan-Upgrade erforderlich, um die Apps zu automatisieren, die Ihr Team täglich nutzt. Und fine-grained Control bis auf Channel-, Repo- und Projektebene - tiefer als SCIM es je erlauben würde.

Die Implementierungs-Checkliste

Kein Artikel über JIT Access ist vollständig ohne eine konkrete Vorlage. Hier ist die Checkliste, die IT-Teams als Ausgangspunkt nutzen können:

Phase 1: Inventarisierung (Woche 1-2)

• Alle privilegierten Accounts inventarisieren: Directories, Datenbanken, Cloud-Ressourcen, CI/CD-Pipelines, Konfigurationsdateien
• Nicht-menschliche Identitäten separat erfassen: Service Accounts, API Keys, OAuth Tokens, Bot Accounts, AI Agents
• Für jeden Account dokumentieren: Wer ist Owner? Wann wurde er zuletzt genutzt? Welche Berechtigungen hält er?
• Accounts ohne klaren Owner oder ohne nachweisbare Nutzung in den letzten 90 Tagen markieren

Phase 2: Policy-Design (Woche 3-4)

• Risikostufen definieren: Niedrig / Mittel / Hoch / Kritisch - nach Ressource und Datensensitivität
• TTL pro Risikostufe festlegen (z. B. Niedrig: 8h, Mittel: 4h, Hoch: 1h, Kritisch: 30min)
• Approval-Workflows pro Risikostufe konfigurieren: Auto-Approve / Self-Service / Manuelle Freigabe
• Break-Glass-Prozeduren dokumentieren: Wer darf im Notfall eskalieren, und wie wird das protokolliert?
• MFA-Anforderung am Punkt der Elevation (nicht nur beim Login) definieren

Phase 3: Rollout (Woche 5-8)

• Mit kritischen Systemen beginnen, nicht mit dem gesamten Stack auf einmal
• Pilot mit einem Team oder einer Abteilung durchführen, Feedback einholen
• Logging und Monitoring konfigurieren: Jede Anfrage, Genehmigung, Nutzung und Entzug muss unveränderlich protokolliert werden
• Revocation-Prozesse testen: Wird der Zugriff wirklich aus allen nachgelagerten Systemen entzogen?

Phase 4: Kontinuierliche Governance

• Regelmäßige Reviews der JIT-Policies (mindestens quartalsweise)
• Anomalie-Detection für ungewöhnliche Anfragemuster einrichten
• Audit-Evidenz für SOC 2 / ISO 27001 automatisch generieren und aufbewahren
• Non-Human Identities in denselben Review-Zyklus einbeziehen wie menschliche Nutzer

Das Ziel: Audit-Ready, nicht nur sicher

JIT Access ist nicht nur ein Sicherheitsgewinn - es ist ein Compliance-Gewinn. Da ein gut implementiertes JIT-System jeden Schritt - Anfrage, Genehmigung, Nutzung, Entzug - in einem unveränderlichen Audit Trail protokolliert, ist es für Forensik und Compliance-Nachweise erheblich wertvoller als periodische Access Reviews.

ISO 27001:2022 verlangt, dass privilegierter Zugriff mindestens alle sechs Monate überprüft wird. SOC 2 erwartet periodische Reviews mit dokumentierten Ergebnissen. Beides lässt sich mit JIT-Workflows und automatisch generierter Evidenz deutlich einfacher nachweisen als mit Spreadsheets und manuellen Zertifizierungskampagnen.

Der entscheidende Unterschied: Standing Privilege erzeugt Risiko, das Sie im Nachhinein erklären müssen. JIT Access erzeugt Evidenz, die Sie proaktiv vorlegen können.

Wer heute mit JIT Access beginnt, baut nicht nur eine sicherere Umgebung - er baut eine, die beim nächsten Audit nicht ins Schwitzen gerät.