Der Leitfaden beschreibt IAM-Compliance als Sammelpunkt unterschiedlicher Vorgaben: regulatorische Anforderungen, Branchenstandards und interne Governance-Regeln formulieren ähnliche Prinzipien für Zugriffskontrolle, Authentifizierung und Rechenschaftspflicht in unterschiedlicher Sprache. Nachhaltiger sei es, IAM-Kontrollen einmal auf diese Rahmenwerke abzubilden und die daraus entstehenden Nachweise mehrfach zu nutzen, statt jede Prüfung als isolierte Aufgabe zu behandeln.
Wiederkehrend verlangen diese Rahmenwerke Nachweise darüber, wer wann worauf zugegriffen hat. Als Beispiele nennt der Text PCI DSS Anforderung 10 und die Kontrollfamilie AU aus NIST SP 800-53. Entscheidend sei dabei nicht nur, dass Protokolle vorhanden sind, sondern dass sie den tatsächlichen Ort der Durchsetzung abdecken. Viele Organisationen bewahrten nur Protokolle des Identitätsanbieters auf, während Aktivitäten auf Anwendungsebene unbeobachtet blieben. Wenn Angreifer legitime Zugangsdaten nutzen, können diese Protokolle unauffällig wirken; alleinige Telemetrie des Identitätsanbieters zeigt laut dem Leitfaden meist nicht, was eine Identität innerhalb der Anwendung tatsächlich getan hat.
Der Text leitet daraus konkrete Anforderungen an die Ausgestaltung von IAM-Programmen ab. Rollenbasierte Zugriffskontrolle soll Berechtigungen an Aufgaben ausrichten, damit Zugriffe nicht durch Ausnahmen immer weiter anwachsen. Geringstmögliche Rechte und Funktionstrennung zählen demnach zu den Kontrollen, die Auditoren besonders genau prüfen. Maßgeblich ist jedoch nicht die Rollenbeschreibung selbst, sondern der Nachweis, dass sie überall durchgesetzt wird, auch in Anwendungen mit eigenen lokalen Berechtigungen.
Ähnlich bewertet der Leitfaden starke Authentifizierung. Multi-Faktor-Authentifizierung und bedingter Zugriff erhöhen die Hürden für den Missbrauch von Zugangsdaten und sind deshalb in nahezu allen Rahmenwerken für sensible Zugriffe vorgesehen. Die eigentliche Compliance-Frage sei aber die Abdeckung: Eine beim Identitätsanbieter erzwungene MFA verliere ihren Wert, wenn eine Altanwendung direkte lokale Anmeldungen akzeptiert und sie damit umgeht.
Breiten Raum nimmt das Joiner-Mover-Leaver-Modell ein. Es soll sicherstellen, dass Zugriffsrechte Beschäftigungs- und Rollenwechseln folgen. Der Leitfaden nennt als typisches Versagen, dass das zentrale Konto eines ausgeschiedenen Auftragnehmers deaktiviert wird, während lokale Zugänge in Anwendungen aktiv bleiben. Reife Lebenszyklussteuerung arbeite deshalb ereignisgesteuert statt prüfungsgetrieben: Bereitstellung und Entzug von Zugriffsrechten werden durch autoritative Ereignisse in verbundenen Systemen ausgelöst, nicht erst bei der nächsten turnusmäßigen Kontrolle.
Dasselbe fordert der Text für nicht-menschliche Identitäten. Servicekonten und Automatisierungszugänge brauchen demnach einen Eigentümer, einen Zweck, ein Ablaufdatum und Überwachung. Solche Maschinenidentitäten würden durch Infrastrukturautomatisierung häufig außerhalb der an Personalprozessen orientierten Lebenszyklussteuerung entstehen.
Als typische Schwachpunkte nennt der Leitfaden schleichende Berechtigungsausweitung, überprivilegierte Konten, Lücken bei Privileged Access Management und unzureichend abgegrenzte Zugriffsprüfungen. Besonders problematisch seien Prüfungen, die nur an das IdP angebundene Systeme einbeziehen oder bestehende Rechte lediglich abnicken. Wo lokale Konten von Altanwendungen nicht erfasst werden, entsteht erneut „Identitäts-Dunkelmaterie“, also ein Bereich ohne belastbare Governance und ohne belastbaren Audit-Nachweis.
Abhilfe soll Automatisierung schaffen. Laut Leitfaden verschiebt sie IAM-Compliance von periodischer manueller Bestätigung hin zu kontinuierlicher Verifikation, reduziert menschliche Fehler und verkürzt die Zeit zur Nachweiserhebung. Automatisierte Bereitstellung belegt, dass Zugriff korrekt vergeben wurde; Überwachung zeigt, dass dies so bleibt. Kontinuierliche Durchsetzung von Richtlinien erkennt Abweichungen zwischen beabsichtigtem Zugriff und tatsächlichem Zustand, bevor sie zu Audit-Feststellungen werden.
Als Beispiel für einen Anbieter dieser Kategorie nennt der Text Orchid Security. Die Plattform verlasse sich nicht allein auf Konfigurationsdaten des IAM, sondern erfasse Identitäten direkt aus Anwendungen und Infrastruktur, mache Identitäts-Dunkelmaterie sichtbar und ordne Identitätskontrollen aktiven regulatorischen Anforderungen zu. Dadurch entstünden auditfähige Nachweise auf Grundlage beobachteter Durchsetzung. Für den Leitfaden ist genau das der Kern: IAM-Compliance ist vor allem ein Problem der Integrität von Nachweisen, bei dem nicht die dokumentierte Absicht zählt, sondern die in laufenden Systemen belegbare Umsetzung.