# Interpret IAM last-accessed records as attempts with coverage limits

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

- Canonical URL: https://update.dsesecurity.com/updates/interpret-iam-last-accessed-records-as-attempts-with-coverage-limits/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-10-20T18:13:33+00:00
- Modified: 2026-10-20T18:34:28+00:00
- Last reviewed by DSE: 2026-10-20
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, IT
- Reading time: 2 minutes

## What you need to know

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

## Potentially affected

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.

## Article

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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_last-accessed.html).

## 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_last-accessed.html). Reviewed October 20, 2026.

## Primary reference

- Name: AWS Documentation
- Authority: docs.aws.amazon.com
- URL: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_last-accessed.html
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Interpret IAM last-accessed records as attempts with coverage limits,” DSE Security, https://update.dsesecurity.com/updates/interpret-iam-last-accessed-records-as-attempts-with-coverage-limits/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.