Interpret IAM last-accessed records as attempts with coverage limits

Use access history to investigate permissions without equating every entry with success.

Source facts

IAM service last-accessed information includes attempted API access, including denied attempts. Action-level history covers supported management actions rather than data-plane events, and iam:PassRole is not tracked there. AWS directs administrators to CloudTrail for evidence about API calls and whether they succeeded or were denied.

Source: AWS Documentation.

Applicability

This applies when reviewing IAM permissions using last-accessed reports, especially before removing apparently unused permissions.

DSE recommendation

DSE recommends recording the report scope and collection period before interpreting an entry. Correlate unexpected activity with the relevant audit event instead of treating it as proof of successful access or compromise. Ask application owners about periodic, recovery and emergency operations before narrowing a policy. Keep a proposed removal small enough to validate, with the prior policy available. Document known coverage gaps so a later reviewer does not interpret absence in this report as evidence that a capability is unnecessary. Label every proposed removal with the evidence available and the important operation still needing owner confirmation. Keep infrequent disaster-recovery actions in a separate review queue so a quiet reporting period does not become the sole reason to remove them.

Verification

Proposed verification: compare a selected last-accessed entry with its audit evidence and confirm the action is within documented coverage. Pilot any approved permission removal against normal and recovery workflows. Retain the owner decision and observed behavior with the revised policy.

Official reference

AWS Documentation. Reviewed October 20, 2026.