They cannot prove why an application allowed or denied a tenant- or resource-level action. IdP data shows identity events such as login and MFA, but it does not explain policy evaluation, resource scope, or the boundary that held. That leaves reviewers with authentication evidence but incomplete authorization evidence.
Why IdP Logs Are Not Enough for Access Review Evidence
IdP logs prove that an identity authenticated and may show MFA or federation events, but they do not explain the authorization decision the application made. For an access review, that gap matters because reviewers need evidence about policy evaluation, resource scope, and whether the application or API boundary actually allowed the action.
That is why relying only on IdP logs can produce a false sense of assurance. You may be able to confirm who signed in, but not whether the user was entitled to the tenant, workspace, record, or function that was used. The control failure is not the login event, it is the missing authorization context.
When the access decision is tenant- or resource-specific, the review must account for application-side entitlements, scoped tokens, role evaluation, and any conditional logic that changed the outcome. Without that, the reviewer can prove presence at the door but not what the application let that person do after entry.
What Evidence the Reviewer Actually Needs
IdP telemetry is one input, not the full audit trail. A complete review needs the evidence chain that connects authentication to authorization: the identity that authenticated, the scope or role presented, the policy or entitlement evaluated, and the resource or tenant boundary that was enforced.
That distinction becomes more important when one identity can reach multiple tenants, applications, or datasets. In those cases, a sign-in event tells you almost nothing about whether the action was allowed for a specific resource, especially if authorization depends on app-local roles, claims, group membership, or context that never appears in the IdP log.
Practically, the missing record is often in the application, gateway, API, or resource layer. If those systems do not emit decision logs, reviewers end up inferring authorization from authentication, which is an audit shortcut rather than a defensible control.
How to Rebuild the Review Trail
Use IdP logs as the starting point, then join them to the application or resource logs that show the permission decision. For many teams, that means correlating login, token issuance, role assertion, policy evaluation, and the final allow or deny result for each sensitive action.
The strongest review model is the one that can answer three questions for each sampled access path: who authenticated, what scope or privilege was presented, and why the target system allowed the action. If any of those three is missing, the review may still be useful, but it is not complete evidence of authorization.
- Confirm the application can log allow and deny decisions at the resource or tenant boundary.
- Verify the review sample includes the entitlement or role actually used, not just the login event.
- Retain enough context to show whether the action depended on policy, group membership, or a scoped token.
Risk and Threat Considerations
When teams over-rely on IdP logs, they can miss unauthorized access that occurs after a legitimate sign-in. That creates audit blind spots, especially where privilege is determined inside the application, where tokens carry broad scope, or where tenant boundaries are enforced inconsistently.
Failure mechanism: Authentication evidence is mistaken for authorization evidence, so reviewers cannot reconstruct the actual decision path that permitted or denied the action. Attackers and insider misuse benefit from that gap because a valid login can conceal excessive scope, broken authorization, or policy drift in the downstream system.
Impact: Access reviews may approve access that should have been removed, miss overbroad entitlements, or fail to detect abuse of legitimate sessions. Over time, that weakens recertification, hides privilege creep, and reduces confidence in the review process itself.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Access review evidence depends on logged authorization decisions. |
| AU-12 — Audit Record Generation | The question turns on whether systems record enough context to explain allow/deny outcomes. | |
| AC-2 — Account Management | Access reviews assess whether accounts retain appropriate entitlements over time. | |
| Recommendation — Log resource-level allow and deny events needed to support recertification. Generate audit records that capture the policy and scope behind each access decision. Review and remove unnecessary account access based on current entitlement evidence. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The issue is whether access decisions are governed and evidenced at the right layer. |
| A.8.15 — Logging | Reviewers need logs that show authorization outcomes, not only authentication events. | |
| Recommendation — Define access control evidence requirements across IdP and application layers. Ensure logs record authorization-relevant events for review and investigation. | ||
Practitioner Guidance
What to verify: For each high-risk application, verify that you can produce both authentication evidence and authorization evidence for the same access path. If the IdP cannot explain the resource decision, treat the application log, API log, or policy engine output as required review evidence, not optional enrichment.
Common mistake: Teams often sample only successful sign-ins because the data is easy to obtain. That misses the more important question for access review, which is whether the user was entitled to the specific tenant, resource, or function at the time the action occurred.
Practitioner takeaway: A good access review proves more than identity presence. It should let you reconstruct the authorization decision that the application made, or else you are reviewing authentication history, not access.