In AWS IAM, what is the credential report, and how would you use it to answer "which IAM users still hold stale long-lived credentials, and is MFA enabled on the root user?"

## What the report is The IAM credential report is a single, account-wide CSV snapshot of the state of every long-lived credential in the account. It is not a log and not a stream of events — it is a point-in-time inventory. AWS builds it on request and caches it, so it is the fastest way to answer questions of the shape "across this whole account, who has what, and when did they last use it?" ## Getting it Two API calls. `GenerateCredentialReport` kicks off the build and returns a state (`STARTED` or `COMPLETE`); `GetCredentialReport` returns the CSV, base64-encoded in the `Content` field, along with a `GeneratedTime`. On the CLI: ```bash aws iam generate-credential-report aws iam get-credential-report --query Content --output text | base64 --decode ``` AWS regenerates the report at most once every four hours. If you call `GenerateCredentialReport` again inside that window you get the cached copy, so the freshest report you can ever hold may describe the account as it was up to four hours ago. That is fine for hygiene sweeps and wrong for incident response — during an incident you want CloudTrail, not a cached inventory. ## What is in a row One row per IAM user, plus one synthetic row whose `user` column is `<root_account>`. The columns worth knowing: - `password_enabled`, `password_last_used`, `password_last_changed`, `password_next_rotation` — console-login state and age. - `mfa_active` — whether the identity has an MFA device attached. This is the column people actually open the report for, because the root row tells you in one glance whether the account's most dangerous identity is protected. - `access_key_1_active` / `access_key_2_active` — an IAM user can hold at most two access keys, which is exactly why rotation is a two-slot dance: create the second key, roll consumers onto it, confirm the first has stopped being used, then delete it. - `access_key_N_last_rotated` — when the key was created. This is your age signal. - `access_key_N_last_used_date`, `..._last_used_service`, `..._last_used_region` — when and against what the key was last used. A value of `N/A` means the key has not been used since AWS began tracking, which usually means never. - `cert_1_active` / `cert_2_active` — signing certificates, a legacy surface most accounts should show as false. ## Reading it for the two questions asked For stale credentials, the useful predicate combines two columns, not one. A key that is `active` and was `last_rotated` two years ago is an age problem. A key that is `active` and shows `N/A` for `last_used_date` is a different and often worse problem: nothing depends on it, so nobody will notice if an attacker starts using it. Both are deletion candidates; the unused one is the easy win because removing it cannot break a caller. For root MFA, read `mfa_active` on the `<root_account>` row. While you are there, `access_key_1_active` on that same row should be `false` — root access keys are a finding on their own, since they cannot be constrained by IAM policy and, in the organization's management account, are not constrained by service control policies either. ## What it does not cover The report is about long-lived credentials attached to IAM *users*. Roles do not appear in it at all, and in a well-built account most access is roles assumed through federation, so an empty-looking credential report is a good sign rather than a complete picture. For roles you need a different evidence source: service last-accessed data tells you which services a role's permissions were actually used against, IAM Access Analyzer's unused-access findings surface roles nobody has assumed, and CloudTrail is the underlying record of individual calls. It also says nothing about *what* a user is permitted to do. `mfa_active = false` on a user with read-only access to one bucket and on a user with `AdministratorAccess` look identical in the CSV. Pair the report with the policies attached to each row before you rank findings, or you will spend your remediation effort on the harmless users. ## Where it fits Treat the credential report as the recurring hygiene sweep: run it on a schedule, diff it, and drive three metrics to zero — root access keys, users without MFA, and active keys older than your rotation policy. It is cheap, needs only `iam:GenerateCredentialReport` and `iam:GetCredentialReport`, and it is the artifact an auditor will ask for by name.