IAM building block · 2 min read
Audit: knowing who did what
Short answer
Identity audit means recording authentication, authorization and administrative events in a tamper-resistant, searchable form, regularly reviewing who has which access, and keeping evidence that controls such as MFA, deprovisioning and separation of duties actually worked.
Key takeaways
- Log sign-ins, failures, MFA events, token issuance, admin changes and consent grants, centrally.
- Access reviews work when they are small, specific and lead to automatic removal.
- Never log secrets: passwords, tokens and full assertions do not belong in logs.
Audit closes the loop in IAM. Without it, you cannot investigate an incident, show a regulator that controls work, or notice that access has drifted. It also makes the other building blocks honest: a provisioning process that "always" removes leavers looks different once you compare it with the logs.
What should be logged?
Every event that changes who can do what, and every attempt to use that access.
| Event | Source | Why |
|---|---|---|
| Successful and failed sign-ins | IdP | Attacks, compromised accounts |
| MFA enrollment, removal, recovery | IdP | Takeover often starts here |
| Token issuance and refresh | Authorization server | Unusual clients, volumes |
| Admin role changes | IdP, apps, cloud consoles | Privilege escalation |
| OAuth consent grants | IdP | Third-party apps reaching data |
| Federation configuration changes | IdP | New trust, new certificates |
| Provisioning actions | IGA, SCIM logs | Joiner, mover, leaver evidence |
Include who, what, when, from where (IP, device), the result and a correlation ID. Exclude secrets: no passwords, no full tokens, no complete SAML assertions. If you need to reference a token, log its jti or a hash. When debugging assertions, decode them locally with the SAML Decoder rather than pasting them into tickets.
How do access reviews work?
Owners periodically confirm or revoke each person's access, and the decisions are carried out and recorded.
Make reviews workable:
- Review privileged access more often (quarterly) than ordinary access (yearly).
- Show context: last use, role, peers' access, the reason it was granted.
- Keep each review small enough to finish in a sitting.
- Revoke automatically on "no" or on no answer, after warnings.
A review that is rubber-stamped is evidence of a weak control. Track the revoke rate; zero over many cycles is a warning sign.
What do auditors ask for?
Evidence that policies exist and that controls operated: samples of joiners and leavers, review records, MFA coverage, admin access lists and log retention.
Typical requests: the list of users with admin rights and who approved them; leavers from the period and the date their access ended; MFA enforcement settings and exceptions; completed access reviews with outcomes. Automate these reports where you can.
How does audit connect to real-time response?
Through alerting and event sharing, so an identity signal leads to action within minutes.
Send identity logs to your SIEM and alert on high-value patterns. The OpenID Foundation's Shared Signals specifications, including CAEP and RISC, let identity providers and applications exchange security events such as session revocation or credential compromise in near real time. For the lifecycle side, see the provisioning guide.
Questions
How long should identity logs be kept?
It depends on regulation and your incident response needs. Many organizations keep detailed logs for at least one year and summaries longer. Check sector rules and privacy law, which can also limit retention.
What is separation of duties?
A control that prevents one person from holding two conflicting permissions, such as creating a vendor and approving payments to it. IGA tools can check for these combinations when access is requested and during reviews.