Security Information and Event Management (SIEM)
Security Information and Event Management (SIEM) collects, normalizes and correlates log events from across an organization's systems, and keeps them as the record that investigations and audits are answered from. For an IAM team it is where identity telemetry has to arrive in usable form: sign-ins, token issuance, directory and entitlement changes, privileged sessions, and changes to the identity systems' own configuration. What the SIEM can detect and prove about identities is decided less by the SIEM than by choices the IAM team makes: which events each identity system emits, which identifier ties an event to a person or a workload, and how long the events are kept.
The Events an IAM Team Owns
Security operations can collect whatever a system writes, but only the IAM team knows which identity events matter and what a complete one looks like. Five groups cover most of it. Authentication events record each sign-in, successful or not, with the factor used and the assurance it gave, so that a password-only sign-in to an account that normally uses a passkey stands out. Session and token events record what the sign-in produced: a session established, a token issued to a named client with named scopes, a refresh, a revocation. Lifecycle and entitlement events record accounts created, disabled and deleted, and group memberships and role assignments added or removed. Privileged access events come from session management and credential vaults: who checked out which credential, and which privileged session started and ended. The fifth group is the one most often missing, and it gets its own section below: changes to the configuration of the identity systems themselves.
For each event, the fields decide what can be done with it later. It needs the subject the action was about, the actor who performed it where the two differ (an administrator resetting someone's password, or a service acting on a user's behalf through token exchange, which RFC 8693 records in the act claim), the client or application, the session, the source address and device where known, and the outcome. A change event should also carry the reference of the request that authorized it, since that reference is what separates an approved grant from one made out of band. The OWASP Logging Vocabulary Cheat Sheet gives a common set of event names for authentication, authorization and user management, which is a useful starting point for applications the organization writes itself.
Some values must never reach the log. Passwords are the obvious case, and the OWASP Logging Cheat Sheet adds session identifiers and access tokens, which anyone with read access to the SIEM could replay. Log a token's identifier (its jti) or a hash instead. The SIEM holds a copy of the organization's identity activity, and its readers should not be able to become the users they are reading about.
One Person, Many Identifiers
Correlation fails most often on identifiers. The identity provider logs a user by an internal object ID, the directory by a login name, a SaaS application by email address, and a SAML application by whatever NameID it was configured with. OpenID Connect makes it harder by design: a pairwise subject identifier gives the same user a different sub at each client, so that applications cannot track users across each other, and the application's own log cannot be joined to another's on that value. A rule that should fire on "same person, three systems, ten minutes" sees three unrelated accounts.
The mapping from account to person is identity data, and the IAM team already maintains it in the directory and the identity governance system. The SIEM needs it as an enrichment table: for every account, the person or owner it belongs to, whether it is a human, service or agent account, whether it is privileged, and the owner's employment status. Workload and machine identities need an owner in that table as much as people do, because an alert on a service account with no owner goes to nobody.
Enrichment at ingestion and lookup at query time give different answers, and audits need the first. An auditor asking who held an administrator role in March, and whether they were still employed, needs the identity context as it was in March. A lookup against today's directory returns today's owner, department and status. Writing the relevant attributes into the event when it is stored keeps the record accurate after people move, and after accounts are deleted.
Normalization then puts every source into one schema, so that a rule written once runs against all of them. The Open Cybersecurity Schema Framework (OCSF), an open-source project, defines an Identity & Access Management category with classes for authentication, account changes, session authorization and group management. Which schema is chosen matters less than mapping every source consistently to subject, actor, action, target and outcome, and keeping all timestamps in UTC from synchronized clocks. Where two sources disagree by a few minutes, a sign-in and the privilege change that followed it can appear in the wrong order.
The Identity Systems' Own Audit Trail
The events with the most value per byte are changes to the identity infrastructure: a new federation trust or identity provider, a token-signing certificate added, a multi-factor authentication (MFA) policy relaxed, an exclusion added to a conditional access rule, an administrator role assigned, a credential added to an application registration. These are the changes an attacker makes to stay in after a password reset, and MITRE ATT&CK catalogues them as Trust Modification (T1484.002), Modify Authentication Process (T1556) and Additional Cloud Credentials (T1098.001). They are rare, so they produce little volume, and almost every one of them deserves a look.
They are also the events most often left out. Cloud identity services keep their administrative audit log inside the service, often for a limited period set by the subscription, and nobody forwards it because it is not a "security log" in the sense a network team means. The IAM team is the one that knows these logs exist and what the entries mean, so connecting them is its job.
The same logs need protection from the people they record. An identity administrator who can alter the identity provider's configuration and also delete the SIEM's copy of that change can remove the evidence of both. Forwarding in near real time, storing without the ability to modify, and keeping SIEM administration separate from identity administration close that gap. NIST SP 800-53 states the last one as a control of its own: access to audit functions limited to a defined subset of privileged users (AU-9(4)).
Detections That Need Identity Context
With identity context attached, a SIEM can raise alerts that no single system can. A sign-in by an account whose owner left the organization yesterday is ordinary to the application and conclusive to anyone holding the leaver date. A group membership added directly in the directory, with no request reference that matches the governance system, is a grant that bypassed approval, whether an attacker made it or an administrator in a hurry. A service account that signs in interactively, a burst of declined MFA prompts followed by one approval (MFA Request Generation, T1621), and a session identifier seen from two devices in different countries each need to know what kind of account it is, or what the session was bound to. Device Bound Session Credentials make the last one rarer, and the attempt more telling when it still appears. For agents, the signal is an action whose delegating principal is missing or does not match the task, which is only visible when both identities are in the event.
Identity Threat Detection and Response (ITDR) covers similar ground from a different position. It reads identity systems directly, understands their protocols and keeps behavioural baselines. The SIEM holds the retained record across every domain, identity and otherwise. Where both exist, ITDR's findings should arrive in the SIEM as events, so an incident has one timeline and one retention policy. Events from the Shared Signals Framework (SSF) belong there for the same reason: a session revocation next to a run of failed sign-ins reads differently from either alone. What a detection starts is the business of SOAR, and every action a playbook takes should come back into the SIEM with its case reference, so the record shows the response as well as the attack.
Retention and What the Auditor Asks
Auditors ask identity questions of the SIEM: who held privileged access on a given date and what they did with it, whether a leaver's access was removed and not used afterwards, who approved a particular grant. Answering them needs the events of the whole audit period, plus the time it takes for an investigation to start after an attacker got in. That is why regulated sectors write a minimum down; PCI DSS, for example, asks for twelve months, the most recent three immediately available for analysis.
Retention differs by event group. Changes to identity configuration and privilege assignments are low in volume and high in audit value, and belong in the longest tier. Successful routine sign-ins are high in volume and mostly useful for detection and short investigations, so a shorter hot period followed by cheaper storage fits them. Writing the period and its reason down for each group turns retention from a storage budget into an answer an auditor accepts.
Identity logs are personal data, so the limit runs in both directions: under the GDPR, a log kept "just in case" needs a purpose and an end date as much as a minimum. In Germany, a SIEM that analyses employee behaviour also needs the works council's agreement, which usually settles which events may be used for what and who may resolve pseudonymized data to a person. Agreeing it before behavioural rules go live is faster than stopping them afterwards.